Open Source

Was ist Open Source?

Open Source (quelloffene Software) bezeichnet Software, deren Quelltext öffentlich zugänglich ist und nach den Bedingungen einer Lizenz von jedermann genutzt, untersucht, verändert und weitergegeben werden darf. Quelltext ist der für Menschen lesbare Programmcode, aus dem die lauffähige Software erzeugt wird. Maßgeblich ist nicht der Preis, sondern die Lizenz: Sie räumt weitreichende Nutzungsrechte ein, knüpft sie aber je nach Lizenztyp an Pflichten. Vergleichbar ist das mit einem veröffentlichten Rezept, das jeder nachkochen und abwandeln darf, solange er die Bedingungen des Verfassers einhält, etwa dessen Namen nennt.

Nahezu jedes Softwareprodukt enthält heute Open-Source-Bausteine, oft indirekt, weil ein eingebauter Baustein seinerseits weitere mitbringt. Sie sind damit fester Teil des Tech Stack. Nach deutschem Recht räumt der Urheber mit der Lizenz jedermann einfache urheberrechtliche Nutzungsrechte ein. Deutsche Gerichte haben verbreitete Open-Source-Lizenzen als wirksam anerkannt. Nach verbreiteter Auffassung entfallen die Nutzungsrechte, sobald die Lizenzpflichten verletzt werden; dann drohen Unterlassungs- und Schadensersatzansprüche nach § 97 UrhG. Einzelne Lizenzen, etwa die GPL in Version 3, erlauben es, die Rechte durch zügige Behebung des Verstoßes zurückzuerlangen.

In Finanzierungsrunden und Unternehmensverkäufen ist Open Source deshalb fester Bestandteil der technischen und rechtlichen Due Diligence, also der Untersuchung durch Investoren und Käufer vor dem Einstieg oder Kauf. Hinzu kommen besondere Garantien im Kaufvertrag.

Lizenztypen

Freizügige Lizenzen

Freizügige Lizenzen (Permissive Licenses) wie MIT, BSD oder Apache 2.0 erlauben, den Code in eigene Produkte einzubauen und diese unter eigenen, auch geschlossenen Bedingungen zu vertreiben. Verlangt wird im Wesentlichen, Urheber- und Lizenzhinweise beizubehalten. Die Apache-Lizenz enthält zusätzlich eine Patentlizenz und verlangt, Änderungen kenntlich zu machen.

Copyleft-Lizenzen

Copyleft-Lizenzen verlangen, dass veränderte Fassungen und darauf aufbauende Werke bei ihrer Weitergabe unter derselben Lizenz stehen und ihr Quelltext zugänglich gemacht wird. Bei strengem Copyleft wie der GNU General Public License (GPL) kann das auch eigenen Code erfassen, der mit dem GPL-Baustein zu einem einheitlichen Programm verbunden ist. Wie weit diese Wirkung reicht, hängt von der technischen Einbindung ab, etwa davon, ob der Baustein fest in das eigene Programm eingefügt oder als getrenntes Programm aufgerufen wird. Für manche Konstellationen ist das rechtlich nicht abschließend geklärt.

Schwaches Copyleft beschränkt die Pflichten im Wesentlichen auf den Baustein selbst und dessen Änderungen. Bei der GNU Lesser General Public License bleibt eigener Code frei, wenn er die Bibliothek nur nutzt und Empfänger sie gegen eine geänderte Fassung austauschen können. Die Mozilla Public License knüpft an einzelne Dateien an: Geänderte Dateien des Bausteins bleiben offen, eigene Dateien nicht.

Weitergabe und Nutzung über ein Netzwerk

Die Pflichten der GPL knüpfen an die Weitergabe der Software an, etwa die Auslieferung einer App oder einer installierbaren Software an Kunden. Wird die Software nur auf eigenen Servern betrieben und Kunden über das Internet zur Nutzung angeboten, liegt nach verbreitetem Verständnis keine Weitergabe im Sinne der GPL vor. Die GNU Affero General Public License (AGPL) erweitert die Pflichten auf diesen Fall: Wer eine veränderte Fassung eines AGPL-Programms Nutzern über ein Netzwerk zur Verfügung stellt, muss ihnen den Quelltext dieser Fassung anbieten.

Pflichten bei der Weitergabe

Vereinfacht gilt: Freizügige Lizenzen verlangen, den Urheber zu nennen; Copyleft-Lizenzen verlangen zusätzlich, den Quelltext zu teilen. Im Einzelnen sind bei der Weitergabe üblich:

• bei allen Lizenzen: Lizenztext und Urheberhinweise mitliefern, etwa in einer Übersicht in der App oder in der Dokumentation, bei Apache 2.0 zusätzlich eine mitgelieferte Hinweisdatei,
• bei Copyleft: den Quelltext des Bausteins mit allen Änderungen mitliefern oder schriftlich anbieten, bei der GPL auch den Quelltext des damit verbundenen Programms,
• bei Copyleft außerdem: den Empfängern keine zusätzlichen Beschränkungen auferlegen, die der Lizenz widersprechen.

Open Source als Geschäftsmodell

Manche Unternehmen veröffentlichen eigene Software bewusst als Open Source, um Verbreitung ohne Vertriebsaufwand zu erreichen. Umsatz entsteht über den Betrieb als verwalteter Onlinedienst, über kostenpflichtige Zusatzfunktionen für Unternehmen (Open Core) oder über Supportverträge. Eine weitere Form ist die Doppellizenzierung: Kunden erwerben eine kommerzielle Lizenz, um die Pflichten der Copyleft-Lizenz nicht erfüllen zu müssen. Investoren prüfen hier vor allem die Umwandlung kostenloser Nutzer in zahlende Kunden. Für eine Doppellizenzierung benötigt das Unternehmen an sämtlichem Code die erforderlichen Nutzungsrechte, auch an Beiträgen externer Entwickler, was Beitragsvereinbarungen (Contributor License Agreements) voraussetzt.

Prüfung in der Due Diligence

Grundlage ist eine Software-Stückliste (Software Bill of Materials), die alle eingesetzten Bausteine mit Version und Lizenz aufführt. Prüfer erstellen oder kontrollieren sie mit Werkzeugen, die den Code automatisch mit bekannten Open-Source-Bausteinen abgleichen. Sie achten besonders auf:

• Copyleft-Bausteine in ausgelieferter Software, etwa Apps oder installierbaren Produkten,
• AGPL-Bausteine in Diensten, die Kunden über das Internet nutzen,
• fehlende Urheber- und Lizenzhinweise, auch bei freizügigen Lizenzen,
• Bausteine ohne erkennbare Lizenz oder mit bekannten Sicherheitslücken.

Die meisten Befunde lassen sich beheben, etwa durch Austausch eines Bausteins oder Ergänzung fehlender Hinweise. Zeitkritisch wird es, wenn ein Baustein tief im Produkt verankert ist und der Austausch Monate beansprucht. Für Käufer und Investoren zählt deshalb weniger die Zahl der Befunde als die Frage, ob ein Befund das Geschäftsmodell berührt, etwa weil ein Kernbestandteil des Produkts offengelegt werden müsste.

Garantien im Kaufvertrag

Im Unternehmenskaufvertrag und häufig auch im Beteiligungsvertrag sichern sich Erwerber über besondere Garantien ab. Üblich sind drei Zusicherungen:

• Alle eingesetzten Open-Source-Bausteine sind in einer Anlage zum Vertrag offengelegt (Disclosure Schedule).
• Die Lizenzbedingungen dieser Bausteine werden eingehalten.
• Kein Copyleft-Baustein löst eine Pflicht zur Offenlegung eigenen Quelltexts aus.

Bekannte Befunde werden dagegen nicht über eine Garantie geregelt, weil der Kaufvertrag Garantieansprüche für Umstände, die der Käufer kennt, in der Regel ausschließt. Üblich sind stattdessen eine gesonderte Freistellung (Indemnification), also die Zusage, bestimmte Schäden zu ersetzen, oder eine Behebung vor dem Vollzug. Vollzug ist der Tag, an dem das Unternehmen tatsächlich übergeht.

Praxisbeispiel

Ein Anbieter eines Onlinedienstes für Vertragsmanagement wird an einen Finanzinvestor verkauft. Die Software-Stückliste umfasst rund 1.400 Bausteine. Die Prüfung ergibt zwei Befunde:

• In der Oberfläche fehlen die vorgeschriebenen Lizenzhinweise für mehrere Bausteine unter freizügigen Lizenzen. Das Unternehmen ergänzt sie innerhalb weniger Tage.
• Ein Modul zur Dokumentenumwandlung steht unter der AGPL und wurde vom Entwicklungsteam angepasst. Weil Kunden den Dienst über das Internet nutzen, müsste das Unternehmen den Quelltext der angepassten Fassung anbieten. Das Modul ist eng mit dem eigenen Kernprodukt verbunden, und es ist nicht sicher abzugrenzen, wie viel eigener Code von der Offenlegung erfasst wäre. Das Unternehmen entscheidet sich deshalb für den Austausch gegen einen kommerziell lizenzierten Baustein, der nach Schätzung der Prüfer vier Monate dauert.

Die Parteien vereinbaren, dass der Verkäufer den Austausch vor dem Vollzug beginnt. Das verbleibende Risiko wird über eine Freistellung und einen Einbehalt vom Kaufpreis auf einem Treuhandkonto abgesichert, der erst nach nachgewiesenem Austausch freigegeben wird. Der erste Befund ist eine Formsache. Der zweite verhindert den Verkauf nicht, bindet aber einen Teil des Kaufpreises und hätte sich mit einer früh gepflegten Stückliste ohne Zeitdruck lösen lassen.

Abgrenzung zu verwandten Begriffen

• Source Available: Lizenzmodelle, bei denen der Quelltext einsehbar ist, die Nutzung aber eingeschränkt bleibt, etwa für den Betrieb als Dienst für Dritte. Sie gelten nicht als Open Source, weil sie bestimmte Nutzungen ausschließen.
• IP Assignment: sichert dem Unternehmen die Rechte an Code, der für es geschaffen wurde. Open-Source-Lizenzen regeln dagegen die Nutzung fremden Codes.

Typische Fehler

• Keine Software-Stückliste. Ohne vollständige Aufstellung lässt sich in der Due Diligence nicht belegen, welche Lizenzpflichten bestehen.
• Prüfung erst vor dem Verkauf. Werden Lizenzfragen erst im laufenden Prozess geklärt, ist der Austausch eines Bausteins teuer und zeitkritisch.
• Hinweispflichten übersehen. Auch freizügige Lizenzen verlangen Urheber- und Lizenzhinweise; fehlen sie, ist die Nutzung nicht vollständig lizenzkonform.
• AGPL unterschätzt. Anbieter von Onlinediensten gehen oft davon aus, dass Copyleft sie mangels Weitergabe nicht betrifft. Für angepasste AGPL-Bausteine trifft das nicht zu.
• Keine interne Regel. Fehlt eine Liste erlaubter und freigabepflichtiger Lizenzen, entscheidet jeder Entwickler selbst, was eingebaut wird.

Häufige Fragen

Darf ein Unternehmen GPL-Software einsetzen?

Ja. Die rein interne Nutzung innerhalb des Unternehmens löst keine Offenlegungspflicht aus; schon die Überlassung an eine andere Konzerngesellschaft kann aber als Weitergabe gelten. Pflichten entstehen, wenn GPL-Code in Software eingebaut wird, die an Kunden weitergegeben wird, und bei der AGPL zusätzlich, wenn eine veränderte Fassung über ein Netzwerk angeboten wird.

Muss ein Unternehmen seinen Quelltext veröffentlichen, wenn GPL-Code im Produkt gefunden wird?

Nicht zwingend. Die Lizenz erlaubt die Weitergabe nur unter ihren Bedingungen, erzwingt aber keine Veröffentlichung. Das Unternehmen kann die Bedingungen erfüllen oder den Baustein ersetzen und die Weitergabe der betroffenen Fassung einstellen. Für die Vergangenheit bleiben Ansprüche der Rechteinhaber möglich.

Mindern Open-Source-Befunde den Kaufpreis?

Selten unmittelbar. Die meisten Befunde werden vor dem Vollzug behoben oder vertraglich abgesichert. Einen Abschlag verlangen Käufer vor allem, wenn ein Austausch aufwendig ist und das Geschäftsmodell berührt.

Verlangen auch Kunden eine Software-Stückliste?

Zunehmend ja, vor allem größere Unternehmenskunden und Kunden aus regulierten Branchen. Sie nutzen die Aufstellung, um Lizenzrisiken und Sicherheitslücken in eingekaufter Software zu überwachen.

Wie lässt sich die Lizenzkonformität dauerhaft sichern?

Durch automatisierte Prüfung im Entwicklungsprozess, eine laufend gepflegte Software-Stückliste und eine schriftliche Regel, welche Lizenzen ohne Freigabe eingesetzt werden dürfen.

Roemer Capital Perspektive

Die Software-Stückliste gehört bei uns in den Datenraum einer Finanzierungsrunde oder eines Verkaufs, bevor der erste Investor oder Käufer danach fragt. Befunde, die dort sichtbar werden, lassen sich noch in Ruhe beheben; im laufenden Prozess nur unter Zeitdruck und mit Zugeständnissen im Vertrag.

Die lizenzrechtliche Bewertung einzelner Bausteine übernimmt die Kanzlei des Mandanten. Wir sorgen dafür, dass technische Befunde, Aufwand für den Austausch und vertragliche Absicherung zusammen betrachtet werden, damit Garantien, Freistellungen und Zeitplan zueinander passen.