Open-Source-Lizenz

Open-Source-Lizenzen sind Softwarelizenzen , die die Nutzung, Änderung und Weitergabe von Inhalten erlauben. Sie fördern die Entwicklung freier und quelloffener Software (FOSS). Gesetze zum Schutz des geistigen Eigentums schränken die Änderung und Weitergabe kreativer Werke ein. Freie und quelloffene Lizenzen nutzen diese bestehenden Rechtsstrukturen für einen gegenteiligen Zweck. Sie gewähren dem Lizenznehmer das Recht, die Software zu nutzen, den Quellcode einzusehen , ihn zu modifizieren und die Änderungen weiterzugeben. Diese Kriterien sind in der Open Source Definition (OSD) dargelegt.

Nach 1980 begannen die Vereinigten Staaten, Software als literarisches Werk zu behandeln, das dem Urheberrecht unterliegt. Richard Stallman gründete die Freie-Software-Bewegung als Reaktion auf den Aufstieg proprietärer Software . Der Begriff „Open Source“ wurde von der Open Source Initiative (OSI) geprägt , die von den Freie-Software-Entwicklern Bruce Perens und Eric S. Raymond gegründet wurde . „Open Source“ betont die Stärken des offenen Entwicklungsmodells und nicht die Freiheiten der Softwareentwicklung. Obwohl die Ziele hinter den Begriffen unterschiedlich sind, beschreiben Open-Source-Lizenzen und Freie-Software-Lizenzen dieselbe Art von Lizenzen. ^{[ 1 ]}

Die beiden Hauptkategorien von Open-Source-Lizenzen sind permissive und Copyleft-Lizenzen . Beide erlauben die Veränderung und Verbreitung von Software. Üblicherweise ist die Nennung des Urhebers erforderlich , und die Haftung wird ausgeschlossen . Permissive Lizenzen stammen aus dem akademischen Bereich. Copyleft-Lizenzen sind Teil der Freie-Software-Bewegung. Sie verlangen, dass abgeleitete Werke zusammen mit dem Quellcode und unter einer ähnlichen Lizenz verbreitet werden. Seit Mitte der 2000er-Jahre haben Gerichte in verschiedenen Ländern die Gültigkeit beider Lizenztypen bestätigt. Softwareentwickler haben Klagen wegen Urheberrechtsverletzung und Vertragsbruch eingereicht.

Intellectual property (IP) is a legal category that treats creative output as property, comparable to private property.^[2] Legal systems grant the owner of an IP the right to restrict access in many ways.^[3] Owners can sell, lease, gift, or license their properties.^[4] Multiple types of IP law cover software including trademarks, patents, and copyrights.^[4]

Most countries, including the United States (US), have created copyright laws in line with the Berne Convention with slight variations.^[5] These laws assign a copyright whenever a work is released in any fixed format.^[6] Under US copyright law, the initial release is considered an original work.^[7] The creator, or their employer, holds the copyright to this original work and therefore has the exclusive right to make copies, release modified versions, distribute copies, perform publicly, or display the work publicly. Modified versions of the original work are derivative works.^[8] When a creator modifies an existing work, they hold the copyright to their modifications.^[9] Unless the original work was in the public domain, a derivative work can only be distributed with the permission of every copyright holder.^[10]

1980 änderte die US-Regierung das Gesetz, um Software als literarisches Werk zu behandeln. Software, die nach diesem Zeitpunkt veröffentlicht wurde, unterlag den Gesetzen zum Schutz geistigen Eigentums. ^{[ 11 ]} Zu dieser Zeit arbeitete der amerikanische Aktivist und Programmierer Richard Stallman als Doktorand am MIT Computer Science and Artificial Intelligence Laboratory . Stallman beobachtete eine zunehmende Fragmentierung der Softwareentwickler. Er machte die Verbreitung proprietärer Software und geschlossener Entwicklungsmodelle dafür verantwortlich. Um diesen Entwicklungen entgegenzuwirken, gründete Stallman die Freie-Software-Bewegung . ^{[ 12 ]} In den 1980er Jahren initiierte er das GNU-Projekt zur Entwicklung eines freien Betriebssystems, verfasste Essays über Freiheit, gründete die Free Software Foundation (FSF) und schrieb mehrere Freie-Software-Lizenzen. ^{[ 13 ]} Die FSF nutzte die bestehenden Gesetze zum Schutz geistigen Eigentums für das Gegenteil ihres eigentlichen Ziels der Einschränkung. Anstatt Beschränkungen aufzuerlegen, gewährte Freie Software dem Nutzer explizit Freiheiten. ^{[ 14 ]}

In den 1990er Jahren wurde der Begriff „Open Source“ als alternative Bezeichnung für freie Software geprägt und spezifische Kriterien festgelegt, um zu bestimmen, welche Lizenzen freie und Open-Source-Software abdecken. ^{[ 15 ] [ 16 ]} Zwei aktive Mitglieder der Freie-Software-Community, Bruce Perens und Eric S. Raymond , gründeten die Open Source Initiative (OSI). ^{[ 17 ]} Bei Debian hatte Perens die Debian Free Software Guidelines (DFSG) vorgeschlagen. ^{[ 18 ]} Die DFSG wurden entworfen, um einen spezifischeren und objektiveren Standard für die freie und Open-Source-Software (FOSS) bereitzustellen, die Debian in seinen Repositories hosten würde. ^{[ 19 ]} Die OSI übernahm die DFSG und nutzte sie als Grundlage für ihre Open-Source-Definition. ^{[ 20 ]} Die Free Software Foundation pflegt ein konkurrierendes Kriterienset, die Free Software Definition. ^{[ 21 ]} Historisch gesehen waren diese drei Organisationen und ihre Kriteriensets die maßgeblichen Autoritäten bei der Bestimmung, ob eine Lizenz freie und Open-Source-Software abdeckt. ^{[ 22 ]} Es besteht eine erhebliche Vielfalt zwischen den einzelnen Lizenzen, jedoch nur geringe Unterschiede zwischen den konkurrierenden Definitionen. ^{[ 16 ]} Alle drei Definitionen setzen voraus, dass die Empfänger der geschützten Software diese nutzen, verändern und weiterverbreiten dürfen. ^{[ 23 ]}

Eric S. Raymond war ein Verfechter des Begriffs „ Open Source “ gegenüber „Freier Software“. Er sah Open Source als attraktiver für Unternehmen und als Ausdruck der greifbaren Vorteile der FOSS-Entwicklung. Eines von Raymonds Zielen war es, die bestehende Hacker- Community um große kommerzielle Entwickler zu erweitern. ^{[ 24 ]} In „Die Kathedrale und der Basar“ verglich Raymond die Open-Source-Entwicklung mit einem Basar , einem öffentlichen Markt unter freiem Himmel. ^{[ 25 ]} Er argumentierte, dass das offene Modell neben ethischen Aspekten Vorteile biete, die proprietäre Software nicht nachbilden könne. ^{[ 26 ] [ 27 ]} Raymond legte großen Wert auf Feedback , Tests und Fehlerberichte . ^{[ 28 ]} Er stellte das proprietäre Modell, bei dem kleine, verschwiegene Gruppen von Mitarbeitern diese Arbeit leisteten, der Entwicklung von Linux gegenüber, bei der der Testerpool potenziell die ganze Welt umfasste. ^{[ 29 ]} Er fasste diese Stärke mit den Worten zusammen: „Wenn genug Augenpaare hinschauen, sind alle Fehler oberflächlich.“ ^{[ 30 ]} Die OSI erreichte, dass Open-Source-Entwicklung auch für Unternehmen wie Sun Microsystems, IBM , Netscape, Mozilla , Apache , Apple Inc., Microsoft und Nokia zugänglich wurde. Diese Unternehmen veröffentlichten Code unter bestehenden Lizenzen und entwarfen eigene Lizenzen, die von der OSI genehmigt wurden. ^{[ 31 ] [ 32 ]}

Open-Source-Lizenzen werden in Copyleft- und permissive Lizenzen unterteilt . ^{[ 33 ]} Copyleft-Lizenzen verlangen, dass abgeleitete Werke den Quellcode unter einer ähnlichen Lizenz enthalten. Permissive Lizenzen hingegen nicht, sodass der Code auch in proprietärer Software verwendet werden kann. Copyleft-Lizenzen lassen sich weiter in starke und schwache Lizenzen unterteilen, je nachdem, ob sie abgeleitete Werke weit oder eng definieren. ^{[ 34 ] [ 35 ]}

Lizenzen konzentrieren sich auf das Urheberrecht, doch Code ist auch durch andere Formen des geistigen Eigentums geschützt. ^{[ 36 ]} Wichtige Open-Source-Lizenzen, die seit Ende der 1990er Jahre verfasst wurden, beinhalten Patentrechte. Diese Open-Source-Patentrechte decken die Patente der Entwickler ab. ^{[ 37 ]} Softwarepatente schützen Ideen und nicht nur eine konkrete Implementierung, sondern jede Umsetzung eines Anspruchs . Patentansprüche geben dem Inhaber das Recht, andere von der Herstellung, Verwendung, dem Verkauf oder dem Import von Produkten auszuschließen, die auf der Idee basieren. Da Patente das Ausschlussrecht und nicht das Recht zur Erfindung gewähren, kann man zwar ein Patent auf eine Idee besitzen, diese aber dennoch nicht legal umsetzen, wenn die Erfindung auf einer anderen patentierten Idee beruht. Daher können Open-Source-Patentrechte nur die Nutzung von geschützten Patenten erlauben. Sie können nicht garantieren, dass Dritte keine im Code enthaltenen Konzepte patentiert haben. ^{[ 36 ]} Ältere, permissive Lizenzen erwähnen Patente nicht direkt und bieten in ihren Angeboten zur Nutzung oder zum Verkauf des geschützten Materials lediglich implizite Patentrechte an. ^{[ 38 ]} Neuere Copyleft-Lizenzen und die Apache-Lizenz von 2004 bieten explizite Patentrechte und begrenzten Schutz vor Patentstreitigkeiten. ^{[ 39 ]} Diese Patentschutzklauseln schützen Entwickler, indem sie die Rechte für jede Partei erlöschen lassen, die eine Patentklage bezüglich der abgedeckten Software einleitet. ^{[ 39 ]}

Markenrechte sind die einzige Form des geistigen Eigentums, die bei freier und Open-Source-Software nicht geteilt wird. Markenrechte in FOSS funktionieren wie alle anderen Markenrechte. ^{[ 40 ]} Eine Marke ist ein Design, das die eindeutige Herkunft eines Produkts kennzeichnet. Da sie Produkte unterscheiden, können dieselben Designs in verschiedenen Bereichen verwendet werden, ohne dass Verwechslungsgefahr mit ähnlichen Produkten besteht. ^{[ 41 ]} Der Verzicht auf die Kontrolle über eine Marke führt zu deren Verlust. Daher bietet keine Open-Source-Lizenz die freie Nutzung einer Marke an. ^{[ 42 ]}

Markenrechtliche Beschränkungen können sich mit Urheberrechten überschneiden und auch frei verfügbares Material betreffen. ^{[ 43 ]} Der Oberste Gerichtshof der USA bezeichnete die Nutzung des Markenrechts zur Einschränkung gemeinfreier Inhalte als „mutiertes Urheberrecht“. ^{[ 44 ]} Im Fall Dastar Corp. gegen Twentieth Century Fox Film Corp. warnte das Gericht vor Missbrauch oder übermäßiger Ausdehnung des Markenrechts, ohne jedoch eine endgültige Entscheidung zu diesen mutierten Urheberrechten zu treffen. ^{[ 45 ] [ 46 ]} Markenrechtliche Überschneidungen können Open-Source- und Free-Content-Projekte anfällig für eine „feindliche Übernahme“ machen, wenn Dritte Markenrechte an abgeleiteten Werken anmelden. ^{[ 47 ]} So meldete beispielsweise Andrey Duskin Markenrechte an der SCP Foundation an , einem kollaborativen Schreibprojekt, als er abgeleitete Werke auf Basis von SCP-Geschichten erstellte. ^{[ 48 ]}

Permissive Lizenzen , auch bekannt als akademische Lizenzen ^{[ 49 ],} erlauben es den Empfängern, Software zu nutzen, zu verändern und zu verbreiten, ohne den Quellcode offenlegen zu müssen. Institutionen haben diese Lizenzen entwickelt, um ihre Werke der Öffentlichkeit zugänglich zu machen. ^{[ 49 ]} Permissive Lizenzen sind in der Regel kurz, oft weniger als eine Seite Text. Sie enthalten wenige Bedingungen . Die meisten beinhalten Haftungsausschlüsse und die Verpflichtung zur Nennung der Urheber. Einige wenige enthalten explizite Bestimmungen zu Patenten, Marken und anderen Formen des geistigen Eigentums. ^{[ 50 ]}

Die University of California, Berkeley, schuf die erste Open-Source-Lizenz, als sie mit der Verbreitung ihres Betriebssystems Berkeley Software Distribution (BSD) begann. Die BSD-Lizenz und ihre späteren Varianten erlauben die Modifizierung und Verbreitung der darunterliegenden Software. Die Lizenzen brachten das Konzept der akademischen Freiheit in die Informatik. Frühe akademische Softwareentwickler hatten Code auf der Grundlage impliziter Zusagen geteilt. Berkeley machte diese Konzepte explizit durch klare Haftungsausschlüsse und Gewährleistungsausschlüsse sowie Bedingungen oder Klauseln für die Weiterverbreitung. Die ursprüngliche Lizenz enthielt vier Klauseln, spätere Versionen haben die Einschränkungen jedoch weiter reduziert. Daher ist es üblich anzugeben, ob die Software eine Version mit zwei oder drei Klauseln verwendet. ^{[ 51 ] [ 52 ]}

Das Massachusetts Institute of Technology (MIT) entwickelte eine akademische Lizenz, die auf der ursprünglichen BSD-Lizenz basiert. Die MIT-Lizenz präzisierte die Bedingungen durch eine explizitere Formulierung. ^{[ 53 ]} Beispielsweise beschreibt die MIT-Lizenz das Recht zur Unterlizenzierung . ^{[ 54 ]} Eine der Stärken der Open-Source-Entwicklung liegt im kontinuierlichen Prozess, in dem Entwickler auf den abgeleiteten Werken anderer aufbauen und ihre Projekte zu gemeinsamen Werken zusammenführen können. Die explizite Unterlizenzierbarkeit des Codes bietet einen rechtlichen Vorteil bei der Nachverfolgung der Urheberschaft. ^{[ 53 ]} Die BSD- und die MIT-Lizenz sind Vorlagenlizenzen, die an jedes Projekt angepasst werden können. Sie werden von vielen FOSS-Projekten häufig verwendet und adaptiert. ^{[ 51 ]}

Die Apache-Lizenz ist umfassender und expliziter. Sie wurde von der Apache Software Foundation für ihren Apache HTTP Server verfasst . Version 2, veröffentlicht im Jahr 2004, bietet rechtliche Vorteile gegenüber einfacheren Lizenzen und gewährt ähnliche Rechte. ^{[ 55 ]} Während die BSD- und MIT-Lizenzen implizite Patentrechte gewähren, ^{[ 56 ]} enthält die Apache-Lizenz einen Abschnitt über Patente mit einer expliziten Patentgewährung durch die Mitwirkenden. ^{[ 57 ]} Darüber hinaus ist sie eine der wenigen permissiven Lizenzen mit einer Patentvergeltungsklausel. ^{[ 58 ]} Patentvergeltungsklauseln oder Klauseln zur Patentaussetzung treten in Kraft, wenn ein Lizenznehmer ein Patentverletzungsverfahren bezüglich des unter die Lizenz fallenden Codes einleitet . In diesem Fall werden die Patentrechte widerrufen. Diese Klauseln schützen vor Patenttrolling . ^{[ 59 ]}

Copyleft -Lizenzen verlangen, dass der Quellcode zusammen mit der Software verbreitet wird und unter einer ähnlichen Lizenz verfügbar gemacht wird. ^{[ 34 ] [ 60 ]} Wie die permissiven Lizenzen erfordern auch die meisten Copyleft-Lizenzen die Namensnennung. ^{[ 61 ]} Die meisten, einschließlich der GPL, schließen jegliche Gewährleistung aus. ^{[ 62 ]}

Copyleft nutzt die Beschränkungen des Urheberrechts – entgegen ihrer üblichen Funktion –, um die Verfügbarkeit des Quellcodes zu gewährleisten. ^{[ 63 ]} Der Begriff und der zugehörige Slogan „Alle Rechte vorbehalten“ wurden zuvor von Principia Discordia und Tiny BASIC spielerisch verwendet ; die moderne Verwendung geht auf Richard Stallmans Bemühungen um ein freies Betriebssystem zurück. 1984 schickte der Programmierer Don Hopkins Stallman ein Handbuch mit einem „Copyleft Ⓛ“-Aufkleber. Stallman, der am GNU-Betriebssystem arbeitete, übernahm den Begriff. ^{[ 64 ]} Eine frühe Version der Copyleft-Lizenz wurde für die Veröffentlichung von GNU Emacs im Jahr 1985 verwendet . ^{[ 14 ] [ 65 ]} Der Begriff wurde später mit den Gegenseitigkeitslizenzen der FSF, insbesondere der GNU General Public License (GPL), in Verbindung gebracht. ^{[ 66 ]}

Traditionelle, proprietäre Softwarelizenzen sind auf Gewinnmaximierung ausgerichtet . Stallman hingegen verfasste die GPL, um die Menge an verfügbarer freier Software zu vergrößern. Seine reziproken Lizenzen gewähren das Recht, das Werk zu nutzen, zu verändern und zu verbreiten, unter der Bedingung, dass abgeleitete Werke unter einer Lizenz veröffentlicht werden, die dieselben Freiheiten bietet. Software, die auf einer Copyleft-Basis aufbaut, muss mit dem Quellcode ausgeliefert werden, und der Quellcode muss unter derselben oder einer ähnlichen Lizenz verfügbar sein. Dies schützt davor, dass proprietäre Software Code verwendet, ohne ihn zurückzugeben. ^{[ 67 ] [ 68 ]} Richard Stallman erklärte: „Die zentrale Idee von Copyleft besteht darin, das Urheberrecht umzukehren, sodass es dem Gegenteil seines üblichen Zwecks dient: Anstatt Software zu privatisieren, wird das Urheberrecht zu einem Mittel, Software frei zu halten.“ ^{[ 69 ]} Freie Softwarelizenzen sind auch Open-Source-Softwarelizenzen. ^{[ 70 ]} Die unterschiedlichen Begriffe „freie Software“ und „Open-Source-Software“ spiegeln unterschiedliche Werte und nicht etwa einen rechtlichen Unterschied wider. ^{[ 71 ]} Beide Bewegungen und ihre formalen Definitionen fordern, dass das betreffende Werk mit Quellcode und der Erlaubnis zur Änderung und Weiterverbreitung zur Verfügung gestellt wird. ^{[ 16 ]} Es gibt vereinzelt Ausnahmefälle, in denen nur eine der beiden Organisationen, die FSF oder die OSI, eine Lizenz akzeptiert, aber die gängigen freien Softwarelizenzen sind Open Source, einschließlich der GPL . ^{[ 72 ]}

Die praktischen Vorteile von Copyleft-Lizenzen haben kommerzielle Entwickler angezogen. Unternehmen haben Gegenseitigkeitslizenzen mit einem engeren Geltungsbereich als die GPL verwendet und verfasst. ^{[ 74 ]} So entwarf beispielsweise Netscape eigene Copyleft-Bedingungen, nachdem es permissive Lizenzen für das Mozilla-Projekt abgelehnt hatte. ^{[ 32 ]} Die GPL ist nach wie vor die populärste Lizenz dieser Art, aber es gibt weitere bedeutende Beispiele. Die FSF hat die Lesser General Public License (LGPL) für Bibliotheken entwickelt . Mozilla verwendet die Mozilla Public License (MPL) für seine Veröffentlichungen, einschließlich Firefox . IBM entwarf die Common Public License (CPL) und übernahm später die Eclipse Public License (EPL). Ein Unterschied zwischen der GPL und anderen Gegenseitigkeitslizenzen liegt in der Definition abgeleiteter Werke, die unter die Gegenseitigkeitsbestimmungen fallen. Die GPL und die darauf basierende Affero License (AGPL) verwenden einen weiten Geltungsbereich, um betroffene Werke zu beschreiben. Die AGPL erweitert die Gegenseitigkeitsverpflichtung der GPL auf Software, die über ein Netzwerk bereitgestellt wird. ^{[ 74 ] [ 32 ]} Sie werden als starke Copyleft-Lizenzen bezeichnet , im Gegensatz zu den schwächeren Copyleft -Lizenzen, die häufig von Unternehmen verwendet werden. Schwache Copyleft-Lizenzen verwenden engere, explizite Definitionen von abgeleiteten Werken. ^{[ 75 ] [ 35 ]} Die MPL verwendet eine dateibasierte Definition, die CPL und EPL eine modulbasierte Definition, und die LGPL der FSF bezieht sich auf Softwarebibliotheken. ^{[ 76 ]}

Die Lizenzkompatibilität bestimmt, wie Code mit unterschiedlichen Lizenzen gemeinsam verbreitet werden kann. Ziel von Open-Source-Lizenzen ist es, die Arbeit frei zugänglich zu machen. Dies gestaltet sich jedoch kompliziert, wenn mit verschiedenen Lizenzbedingungen und unterschiedlichen Anforderungen gearbeitet wird. ^{[ 77 ]} Es gibt viele unübliche Lizenzen , und manche Projekte erstellen eigene , individuelle Vereinbarungen. Dies führt zu mehr Verwirrung als andere rechtliche Aspekte. Bei der Veröffentlichung einer Sammlung von Anwendungen kann jede Lizenz einzeln betrachtet werden. Beim Versuch, Software zu kombinieren, kann Code aus einem anderen Projekt jedoch nur dann einlizenziert werden, wenn das Projekt kompatible Lizenzbedingungen verwendet. ^{[ 78 ]}

Beim Zusammenführen von Codebasen können die ursprünglichen Lizenzen für einzelne Komponenten beibehalten und das Gesamtwerk unter einer kompatiblen Lizenz veröffentlicht werden. ^{[ 79 ]} Diese Kompatibilität ist oft einseitig. Gemeinfreie Inhalte können überall verwendet werden, da kein Urheberrechtsanspruch besteht. Code, der unter beliebigen Bedingungen erworben wurde, kann jedoch nicht in die Gemeinfreiheit überführt werden. Permissive Lizenzen können innerhalb von Copyleft-Werken verwendet werden, Copyleft-Materialien dürfen jedoch nicht unter einer permissiven Lizenz veröffentlicht werden. Einige schwache Copyleft-Lizenzen können unter der GPL verwendet werden und gelten als GPL-kompatibel. GPL-Software darf nur unter der GPL oder AGPL verwendet werden. ^{[ 77 ]} Permissive Lizenzen sind weitgehend kompatibel, da sie verschiedene Teile eines Projekts abdecken können. Mehrere Lizenzen, darunter die GPL und die Apache License, wurden überarbeitet, um die Kompatibilität zu verbessern. ^{[ 80 ]}

Übersetzungsprobleme, Unklarheiten in den Lizenzbedingungen und die Unvereinbarkeit mancher Lizenzen mit dem Recht bestimmter Rechtsordnungen verschärfen das Problem der Lizenzkompatibilität. ^{[ 81 ]} Das Herunterladen eines Open-Source-Moduls ist unkompliziert, die Einhaltung der Lizenzbedingungen hingegen kann sich als schwieriger erweisen. ^{[ 82 ]} Aufgrund der Vielzahl an Softwareabhängigkeiten greifen Entwickler komplexer Projekte häufig auf Lizenzmanagement-Software zurück, um die Einhaltung der Lizenzbedingungen von Open-Source-Komponenten sicherzustellen. ^{[ 83 ]} Viele Open-Source-Softwaredateien geben die Lizenz nicht eindeutig an, was die Einhaltung zusätzlich erschwert. ^{[ 82 ]}

Freie und Open-Source-Softwarelizenzen werden seit Mitte der 2000er-Jahre erfolgreich vor Zivilgerichten durchgesetzt . ^{[ 85 ]} In zwei frühen Gerichtsverfahren – Jacobsen gegen Katzer in den USA und Welte gegen Sitecom in Deutschland – argumentierten die Beklagten, dass Open-Source-Lizenzen ungültig seien. ^{[ 86 ] [ 87 ]} Sitecom und Katzer machten unabhängig voneinander geltend, die Lizenzen seien nicht durchsetzbar. Sowohl die US-amerikanischen als auch die deutschen Gerichte wiesen diese Argumente zurück. Sie urteilten, dass die Beklagten die Software nicht rechtmäßig hätten verbreiten können, wenn die Lizenzen nicht durchsetzbar gewesen wären. ^{[ 85 ] [ 84 ]}

Gerichte haben entschieden, dass die Verbreitung von Software die Zustimmung zu den Lizenzbedingungen impliziert. ^{[ 88 ]} Bei physischen Softwareveröffentlichungen kann die Zustimmung des Verbrauchers durch auf der Verpackung angebrachte Hinweise eingeholt werden . Die Online-Verbreitung kann Clickwrap nutzen , ein digitales Äquivalent, bei dem der Nutzer durch Klicken zustimmen muss. ^{[ 89 ]} Open-Source-Software verfügt über einen zusätzlichen Zustimmungsmechanismus. Ohne die Erlaubnis des Urheberrechtsinhabers ist die Weiterverbreitung gesetzlich verboten. ^{[ 90 ]} Daher werten Gerichte die Weiterverbreitung als Zustimmung zu den Lizenzbedingungen. Diese können Namensnennungsvorschriften oder Bestimmungen zum Quellcode bei Copyleft-Lizenzen umfassen. ^{[ 91 ] [ 92 ]}

Entwickler erreichen die Einhaltung der Vorschriften in der Regel ohne Gerichtsverfahren. Sozialer Druck, wie die Möglichkeit negativer Reaktionen aus der Community, ist oft ausreichend. ^{[ 93 ]} Abmahnungen sind eine gängige Methode, um Unternehmen zur Einhaltung der Vorschriften zu bewegen, insbesondere in Deutschland. ^{[ 94 ]} Im deutschen Rechtssystem hat sich ein Standardverfahren etabliert. FOSS-Entwickler stellen Unternehmen Abmahnungen zu. Diese Schreiben erläutern, wie die Einhaltung der Vorschriften nach einem Verstoß wiederhergestellt werden kann. Deutsche Richter können gegen nicht reagierende Unternehmen eine gerichtlich angeordnete Abmahnung erlassen. Scheitern diese ersten Schritte, werden Zivilprozesse eingeleitet. Das deutsche Prozessrecht ist klar und klägerfreundlich. ^{[ 95 ]}

Es bestehen weiterhin Unsicherheiten hinsichtlich der Behandlung bestimmter Aspekte der Lizenzierung durch verschiedene Gerichte. ^{[ 96 ]} Im Allgemeinen gibt es im Softwarebereich Debatten darüber, was patentierbar und was urheberrechtlich geschützt werden kann. Bezüglich einer Anwendungsprogrammierschnittstelle (API) stellte der Europäische Gerichtshof im Fall SAS Institute von 2012 fest , dass „Ideen und Prinzipien, die [Computerprogramm-]Schnittstellen zugrunde liegen, nicht urheberrechtlich geschützt sind“. ^{[ 97 ]} In einem ähnlichen Fall aus dem Jahr 2021 erlaubte der Oberste Gerichtshof der USA die Nachbildung einer API in einem transformativen Produkt im Rahmen der Fair-Use- Doktrin . ^{[ 98 ]}

A long-debated subject within the FOSS community is whether open-source licenses are "bare licenses" or contracts.^[96] A bare license is a set of conditions under which actions otherwise restricted by IP laws are permitted.^[85] Under the bare license interpretation, advocated by the FSF, a case is brought to court by the copyright holder as copyright infringement.^[85] Under the contract interpretation, a case can be brought to court by an involved party as a breach of contract.^[99] US and French courts have tried cases under both interpretations.^[100] Non-profit organizations like FSF and the Software Freedom Conservancy offer to hold the rights to developers' projects to enforce compliance.^[95]

When a copyright expires, the work enters the public domain, and is freely available to anyone.^[102] Some creative works are not covered by copyright and enter directly into the public domain. In the early history of computing, this applied to software.^[11] Early computer software was often given away with hardware.^[103] Developed initially at MIT, the pioneering video game Spacewar! was used to market and test the PDP-1 computer.^[104]

According to attorney Lawrence Rosen, copyright laws were not written with the expectation that creators would place their work into the public domain. Thus intellectual property laws lack clear paths to waive a copyright. Highly permissive licenses described as "public domain" may legally function as unilateral contracts that offer something but impose no terms.^[105][106]

A public-domain-equivalent license, like the Creative Commons CC0, provides a waiver of copyright claims into the public domain along with a permissive software license as a fallback. In jurisdictions that do not accept a public domain waiver, the permissive license takes effect.^[107] Public domain waivers share limitations with simple academic licenses. This creates the possibility that an outside party could attempt to control a public domain work via patent or trademark law.^[108] Public domain waivers handle warranties differently from any type of license. Even very permissive ones, like the MIT license, disclaim warranty and liability. Anyone using the free software must accept this disclaimer as a condition. Because public domain content is available to everyone, the copyright waiver cannot impose a disclaimer.^[102]

Open-source licenses allow other businesses to commercialize covered software.^[109] Work released under a permissive license can be incorporated into proprietary software.^[110] Permissive licenses permit the addition of new terms, including proprietary ones.^[111][112] Proprietary software has heavily integrated open-source code released under the Apache, BSD, and MIT licenses.^[113]Open core is a business model where developers release a core piece of software as open source and monetize a product containing it as proprietary software.^[114] The strong copyleft GPL is written to prevent distribution within proprietary software.^[115][116] Weak copyleft licenses impose specific requirements on derivative works that may allow the covered code to be distributed within proprietary software in certain circumstances.^[77]

Cloud Computing basiert auf freier und Open-Source-Software und umgeht die Verbreitung, die die meisten Lizenzen auslöst. Cloud-Software wird gehostet statt verteilt. ^{[ 117 ]} Ein Anbieter hostet die Software online, und die Endnutzer müssen den verwendeten Code weder herunterladen noch darauf zugreifen oder ihn überhaupt kennen. ^{[ 118 ]} Die Copyleft-Lizenz GNU Affero General Public License (AGPL) greift, sobald der zugehörige Code gehostet oder verteilt wird. ^{[ 119 ]} Einige Entwickler haben die AGPL übernommen, andere sind auf proprietäre Lizenzen mit Merkmalen von Open-Source-Lizenzen umgestiegen. ^{[ 120 ]} Beispielsweise wechselte der Open-Core-Entwickler Elastic von der Apache-Lizenz zur „quellcodeverfügbaren“ Server Side Public License (SSL) . ^{[ 121 ]} Quellcodeverfügbare Software enthält den Quellcode als Referenz. ^{[ 122 ]}

Seit 2010 hat das Cloud-Modell an Bedeutung gewonnen. ^{[ 117 ]} Entwickler kritisieren Cloud-Unternehmen, die von der Bereitstellung von Open-Source-Software profitieren, ohne selbst Geld oder Code beizusteuern, und vergleichen diese Praxis mit dem Abbau von Rohstoffen . ^{[ 123 ]} Der Cloud-Computing-Marktführer Amazon Web Services ( AWS ) erklärt, Lizenzen einzuhalten und im besten Interesse seiner Kunden zu handeln. ^{[ 123 ] [ 124 ]}