Abschluss des Verfahrens gegen AVM wegen OSS-Lizenzverletzung – einmal mehr FUD – oder ein echter Game Changer?

Die Ausgangslage

Das von der SFC gesponserte Verfahren drehte sich im Wesentlichen um die Frage, was neben dem eigentlichen Source Code Downstream-Nutzern weitergegeben werden muss, wenn unter der GPL-2.0 und der LGPL-2.1 lizenzierte Software in Binärform an Dritte weitergegeben wird.

Die Auseinandersetzung begann, wie so oft, mit der Bitte des Klägers, eines Entwicklers an die Beklagte, in diesem Fall AVM, um Herausgabe des Source Codes für einen von der Beklagten hergestellten Router, den der Kläger erworben hatte.

Zwar händigte AVM nach Darstellung der SFC den Source Code auch zunächst aus. Allerdings soll dieser offenbar nicht ausgereicht haben, um Modifikationen der entsprechenden OSS-Komponenten dauerhaft im Speicher der Geräte abzulegen.

Nach Darstellung des Klägers in der veröffentlichten Klageschrift hat die Beklagte zwar auf mehrere Nachfragen Source Code und weitere Informationen wie die Skripte zur Kompilierung und Installation herausgegeben, allerdings sollen bis zur Klageerhebung Informationen gefehlt haben, um die modifizierten OSS-Komponenten auf der konkreten, vom Kläger erworbenen Hardware dauerhaft zu installieren. Letztlich habe, so die Darstellung der SFC, AVM jedoch eingelenkt und die vom Kläger angeforderten Informationen übermittelt. Die Parteien haben ausweislich der von der SFC veröffentlichten Informationen den Rechtsstreit übereinstimmend für erledigt erklärt, AVM hat die Anwaltskosten des Klägers übernommen. In der Presseberichterstattung wird AVM hingegen anders zitiert. Der Kläger, so AVM, habe die Klage zurückgezogen. Da es sich um eine Privatperson gehandelt habe, habe sich AVM freiwillig entschieden, die Gerichtskosten zu begleichen.

Mit der Beendigung dieses Verfahrens geht, wie so oft, eine weitere Auseinandersetzung in Sachen Open Source Compliance ohne eine gerichtliche Entscheidung zu Ende. So vorteilhaft es für die konkreten Verfahrensbeteiligten sein mag, sich geeinigt zu haben, wäre es aus Sicht der Öffentlichkeit doch wünschenswert gewesen, wenn durch ein entsprechendes Urteil mehr Klarheit in die Frage der Auslegung der GPL-2.0 und der LGPL-2.1 gebracht worden wäre.

Die offenbar diskutierten Fragen

Denn der im konkreten Verfahren diskutierte Aspekt wird in der Open Source Community schon seit Längerem kontrovers diskutiert. Im Kern geht es um zwei Fragen: Zum einen, ob es genügt, lediglich den Source Code der konkreten Komponente zur Verfügung zu stellen, und zum anderen, ob die konkrete Komponente dann auf der Ausgangshardware installiert und zum Laufen gebracht werden können muss oder ob es ausreicht, dass sie auf irgendeinem System ausgeführt werden kann.

Überlassung nur des Source Codes?

Im ersten Fall sprechen die besseren Argumente dafür, dass allein die Überlassung des Source Codes nicht genügt. Die Lizenzen verlangen schließlich auch die Skripte, die für das Kompilieren und das Bauen der Software erforderlich sind (in Ziff. 0 Abs. 4 der GPL-2.0 bzw. Ziffer 3 Abs. 2 der LGPL-2.1 heißt es etwa, zum Source Code der Library gehören auch „any associated interface definition files, plus the scripts used to control compilation and installation of the library“). Man wird also durchaus verlangen können, dass der Empfänger der Software grundsätzlich in die Lage versetzt werden muss, den Source Code zu einem lauffähigen Executable zu kompilieren.

Was das allerdings in der Praxis bedeutet, ist oftmals nicht klar. So hat im vorliegenden Fall der Kläger argumentiert, es würden Skripte zur Kompilierung und Installation fehlen, die Beklagte sei auch schlicht nicht gewillt, das Aufspielen modifizierter Bibliotheken zu ermöglichen. Dem trat wiederum AVM, ausweislich neuerer Berichterstattung in der Presse, mit dem Argument entgegen, dass AVM durchaus Interesse an Innovationen durch die Community habe, weswegen es widersinnig wäre, die Community auszuschließen. Zahlreiche andere Entwickler hätten mit dem jeweiligen Source Code keine Probleme gehabt. Die Fehlermeldungen, welche der Kläger erhielt, deuteten vielmehr auf Unerfahrenheit beim Cross-Compiling-Prozess hin.

Muss die Installation auf der Ausgangshardware ermöglicht werden?

Umstritten ist allerdings die Frage, ob es in jedem Fall ermöglicht werden muss, dass der Empfänger der Software seine Modifikationen auch auf der Ausgangshardware zum Laufen bringen kann und ob die genannten Regelungen so zu interpretieren sind, dass sie dies zwingend vorschreiben.

Viele Unternehmen sichern ihre Hardware vor unbefugten Modifikationen durch sogenannte Digital Rights Management (DRM)-Systeme. Dabei wird durch technische Maßnahmen sichergestellt, dass der auf dem Gerät befindliche Binärcode nicht unbefugt modifiziert werden kann.

Ein solches DRM-System hat meist weniger den Hintergrund, dem Hardwarenutzer die Modifikation von Open Source Software zu verweigern, sondern dient vielmehr der Erfüllung regulatorischer und IT-Sicherheitsanforderungen. Gerade bei kritischen Systemen, wie etwa medizinischen Geräten oder sicherheitsrelevanten Steuerungen in der Automobilbranche, sollen die Anwender davor geschützt werden, dass Hardware manipuliert wird. Letzteres wird teilweise auch regulatorisch verlangt (vgl. beispielsweise Anhang I, Kapitel II, Abschnitt 17 der EU-Medizinprodukte-Verordnung und UNECE-Regelung Nr. 155 zur Cybersicherheit in Fahrzeugen).

Aus diesem Grund vermeiden viele Unternehmen auch den Einsatz von (A/L)GPL-3.0-lizenzierter Software, weil diese Lizenz genau eine solche Möglichkeit der Modifikation der Software zwingend auch für Embedded Systems vorsieht und damit einen Schutz durch DRM faktisch verbietet.

Wäre nun die GPL-2.0 und auch die LGPL-2.1 genauso zu interpretieren wie die (A/L)GPL-3.0, hätte das weitreichende Auswirkungen auf den Markt für Embedded Systems. Ein Einsatz beispielsweise von Linux als Betriebssystem für Systeme, die derart geschützt sind, wäre nur noch mit sehr starken Einschränkungen möglich.

Ob ein solches DRM-Verbot auch in die GPL-2.0 und die LGPL-2.1 hineinzulesen ist, ist in der Fachliteratur allerdings umstritten. Während einige Stimmen dies mit Blick auf die vorstehend zitierten Regelungen bejahen (siehe etwa Jäger/Metzger, Open-Source-Software, Rn. 43), wird dies von anderen Stimmen mit dem Argument abgelehnt, dass es keiner expliziten Regelungen in der GPL-3.0 bedurft hätte, wenn eine solche Anforderung schon in den Vorgängerversionen enthalten gewesen wäre (Schöttle in: Marly, Praxishandbuch Softwarerecht, § 12 Rn. 276 f. sowie Galetzka/Jun/Roßmann Praxishandbuch Open Source/Galetzka, Rn. 646). Zudem wäre der Anwendungsbereich der Regelung in der GPL-3.0 und LGPL-3.0 enger als in der ursprünglichen Lizenzvariante, da sich die Regelungen der LGPL-3.0 lediglich auf in der GPL-3.0 definierte User Products erstrecken und nicht auf sämtliche Produkte.

Fazit

Leider ist der hier abgeschlossene Fall zu speziell und das, was an Kommunikation die Öffentlichkeit erreichte zu widersprüchlich, als dass sich daraus klare Lehren für den Einsatz von GPL-2.0- und LGPL-2.1-lizenzierter Software für die Allgemeinheit ziehen ließen.

Auch wenn aus Sicht der Open-Source-Community hier die Chance vertan wurde, durch eine gerichtliche Entscheidung zumindest ein wenig Licht in das Dunkel zu bringen, zeigt die Auseinandersetzung allerdings eines: Nämlich, dass die Frage, ob dem Empfänger von Open-Source-Software das Nachbauen und Aufspielen von modifizierter Software auf Ausgangs-Hardware ermöglicht werden muss, noch lange nicht ausdiskutiert ist.

Nichtsdestotrotz sollten Unternehmen, die OSS einsetzen, ihre Compliance-Prozesse regelmäßig überprüfen und sicherstellen, dass alle Anforderungen der jeweiligen Lizenz erfüllt werden, um rechtliche Risiken zu minimieren. Mit Blick auf den Source Code heißt das also: Gerade wer Drittkomponenten nicht selbst aus den Sourcen baut, sollte prüfen, ob all das vorhanden ist, was benötigt wird, um eben diese Drittkomponenten zu modifizieren und wieder zum Laufen zu bringen. Das ist eben nicht nur der Source Code, sondern mehr. Die Auseinandersetzung in Sachen AVM hat aber auch gezeigt, dass ein unterschiedliches Verständnis darüber herrscht, welche Kenntnisse und Fähigkeiten von den Empfängern der Materialien erwartet werden können – oder eben nicht. Auch wenn es eine Binsenweisheit ist: Softwareentwicklung ist komplex und es ist eben nicht damit getan, einfach nur Source Code in einen Compiler zu kippen. Ein Softwareprojekt erfolgreich zum Laufen zu bringen, erfordert Anstrengungen – im konkreten Fall auf beiden Seiten. Wo die Grenze zu ziehen ist, was erwartet werden kann, bleibt weiterhin eine Frage des Einzelfalles.

Auch wenn man sich es anders gewünscht hätte – zumindest ein bisschen Uncertainty and Doubt bleibt. Ob sie gleich von Fear begleitet sein müssen, mag jeder für sich selbst entscheiden.