Open-Source-Komponenten sind integraler Bestandteil nahezu aller Software-Lösungen geworden. Die verschiedenen Open-Source-Lizenzen regeln dabei, wie diese Komponenten eingesetzt werden dürfen. Worauf Sie dabei achten sollten, erfahren Sie in diesem Artikel. [...]
Linux, Git, MySQL, Node.js, Docker, Hadoop – die Verwendung von freier Software in Form unzähliger Libraries, Frameworks und Tools ist selbstverständlich geworden. Open-Source-Komponenten – also in sich geschlossene Einheiten, deren Quelltext frei einsehbar ist – sind aus keinem Projekt mehr wegzudenken.
Austausch und gemeinsame Kreativität sind lange nicht mehr die einzigen Beweggründe, sich der Open Source Community anzuschließen. Kaum ein kommerzielles Produkt der digitalen Sphäre baut nicht auf frei verfügbaren Code, da Code-Qualität, Innovationsorientierung und Sicherheit der kollaborativ entwickelten Software überzeugen. Der Markt bewertet diese Software entsprechend hoch, weshalb auch Unternehmen selbst Projekte samt Quellcode frei zugänglich bereitstellen, um ihre Reputation zu steigern und neue Geschäftsmodelle zu erschließen.
Open Source heißt nicht bedingungslos
Dass freie und quelloffene Software keine freie, bedingungslose Nutzung bedeutet, muss im kommerziellen Umfeld klar sein. Im kleinen Rahmen, für den Einzelgebrauch eines individuellen Entwicklers, kommen die Rechte der Code-Autoren vielleicht nicht so offensichtlich zum Tragen. Aber sobald die Abhängigkeit eines Geschäftsmodell von Open Source besteht und ein Wert geschöpft werden soll, müssen die rechtlichen Konsequenzen eindeutig verstanden sein. Denn die Open-Source-Lizenzen sollen den Gedanken der freien, quelloffenen Software sowie deren Community schützen und die Ausbeutung kostenloser Ressourcen zu kommerziellen Zwecken verhindern.
Der Grundgedanke von Open Source
Die Open-Source-Community, deren Zusammenarbeit vor allem auf Plattformen wie GitHub stattfindet, schließt dabei jeden Entwickler ein, der selbst schon einmal Fragmente seines Codes – seien es nur kleine Schnipsel, Bugfixes oder auch vollständige Projekte – veröffentlicht hat.
Grundsätzlich erfordert die Definition freier Software (kurz OSS) gemäß der Open Source Initiative (kurz OSI), den Quellcode offenzulegen, Kopien zu erlauben, aber auch den Einsatz sowie Modifikation oder Erweiterung ohne Nutzungsbeschränkung und Zahlungsverpflichtung. Das ermöglicht nicht nur freie Distribution und Modifizierung, es verhindert auch die Diskriminierung von Personen, Gruppen oder Verwendungszwecken.
Aufgrund des Diskriminierungsverbots werden folglich weder Nutzergruppen sowie Einsatzbereiche eingeschränkt. Ein Ausschluss von kommerzieller, militärischer oder für beispielsweise Firmenangehörige gesonderter Nutzung ist somit nicht mit den Leitlinien der Open-Source-Definition vereinbar. Lizenzen, die ebendiese Prinzipien durchsetzen, bieten den rechtlichen Rahmen, Code überhaupt erst als Open Source zu veröffentlichen. Ohne entsprechende Lizensierung gilt für den Code andernfalls der Urheberschutz. Denn der Einsatz fremden Codes, ähnlich wie der eines Kunstwerkes, erfolgt auf Basis geltenden Rechts.
Wem gehört der Code?
Im anglo-amerikanischen Rechtsraum, aus dem jede der hier betrachteten Lizenzen stammt, ist eine vollständige Übertragung des Copyrights auf eine andere juristische Person durchaus denkbar. In Deutschland lässt sich das Urheberrecht laut §29 Abs. 1 UrhG hingegen nicht abtreten, sondern lediglich der Anspruch auf einfache oder ausschließliche Nutzungsrechte übergeben.
Demnach kann ein amerikanischer Arbeitgeber das Copyright an einem Open-Source-Code gemäß der Work-made-for-hire-Doktrin besitzen, während in Deutschland dem Arbeitgeber nach §69b Abs. 1 UrhG nur die ausschließlichen Nutzungsrechte der Software zustehen. Der Arbeitnehmer stellt jedoch immer noch den Autor des Codes dar und hat ein ideelles Urheberrecht inne.
In Folge einer Lizensierung des Codes mit einer Open-Source-konformen Lizenz werden nicht-ausschließliche Nutzungs- und Verwertungsrechte ebenfalls an den jeweiligen Empfänger übertragen. Es muss jedoch sichergestellt sein, dass die Copyright-Informationen über den ursprünglichen Autor bei der Distribution oder Modifizierung übernommen werden und dass der Autor nicht für eventuell entstehende Schäden verantwortlich gemacht werden kann. Dies fällt unter das Schlagwort „no-liability“. Oft wird auch eine Advertising Clause festgelegt, der nach bei der Bewerbung eines Produktes, welches die Open-Source-Komponente enthält, auf den Inhaber des Copyrights hingewiesen werden muss.
Bei Open-Source-Projekten ist für die Urheberschaft sowohl ein einzelner Urheber als auch die Zusammenarbeit mit Miturhebern oder einzelne Urheber pro geschaffene Sektion des „verbundenen Werks“ im Sinne des §9 UrhG denkbar. Mithilfe eines Contributor License Agreements (kurz CLA) lässt sich sicherstellen, dass der Projektinhaber eines Open-Source-Projekts die Urheberrechte zu beispielsweise einer möglichen Relizensierung oder der Verfolgung von Urheberrechtsverletzungen vor Gericht erhält und ein „Transfer of Ownership“ vom Urheber des Codes auf den Inhaber des gesamten Projekts erfolgt.
Wenn der Arbeitgeber nach deutschem Arbeitsvertrag die Nutzungs- und Verwertungsrechte von Software innehält, steht es als Folge von § 69b Abs. 1 UrhG auch nur ihm zu, ein CLA zu unterzeichnen und diese Rechte abzutreten. Dies bedeutet insbesondere, dass ein Arbeitnehmer keine solche CLA selbst unterzeichnen darf, wenn er keine Prokura seines Arbeitgebers besitzt.
Im Zuge der Beschäftigung mit dem Copyright darf hierbei die Definition von Copyleft nicht fehlen: Ein Copyleft-Effekt stellt sicher, dass Redistributionen und Modifizierungen eines Programms ebenfalls frei bleiben, indem sie unter derselben Lizenz weiter lizensiert werden müssen, unter der sie auch empfangen wurden. Ein starker Effekt schließt dabei im Gegensatz zu einem schwachen Copyleft-Effekt auch zusätzliche weitere Teile eines Projektes ein und greift somit auf den gesamten Quellcode desselben über. Die Konsequenz: Das gesamte Projekt muss unter dieselbe Copyleft-Lizenz gesetzt werden. Ausnahme sind aggregierte Werke, da diese aus separaten Programmen bestehen, die lediglich miteinander kommunizieren.
MIT, BSD3, Apache 2.0, LGPL 2.1, GPL 2 und GPL v3: Die Absichten der Lizenzen
Generell spricht die Balance zwischen dem Beitragen zur Open Source Community und gleichzeitig der Möglichkeit, dass der Code in proprietäre Software eingebunden wird, für die Nutzung einer schwachen Copyleft-Lizenz, wie sie auch die Mozilla Public License und die Eclipse Public License darstellen. So verzichten MIT, BSD3 und Apache 2.0 auf den Copyleft-Effekt, legen dem Nutzer also kaum Verpflichtungen auf. LGPL 2.1, GPL v2 und GPL v3 üben hingegen einen Copyleft-Effekt aus.
BSD3 und MIT – genauer gesagt, die X11-Lizenz – sind beinahe identisch. Sie unterscheiden sich nur in der „non-endorsement clause“ der BSD3. Sie verbietet die Nutzung des Namens des Lizenzgebers bei der Vermarktung abgeleiteter Produkte; außer er hat ausdrücklich zugestimmt.
Zu Apache 2.0 existieren derweil mehrere Unterschiede. Dazu zählen die explizite Übertragung von Patentrechten und das Auflisten aller signifikanten Modifizierungen am Code.
Die GPL v3 stellt die aktuelle Version der GPL-Lizenzen dar. Auch bei der Vorgängerversion GPL v2 muss bei einer Redistribution eines Programmes mit Code, welcher unter GPL lizensiert ist, das gesamte Programm ebenfalls unter die GPL gestellt werden – dazu zählen auch verlinkte Bibliotheken und hinzugefügte Komponenten des Programmes.
Bei der GNU Lesser General Public License 2.1, kurz LGPL, die vor allem auf Bibliotheken angewandt wird, kommt jedoch nur ein schwacher Copyleft-Effekt zum Tragen: Falls die Bibliothek verändert wird, müssen die Veränderungen ebenfalls unter LGPL 2.1 gestellt werden – bei der reinen Nutzung ohne Modifikation der Bibliothek ergeben sich jedoch keinerlei weitere Auswirkungen und das gesamte restliche Programm, welches die Bibliothek benutzt bzw. dynamisch einbindet, darf anderweitig lizensiert werden.
Anhand der beiden Paradebeispiele für Lizenzen, also Apache und MIT, lässt sich leicht die Grundintention hinter den permissiven Lizenzen aufzeigen: Freie Software bereitstellen, wobei eigene Modifizierungen der Nutzer nicht an den Softwaregeber zurückgeschickt werden müssen. Der Lizenztext der Apache 2.0 ist zwar um einiges länger und ausführlicher geschrieben als jener der MIT-Lizenz, beinhaltet aber zusätzlich nur die Bedingung, dass Buch über die vollzogenen Modifikationen geführt werden muss und der eigene Produktname eines Nutzers nicht auf den Namen Apache hinweisen darf.
Grundsätzlich eignen sich derart freizügige Lizenzierungsmodelle wie MIT, BSD3 und Apache 2.0 für Projekte von eher geringer Schöpfungshöhe. Also Projekte, für die theoretisch geringere Fähigkeiten und wenig Aufwand notwendig sind, um das Programm von Grund auf selbst neu zu schreiben. Denn dann ist das Interesse der Codeautoren, den Code explizit zu schützen, meist begrenzt.
Kreation und Funktion
Während die kreativen Aspekte von Software diese zu einem Subjekt des Urheberrechts machen, werden die funktionalen Aspekte durch das Patentrecht geschützt. Der Inhaber eines Patents ist befähigt, Andere von der Nutzung und Kopie der Software auszuschließen.
Patentrechtlich relevant wird Software als solche nur, wenn sie „ein Verfahren implementiert, das technischer Natur ist“ beziehungsweise ein „technisches Mittel zur Lösung eines konkreten technischen Problems“ darstellt.
Es muss jedoch im Einzelfall entschieden werden, ob der Open-Source-Code respektive eine „computerimplementierte Erfindung“ im Fall eines Rechtsstreits als Subjekt des Patentrechts angesehen werden kann oder nicht. Implizit enthalten die von der Open-Source-Initiative gekennzeichneten Lizenzen bereits ein „patent grant“. Jedoch steht bei fehlender expliziter Regelung der Umfang der übertragenen Patentrechte nicht fest, weshalb einige Lizenzen auch explizit den Patentanspruch regeln.
Es muss jedoch im Einzelfall entschieden werden, ob der Open-Source-Code respektive eine „computerimplementierte Erfindung“ im Fall eines Rechtsstreits als Subjekt des Patentrechts angesehen werden kann oder nicht. Implizit enthalten die von der Open-Source-Initiative gekennzeichneten Lizenzen bereits ein „patent grant“. Jedoch steht bei fehlender expliziter Regelung der Umfang der übertragenen Patentrechte nicht fest, weshalb einige Lizenzen auch explizit den Patentanspruch regeln.
In den Lizenztexten von Apache 2.0 oder auch GPL werden jegliche Patentrechte übertragen, wohingegen sie bei MIT und der BSD3 nicht explizit genannt werden, jedoch sinnhaft durch andere Rechtszugeständnisse ersetzt werden. Gerade bei umfangreicheren Programmen führt diese Patentbeendigungsklausel der Apache 2.0 daher zu einem Vorteil gegenüber anderen freizügigeren Lizenzen ohne Copyleft-Effekt. Denn Nutzer und Entwickler müssen keine Klage aufgrund von Patentrechtsverletzungen eines Urhebers befürchten.
Entscheidend bei der Lizensierung von Programmen ist außerdem die Kompatibilität der Non-Copyleft-Lizenzen mit den Copyleft-Lizenzen der GPL-Reihe. Während BSD3 und MIT grundsätzlich mit jeglichen GPL-Varianten vereinbar sind, lässt sich ein Produkt unter Apache 2.0 aufgrund ihrer Patentbeendigungs- und Schadensersatzklauseln nicht mit Komponenten unter GPL v2 kombinieren.
Sieben klassische Use Types
Die Unterschiede zwischen den Lizenztexten lassen sich vor allem anhand des Umgangs mit den verschiedenen Nutzungskontexten feststellen. Herauskristallisiert haben sich folgende Use Types:
- Bereitstellung der Open-Source-Komponente im Source-Code-Format oder kompiliert;
- Abhängigkeit des Produkts von der Komponente oder optionales Laden, sodass das Produkt auch ohne Komponente funktioniert;
- Interne Nutzung ohne Distribution über die Grenzen einer legalen Entität hinaus oder Distribution;
- Lokaler Aufruf der Komponente oder Remote Call (SaaS);
- Kommunikation mit der Komponente über In-process-Mechanismus, wie einen Funktionsaufruf, oder über ein System oder Netzwerk-Dienst, wie eine Pipe oder ein Socket;
- Sichtbarkeit der Komponentenartefakte als noch eigenständige Teile oder Einbettung in das Produkt, sodass die Komponente nicht mehr offensichtlich als solche erkennbar ist;
- Vorliegen der Artefakte als unverändert, wie vom Anbieter empfangen oder modifiziert.
Anhand der Einordnung der Nutzung einer Open-Source-Komponente lassen sich zutreffende Passagen aus dem Lizenztext leichter finden und bestimmte Verpflichtungen ausschließen oder bestätigen. Da die exakte Wortwahl der englischsprachigen Lizenztexte jedoch in ihrer Bedeutung variieren kann und für Laien auf dem Rechtsgebiet nicht immer eindeutig ist, ist Genauigkeit bei der Analyse der Lizenzen gefragt. Auch wenn die vorgestellten sechs der gebräuchlichsten Lizenzen gut etabliert und dadurch umfassend aufgearbeitet sind, ist es dennoch wichtig, alle Eventualitäten bei der Auslegung der Lizenztexte zu bedenken, um eine Rechtsverletzung zu vermeiden.
Diese Verpflichtungen entstehen
Die grundsätzlichen Verpflichtungen, die aus jeder der betrachteten Open-Source-Lizenzen entstehen, sind das Bereitstellen des kompletten Lizenztextes und des originalen Urheberrechtshinweises (Copyright Notice), sowie die Bedingung, dass der Autor des Codes nicht für daraus resultierende Schäden verantwortlich gemacht werden kann. Außerdem dürfen keine Lizenzgebühren für die Verschaffung von Nutzungsrechten erhoben werden. Für den Verkauf der Software selbst kann theoretisch ein Entgelt verlangt werden, jedoch darf ein Käufer diese kopieren und Kopien des Codes weiterverbreiten, ohne dem Lizenzgeber dafür etwas zu bezahlen.
Der Haftungsausschluss ist mit deutschem Recht jedoch nicht vereinbar, da eine Haftung im Fall von Vorsatz und grober Fahrlässigkeit nach §521 BGB nicht auszuschließen ist, wenn man die dauerhafte Überlassung von Open-Source-Code als Schenkung auslegt.
Bei den permissiveren Lizenzen kommen nicht mehr allzu viele Verpflichtungen dazu, da die Nutzung des Codes sowohl Modifizierungen, Redistributionen als auch die kommerzielle Verwendung einschließt. Sowohl Apache 2.0 und BSD3 fordern, dass der Name der Komponente bei Modifizierung und Redistribution geändert werden muss, sodass sich bei der Namensgebung oder Bewerbung eines Produkts eines Nutzers nicht darauf schließen, dass die Lizenzgeberin University of California, Berkeley beziehungsweise die Apache Software Foundation an diesem direkt beteiligt sei. Namenszusätze wie „basierend auf Apache Hadoop“ beispielsweise sind jedoch erlaubt.
Eine Besonderheit der Apache 2.0 ist zudem, dass die durchgeführten Veränderungen des Codes notiert werden müssen und wenn bereits eine solche NOTICE-Datei mit dieser Dokumentation vorliegt, dieses zusammen mit dem abgeleiteten Werk ebenfalls mitzuliefern ist, sofern sich die Inhalte des Dokuments auch auf verwendete Bestandteile des genutzten Codes beziehen.
Die aktuelle Version der GPL-Lizenzen – GPL v3 – zeichnet sich durch ihren umfassenden Copyleft- Effekt aus. Wie ihre Vorgängerversion GPL v2 erfordert sie somit, dass abgeleitete Werke als Ganzes auch wieder unter dieselbe Lizenz gestellt werden müssen und greift in ihrem Wirkungsraum somit auch auf zusätzliche Teile eines aggregierten Programmes über. Dieser virale Effekt hat zur Folge, dass auch darauf aufbauend und entstehender proprietärer Source Code offengelegt werden muss – unabhängig davon, ob die Open-Source-Komponente dynamisch oder statisch gelinkt wird.
Eine Ausnahme hiervon machen die beiden Lizenzen dann, wenn die Komponente sowieso im Source-Format übermittelt wird. Außerdem führt bei GPL v2 eine lediglich interne Distribution oder das reine Ausführen des Codes – also wenn ein Programm eine für sich eigenständige Open-Source-Komponente optional laufen lässt, zu einem Wegfallen jeglicher Lizenzverpflichtungen. Ob die Komponente hierbei lokal oder remote aufgerufen wird, spielt keine Rolle – wichtig ist nur, dass sie nicht in ein Programm eingebunden, sondern über Kommunikationsmechanismen wie pipes, sockets oder per command-line genutzt wird.
Die Konsequenz für Cloud Computing
Die Nachfolgelizenz GPL v3 stellt hierauf aufbauend explizit klar, dass es nicht als Redistribution gilt, wenn die Interaktion mit einem Programm per Computernetzwerk erfolgt und betitelt die bloße Bereitstellung von Kopien ohne den tatsächlichen Transfer einer Kopie als „Propagation“ statt als Akt der Distribution („Conveying“). Die bloße Nutzung einer Open-Source-Komponente, indem diese remote aufgerufen wird, ohne eine Kopie des Codes zu übertragen, ist somit ohne zusätzliche Verpflichtungen erlaubt. Wie auch bei der GPL v2 kommt es bezüglich der Lizenzverpflichtungen nur auf die tatsächliche Distribution an, da das Ausführen des Codes ja nicht eingeschränkt ist.
Bei der Bereitstellung durch einen Application Service Provider (ASP) oder einen Cloud-basierten Einsatz besteht keine Pflicht zur Offenlegung des Source Codes – der Copyleft-Effekt greift in diesem Fall nicht auf ein gesamtes Produkt über, das lediglich die Open-Source-Komponente remote aufruft. Dies hat vor allem in Bezug auf Cloud Computing Bedeutung.
Wie bereits vermerkt, ermöglicht der neuere Lizenztext von GPL v3 außerdem die Kompatibilität mit beispielsweise Apache 2.0. Eine zusätzliche Verpflichtung der Lizenz trifft für die Verbreitung modifizierter Versionen zu: Es müssen demnach Hinweise zur Installation der veränderten Software an die „Third Party“, die die Software erhält, gegeben werden.
Die LGPL 2.1 findet vor allem bei Programmbibliotheken Anwendung, die unmodifiziert aufgerufen und nicht obligatorisch in ein Programm eingebunden werden. Solange der Open-Source-Code demnach nicht mit dem Programm übergeben wird, sondern die Bibliothek nur dynamisch gelinkt wird, greift der Copyleft-Effekt der Lizenz nicht auf das komplette Programm über, sodass dieses nicht unbedingt unter LGPL lizensiert werden muss.
Dieser Unterschied macht den schwächeren Copyleft-Effekt der LGPL 2.1 im Vergleich zu den reinen GPL-Lizenzen aus: Nur bei Veränderung der Open-Source-Komponente selbst muss deren Source Code offengelegt werden. Der schwache Copyleft-Effekt von LGPL greift also nicht auf das Gesamtwerk über, sondern betrifft nur die modifizierte Komponente selbst. Wenn Abschnitte des Codes jedoch als Teil eines Ganzen, welches auf dem Open-Source-Code basiert, eingebettet publiziert werden oder Teile einer Bibliothek mit übergeben werden, muss auch die Distribution dessen in Übereinstimmung mit dem Lizenztext von LGPL 2.1 geschehen.
Beim statischen Linken einer Bibliothek gestaltet es sich jedoch etwas anders: es muss entweder sowohl proprietärer (eigener) Code, als auch die Bibliothek unter LGPL lizensiert sein, oder es muss bei Distribution sichergestellt werden, dass der Nutzer auch mit einer anderen Version des LGPL Source Codes die Bibliothek neu linken kann – somit muss zwar kein Source Code der proprietären Software übergeben werden, aber die Object Files.
Insofern verhält sich die Lizenz bei einer rein internen Nutzung und der bloßen Ausführung der unmodifizierten Open-Source-Komponente durch dynamisches Linken sehr freizügig: Jegliche Verpflichtungen des Lizenztextes entfallen. Das eröffnet die Möglichkeit, Programme unter GPL v2, GPLv3 oder LGPL 2.1 durch SaaS-Produkte zugänglich zu machen, ohne die weiteren Lizenzbedingungen wie die Offenlegung des Source Codes und ähnliches einhalten zu müssen. Die GNU Affero General Public License (kurz AGPL) schließt diese Schwachstelle, indem sie auch als SaaS bereitgestellte Open-Source-Software als „conveying“ betitelt. Somit sind auch die regulären Pflichten wie die Weitergabe des Source Codes einzuhalten.
Unwissenheit schützt vor Strafe nicht
Zum Jahresbeginn 2021 ließ sich Spannendes beobachten. Elasticsearch wechselte von Apache 2.0 hin zur Server Side Public License (kurz SSPL). Die SSPL stellt keine von der Open Source Initiative akzeptierte Open-Source-Lizenz dar. Auch andere Open-Source-Programme gingen von einer permissiven Lizenz zu einer Lizenz mit weitgreifenden Copyleft- bzw. Nutzungsrechtseinschränkungen über. Die Intention hinter diesen Relizenzierungen ist, ASPs und Cloud Provider wie Amazon Web Services daran zu hindern, Freizügigkeiten der Apache 2.0 für gehostete Versionen auszunutzen und somit die Open-Source-Programme zu verwenden, ohne wiederum selbst einen Beitrag zur Community zu leisten. So passten neben Elastic auch Grafana, Redis Labs, MongoDB, Timescale und Cockroach Labs ihre freien Lizenzen an.
Lediglich Grafana ging zu der von der OSI als Open-Source-Lizenz gelisteten AGPLv3 über, um dem Ideal der fairen Open-Source-Nutzung treu zu bleiben und das Prinzip der Nichtdiskriminierung – weder von einzelnen Personen, Regierungen, religiösen Organisationen oder eben auch der „Trillion Dollar Corporation“ Amazon – beim Wort zu nehmen.
MongoDB begründet den Wechsel von AGPL zu der von ihr in 2018 publizierten SSPL vor allem damit, das Potenzial eines Open-Source-Ansatzes bezüglich der Robustheit und Sicherheit der Software nutzen zu wollen. Gleichzeitig will das Unternehmen verhindern, dass die großen Cloud-Anbieter Open-Source-Produkte als SaaS bereitstellen, ohne einen eigenen Beitrag zu den Community-Projekten zu leisten. Die AGPL, unter der die Datenbankdienste von MongoDB zuvor lizensiert waren, sah im Vergleich dazu lediglich vor, dass dem Kunden modifizierter Code zugänglich gemacht werden muss, sobald die Software „as a service“ bereitgestellt wird.
SSPL basiert auf GPLv3 und unterscheidet sich nur insofern, dass sich die Lizenzbedingungen auch auf die Distribution der Software als Dienst ausweiten. Als Konsequenz muss der komplette Source Code inklusive zugehöriger Teile des Dienstes wie Schnittstellen, Speicher und Hosting-Software – quasi der „Service Source Code“ – der Öffentlichkeit zugänglich gemacht werden. Das steht im Gegensatz zu AGPL, auch wenn die Open-Source-Komponente unmodifiziert verwendet wird.
Ergebnislose Diskussionen sind absehbar
Gerade an diesem Punkt lässt sich über das zukünftige Verfahren mit dem Open-Source-Konzept diskutieren: Unterliegt der reinen Open-Source-Definition auch eine normative, wenn es darum geht, wer von dem Code profitieren darf und sollte das Diskriminierungsverbot weiterhin durchgesetzt werden? Oder ist es gerade in Anbetracht der Veränderungen des Marktes hin zu der Nutzung jeglicher Software als Dienst wichtig, doch Unterscheidungen innerhalb der Profiteure und der Community zu treffen?
Wie die jeweiligen Lizenztexte im Ernstfall ausgelegt werden, muss entsprechend in jedem Fall einzeln untersucht werden, da es sich beim Urheber- und Patentrecht von Software genauso verhält, wie bei jenem für Kunst oder Musik. Jedoch lässt sich sagen, dass die generellen Ziele der Open Source Community bekannt sind und die Grundintention hinter den Lizenzen bereits einen Hinweis darauf geben kann, ob man sich mit der spezifischen Nutzung von Open-Source-Code rechtlich gesehen in sicheren Gewässern oder einer Grauzone befindet.
Es ist demnach eine Good Practice, bereits vor dem Verbauen einer Komponente zu prüfen, ob die Einbindung in Anbetracht des Nutzungsziels überhaupt möglich ist und keine eventuell schwerwiegenden Verpflichtungen nach sich zieht.
*Theresa Kern arbeitet bei msg Research. Dort beschäftigt sie sich intensiv mit dem Thema Open Source Lizenzierung im Umfeld betrieblicher Informationssysteme.
Be the first to comment