Wenn Sie nicht auf Lizenzen achten, kann Open-Source-Code Ihr Unternehmen in einen kostspieligen Rechtsstreit verwickeln oder Sie dazu bringen, das gesamte Produkt neu zu schreiben. Sie sollten jedoch keine Angst vor Lizenzen haben, sondern verstehen, wie sie funktionieren und wie Sie sie einhalten können. Prüfen Sie, ob die von Ihnen verwendeten offenen Quellen eine Bedrohung für Ihr Unternehmen darstellen, und finden Sie heraus, was Sie heute tun können, um Ihr Unternehmen über Jahre hinweg abzusichern.
A QUICK SUMMARY – FOR THE BUSY ONES
Sie müssen keine Angst vor den restriktiven Lizenzen haben. Sie müssen sich nur bewusst sein, dass einige der Lizenzen ein Problem darstellen können, und ein grundlegendes Verständnis dafür haben, wie sie funktionieren. Auf diese Weise können Sie die Anforderungen entsprechend einhalten.
Der Schlüssel zur Verwaltung von Lizenzen ist Verständnis. Damit bist du das Risiko managen — und reduzieren —.
Mit dem Wachstum eines Produkts wird die Anzahl der Lizenzen, denen man folgen und auf die man achten muss, zu einem Problem. Was Ihnen helfen kann, die Lizenzen in Ihrem Code nachzuverfolgen, ist Tool für Lizenzprüfer, das Benachrichtigungen sendet, nachdem ein potenzielles Problem erkannt wurde.
TABLE OF CONTENTS
Diese Visualisierung zeigt etwa 1600 Abhängigkeiten, die jedes Mal auftreten, wenn Sie eine neue React-App einrichten.
Jeder von ihnen kann eine andere Lizenz haben.
Sie manuell zu verfolgen ist praktisch unmöglich. Sie überhaupt nicht zu verfolgen, könnte rechtliche Konsequenzen haben.
Wie können Sie also die Lizenzkonformität sicherstellen und rechtliche Risiken problemlos vermeiden?
Verstehen Sie das Wesentliche und die Absicht der Lizenztypen und wähle ein Tool, das dir bei der Verwaltung hilft.
Wir erklären es unten. Lass uns eintauchen.
Beginnen wir mit der Tatsache, dass jeder Code lizenziert ist. Und eine Lizenz bedeutet im Grunde, dass Sie den Code verwenden können, wenn Sie die Bedingungen einhalten. Es definiert die Verantwortlichkeiten für diejenigen, die den Code verwenden und verteilen.
Die meisten Lizenzen entsprechen einem bestimmten Problem und wurden geschaffen, weil es in einem Rechtssystem eine Lücke gab.
Und dein Code ist voll davon. Je tiefer Sie gehen, desto mehr Lizenzen erscheinen.
Zum Beispiel installieren Sie Electron und müssen 87 Pakete hinzufügen — das bedeutet 87 Lizenzabhängigkeiten. Jedes einzelne Paket hat wahrscheinlich seine eigenen Abhängigkeiten und daher eine weitere Lizenz, die Sie einhalten müssen.
Wie Sie sehen, kann die Lizenzverwaltung in den meisten Fällen nicht manuell durchgeführt werden, und wenn sie falsch ausgeführt wird, kann eine technische Schulden.
Bei Open-Source-Code ist das nicht anders. Es ist ein weit verbreitetes Missverständnis, dass die Nutzung kostenlos ist, aber meistens stehen die Pakete unter einer bestimmten Lizenz. Und natürlich müssen Sie eine Verletzung dieser Richtlinie vermeiden. Andernfalls können Lizenzstreitigkeiten mit einem sehr kostspieligen Gerichtsverfahren enden, oder Sie müssen Ihren Code möglicherweise unter derselben Lizenz veröffentlichen wie die von Ihnen verwendete Paketabhängigkeit.
Open-Source-Softwarelizenzen (OSS) ermöglichen es Entwicklern, ihren Code als Open Source kostenlos mit anderen zu teilen. Sie sind für Komponenten oder Bibliotheken üblich.
Aber jede Open-Source-Lizenz hat Allgemeine Geschäftsbedingungen, die den Benutzern sagen, was sie tun können oder nicht. Ein Benutzer muss möglicherweise einen bestimmten Lizenztext veröffentlichen, wenn er den Code verteilt. Jede Online-Software ist lizenziert, und das bedeutet, dass Sie sie nicht einfach kopieren und in Ihre Codebasis einfügen können.
Das Problem mit Open-Source-Software ist, dass es viele Mitwirkende gibt und es riskant ist anzunehmen, dass die Hauptlizenz die einzige ist, die Sie einhalten müssen.
Die Lizenz einer Komponente gilt nicht unbedingt für jede Datei und sogar für jede Codezeile. Dadurch jede Komponente kann von vielen Lizenzen abhängig sein und Sie werden es ohne eine eingehende Untersuchung nicht identifizieren können. Außerdem bedeutet jede Art von Lizenz unterschiedliche Verpflichtungen.
<span class="colorbox1" fs-test-element="box1"><p><strong>Tipp:</strong></p> <p>Wenn du eine React-App entwickelst und Hilfe suchst, sieh dir unsere Liste an Die besten React-Entwicklungsunternehmen — Man kann mit Sicherheit sagen, dass diese Anbieter die Lizenzprobleme verstehen. Und hier finden Sie Tipps zu Aufbau einer Softwareentwicklungspartnerschaft</p></span>.
Wenn jemand Ihr Unternehmen oder Ihre SaaS-Software kaufen möchte, wird er sich Ihre Lizenzvereinbarung ansehen, um sicherzustellen, dass alles funktioniert. Nachdem der Käufer während des Lizenzaudits Probleme entdeckt hat, kann er zurückweichen.
Andere potenzielle Probleme sind:
Stellen Sie sich vor, es passiert in einer sensiblen Branche wie Fintech. Deshalb ist es wichtig, mit zuverlässigen Entwicklungspartnern zusammenzuarbeiten, die sowohl die Branche als auch die Risiken verstehen und wissen, wie man sie mindert. (Schauen Sie sich unseren Vergleich von an die besten Anbieter von Fintech-Entwicklungen, falls das nach deiner Tasse Tee klingt.)
Im Allgemeinen Je später Sie die problematische Abhängigkeit entdecken, desto teurer wird es, dieses Problem zu lösen.
Es ist wichtig, über Prozesse und Tools zu verfügen, um alle Abhängigkeiten und Lizenzen in Ihrem Code zu verwalten und zu wissen, wie die verschiedenen Lizenztypen funktionieren.
<span class="colorbox1" fs-test-element="box1"><p>Tipp:<p></p>Vermeiden Sie das Geschäftsrisiko, das durch die einfache Verwendung von Open-Source-Lizenzen entsteht, mit dem Lizenzprüfer — ein kostenloses Tool, das Lizenzen in Ihrem Code verfolgt und validiert</p></span>.
Proprietäre Lizenzen — Benutzer erhalten den Betriebscode und können die Software nicht beliebig ändern. Es ist illegal, die Software zu kopieren, zu ändern oder zu verteilen. Dies ist der restriktivste Lizenztyp.
Copyleft-Lizenzen — auch als wechselseitige Lizenzen oder virale Lizenzen bezeichnet. Sie verlangen, dass Sie jeden Code, den Sie erstellen, unter denselben Copyleft-Lizenzbedingungen veröffentlichen, um den Code verteilen und ändern zu können.
Geringere allgemeine öffentliche Lizenzen — Sie müssen eine LGPL-lizenzierte Bibliothek mit Ihrem eigenen Code verknüpfen, um Ihre Software unter einer beliebigen Lizenz veröffentlichen zu können.
Semi-permissive Lizenzen — Für diese Lizenzen müssen Sie die Codeänderungen gemäß den Bedingungen der jeweiligen Lizenz verfügbar machen.
Permissive Lizenzen — Diese Lizenzen enthalten einige Anforderungen für den Vertrieb und die Änderung der Software, wobei Lizenzhinweise, Urheberrechte oder Marken erhalten bleiben. Die Einschränkungen sind minimal.
Gemeinfrei — jeder kann Code aus dieser Software verwenden, ändern oder in eine Anwendung integrieren. Unternehmen sollten vorsichtig mit den Qualitäts- und Sicherheitsstandards des Codes umgehen.
GNU General Public License (GPL) 2.0 — Um die Software kopieren, verteilen und modifizieren zu können, müssen Sie Änderungen und Daten in den Quelldateien verfolgen. Alle Änderungen müssen unter GPL-lizenziertem Code zur Verfügung gestellt werden.
GNU General Public License (GPL) 3.0 — Um die Software kopieren, verteilen und modifizieren zu können, müssen Sie Änderungen und Daten in den Quelldateien verfolgen. Alle Änderungen müssen unter GPL-lizenziertem Code zur Verfügung gestellt werden.
GNU Affero General Public License 3.0 oder höher — Sie können geänderte Versionen verteilen, wenn Sie die Änderungen und das Datum, an dem Sie sie vorgenommen haben, verfolgen. Wie bei anderen GNU-Lizenzen müssen Derivate unter AGPL lizenziert werden.
GNU Lesser General Public License (LGPL) 2.1 — Sie dürfen die Software kopieren, verteilen und ändern, wenn Sie die Änderungen unter LGPL-2.1 lizenzieren. Alles, was statisch mit der Bibliothek verknüpft ist, kann nur unter LGPL weiterverbreitet werden. Anwendungen, die die Bibliothek verwenden, müssen das nicht sein.
GNU Lesser General Public License (LGPL) 3.0 — Sie dürfen die Software kopieren, verteilen und ändern, wenn Sie die Änderungen unter LGPL lizenzieren. Änderungen oder alles, was statisch mit der Bibliothek verknüpft ist, kann nur unter LGPL weiterverbreitet werden. Anwendungen, die die Bibliothek verwenden, müssen das nicht sein.
GNU General Public License (GPL) und GNU Affero General Public License (AGPL) sind die restriktivsten Open-Source-Lizenzen.
Bei einigen restriktiven Lizenzen wie GPL 3.0 oder AGPL müssen Sie vorsichtig sein. Im schlimmsten Fall müssen Sie Ihre Software möglicherweise unter derselben Lizenz lizenzfrei veröffentlichen.
Wir sollten jedoch nicht sagen, dass diese Lizenzen schlecht sind. Sie stellen ein rechtliches Risiko dar oder können dazu führen, dass Sie das gesamte Produkt neu schreiben, aber nur, wenn Sie die damit verbundenen Regeln nicht befolgen.
Der Schlüssel zur Verwaltung von Lizenzen liegt darin, zu verstehen, wie sie funktionieren, ihre Regeln zu befolgen und idealerweise Software zu verwenden, mit der Sie die Lizenzen in Ihrem Produkt verfolgen können, um nicht gegen Gesetze zu verstoßen oder Ihr Produkt durch Unachtsamkeit zu beeinträchtigen.
Semi-permissive Lizenzen erfordern meistens, dass Sie die Codeänderungen unter den Bedingungen der jeweiligen Lizenz verfügbar machen.
Künstlerische Lizenz 2.0 — es ermöglicht Ihnen, modifizierte Versionen zu verteilen oder zu verkaufen, solange Sie Zugriff auf die Originalversion behalten und Änderungen veröffentlichen.
Gemeinsame Entwicklungs- und Vertriebslizenz — Sie können Binärdateien unter einer proprietären Lizenz verteilen, solange der ursprüngliche und modifizierte Quellcode unter CDDL zur Verfügung gestellt wird.
Öffentliche Microsoft-Lizenz — Sie müssen die Lizenz und die vorhandenen Urheberrechte verknüpfen, um die Software frei verwenden zu können. Diese Lizenz kann nur mit kompatiblen Lizenzen verwendet werden.
Mozilla Public License (MPL) 1.1 — Sie müssen in jede Quelldatei einen Hinweis aufnehmen. Diese Lizenz ist nicht mit der GPL kompatibel.
Bei freizügigen Lizenzen müssen Sie in den meisten Fällen den Copyright-Hinweis beibehalten.
Apache Lizenz 2.0 — es handelt sich um eine freizügige Lizenz, die es Ihnen ermöglicht, mit der Software zu tun, was Sie wollen, und alles, was Sie tun müssen, ist die erforderlichen Hinweise beizufügen.
BSD-Lizenz 2.0 — Sie müssen den BSD-Copyright-Hinweis angeben, um den Code kopieren, verteilen und ändern zu können.
Codeprojekt Open License 1.02 — keine Software darf für „illegale, unmoralische oder unangemessene Zwecke“ verwendet werden.
ISC-Lizenz — Sie müssen das ursprüngliche Copyright angeben, um den Code frei verwenden zu können.
MIT-Lizenz — das ist eine der freizügigsten Open-Source-Lizenzen. Sie müssen lediglich sicherstellen, dass Sie eine Kopie der ursprünglichen MIT-Lizenz und des Copyright-Hinweises hinzufügen.
OSS-Compliance ist die Prozess, wenn Ihr Team Copyright-Hinweise beachtet, um die Anforderungen zu erfüllen der Lizenzen für jede Komponente ihrer Software. Um die Anforderungen zu erfüllen, müssen Sie wissen, welche Open-Source-Komponenten in der Codebasis enthalten sind.
Was tun, wenn Sie feststellen, dass Sie die Lizenz nicht eingehalten haben? In den meisten Fällen haben Sie drei Möglichkeiten. Die erste besteht darin, sie einfach einzuhalten (bei vielen Lizenzen bedeutet das nur, dass Sie die Lizenzdatei hinzufügen müssen). Die zweite besteht darin, dass Sie sich nicht mehr auf diesen lizenzierten Code verlassen müssen. Und die dritte besteht darin, zu bezahlen und eine alternative kommerzielle Lizenz zu erhalten.
<blockquote><p>Es gibt über 300 OSS-Lizenzen, und es werden immer mehr. Die gute Nachricht ist jedoch, dass rund 20 Lizenzen 80% der in Unternehmen häufig verwendeten OSS ausmachen. Eine schwarze und weiße Liste dieser Lizenzen zusammen mit einem Scan-Tool bietet also bereits einen sehr guten Ausgangspunkt</p> für deren Verwaltung. <p>— Debmalja Biswas, Direktor für Datenanalyse und KI bei Wipro</p></blockquote>
Wenn Sie den Lizenzen vorher nicht viel Aufmerksamkeit geschenkt haben, Konzentrieren Sie sich zunächst darauf, die restriktivsten Lizenzen zu erkennen.
Dann wird es entscheidend sein, Ihr Entwicklungsteam zu schulen — es muss sich der Risiken und Absichten bewusst sein, die hinter Lizenzen stehen. Bei der Vorbereitung Ihres Prozesses empfiehlt es sich, eine weiße und eine schwarze Liste von Lizenzen zu erstellen.
Da Ihr Code höchstwahrscheinlich voller tief versteckter Lizenzen ist, möchten Sie vielleicht beginnen Sie mit der Verwendung eines Tools zur Nachverfolgung von Softwarelizenzen um potenzielle Probleme automatisch zu erkennen.
Die <blockquote><p>Lizenznutzung scheint sich auf Projekte zu verlagern und eher freizügige Lizenzen zu bevorzugen. Allerdings mit den jüngsten Ereignissen — wie denen rund um Faker (wo der Autor hat seine eigene Bibliothek beschädigt) und Log4Shell (weit verbreitetes Sicherheitsproblem) — Ich glaube, wir werden sehen, dass entweder die Leute mehr Kontrolle anstreben (wie ihre eigenen Unternehmens-OSS-Lizenzen, denken Sie an Amazon und ihren ElasticSearch-Fork) oder wir werden vielleicht gemeinsam eine sehr harte Lernerfahrung machen. Angesichts der Tatsache, dass die meisten Open-Source-Programme auch ausgebeutet und unterbezahlt (falls überhaupt bezahlt) werden wir möglicherweise sogar Änderungen an den Betriebsmodellen feststellen, die die Art und Weise betreffen, wie OSS überhaupt erstellt wird.</p> <p>— Mikael Vesavuori, Cloud-Softwarearchitekt und Leiter der technischen Standards bei Polestar</p></blockquote>
Unsere Entwickler haben ein License Auditor-Tool entwickelt, mit dem Sie die Lizenzen in Ihrem Projekt verfolgen und validieren können. Es hilft Teams dabei, Open-Source-Lizenzen einzuhalten, indem Senden von Benachrichtigungen über mögliche Probleme.
Den License Auditor finden Sie hier auf GitHub.
<blockquote><p>Ich habe den „kopflosen Hühnertanz“ gesehen, bei dem Unternehmen entweder bei Verstößen erwischt werden oder anfangen, darüber nachzudenken und ausrasten, versuchen, alles ohne Werkzeug zu inventarisieren und den Verbrauch aufgrund fehlgeleiteter Meinungen oder Angst einschränken. <p></p>Stattdessen sollten Sie dazu beitragen, mithilfe von Tools und Prozessen, die Sie bei der Arbeit unterstützen, einen Überblick zu schaffen und dies dann in (für Entwickler zuständigen) Tools zu automatisieren — dort, wo es täglich darauf ankommt. Fördern Sie auch das Bewusstsein dafür, entweder durch Schulungen oder durch Bekanntwerden, z. B. durch interne Open-Source-Projekte, was dazu beitragen wird, die Lizenzfrage zu einem weniger theoretischen Thema zu machen</p>. <p>— Mikael Vesavuori, Cloud-Softwarearchitekt und Leiter der technischen Standards bei Polestar</p></blockquote>
Die Einhaltung von Open-Source-Lizenzen mag auf den ersten Blick einschüchternd wirken, aber letztendlich müssen Sie nur das Bewusstsein dafür schärfen und das Risiko managen.
Verstehen Sie zunächst die Absichten hinter den Lizenzen und verwenden Sie ein Tool zur Nachverfolgung von Softwarelizenzen, das Benachrichtigungen sendet, wenn Probleme festgestellt werden.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
.jpg){kind=avatar}
Software Engineer & Solutions Architect mit 16 Jahren Berufserfahrung. Leiter der technischen Abteilung bei Brainhub, der das Engineering-Team technisch leitet.
Enthusiast für Softwareentwicklung mit 8 Jahren Berufserfahrung in der Technologiebranche. Erfahrung im Outsourcing von Marktanalysen, mit besonderem Schwerpunkt auf Nearshoring. In der Zwischenzeit unser Experte darin, technische, geschäftliche und digitale Themen auf verständliche Weise zu erklären. Autor und Übersetzer nach Feierabend.
Software Engineer & Solutions Architect mit 16 Jahren Berufserfahrung. Leiter der technischen Abteilung bei Brainhub, der das Engineering-Team technisch leitet.
Enthusiast für Softwareentwicklung mit 8 Jahren Berufserfahrung in der Technologiebranche. Erfahrung im Outsourcing von Marktanalysen, mit besonderem Schwerpunkt auf Nearshoring. In der Zwischenzeit unser Experte darin, technische, geschäftliche und digitale Themen auf verständliche Weise zu erklären. Autor und Übersetzer nach Feierabend.
Read next
Popular this month
previous article in this collection
It's the first one.
