Urheber auch einzelner Software-Bestandteile können solche Ansprüche geltend machen, wenn die Lizenzvorgaben vom Verwender ihrer Open Source-Software nicht eingehalten werden. Die Linux-Bestandteile stehen zu einem großen Teil unter der klassischen Open Source-Lizenz GPL (GNU General Public License).

Diese fordert unter anderem für den Fall einer Weitergabe zum Beispiel an Kunden in einem Produkt:

• das Beifügen des Lizenztextes der GPL,
• das Beifügen von Copyright-Vermerken,
• die Zurverfügungstellung von Änderungen am ursprünglichen Code ebenfalls unter der GPL und
• das Bereitstellen von hinzugefügtem eigenen Code unter der GPL, wenn ein so genanntes "derivative work" entstanden ist (Copyleft).

Deswegen muss ich also einen Ausdruck mit Lizenztexten, Copyright-Vermerken und einem Angebot zur Bereitstellung von Source Code mit meinem Geschirrspüler erhalten, wenn beispielsweise Linux mit Code unter der GPL in der Geschirrspüler-Software enthalten und dadurch mit dem Geschirrspüler an mich weitergegeben wird. Wird das versäumt, drohen aufwändige Ansprüche. Macht ein Rechteinhaber Unterlassung geltend, darf das Produkt mit dessen Code zukünftig nicht weiterverbreitet werden, ohne dass die Lizenzvorgaben eingehalten werden. Schadensersatzforderungen und Anwaltskosten stehen im Raum, häufig wird auch ein Rückruf und die Freigabe des hinzugefügten, regelmäßig proprietären Codes gefordert.

Für Linux-Bestandteile war Harald Welte von gpl-violations.org in Deutschland bereits an einigen Gerichtsverfahren beteiligt. Zum Beispiel gab es ein Verfahren von ihm als Urheber der netfilter-/iptables-Bestandteile unter der GPL gegen die FANTEC GmbH wegen eines Media Players, der diesen Code beinhaltet, ohne dass zu der Firmware auch der komplette korrespondierende Source Code bereitgestellt wurde. Dieser Verstoß wurde in einem "Hacking for Compliance-Workshop" festgestellt. Ihm geht es tatsächlich darum, dass die Bedingungen der GPL eingehalten werden und vor allem der verbundene oder veränderte Code in jedem Fall freigegeben werden muss.

Mit vergleichbaren Forderungen tritt Patrick McHardy an Unternehmen nach Testkäufen heran. Ihm wird vorgeworfen, mehr an einer finanziellen Lösung interessiert zu sein, als an der Durchsetzung der Lizenz; er wurde von dem Netfilter Core Development-Team suspendiert [4]. In einem Fall verlangte er eine Unterlassungserklärung, die für die Zukunft pauschal die Einhaltung aller Lizenzbedingungen der GPL einforderte, ohne sich lediglich auf konkrete Verstöße zu beziehen. Das macht die Compliance mit der Erklärung schwierig und Verstöße gegen sie, die hohe Vertragsstrafen auslösen können, wahrscheinlich. Daher ist im Umgang mit solchen Forderungen Vorsicht geboten. Wenn Open Source-Software eingesetzt wird, geht es in jedem Fall nicht ohne Einhaltung der Lizenzvorgaben. Das gilt nicht nur bei einer eigenen Verwendung in Produkten, es besteht auch eine Verantwortung beim Vertrieb von Produkten, die man selbst nur geliefert bekommen hat. 

Es gibt verschiedene Herangehensweisen für die Erstellung und Analyse einer so genannten "Bill of Material". In jedem Fall sollte der Entwickler eine Auflistung vorliegen haben, aus der sich ergibt, welche Open Source-Software mit welchen möglichen Dependencies eingesetzt wird und unter welcher Open Source-Lizenz diese jeweils stehen. Alternativ oder im Idealfall parallel dazu empfiehlt sich eine Prüfung des Codes eines Projektes mit einer Scansoftware.

Ein guter Überblick über den eingesetzten Code lässt sich mit einem so genannten Header-Scan der Code Base, also des in das Produkt einfließenden Codes, erreichen. Um nicht unnötig Treffer zu generieren, die später überprüft und bewertet werden müssen, sollte der "Shipping Status" geklärt sein, das heißt die Code Base sollte nur die Files enthalten, die später in das entwickelte Produkt einfließen. Für diese Header-Scans gibt es Scan-Tools, die als Open Source verfügbar sind und somit nicht erworben werden müssen. Die bekanntesten sind FOSSology und Scancode [5], die beide zuverlässig Open Source-Informationen zu dem gescannten Code auflisten. Dabei wird zu den einzelnen Files die aus dem Header ersichtliche Lizenz zugeordnet.

Der Mehrwert der kommerziellen Scan-Tool-Anbieter besteht vor allem darin, dass auch so genannte "Snippets" bei der Suche identifiziert werden. Dabei handelt es sich um Code-Bestandteile von Open Source-Software, die nur aus einzelnen Zeilen oder Teilen von Files bestehen und daher keine Header-Informationen mehr zur Identifizierung aufweisen. Somit würden diese Treffer bei einem Header-Scan auch nicht gefunden. Die bekanntesten Anbieter kommerzieller Scan-Tools sind Black Duck und Palamida [6]. Diese scannen die übermittelte Code Base automatisiert auf Übereinstimmungen mit bekannter Open Source-Software, danach erfolgt manuell ein so genanntes Audit, in welchem die Treffer beurteilt und nicht relevante Hits aussortiert werden. Den gefundenen Open Source-Komponenten wird die bekannte Lizenz zugewiesen, der Kunde erhält eine Auflistung zur weiteren Auswertung.

Es ist wichtig, dass neben der so genannten Top-Level-Lizenz auch die Lizenzen von Unterfiles ermittelt werden. Die Top-Level-Lizenz ist die der Open Source-Software zugeordnete Lizenz, quasi eine Hauptlizenz. Stehen nicht sämtliche Files der Open Source-Software ohne Ausnahme unter eben der Lizenz, muss neben der Hauptlizenz auch jede weitere Lizenz solcher Unterfiles für die rechtliche Beurteilung berücksichtigt werden. Die Lizenzbedingungen müssen für jede enthaltene Lizenz eingehalten werden, die Hauptlizenz "konsumiert" nicht enthaltene Unterlizenzen auf, da der jeweilige Urheber des einzelnen Files die Lizenz frei festlegen kann. Die Angaben auf den Projektseiten von Open Source-Software zu Lizenzen beschränken sich regelmäßig auf die Hauptlizenzen, daher empfiehlt es sich, auch bei einer zuverlässigen Listung der eingesetzten Open Source-Software einen Header-Scan durchzuführen, um die implementierten Files auf abweichende Unterlizenzen zu überprüfen und auch diese zu listen. Diese Funktion soll auf Anforderung auch von den kommerziellen Tools umgesetzt werden können, standardmäßig wurden zuletzt nur Top-Level-Lizenzen gelistet.

Aus technischer Sicht müssen daneben noch weitere Informationen evaluiert werden, die für die rechtliche Beurteilung wichtig sind. Je nachdem welche Open Source-Lizenzen relevant sind, kann es erforderlich sein, genaue Informationen dazu auszuwerten, mit welchen anderen Komponenten die Software interagiert. Besonders interessant sind die so genannten statischen und dynamischen Verlinkungen zum Beispiel bei der LGPL (GNU Lesser General Public License). Ist die Open Source-Komponente hier zur Runtime noch eigenständig auf dem Filesystem identifizierbar und wird nur über eine Standardschnittstelle geladen, sodass der User sie theoretisch auch austauschen kann, muss der übrige Code trotz Copyleft der Lizenz zum Beispiel nicht als Open Source verfügbar gemacht werden.

Weiteres wichtiges Thema sind möglicherweise für das Produkt eingesetzte Sicherungsmaßnahmen wie signierte Bootloader. Manche Open Source-Lizenzen, wie zum Beispiel die GPL in der aktuellen Version 3, verbieten es, das System dergestalt unzugänglich zu machen. Derartige Informationen zu dem Produkt müssen also ebenfalls evaluiert werden. Gleiches gilt, wenn Dependencies von Komponenten erst im Kompiliervorgang gezogen werden und daher in der analysierten Code Base noch nicht enthalten waren. Teilweise fließen auch aus Compilern wiederum einzelne Files in das kompilierte Produkt ein. Sollte das der Fall sein, muss die Information für die rechtliche Bewertung vorliegen, damit auch für diese Files die Lizenzbedingungen eingehalten werden. Eine exakte Aufbereitung aus technischer Sicht ist somit zur Vorbereitung der rechtlichen Beurteilung unerlässlich.

Wenn das Ausmaß hiervon noch nicht kompliziert klingt, sollten wir an dieser Stelle noch einmal auf Linux zurückkommen. Linux besteht aus tausenden Files, von denen zunächst die Mehrzahl unter der GPL steht, wobei jedoch nicht in jedem Header der gleiche Copyright-Vermerk enthalten ist. Für diese Files müssten somit aus den Headern die verschiedenen Vermerke zusammengestellt werden. Dann würde dazu der Lizenztext der GPL gelistet. Danach würde geprüft werden, unter welchen weiteren Lizenzen Unterfiles stehen, wobei sich eine Vielzahl von Lizenzen ergibt, zum Beispiel unter der BSD-, MIT- oder Apache-Lizenz. Für alle diese Files müssten dann wiederum die nach den entsprechenden Lizenzen erforderlichen Pflichtangaben aufgenommen werden. Bei der MIT-Lizenz sind das beispielsweise der komplette Lizenztext mit dem darüberstehenden Copyright-Vermerk, bei der Apache-Lizenz der Lizenztext und der Inhalte eines NOTICE-Files, falls ein File mit einer solchen Bezeichnung im Code der ursprünglichen Open Source-Komponente enthalten ist. Hier wird der Umfang der notwendigen Arbeiten für ein so großes Paket wie Linux gut ersichtlich: es entstehen schnell tausende Seiten an Auflistung. Manuell lässt sich das nicht wirklich bewältigen, hier sind die Scan-Tools ein dringend benötigtes Hilfsmittel.

Soll diese Zusammenstellung dann auf Papier mitgeliefert werden, müsste im Falle meines Geschirrspülers mit Linux ein umfangreiches Handbuch beigelegt sein. Einfacher ist es, zum Beispiel ein Speichermedium mit den Angaben beizufügen oder gleich die Angaben in einem bestimmten Screen des Produkts anzeigen zu lassen, was die Standardlösung für Apps ist. Eine genaue Regelung zur Art der Bereitstellung findet sich in den meisten Lizenzen nicht. Das lapidare "along with the software", das in den Open Source-Lizenzen teilweise zu lesen ist, schließt jedoch vom Wortlaut das Einfügen eines Links unter dem die Angaben stehen aus.

Bei Lizenzen mit Copyleft muss außerdem bei einer Weitergabe in kompilierter Form auch der Source Code der Open Source-Komponenten oder sogar des eigenen hinzugefügten Codes unter der Open Source-Lizenz der Ursprungskomponente bereitgestellt werden. Hat der Entwickler Code der Open Source-Komponente bearbeitet, so muss dieser ebenfalls enthalten sein. Dabei ist unerheblich, ob der Empfänger des kompilierten Codes sich den Source Code zu den Open Source-Komponenten selbst einfacher im Internet beschaffen könnte. Für etwaige Anfragen sollte der Code vorhanden sein und auch ausgegeben werden. Nach den meisten Lizenzen ist es nicht erforderlich, einen Datenträger mit dem Source Code mit auszuliefern, es genügt ein so genanntes "written offer", dem Empfänger auf Anforderung das Material verfügbar zu machen. Dieses schriftliche Angebot kann in die Pflichtangaben mit aufgenommen werden. Für den Fall einer Komponente unter einer Open Source-Lizenz, die zumindest nach konservativer Austauschbarkeit fordert, wie beispielsweise der LGPL, kann es erforderlich sein, eine Austauschanleitung zusammenzustellen, die dem Nutzer diese theoretische Austauschmöglichkeit erläutert.