Der Open-Source-Dschungel: Rechtliche Fragen im Rampenlicht

Software ist in der Schweiz durch das Urheberrechtsgesetz (URG) geschützt. Das Urheberrecht an Software entsteht automatisch mit der Erstellung der Software. Es bedarf dazu keiner Registrierung, Veröffentlichung oder sonstigen amtlichen Anerkennung. Demzufolge gibt es in der Schweiz auch kein Eigentumsregister für Urheberrechte.

Das URG gewährt dem Entwickler (Urheber) verschiedene ausschliessliche Rechte. So kann er unter anderem über die Vervielfältigung, Änderung und öffentliche Zugänglichmachung der Software entscheiden. Durch das Urheberrecht wird nur der Code selbst geschützt, nicht aber die Idee oder die Funktion, die der Software zu Grunde liegt. Solange der Code nicht kopiert wird, kann die Idee oder Funktion einer Software also einfach kopiert werden, ohne dass das Urheberrecht verletzt wird. Um die Idee oder Funktion einer Software zu schützen, besteht die Möglichkeit, die Software durch Patente zu schützen. Entgegen einer weit verbreiteten Meinung ist dies auch in Europa nahezu uneingeschränkt möglich.

Das Urheberrecht schützt bei Computerprogrammen grundsätzlich die konkrete Umsetzung einer Idee, insbesondere den individuell gestalteten Quellcode. Die dahinterstehende Idee, eine mathematische Methode oder die blosse Funktion eines Programms ist dagegen grundsätzlich nicht urheberrechtlich geschützt.

Schwieriger wird die Abgrenzung, wenn sich eine Idee technisch nur auf wenige Arten umsetzen lässt. Dann liegen Idee und konkrete Umsetzung sehr nahe beieinander. Nach der im US-amerikanischen Recht entwickelten «Merger Doctrine» kann eine Software, deren Ausdrucksform mit der Idee «verschmilzt» nicht urheberrechtlich geschützt werden. Der Urheberrechtsschutz soll in solchen Fällen nicht dazu führen, dass über den Schutz des Quellcodes faktisch auch die zugrunde liegende Idee oder Methode monopolisiert wird.

In der Schweiz ist die Merger Doctrine zwar kein eigenständiger Rechtsgrundsatz. Das Schweizer Urheberrecht kann jedoch zu einem ähnlichen Ergebnis führen: Geschützt ist die individuell gestaltete Ausdrucksform, nicht die dahinterstehende Idee. Je stärker ein Quellcode durch technische Vorgaben, Standards oder die gewünschte Funktion vorgegeben ist, desto enger kann daher sein urheberrechtlicher Schutz sein.

Ein Algorithmus kann jedoch auf andere Weise geschützt werden, etwa durch Geheimhaltung, vertragliche Regelungen oder – sofern die entsprechenden Voraussetzungen erfüllt sind – durch ein Patent.

Eine Lizenz ist ein rechtlicher Vertrag zwischen dem Inhaber der Urheberrechte (Lizenzgeber) und einem Nutzer (Lizenznehmer), durch den dem Nutzer ein vertragliches Nutzungsrecht eingeräumt wird. Die Nutzungsrechte an einer Software können unterschiedlich ausgestaltet sein. Einerseits kann ein umfassendes Recht eingeräumt werden, das sowohl die Nutzung als auch die Vervielfältigung, Änderung und öffentliche Zugänglichmachung der Software umfasst.

Andererseits können die verschiedenen im Urheberrecht enthaltenen Rechte auch einzeln eingeräumt werden (sog. «Bundle of Sticks»). Lizenzen ermöglichen es dem Urheber auch, unterschiedliche Lizenz- und Geschäftsmodelle umzusetzen, indem die Nutzungsrechte massgeschneidert angepasst und mit spezifischen Bedingungen verknüpft werden. So kann z.B. die Nutzung der Software kostenlos, die kommerzielle Verbreitung aber kostenpflichtig sein.

OSS ist Software, deren Quellcode öffentlich zur Verfügung steht und von Dritten eingesehen, geändert und genutzt werden kann. OSS wird unter Lizenzen veröffentlicht, deren Nutzungsbedingungen unterschiedlich ausgestaltet sein können. Grundsätzlich wird zwischen zwei Lizenztypen unterschieden: Copyleft Lizenzen und freizügige (auch permissive) Open-Source-Lizenzen. Der wichtigste Unterschied der beiden Lizenzen zeigt sich bei der Weitergabe der bearbeiteten OSS. Während bei der Copyleft-Lizenz Bearbeitungen der Software zwingend unter die gleiche Lizenz gestellt werden müssen (sogenannter «viraler Effekt»), besteht bei der freizügigen Open-Source-Lizenz eine solche Verpflichtung nicht.

Nein. Open-Source bedeutet nicht, dass die Nutzung des Quellcodes ohne Einschränkung erlaubt ist. Wie bei proprietären Lizenzen wird die Nutzung an Bedingungen geknüpft, die vom Inhaber der Urheberrechte (dem Lizenzgeber) festgelegt werden. Die meisten Lizenzen beschränken sich dabei auf Bedingungen, die in direktem Zusammenhang mit der Weitergabe stehen. Dazu gehören zum Beispiel die Pflicht, den Lizenztext mit der Software mitzuliefern, den Urheber zu nennen oder alle Änderungen am Code durch ein Änderungsprotokoll nachvollziehbar zu machen. Es gibt aber auch Open-Source-Lizenzen, die den Nutzer dazu verpflichten, dem Lizenzgeber bei einem persönlichen Treffen ein Bier zu kaufen (Beerware License) oder einen bestimmten Tanz aufzuführen und ein Video davon in sozialen Netzwerken zu veröffentlichen (Chicken Dance License).

Open Source bedeutet, dass der Quellcode öffentlich verfügbar ist und auch kostenlos genutzt werden kann. Die ausführbare Software, die auf einem OSS-Quellcode basiert, muss indes nicht kostenlos weitergegeben werden. Die Umwandlung des Quellcodes in ausführbare Software (Kompilierung) erfordert Fachwissen, Zeit und Ressourcen, die nicht jeder Nutzer zur Verfügung hat oder aufwenden will. Entwickler können die Kompilierung des Quellcodes deshalb gegen Entgelt anbieten, auch wenn der Quellcode als OSS verfügbar ist.

Ein gutes Beispiel hierfür ist die Linux-Distribution «Red Hat Enterprise Linux», die vom Softwarehersteller «Red Hat» angeboten wird. Der Quellcode der Software ist frei als OSS verfügbar und kann auf Plattformen wie GitHub eingesehen werden. Möchte ein Unternehmen jedoch den produktionsbereiten Code der Software erhalten, ohne ihn selbst aus dem Quellcode rekonstruieren zu müssen, muss es eine kostenpflichtige Subskription erwerben.

Die Verwendung des Begriffs „Free Software“ im Zusammenhang mit Open-Source-Software (OSS) führt häufig zu Missverständnissen darüber, ob Entwickler von OSS für ihre Arbeit Geld verlangen dürfen. Die Free Software Foundation erklärt hierzu:

„Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer.’”

Entgegen einem weit verbreiteten Irrtum ist es keineswegs verboten, Quellcode, der unter einer gängigen Copyleft-Lizenz veröffentlicht wurde, zu kommerzialisieren. Der Urheber darf beispielsweise für Kopien des lizenzierten Codes (in Quell- oder Binärform) ein Entgelt verlangen oder Gebühren für Supportleistungen sowie für das Anbieten einer Garantie erheben. Auch wenn der Quellcode auf einem physischen Datenträger bereitgestellt wird, dürfen angemessene Kosten für dessen Erstellung und Verteilung berechnet werden.

Ein weiteres Beispiel ist das Angebot von kostenpflichtigen Erweiterungen oder Premium-Funktionen für eine Open-Source-Software. Viele Unternehmen verwenden Open-Source-Software als Basis und bieten dann zusätzliche Funktionen, die nur gegen Bezahlung erhältlich sind, wie es zum Beispiel bei Open-Core-Modellen der Fall ist. Auch im Bereich Cloud-Services ist eine kommerzielle Nutzung möglich. Anbieter wie „Red Hat“ oder „Canonical“ bieten Open-Source-Software wie „Linux“ oder „OpenStack“ kostenlos zum Download an, verdienen aber durch die Bereitstellung von Support-Diensten, massgeschneiderten Lösungen und Cloud-Infrastrukturdiensten Geld.

Die Lizenzierung von Software unter einer Open-Source-Lizenz bedeutet somit nicht, dass die Software umsonst oder ohne die Möglichkeit, Geld zu verdienen, angeboten werden muss. Vielmehr geht es um die Freiheit, den Code zu nutzen, zu verändern und weiterzugeben. Entwickler können somit durchaus kommerzielle Geschäftsmodelle auf Basis von Open-Source-Software aufbauen, sei es durch kostenpflichtige Zusatzfunktionen, Support oder massgeschneiderte Dienstleistungen.

Nein. Die Publikation bezieht sich auf die Veröffentlichung der Software, z.B. durch das Hochladen des Quellcodes in ein Repository wie GitHub. Damit wird die Software der Allgemeinheit und insb. der Open-Source-Community zugänglich gemacht, die die Software nun prüfen, analysieren und Verbesserungen vorschlagen kann (sog. Community Audits). Diese Transparenz fördert die Qualität, die Sicherheit, das Vertrauen der Nutzer und die Innovation von OSS.

Die Lizenzierung hingegen bezieht sich auf die rechtlichen Bedingungen, unter denen die Software genutzt, verändert und verbreitet werden darf. Sie legt fest, welche Rechte und Pflichten den Nutzern der Software eingeräumt werden. Nur weil ein Quellcode veröffentlicht wurde, heisst das also noch lange nicht, dass er in eine bestehende Codebasis integriert, verändert oder weitergegeben werden darf. Aufgrund der leichten Zugänglichkeit von veröffentlichter Software ist es allerdings schwierig, eine solche Nutzung zu verhindern. Die Veröffentlichung des Quellcodes birgt daher immer die Gefahr, dass die Urheberrechte oder Lizenzbedingungen des Urhebers durch Dritte verletzt werden.

Die Lizenzierung von Software unter einer Open-Source-Lizenz bietet zahlreiche Vorteile, die weit über die blosse Offenlegung des Quellcodes hinausgehen. Einer der wichtigsten Vorteile liegt in der rechtlichen Klarheit. Durch etablierte Open-Source-Lizenzen wird genau definiert, wie die Software genutzt, verändert und weitergegeben werden darf. Dadurch lassen sich Unsicherheiten vermeiden, und sowohl Entwickler als auch Unternehmen erhalten eine verlässliche Grundlage für den Einsatz und die Weiterentwicklung der Software. Da Open-Source-Lizenzen den Zugang zur Software ohne komplizierte Lizenzverhandlungen ermöglichen, können sie schneller von Unternehmen, Behörden oder Entwicklern übernommen werden.

Ein weiterer Vorteil ist die Unterstützung durch die Community. Open-Source-Software lebt von der Zusammenarbeit: Andere Entwickler können Fehler melden, Sicherheitslücken identifizieren und aktiv zur Weiterentwicklung beitragen. Dadurch wird die Software nicht nur stabiler, sondern kann sich auch deutlich schneller verbessern. Statt sich auf ein einziges Entwicklerteam oder einen Hersteller zu verlassen, profitieren Open-Source-Projekte von der kollektiven Überprüfung durch eine breite Community.

Neben den technischen und rechtlichen Vorteilen bietet Open Source auch wirtschaftliche Chancen. Entwickler können durch Dienstleistungen wie Support, Beratung oder massgeschneiderte Implementierungen Einnahmen erzielen. Viele erfolgreiche Unternehmen setzen auf ein Open-Core-Modell, bei dem die Basisversion einer Software kostenlos ist, während erweiterte Funktionen oder Premium-Support kostenpflichtig angeboten werden.

Die «Open Source Initiative», eine 1998 gegründete Organisation zur Förderung von OSS, hat mehr als 80 Open-Source-Lizenzen anerkannt. Diese Lizenzen fallen in der Regel in eine von zwei Kategorien: Freizügige Lizenzen und Copyleft-Lizenzen:

• Freizügige Lizenzen ermöglichen es anderen Entwicklern (Dritten), die Software nach Belieben zu verwenden, solange sie bestimmte Lizenzpflichten (z. B. die Nennung des Autors) einhalten. Dritte können somit frei entscheiden, unter welcher Lizenz sie eigene Modifikationen der Software weitergeben möchten.
• Copyleft-Lizenzen hingegen verpflichten andere Entwickler (Dritte), bei der Weitergabe von Modifikationen der Software auch die eigene Weiterentwicklung unter der ursprünglichen Open-Source-Lizenz anzubieten (sogenannter viraler Effekt). Dies hat beispielsweise (wie unter der GPL v3) zur Folge, dass der Quellcode der eigenen Weiterentwicklung bei Weitergabe gemäss den Lizenzbestimmungen offengelegt werden muss, dass für die Nutzung keine Lizenzgebühren erhoben werden dürfen und dass dem Empfänger die Weiterverbreitung der Software nicht untersagt werden kann.

Unter welcher Lizenz das eigene Open-Source-Projekt lizenziert werden soll, ist immer eine Frage des Einzelfalls. Entwickler sollten sich in einem ersten Schritt überlegen, ob sie damit einverstanden sind, wenn Dritte eine proprietäre Version ihrer Software erstellen und mit der Software Geld verdienen, ohne selbst einen Beitrag zu leisten. Falls ja, eignet sich eine freizügige Lizenz. Andernfalls ist eine Copyleft-Lizenz zu wählen. Wird eine Copyleft-Lizenz gewählt, ist insbesondere zu entscheiden, wie stark der virale Effekt sein soll:

• Starke Copyleft-Lizenzen, wie die GNU General Public License (GPL), erlauben die Modifikation und Weiterverbreitung des ursprünglichen Codes, jedoch nur unter der Bedingung, dass das gesamte abgeleitete Werk ebenfalls unter derselben Lizenz veröffentlicht wird. Dies stellt sicher, dass der ursprüngliche Quellcode sowie alle Weiterentwicklungen für die Community zugänglich bleiben.
• Bei schwächeren Copyleft-Lizenzen, wie die Mozilla Public License (MPL), beschränkt sich der virale Effekt auf die direkt modifizierten Dateien. Wird eine der ursprünglichen Dateien verändert, muss diese unter der MPL lizenziert und bei der Weitergabe veröffentlicht werden. Entwickelt ein Autor jedoch neue Dateien unabhängig vom ursprünglichen MPL-Code, können diese unter einer anderen Lizenz veröffentlicht oder sogar proprietär gehalten werden. Dieses Prinzip wird häufig als "file-based Copyleft" bezeichnet, da die Lizenzpflichten auf Datei-Ebene beschränkt bleiben.

Weiter können Gedanken zur Kompatibilität mit anderen Softwarelizenzen sowie das Ziel der Lizenzierung (z.B. Kommerzialisierung) für die Wahl der Open-Source-Lizenz ausschlagegebend sein. Grundsätzlich ist es empfehlenswert, sich bei der Auswahl an den etablierten, weitest verbreiteten Lizenzen zu orientieren und exotische Lizenzen oder die Entwicklung eigener Lizenzen zu vermeiden. Auch ist es ratsam, einen englischen Lizenztext zu wählen, um bei einer internationalen Nutzung keine unnötigen Sprachbarrieren aufzubauen.

Ja, es können neue Lizenzen geschaffen werden. Um als Open-Source-Lizenz anerkannt zu werden, müssen sie jedoch das Prüfverfahren der «Open Source Initiative» durchlaufen. Damit eine Lizenz von der «Open Source Initiative» anerkannt wird, muss sie bestimmte Anforderungen erfüllen, wie zum Beispiel die Gewährleistung der freien Weitergabe, die Bereitstellung des Quellcodes, die Möglichkeit, den Quellcode zu verändern und weiterzugeben, die Nichtdiskriminierung von Personen oder Gruppen, die Unabhängigkeit von Produkten, keine Einschränkungen für andere Software sowie die Technologieneutralität.

Damit eine Lizenz als Open-Source-Lizenz anerkannt wird, muss sie wie oben beschrieben der Open-Source-Definition entsprechen und den Lizenzprüfungsprozess der «Open Source Initiative» durchlaufen haben. Eine anerkannte Open-Source-Lizenz darf daher nicht ohne weiteres verändert werden. Werden dennoch Änderungen an einer anerkannten Lizenz vorgenommen, so handelt es sich nicht mehr um die ursprüngliche Lizenz, sondern um eine neu geschaffene Lizenz (was an sich zulässig ist). In diesem Fall darf jedoch kein Verweis auf den ursprünglichen Lizenznamen gemacht werden.

Die Lizenzierung unter einer Open-Source-Lizenz ist grundsätzlich endgültig. Software, die unter einer bestimmten Open-Source-Lizenz veröffentlicht wurde, kann weiterhin nach den Bedingungen dieser Lizenz genutzt und weitergegeben werden, selbst wenn der ursprüngliche Lizenzgeber die Software später entfernt oder für künftige Versionen eine andere Lizenz verwendet. Nutzer oder nachfolgende Entwickler, welche die Software bereits unter diesen Bedingungen erhalten haben, behalten somit grundsätzlich die ihnen eingeräumten Rechte. Die Open-Source Lizenzierung kann für bereits veröffentlichte Versionen folglich nicht rückgängig gemacht werden.

Es ist jedoch möglich, neue Versionen einer Software unter einer anderen Lizenz zu veröffentlichen, beispielsweise um diese zu kommerzialisieren. Voraussetzung ist, dass der Rechteinhaber über die dafür erforderlichen Rechte am gesamten betroffenen Quellcode verfügt. Haben externe Entwickler Beiträge geleistet, kann ein Lizenzwechsel deren Zustimmung oder eine entsprechende Berechtigung aus einem Contributor License Agreement (CLA) voraussetzen.

Ein Projekt kann somit beispielsweise zunächst unter einer Open-Source-Lizenz veröffentlicht werden, um Marktanteile zu gewinnen und eine Community aufzubauen, und spätere Versionen unter einer kommerziellen oder anderen Lizenz anbieten. Bereits zuvor unter der ursprünglichen Open-Source-Lizenz veröffentlichte Versionen bleiben jedoch weiterhin nach deren Bedingungen nutzbar. 

Wird ein öffentliches Repository auf «private» gestellt, ist der Quellcode für neue Nutzer nicht mehr frei zugänglich. Bereits eingeräumte Rechte aus einer gültigen OSS-Lizenz werden dadurch jedoch grundsätzlich nicht rückwirkend entzogen.

Wer den Quellcode zuvor rechtmässig unter einer OSS-Lizenz bezogen hat, darf ihn weiterhin nach den Bedingungen dieser Lizenz nutzen, bearbeiten und – soweit erlaubt – weitergeben. Auch bestehende Forks werden durch die Umstellung des ursprünglichen Repositories nicht automatisch unzulässig. Allein das Entfernen des Repositories oder des Lizenztexts ändert daran grundsätzlich nichts.

In der Praxis kann allerdings der Nachweis entscheidend sein: Welche Version wurde wann und unter welcher Lizenz bezogen? Entwickler und Unternehmen sollten deshalb Versionen und die dazugehörigen Lizenzinformationen sorgfältig dokumentieren.

Wichtig ist zudem, dass die blosse Veröffentlichung von Quellcode in einem öffentlichen Repository diesen noch nicht zu Open Source macht. Dafür muss der Rechteinhaber entsprechende Nutzungsrechte einräumen, typischerweise durch eine ausdrücklich angegebene OSS-Lizenz.

Werden die Urheberrechte an einer Software übertragen, etwa im Rahmen eines Asset Deals, bleiben bereits wirksam erteilte OSS-Lizenzen nach der hier vertretenen Auffassung bestehen. Auch wenn die dogmatische Einordnung nicht abschliessend geklärt ist, sprechen insbesondere praktische Erwägungen dafür. Das Open-Source-Modell setzt voraus, dass sich Nutzer und Entwickler auf bereits eingeräumte Rechte verlassen können. Könnten diese durch einen Rechteübergang entfallen, würde dies die kooperative Weiterentwicklung gefährden und dem Grundgedanken von Open Source widersprechen.

Nach dieser Auffassung übernimmt der neue Rechteinhaber die Software mit ihrer bestehenden Lizenzhistorie. Der Wechsel des Rechteinhabers lässt die bereits eingeräumten OSS-Nutzungsrechte an den veröffentlichten Versionen unberührt. Dies gilt allerdings vorbehaltlich zwingender Vorgaben der jeweils anwendbaren Rechtsordnung. Der neue Rechteinhaber kann jedoch künftige Versionen unter einer anderen Lizenz veröffentlichen, sofern er über die dafür erforderlichen Rechte am gesamten betroffenen Quellcode verfügt. Wenn externe Contributors eigene Rechte am Quellcode besitzen oder externe Komponenten in den Quellcode integriert wurden, setzt ein Lizenzwechsel unter Umständen die Zustimmung der jeweiligen Rechteinhaber voraus, sofern sich die erforderlichen Befugnisse nicht bereits aus den anwendbaren Lizenzen oder einem Contributor License Agreement (CLA) ergeben.

Bei Unternehmenstransaktionen sollte deshalb geprüft werden, wem die Rechte am Quellcode tatsächlich zustehen und welche OSS-Verpflichtungen bestehen. Relevant sind insbesondere Lizenzinformationen, CLAs, Arbeits- und Entwicklungsverträge sowie die Herkunft des Quellcodes. Eine unklare Rechte- oder Lizenzlage kann den Wert und die Veräusserbarkeit der Software erheblich beeinflussen.

Nahezu alle Open-Source-Lizenzen enthalten Regelungen zum Haftungsausschluss. Diese Haftungsausschlüsse sind jedoch häufig derart weit und umfassend formuliert, dass sie gegen zwingende gesetzliche Vorschriften verstossen (z.B. Haftungsausschluss für grobe Fahrlässigkeit und Vorsatz). Ist dies der Fall, ist die Klausel unwirksam und es gilt die volle gesetzliche Haftung. Das Gesetz schränkt die Haftung nur dann ein, wenn die Software unentgeltlich überlassen wird. In diesem Fall greift das Schenkungsrecht, wonach der Schenker (Entwickler) dem Beschenkten (Nutzer) nur bei Vorsatz oder grober Fahrlässigkeit haftet. Zu beachten ist, dass darüber hinaus auch noch Ansprüche aus dem Produktehaftpflichtgesetz, aus unerlaubter Handlung oder aus der Verletzung von Rechten Dritter (z.B. Urheberrechte) denkbar sind.

Ein Open-Source-Lizenzvertrag kommt in der Regel erst dann zustande, wenn der Nutzer der Software diese weitergibt. Solange ein Nutzer die OSS nicht weitergibt, sind die Open-Source-Lizenzbedingungen für ihn nicht relevant. Eine interne Nutzung ohne Weitergabe der OSS ist daher sowohl für Privatpersonen als auch für Unternehmen unproblematisch. Findet jedoch eine Weitergabe statt, müssen die jeweiligen Lizenzbedingungen eingehalten werden.

Wann eine Weitergabe als Weitergabe gilt, kann je nach Open-Source-Lizenz unterschiedlich sein. Grundsätzlich liegt eine Weitergabe vor, wenn die Software der Allgemeinheit zugänglich gemacht oder sie in Verkehr gebracht wird (z.B. Hochladen auf eine Website, Bereitstellung in einem Repository wie GitHub, direkter Datenaustausch oder Installation auf einem Server). Bei der Weitergabe ist zu beachten, dass der Open-Source-Lizenzvertrag immer zwischen dem ursprünglichen Urheber der Software (Lizenzgeber) und dem Nutzer der Software zustande kommt. Ein Nutzer vergibt also bei der Weitergabe der Software keine Unterlizenz an den nachfolgenden Nutzer, sondern es kommt ein Lizenzvertrag mit dem Urheber zustande.

Unter «Weitergabe» versteht man die Übertragung einer Kopie eines urheberrechtlich geschützten Werks, wie beispielsweise Software, von einer Rechtsperson auf eine andere. Das Prinzip der Weitergabe ist besonders wichtig für Unternehmen und Entwickler, die Open-Source-Software (OSS) einsetzen und in ihre eigenen Produkte integrieren, da viele Verpflichtungen aus OSS-Lizenzen erst bei einer Weitergabe an Dritte wirksam werden.

Entscheidend ist dabei nicht, wie die Software genutzt wird, sondern ob ein Dritter tatsächlich eine Kopie erhält. Solange eine Anwendung nur intern genutzt oder weiterentwickelt wird und keine externen Dritten eine Kopie erhalten, liegt keine Weitergabe vor. Damit werden die Pflichten aus OSS-Lizenzen in diesem Fall noch nicht ausgelöst. Eine Weitergabe liegt typischerweise vor, wenn (i) Software an Kunden ausgeliefert wird, (ii) Quellcode oder Binärdateien überlassen werden oder (iii) Software öffentlich zum Download bereitgestellt wird.

Wird Open-Source-Software nicht nur intern genutzt, sondern an Dritte weitergegeben – zum Beispiel durch die Auslieferung oder das Zurverfügungstellen einer Anwendung mit entsprechenden OSS-Komponenten – greifen bestimmte Lizenzpflichten. Diese unterscheiden sich je nach Lizenztyp und betreffen unter anderem Transparenzanforderungen, die Pflicht, Änderungen kenntlich zu machen, sowie die für Copyleft-Lizenzen typische Verpflichtung, die Software unter denselben Lizenzbedingungen weiterzugeben (siehe unten, Ziffer 18).

Um diese Pflichten zu kennen, müssen Entwickler spätestens beim Produkt-Release genau wissen, welche Komponenten in der Anwendung enthalten sind und unter welchen Lizenzen sie stehen. Es empfiehlt sich die Erstellung einer Software „Bill of Materials“ (BoM), die alle eingesetzten Komponenten samt Lizenzinformationen dokumentiert (siehe auch unten, Ziffer 20). Fehlen diese Informationen oder sind sie unvollständig, kann dies schnell zu Lizenzverstössen führen und rechtliche Risiken nach sich ziehen. Nur wenn problematische Komponenten rechtzeitig erkannt werden, können sie vor dem Release ersetzt oder unter einer geeigneten Lizenz in die Anwendung aufgenommen werden.

Zahlreiche Open-Source-Lizenzen verlangen, dass bei der Weitergabe von Software auf die verwendeten OSS-Komponenten hingewiesen wird. Die sogenannte «Notice»-Pflicht bedeutet, dass Empfänger darüber informiert werden müssen, welche Teile der Software unter welcher Lizenz stehen. In der Praxis werden dazu meist die vollständigen Lizenztexte beigelegt, Urheber und Mitwirkende genannt und gegebenenfalls der zugehörige Quellcode bereitgestellt.

Es hat sich bewährt, den von der Lizenz abgedeckten Quellcode bereits vor der Weitergabe bereitzustellen, da die Lizenztexte in der Regel als Textdateien im Quellcodepaket enthalten sind. Allerdings ist umstritten, ob die reine Einbettung der Lizenztextdateien im Quellcodepaket ausreicht, um den (teilweise) strengen Transparenzanforderungen von Open Source Lizenzen gerecht zu werden. Aus diesem Grund empfiehlt es sich, dem Quellcodepaket oder dem entsprechenden Repository eine zusätzliche Textdatei beizulegen, die klar beschreibt, unter welcher Lizenz die gesamte Anwendung veröffentlicht bzw. weitergegeben wird und unter welcher Lizenz die einzelnen Komponenten stehen.

Der sogenannte «virale Effekt» wird im Zusammenhang mit Copyleft-Lizenzen, insbesondere der GPL, häufig diskutiert. Er beschreibt die verbreitete Vorstellung, dass die Integration von Copyleft-Code in proprietäre Software automatisch dazu führen könnte, dass der eigene Code unter die Copyleft-Lizenz fällt und in der Folge der gesamte Code offengelegt werden muss – auch der eigene. Juristisch gesehen ist diese Vorstellung jedoch unzutreffend.

Copyleft-Lizenzen wie die GPL sehen vor, dass bei der Weiterverbreitung eines kombinierten Werks, das GPL-lizenzierten Code enthält und ein einheitliches «abgeleitetes Werk» bildet, der gesamte verbreitete Code unter den Bedingungen der GPL stehen muss. Wer gegen diese Bedingung verstösst, indem er das kombinierte Werk weitergibt, ohne den vollständigen Quellcode unter der GPL offenzulegen, verliert die Lizenzrechte am GPL-Code. Die weitere Verbreitung stellt dann eine Urheberrechtsverletzung dar, die Unterlassungs- und gegebenenfalls Schadensersatzansprüche nach sich ziehen kann.

Das Urheberrecht kennt jedoch keine Rechtsmittel, mit denen Entwickler gezwungen werden könnten, ihren proprietären Code aktiv unter die GPL zu stellen oder in die Public Domain zu überführen. Die Integration von GPL-Code „infiziert“ proprietären Code nicht automatisch und wandelt ihn nicht kraft Gesetzes in GPL-Code um. Der virale Effekt wirkt ausschliesslich als Bedingung für die rechtmässige Weiterverbreitung: Wer ein kombiniertes bzw. abgeleitetes Werk verbreiten möchte, muss sich entscheiden, entweder die GPL-Bedingungen einzuhalten oder auf die Verbreitung zu verzichten.

Software wird häufig mit externen Bibliotheken verbunden. Beim statischen Linking wird deren Code beim Kompilieren in die ausführbare Datei eingebunden. Beim dynamischen Linking bleibt die Bibliothek separat und wird erst bei der Ausführung geladen.

Diese Unterscheidung kann lizenzrechtlich relevant sein, insbesondere bei Copyleft-Lizenzen. Dabei stellt sich die Frage, ob Bibliothek und Hauptprogramm durch das Linking so eng verbunden werden, dass Lizenzpflichten auch für das Hauptprogramm entstehen. Die Art des Linkings allein ist dafür jedoch nicht entscheidend.

Das zeigt der Vergleich von GNU General Public License (GPL) und GNU Lesser General Public License (LGPL): Bei der GPL führt nach Auffassung der Free Software Foundation sowohl statisches als auch dynamisches Linking dazu, dass das verbundene Programm den Copyleft-Pflichten der GPL unterliegt. Die LGPL erlaubt dagegen grundsätzlich auch das Linking mit proprietärer Software. Dynamisches Linking ist dabei meist einfacher, während bei statischem Linking zusätzliche Pflichten bestehen können, insbesondere um ein erneutes Linking mit einer modifizierten Version der LGPL-Bibliothek zu ermöglichen.

Entscheidend sind daher stets die konkrete Lizenz, ihre Version und die Art der technischen Einbindung der Bibliothek.

Die Classpath Exception ist eine Ergänzung zur GPL. Sie schränkt die Copyleft-Wirkung der GPL beim Verlinken einer GPL-lizenzierten Bibliothek mit unabhängigen Softwaremodulen ein. Ohne die Ausnahme könnte die Verbindung dazu führen, dass die GPL auf das kombinierte Werk Anwendung findet. Die Classpath Exception verhindert diese Copyleft-Wirkung für unabhängige Module.

Konkret erlaubt sie, eine entsprechend lizenzierte Bibliothek mit einem unabhängigen Modul – z.B. einer proprietären Anwendung – zu verbinden, ohne dass dieses Modul allein aufgrund der Verbindung ebenfalls unter die GPL gestellt werden muss. Das daraus entstehende Programm kann grundsätzlich unter selbst gewählten Lizenzbedingungen weitergegeben werden. Die Lizenzbedingungen der eingebundenen Komponenten sind weiterhin einzuhalten.

Dabei spielt es grundsätzlich keine Rolle, ob die Bibliothek statisch oder dynamisch eingebunden wird. Entscheidend ist, dass das verbundene Modul tatsächlich unabhängig ist, also nicht von der GPL-lizenzierten Bibliothek abgeleitet ist oder auf ihr basiert.

Bestimmte Open-Source-Lizenzen, insbesondere die GNU Lesser General Public License (LGPL), sollen sicherstellen, dass Nutzer eine eingebundene OSS-Bibliothek verändern oder durch eine modifizierte Version ersetzen können. Wird eine solche Bibliothek (dynamisch oder statisch) mit proprietärer Software verbunden, darf die technische oder vertragliche Ausgestaltung diese Möglichkeit nicht unzulässig beschränken.

Für Softwareanbieter stellt sich damit auch die Frage, wer die Verantwortung trägt, wenn ein Endnutzer eine solche Änderung selbst vornimmt. Verändert oder ersetzt der Nutzer eine OSS-Bibliothek eigenständig und führt dies zu Fehlfunktionen, Inkompatibilitäten oder anderen Problemen, sollte der Anbieter hierfür grundsätzlich nicht dieselbe Verantwortung übernehmen wie für die von ihm ausgelieferte Software.

Gerade weil bestimmte Open-Source-Lizenzen dem Endnutzer solche Änderungs- oder Austauschmöglichkeiten einräumen, sollte dieses Risiko auch in den Vertragsbedingungen angemessen berücksichtigt werden. Gewährleistungs- und Haftungsregelungen sollten insbesondere klarstellen, dass der Anbieter für Folgen eigenständiger Änderungen oder eines Austauschs der betreffenden OSS-Komponenten durch den Endnutzer grundsätzlich nicht einsteht, soweit dies rechtlich zulässig ist. Gleichzeitig dürfen diese Regelungen die dem Endnutzer durch die anwendbare Open-Source-Lizenz eingeräumten Rechte nicht unzulässig beschränken.

Lizenzkonflikte entstehen, wenn Codebasen unter unterschiedlichen Lizenzen in einem neuen Projekt zusammengeführt werden und die Bedingungen der Lizenzen miteinander unvereinbar sind. Beispielsweise ist die Kombination einer strengen Copyleft-Lizenz mit einer freizügigen (auch «permissiven» Lizenz) grundsätzlich problematisch, wenn beabsichtigt ist, das kombinierte (bzw. abgeleitete) Werk unter einer freizügigen Lizenz zu verbreiten. Lizenzkonflikte können auch entstehen, wenn bestimmte Nutzungsbedingungen einer Lizenz den Bedingungen einer anderen Lizenz widersprechen, etwa hinsichtlich der erlaubten Nutzung, Weitergabe oder Patentrechte

Die jüngste Open Source Security and Risk Analysis‑Studie (OSSRA 2025) von Black Duck zeigt, dass Lizenzkonflikte nach wie vor weit verbreitet sind: In 56 % der untersuchten Anwendungen wurden Lizenzkonflikte festgestellt, und in 33 % der Fälle sind Komponenten ohne eindeutige Lizenz oder mit angepasster Lizenz enthalten, was rechtliche Unsicherheiten verschärft. Verantwortliche von Open-Source-Projekten, Nutzer entsprechender Software und Entwickler sollten daher die Lizenzbedingungen aller eingesetzten Komponenten sorgfältig prüfen und sicherstellen, dass diese miteinander kompatibel sind, bevor sie Code kombinieren oder weiterverbreiten.

In modernen Softwareprojekten werden häufig verschiedene Open-Source-Komponenten kombiniert, die jeweils eigenen Lizenzbedingungen unterliegen. Besonders relevant ist die Kompatibilität dieser Lizenzen im Hinblick auf Copyleft-Mechanismen wie die GPL, die vorschreiben, dass abgeleitete Werke unter derselben Lizenz weitergegeben werden müssen. Kompatibilitätsprobleme können die Nutzung oder Weitergabe von Software einschränken und lassen sich in der Praxis meist nur durch alternative Lizenzierung oder den Austausch einzelner Komponenten lösen.

Eine bewährte Methode zur Risikominimierung ist die Erstellung einer Software „Bill of Materials“ (BoM), die alle eingesetzten Komponenten samt Lizenzinformationen dokumentiert. Die BoM dient als Grundlage für interne Compliance-Audits und wird zunehmend von Kunden, Investoren oder Käufern verlangt, um die rechtliche Lage der Software nachvollziehen zu können. Die wirtschaftliche Bewertung und Veräusserbarkeit einer Softwarelösung hängen massgeblich davon ab, ob ihre Lizenzlage transparent und rechtlich belastbar ist. Fehlende Transparenz oder ungeklärte Lizenzkonflikte können den Wert der Software bzw. den Unternehmenswert mindern oder Transaktionen verzögern, insbesondere wenn entsprechende Risiken erst im Rahmen von Due-Diligence-Prüfungen offenkundig werden.

Im Umgang mit Open-Source-Software ist zwischen einer Nutzung ohne wirksame Lizenz und einer Verletzung bestehender Lizenzbedingungen zu unterscheiden.

Liegt keine wirksame Lizenz oder sonstige Nutzungserlaubnis vor, etwa weil fremder Code ohne Lizenzangabe übernommen wurde und keine anderweitige Einwilligung des Rechteinhabers besteht, handelt es sich um eine Urheberrechtsverletzung. In diesem Fall ist die Nutzung unzulässig; regelmässig kommen nur die nachträgliche Einholung einer Lizenz vom Rechteinhaber oder die vollständige Entfernung des betroffenen Codes in Betracht.

Besteht hingegen eine wirksame Lizenz, wurden deren Bedingungen jedoch nicht oder nicht vollständig eingehalten (z. B. fehlende Copyright-Hinweise oder unterlassene Offenlegungspflichten), liegt eine Lizenzverletzung vor. Je nach Lizenz kann ein solcher Verstoss zum automatischen Wegfall der Nutzungsberechtigung führen, sodass jede weitere Nutzung eine Urheberrechtsverletzung darstellt. Soweit die jeweilige Lizenz und das anwendbare Recht dies vorsehen, kann die Verletzung durch nachträgliche Erfüllung der Lizenzpflichten geheilt und die Lizenz für die Zukunft wiederhergestellt werden. Andernfalls ist die Beendigung der Nutzung durch Entfernung oder Ersetzung des betroffenen Codes erforderlich.

Docker ist eine weit verbreitete Plattform, mit der Software in sogenannten Containern bereitgestellt und ausgeführt werden kann. Container schaffen eine weitgehend einheitliche und isolierte Umgebung, sodass eine Anwendung unabhängig vom jeweiligen System zuverlässig ausgeführt werden kann.

Grundlage dafür ist ein Docker Image. Es enthält die für die Ausführung benötigten Komponenten, beispielsweise die Anwendung selbst, Bibliotheken, Laufzeitumgebungen und Konfigurationsdateien. Ein Container ist eine laufende Instanz eines solchen Images. Aus demselben Image können mehrere voneinander getrennte Container gestartet werden.

Ein Dockerfile ist wiederum eine Textdatei mit Anweisungen zur Erstellung eines Docker Images. Vereinfacht gesagt ist das Dockerfile das „Rezept“, das Image das daraus erstellte Softwarepaket und der Container dessen laufende Instanz.

Docker Images enthalten neben der eigentlichen Anwendung häufig zahlreiche weitere Softwarekomponenten, etwa Betriebssystembestandteile, Bibliotheken und andere Abhängigkeiten. Wird ein Docker Image an Kunden oder andere Dritte weitergegeben, werden grundsätzlich auch diese Komponenten mitgeliefert – selbst wenn sie für die Anwendung gar nicht benötigt werden. Daher müssen auch deren Lizenzbedingungen beachtet werden.

Wichtig ist dabei die Unterscheidung zwischen Dockerfile und Docker Image: Die Lizenz des Dockerfiles sagt grundsätzlich nichts über die Lizenzen der im Docker Image enthaltenen Software aus. Ein Dockerfile unter der MIT License kann z.B. GPL-lizenzierte Software in das Docker Image einbinden. Je nach Lizenz der enthaltenen Komponenten müssen bei einer Weitergabe etwa Lizenztexte und Copyright-Hinweise mitgeliefert oder Quellcode zur Verfügung gestellt werden.

Ein Docker Image besteht zudem aus mehreren Layers. Für die Compliance ist grundsätzlich die Software relevant, die mit diesen Layers weitergegeben wird – nicht nur das, was im fertigen Docker Image sichtbar ist. Unternehmen sollten deshalb die enthaltenen Komponenten und deren Lizenzen kennen und vor einer Weitergabe prüfen. Dies gilt auch für Docker Images aus öffentlichen Repositories.

Moderne Software greift häufig auf zahlreiche externe Softwarepakete und Bibliotheken zurück, die über Package Manager wie npm, Maven oder pip eingebunden werden. Diese Pakete und Bibliotheken können ihrerseits von weiteren Komponenten abhängig sein. Solche sogenannten transitiven Abhängigkeiten werden oft automatisch installiert, ohne dass Entwickler jede einzelne Komponente bewusst auswählen.

Aus lizenzrechtlicher Sicht dürfen auch diese Abhängigkeiten nicht ausser Acht gelassen werden. Die verschiedenen Komponenten können unterschiedlichen Open-Source-Lizenzen unterliegen und je nach Art ihrer Einbindung und Nutzung beispielsweise Pflichten zur Mitlieferung von Lizenztexten und Copyright-Hinweisen oder – insbesondere bei Copyleft-Lizenzen – weitergehende Anforderungen auslösen. Problematisch kann es insbesondere werden, wenn einzelne Lizenzen nicht mit der vorgesehenen Nutzung oder mit anderen eingesetzten Lizenzen kompatibel sind.

Unternehmen sollten deshalb nicht nur die unmittelbar ausgewählten OSS-Komponenten, sondern den gesamten Dependency Tree kennen und dokumentieren. Software-Composition-Analysis-Tools (SCA) und eine aktuelle Software Bill of Materials (SBOM) helfen dabei, direkte und transitive Abhängigkeiten samt deren Lizenzinformationen automatisiert zu erfassen. Vor jeder Veröffentlichung oder Weitergabe der Software sollte deshalb geprüft werden, ob alle resultierenden Lizenzpflichten eingehalten werden.

Bei modernen Bereitstellungsformen wie Software-as-a-Service (SaaS) oder webbasierten Anwendungen ist der Begriff der Weitergabe nicht immer eindeutig. Die zentrale Frage lautet: Liegt eine Weitergabe bereits vor, wenn Nutzer über das Internet mit der Software interagieren, ohne eine Kopie herunterzuladen? Die Antwort hängt von der jeweiligen Open-Source-Lizenz ab. Bei vielen verbreiteten Open-Source-Lizenzen stellt die blosse Interaktion mit der Software über ein Netzwerk grundsätzlich keine Weitergabe dar, sofern die Nutzer keine Kopie der Software erhalten.. So definiert beispielsweise die strenge GPLv3-Lizenz den Begriff «übermitteln» (to convey) wie folgt:

“To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.”

Eine Ausnahme bildet die Affero GPL (AGPL). Sie wurde entwickelt, um sicherzustellen, dass Lizenzpflichten auch dann gelten, wenn Software über ein Netzwerk bereitgestellt wird, ohne dass Kopien übermittelt werden. Wird eine modifizierte AGPL-lizenzierte Software über ein Netzwerk genutzt, muss den Nutzern grundsätzlich die Möglichkeit gegeben werden, den entsprechenden Quellcode über das Netzwerk zu erhalten. SaaS-Anbieter sollten daher besonders darauf achten, ob AGPL-lizenzierte Komponenten eingesetzt werden.

Neben dem Urheberrecht kann Open-Source-Software auch Fragen zu Patenten aufwerfen. Einige Lizenzen, wie Apache 2.0 oder GPLv3, enthalten ausdrücklich eine Patentlizenz, welche die Nutzung geschützter Technologien innerhalb der Software erlaubt und verhindert, dass Rechteinhaber nach der Weitergabe des Codes Patentansprüche gegen Nutzer geltend machen. Andere Lizenzen, etwa BSD, MIT oder GPLv2, treffen hierzu keine klaren Aussagen. Gerichte vertreten teilweise die Auffassung, dass durch die Nutzung des OSS-Quellcodes eine implizite Patentlizenz eingeräumt wird, doch dies ist rechtlich nicht einheitlich geklärt. Grundsätzlich bleibt daher bei Lizenzen ohne ausdrückliche Patentklausel eine gewisse Unsicherheit hinsichtlich möglicher Patentansprüche des Rechteinhabers gegenüber den Nutzern.

Obwohl OSS neben proprietären Lizenzen die am meisten verbreitete Lizenzform darstellt, entscheiden sich immer mehr Entwickler gegen das (reine) Open-Source Modell. Die Gründe dafür sind vielfältig, hängen aber häufig damit zusammen, dass Open-Source-Lizenzen als zu unflexibel empfunden werden. Im Folgenden werden die bekanntesten Alternativen vorgestellt:

• Public Domain: Als Public Domain werden Werke bezeichnet, bei denen der Urheber auf sein Urheberrecht verzichtet und die Software der Allgemeinheit frei zur Verfügung stellt. Jeder kann die Software frei nutzen, verändern, verbreiten und kommerziell nutzen, ohne dass eine Genehmigung in der Form einer Lizenz erforderlich ist. Beispiele von Software-Programmen, deren Quellcode als Public Domain veröffentlicht wurde, sind der «Secure Hash Algorithmus 3» (SHA-3) oder Online-Spiele wie «One Hour One Life» und «The Castle Doctrine».
• Open Core («Freemium»): Bei Open Core ist der Kern der Software für alle Nutzer als OSS verfügbar. Bestimmte Zusatzfeatures und Add-Ons werden jedoch kostenpflichtig unter einer kommerziellen Lizenz vertrieben. Das Open Core Modell wird unter anderem vom Anbieter der Versionsverwaltungssoftware «GitLab» verwendet. Während die «Community Edition» als OSS frei verfügbar ist, wird die «Enterprise Edition», die zusätzliche Funktionen enthält, unter einer kommerziellen Lizenz angeboten.
• Source Available: Source Available bedeutet, dass der Quellcode der Software wie bei OSS öffentlich zugänglich gemacht wird. Der Unterschied zu OSS besteht darin, dass bei Source-Available-Software bestimmte Nutzungsrechte eingeschränkt sind. Lizenzen, die in die Kategorie Source Available fallen, können beispielsweise Einschränkungen in Bezug auf die Nutzung in kommerziellen Projekten oder für bestimmte Anwendungskategorien (wie Deep Learning oder Suchmaschinen) enthalten. Beispiele für Software-Programme, die inzwischen nicht mehr als OSS zur Verfügung stehen, sondern unter einer Source Available-Lizenz angeboten werden, sind das Visualisierungsprogramm «Kibana», das NoSQL-Datenbankmanagementsystem «MongoDB», die Datenplattform «Redis», die Protokollverwaltungslösung «Graylog» sowie die dezentrale Krypto-Börse «Uniswap» (Version 4).
• Dual-Licensing: Beim Dual-Licensing (oder auch Multi-Licensing) wird eine Software unter alternativ wählbaren Lizenzen angeboten. Zum einen wird die Software unter einer strengen Copyleft-Lizenz angeboten, um den «viralen Effekt» zu provozieren. Zum anderen wird die gleiche Software unter einer kommerziellen Lizenz angeboten, die keinen «viralen Effekt» kennt. Die Möglichkeit, den Quellcode uneingeschränkt zu verändern, in prioritären Quellcode zu integrieren und/oder zu verbreiten, ist somit kostenpflichtig. Das Datenbankmanagementsystem «MySQL» von Oracle ist eines der bekanntesten Beispiele für das Dual-Licensing-Modell.

Beim Dual- oder Multi-Licensing werden Softwareprojekte unter mehreren, alternativ wählbaren Lizenzen angeboten. Damit können unterschiedliche Ziele verfolgt werden.

Zum einen kann Dual- oder Multi-Licensing als kommerzielles Geschäftsmodell genutzt werden. Die kostenlose Version der Software wird bewusst unter einer strengen Copyleft-Lizenz mit viralem Effekt angeboten. Solange Dritte die lizenzierte Software nur intern im Unternehmen einsetzen, wird die Software in der Regel nicht weitergegeben und der virale Effekt tritt nicht ein. Geben Dritte die Software jedoch als Bestandteil ihrer Softwareprojekte an nachfolgende Entwickler weiter, werden die Lizenzpflichten ausgelöst und diese müssen ihre Softwareprojekte ebenfalls unter der Copyleft-Lizenz weitergeben. Wollen die nachfolgenden Entwickler dies vermeiden und ihre Projekte ohne die durch die Copyleft-Lizenz auferlegten Beschränkungen (beispielsweise das Verbot zur Erhebung einer Gebühr für die Nutzung der Software) anbieten, müssen sie die kostenpflichtige Variante der Software erwerben, bei der der virale Effekt nicht ausgelöst wird.

Zum anderen reduziert Dual- oder Multi-Licensing das Risiko von Lizenzkonflikten. Durch die Möglichkeit, zwischen mehreren Lizenzmodellen zu wählen, wird es für Entwickler und Unternehmen einfacher, sicherzustellen, dass alle rechtlichen Anforderungen erfüllt sind und keine ungewollten Überschneidungen oder Einschränkungen zwischen den Lizenzen auftreten. Dies fördert eine breitere Akzeptanz der Software und erleichtert deren Integration in verschiedene Projekte und Anwendungen.

Die relevantesten Open-Soure Contribution Policies sind die Contribution Guidelines und die Contributor License Agreements (CLA):

• Contribution Guidelines regeln die Organisation eines Open-Source-Projekts, indem sie die Zusammenarbeit der Entwickler in der Community sowie deren Rollen und Verantwortlichkeiten definieren. Dies ist für den Erfolg eines Projekts und die reibungslose Zusammenarbeit von grosser Bedeutung. Während bei kleineren Projekten mündliche Absprachen oder kurze, stichwortartige Regelungen ausreichen können, empfiehlt sich bei grösseren Projekten eine ausreichend dokumentierte Governance-Struktur.
• Bei Open-Source-Projekten ist es sinnvoll, mit externen Entwicklern (sog. Contributors) Contributor License Agreements (sog. CLA) abzuschliessen. Diese regeln die Bedingungen und Rechte für die Übernahme der externen Beiträge und stellen sicher, dass das Open-Source-Projekt über die notwendigen Rechte zur Nutzung und Weitergabe der externen Beiträge verfügt. Dies ist insbesondere bei kommerziellen Projekten zu empfehlen, erfordert aber einen höheren administrativen Aufwand. Es ist jedoch zu bedenken, dass die Verwendung eines CLA auch abschreckend wirken kann, da die Entwickler schnell erkennen, dass ihre Beiträge allenfalls kommerzialisiert werden.