Offener Brief an die Redaktion der Financial Times Deutschland:
Sehr geehrter Jörn Petring,
aktuell findet sich unter ftd.de ein Artikel von Ihnen, der den Eindruck erweckt, die Verwendung von Opensource-Software in eigenen Softwareprodukten stelle ein unkalkulierbares Risiko dar. Dieser Eindruck ist falsch: Das Risiko ist nicht größer als bei der Verwendung kommerzieller Komponenten, oft lassen sich Entwicklungskosten minimieren und die “doppelte Erfindung des Rades” vermeiden. Damit die positiven Kosteneffekte zum Tragen kommen, ist aber wie bei jeder Entwicklung — sei es nun Software, Hardware, ein Auto, ein Computerchip oder ein Toaster — eine Planung des Entwicklungsprozesses notwendig. Ich möchte daher auf einige Punkte Ihres Artikels eingehen, die einer Präzisierung bedürfen oder sich aus meiner Sicht einfach als falsch darstellen.
Sie schreiben: Wer kostenlose Software für kommerzielle Zwecke verwendet, bekommmt es mit Harald Welte zu tun: Der freie Programmierer verklagt alle Unternehmen, die den Open-Source-Kodex verletzen. Das Prozessrisiko reißt eine große Lücke in die Bilanzen der Unternehmen.
Bereits in der Einleitung haben sich eine Reihe von Fehlern eingeschlichen. Harald Welte verfolgt lediglich Verletzungen seiner Urheberrechte am Linux-Kernel, der unter der relativ restriktiven Lizenz GPL steht. Bei dieser handelt sich keineswegs um einen Kodex (im Sinne einer freiwilligen Selbstverpflichtung), sondern um einen knallharten Vertrag über die Wiedervervendung von Softwarequellcodes. Die Gattung Open Source Software umfasst jedoch noch andere, weniger restriktive Lizenzen, auf die ich später noch genauer eingehen möchte. Die GPL garantiert, dass Modifikationen an einem Programm wieder im Quellcode vertrieben werden. Viele Unternehmen wählen die GPL im Falle einer “strategischen” Freigabe von Software, weil sie in diesem Fall von den Weiterentwicklungen der Konkurrenz etwas zurückbekommen.
Der Punkt des Prozessrisikos in zumindest in Deutschland relativ gut kalkulierbar: Gerichte bemessen dort Schadenersatzforderungen und Streitwerte nach den Kosten, die eine Eigenentwicklung oder ein Zukauf gekostet hätte.
Sie schreiben: “Viele Unternehmen haben Nachholbedarf. Oft wissen Manager nicht einmal, welche Bestandteile von ihren Programmierern in die eigene Software integriert wurden”, sagt Schäfer. Eine Nachlässigkeit mit fatalen Folgen. Ist der Open-Source-Anteil in der neuen Software zu groß, Experten sprechen dann von einem “abgeleiteten Werk”, greift die GPL-Lizenz für die gesamte neue Software, was bedeutet, dass der komplette Quelltext frei zugänglich gemacht werden muss. “Damit wäre die Software nicht mehr kommerziell zu vertreiben”, sagt Schäfer. Für die Entwickler ein großes Unglück
An dieser Stelle wird für den Leser den Eindruck erweckt, ein großes, komplexes Softwareprodukt müsse komplett im Quellcode offengelegt werden. Diese Aussage muss differenziert werden: Die auf Open-Source-Programmen basierende Betriebssoftware vieler Geräte wie DSL-Router (auf die sich Welte besonders konzentriert) oder Linux-basierter DVD-Player besteht aus einer Vielzahl von Komponenten, die oft aus unterschiedlichsten Quellen stammen und unterschiedlichsten Lizenzen unterliegen. Vermischt man diese nicht, beispielsweise indem offene und geschlossene Komponenten in einer einzigen Binärdatei zusammengefasst werden, sind die freizugebenden Komponenten schnell identifiziert. Im erwähnten Beispiel von DSL-Routern handelt es sich meist um den Linux-Kernel und ein Universal-Systemwerkzeug namens BusyBox, die in der Regel nur marginal abgeändert werden. Die Freigabe dieser Komponenten steht einem kommerziellen Vertrieb eines gesamten Produktes meist nicht im Weg. Denn mit einem nackten Kernel und einigen Kommandozeilenwerkzeugen kann die Konkurrenz oft wenig anfangen (siehe bspw. Motorola).
Sie schreiben: Weltes Warnschuss hat schon gewirkt: Erste Unternehmen zittern vor der Vernichtung ihrer Bilanzwerte, andere wittern ein großes Geschäft. Die Firma Black Duck hat sich darauf spezialisiert, Software im Auftrag von Unternehmen zu scannen. “Unsere Kunden wollen sichergehen, dass ihre Software in Ordnung ist. Regelmäßig finden wir dann Sachen, die die Leute richtig blass werden lassen”, sagt Stefan Just von Black Duck. Konzerne wie SAP und Siemens schienen ebenfalls verunsichert und haben sich laut Just bereits von Black Duck beraten lassen.
Die Erwähnung von Black Duck bringt uns zum eigentlichen Punkt meiner Kritik, denn Sie erwähnen nicht, dass Black Duck auf Wunsch nach jeder Art von unrechtmäßig oder zweifelhaft in die eigenen Quellcodes gerutschten Code-Fragmenten scannt. Black Duck beschränkt sich keinesfalls auf die Verletzungen freier Lizenzen.
Ihr Artikel sollte eigentlich vor den generellen Risiken einer schludrigen Verwaltung und Versionierung von Quellcodes warnen, schließlich kommt es auch häufig vor, dass Entwickler eigene Code-Bibliotheken pflegen und oft gar nicht wissen, dass die Rechte daran ihr vorheriger Arbeitgeber hält. Ebenfalls häufig kommt es vor, dass einst lizenzierte Bibliotheken weiterverwendet werden, obwohl die Lizenzverträge ausgelaufen sind. Black Duck kann — in wessen Auftrag auch immer — nach derartigem Code suchen. Verletzungen freier Lizenzen sind daneben leichter während der Entwicklungsphase festzustellen, einen echten Super-GAU bedeutet es dagegen, wenn ein Konkurrent Wind von einer Verletzung seiner Rechte bekommt und bis zur Veröffentlichung des Produktes des “Verletzters” wartet, bis er ihn mit Klagen überzieht.
Wird dagegen eine Verletzung von Lizenzen wie der GPL oder der LGPL festgestellt, ist eine Heilung in vielen Fällen mit vertretbarem Aufwand möglich. Bei Verletzungen der LGPL ist es meist so einfach, darauf zu achten, dass die betreffende Komponente erst zur Laufzeit geladen wird, bei Verletzungen der GPL kann in vielen Fällen der betreffende Code in eine eigene Binärdatei ausgelagert werden, die dann einfach über das System aufgerufen wird. Das ist der Fall in der von mir festgestellten mutmaßlichen Verletzung der GPL durch die Integration einer Funktionen der BusyBox in die Firmware des LaCie-Medienplayers, wo die Funktion zum Einbinden der Festplatte wohl einfach kopiert wurde. Offenbar wollte sich ein Programmierer ein paar Tage Arbeit sparen, die hierfür verwendete Funktion als separate Binärdatei auszulagern1.
Nun ist es nicht Aufgabe derjenigen, deren Rechte verletzt wurden, für eine Heilung des Rechtsbruchs zu sorgen. Es ist also legitim, wenn Welte das naheliegende unternimmt und das Unternehmen vor die Wahl stellt, die GPL zu respektieren oder den Vertrieb eines Produktes zu unterlassen. Für Consulting, wie ein der GPL konfirmer Aufbau eines Produktes aussehen könnte, ist es zu diesem Zeitpunkt zu spät.
Der von vielen Lesern sicher aus Ihrem Artikel herausgelesene Ratschlag, freie Software zu meiden ist daher weltftremd. Freie Software ist Fakt und viele Programmierer üben während des Studiums mit freien Bibliotheken oder durch die Mitarbeit an großen Open-Source-Projekten. Einerseits Zeitdruck auf Entwickler auszuüben und andererseits die Verwendung von freien Komponenten zu verbieten (oder das Vorhandensein freier Software zu leugnen), schließt sich gegenseitig aus. Stattdessen ist es von grundlegender Bedeutung, den Überblick über die eigene Softwareetwicklung zu behalten und Versionskontrollsysteme auch dazu zu verwenden, genutzte Komponenten (freie wie unfreie) zu inventarisieren. Nach Möglichkeit ist bereits zu Beginn einer Entwicklung herauszufinden, welche freien Komponenten Entwickler gerne integrieren würden2. Im nächsten Schritt ist dann zu identifizieren, welche Komponenten als Geschäftsgeheimnis betrachtet werden und daher keine GPL-Software enthalten dürfen und bei welchen Programmen einer Freigabe nichts im Weg steht3.
Grundsätzlich gilt, dass bei vielen Entwicklern wenig Kenntnisse über die Unterschiede der Lizenzen und die Integration in große kommerzielle Projekte herrscht, andererseits kennen viele auf Lizenzfragen spezialisierte Anwälte nicht die technischen Unterschiede zwischen der dynamischen Einbindung einer Bibliothek und der Kommunikation einer Anwendung mit einer anderen über einen Socket. Es ist daher noch viel Aufklärungsarbeit notwendig, bis die — oft nur vordergründig gegensätzlichen — Interessen von Open-Source-Community und kommerziellen Entwicklern unter einen Hut zu bekommen sind. Dass Open-Source längst Realität ist, haben Sie vollkommen richtig festgestellt, diese ist allerdings in den seltensten Fällen umkehrbar. Unternehmen sollten daher dazu animiert werden, Open Source richtig einzusetzen und Chancen und Risiken möglichst früh zu betrachten, anstatt Angst vor klagenden Programmierern zu entwickeln.
Mit freundlichen Grüßen,
Mattias Schlenker
Nachtrag, 15. August 2008:
Nachtrag, 21. August 2008:
1Für die technisch versierten Leser des Blogs: Es handelt sich um das mount-Applet der BusyBox, das separat kompiliert werden kann und sich dann weitgehend wie das mount von GNU/Linux verhält. Der Grund für die GPL-Verletzung ist also in Faulheit, Unwissenheit, Zeitdruck oder einer Kombination aus allen dreien zu suchen.
2Das Testen, ob eine Open-Source-Komponente für den eigenen Einsatzbereich taugt, erfordert übrigens keine aufwendige Freigabe: Erst wenn Binärdateien das Haus verlassen, ist der Quellcode beizulegen.
3Neben der GPL existieren weitere Lizenzen, die oft andere Handhabung des Quellcodes erfordern, LGPL-Code darf beispielsweise nur dynamisch dazugelinkt werden, erfordert aber nur die Freigabe der (modifizierten LGPL-Komponente), die BSD- oder MIT-Lizenzen erfordern dagegen keine Freigabe des Codes, aber die Nennung der Urheber in “Hilfe-Fenstern” oder im Handbuch.
Einem argentinischen Sicherheitsexperten ist es gelungen einen 
Dann reihe ich mich mal in die Schlange der Gratulanten ein. 
