Open Source nutzen.
Die Bedingungen kennen.
Open-Source-Komponenten stecken in Anwendungen, Bibliotheken, Containern und Entwicklungswerkzeugen. Oft gelangen sie über Abhängigkeiten oder externe Lieferanten in ein Unternehmen. Ein Verzeichnis gekaufter Software bildet diese Bestandteile deshalb nur teilweise ab.
bbi unterstützt Sie dabei, die verwendeten Komponenten und ihre Lizenzbedingungen strukturiert zu betrachten. Gemeinsam klären wir den Einsatz, organisieren Nachweise und definieren einen handhabbaren Prüfprozess. Ziel ist eine nachvollziehbare Entscheidung darüber, wie eine Komponente im jeweiligen Projekt verwendet werden kann.
Komponenten kennen
Direkte und mitgelieferte Abhängigkeiten, Versionen und Herkunft nachvollziehbar erfassen.
Bedingungen einordnen
Den jeweiligen Lizenztext mit Nutzung, Änderungen und Weitergabe im Projekt verbinden.
Umsetzung organisieren
Hinweise, Dokumentation und erforderliche Massnahmen mit klaren Zuständigkeiten pflegen.
Open Source erlaubt Nutzung, Veränderung und Weitergabe unter den jeweiligen Lizenzbedingungen. Eine öffentlich einsehbare Quelldatei allein ist noch kein Beleg für eine Open-Source-Lizenz. Die Open Source Initiative bietet eine Übersicht anerkannter Lizenzen.
Der Lizenzname ist der Anfang.
Der Einsatz macht den Unterschied.
Für eine Prüfung benötigen wir mehr als den Namen einer Bibliothek. Relevant sind die konkrete Version, der zugehörige Lizenztext, mögliche Ausnahmen und die Art, wie die Komponente eingebunden und bereitgestellt wird. Bei mehreren Lizenzoptionen sollte dokumentiert sein, auf welcher Grundlage das Projekt arbeitet.
Intern verwenden
Welche Komponente wird unverändert oder angepasst innerhalb der Organisation genutzt? Wer erhält Zugriff oder Kopien?
Software weitergeben
Was liefern Sie an Kunden, Partner oder andere Organisationen aus? Welche Bestandteile und Änderungen enthält dieses Paket?
Über ein Netzwerk anbieten
Welche Software betreiben Sie als Dienst? Gibt es Anpassungen und lizenzspezifische Anforderungen für die Interaktion über ein Netzwerk?
Permissive Lizenzen und Copyleft unterscheiden
Lizenzen wie MIT oder Apache 2.0 werden häufig als permissiv bezeichnet. Auch sie enthalten Bedingungen, beispielsweise zu Hinweisen oder zur Weitergabe des Lizenztextes. Bei Copyleft-Lizenzen wie der GPL können weitergehende Anforderungen für die Weitergabe entstehen. Umfang und Auslöser hängen von der konkreten Lizenz und der technischen Verbindung ab.
Die AGPL enthält zusätzlich eine Regel für bestimmte Netzwerknutzung geänderter Programme. Daraus folgt weder, dass jede intern verwendete Open-Source-Komponente veröffentlicht werden muss, noch dass ein Dienst im Browser grundsätzlich ohne weitere Prüfung auskommt. Die GNU-Lizenz-FAQ erläutert wichtige Unterschiede.
Bei strittigen Auslegungsfragen schaffen wir die technische und vertragliche Faktenbasis für eine gezielte juristische Klärung. Pauschale Freigaben allein aufgrund eines Lizenznamens wären dafür keine belastbare Grundlage.
Aus Listen werden
nachvollziehbare Entscheidungen.
Eine Komponentenliste ist ein guter Anfang
Eine Software Bill of Materials, kurz SBOM, beschreibt die Bestandteile einer Software. Für die Lizenzarbeit ist wichtig, dass die Liste zum untersuchten Produktstand passt. Herkunft, Versionen, erkannte Lizenzen und offene Zuordnungen sollten nachvollziehbar bleiben.
Eine SBOM allein bestätigt noch nicht, dass alle Bedingungen erfüllt sind. Wir verbinden die Bestandsinformationen deshalb mit der vorgesehenen Nutzung und den dazugehörigen Massnahmen. Ergebnisse aus Analysewerkzeugen dienen als Hinweise, die bei unklaren Treffern überprüft werden müssen.
Vor einem Release
Komponentenbestand, Lizenzhinweise und offene Prüfpunkte vor der Auslieferung zusammenführen. Freigaben mit dem betreffenden Produktstand verknüpfen.
Bei externen Lieferanten
Benötigte Informationen und Nachweise bereits im Auftrag festlegen. Die Übergabe einer Anwendung sollte auch ihre relevanten Fremdkomponenten berücksichtigen.
Bei Updates und Änderungen
Neue Versionen, veränderte Abhängigkeiten oder einen anderen Bereitstellungsweg zum Anlass für eine erneute Bewertung nehmen.
Lizenzprüfung und Sicherheitsprüfung ergänzen sich, beantworten aber unterschiedliche Fragen. Ein Paket ohne bekannte Schwachstelle kann dennoch offene Lizenzfragen haben. Umgekehrt sagt eine geklärte Lizenz nichts über die technische Sicherheit aus.
Ein Prozess, der zum
Team passt.
Ein Projekt auswählen
Wir starten mit einer konkreten Anwendung oder einem geplanten Release. Verantwortliche, Auslieferungswege und das gewünschte Ergebnis werden festgelegt.
Bestand und Nachweise sammeln
Komponentenlisten, vorhandene SBOMs, Lizenztexte und Angaben der Lieferanten zusammenführen. Unklare oder fehlende Informationen sichtbar machen.
Prüfpunkte priorisieren
Nutzungsszenarien und Lizenzbedingungen gegenüberstellen. Erforderliche Hinweise, Dokumentation und weiterführende Abklärungen festhalten.
Freigabe und Pflege vereinbaren
Zuständigkeiten, Nachweise und den Umgang mit Änderungen definieren. Das Ergebnis soll bei späteren Releases wiederverwendbar sein.
Als Orientierung für einen organisatorischen Prozess kann OpenChain ISO/IEC 5230 dienen. Der Standard beschreibt Anforderungen an ein Open-Source-Lizenz-Compliance-Programm. Welche Elemente für Ihr Team sinnvoll sind, klären wir anhand Ihrer Organisation und Lieferbeziehungen.
Die Verbindung zum gesamten Softwarebestand finden Sie in unserem strategischen Lizenzmanagement. Für offene Schriftlizenzen und kommerzielle Schriftangebote gibt es unsere Beratung zu Schriften und Schriftlizenzen.
Fragen aus der Praxis.
Ist Open Source immer kostenlos?
Open Source beschreibt die eingeräumten Rechte und Bedingungen. Für Dienstleistungen, Support, Bereitstellung oder andere Angebote können Kosten entstehen. Kostenfreiheit ist kein Ersatz für eine Lizenzprüfung.
Muss unser eigener Quellcode veröffentlicht werden?
Das lässt sich nur anhand der verwendeten Lizenz, der Einbindung, möglicher Änderungen und der Bereitstellung beurteilen. Eine solche Pflicht entsteht nicht pauschal durch jede Open-Source-Komponente.
Reicht ein automatischer Scan aus?
Ein Scan hilft, Komponenten und mögliche Lizenzen zu erkennen. Für eine Entscheidung braucht es zusätzlich den Nutzungskontext, die Prüfung unklarer Treffer und die Umsetzung der einschlägigen Bedingungen.
Betrifft das auch zugekaufte Software?
Auch gelieferte Anwendungen können Open-Source-Komponenten enthalten. Welche Informationen und Aufgaben für Sie relevant sind, hängt unter anderem von Ihrem Einsatz und einer möglichen Weitergabe ab.
Welche Unterlagen helfen beim Einstieg?
Hilfreich sind eine Beschreibung der Anwendung, der geplante Bereitstellungsweg, Komponentenlisten oder SBOMs sowie vorhandene Lizenzinformationen. Wir besprechen, welche weiteren Angaben benötigt werden.
GEMEINSAM KLÄREN
Wo stehen Sie
heute?
Beschreiben Sie uns Ihre Ausgangslage. Wir besprechen die offenen Fragen und einen sinnvollen Umfang für die Unterstützung.