Open-Source im Unternehmen: Ein Blick auf den Value Stream

Open-Source ist keine Randerscheinung. Ob Webframework, Datenbank, DevOps-Tooling oder Embedded-Komponente, Open-Source-Software Komponenten sind heute in fast allen Teilen moderner IT-Landschaften zu finden. Doch der Einsatz von Open Source ist weit mehr als nur eine technische Entscheidung. Er berührt Geschäftsmodelle, Rechtsfragen, Sicherheitsanforderungen und zunehmend auch regulatorische Rahmenbedingungen.

In diesem Artikel betrachten wir den Lebenszyklus von Open-Source in Unternehmen entlang eines Value Streams, also vom ersten Berührungspunkt über die produktive Nutzung bis zur Auslieferung des finalen Produktes. Das Ziel ist es, ein strukturiertes Verständnis zu vermitteln, wie Open-Source im Unternehmen eigentlich„fließt“ und wo steuernde Eingriffe notwendig sind, um langfristig sicher und konform zu bleiben.

Input Stream – Wie Open-Source ins Unternehmen gelangt

Der Einstiegspunkt für Open-Source in Unternehmen ist vielfältig und oftmals intransparent. In der Praxis erfolgt die Einführung von Open-Source-Komponenten häufig informell. Entwickler binden schnell eine Bibliothek ein, ein externer Dienstleister bringt sein eigenes Setup mit oder eine zugekaufte Software enthält bereits zahlreiche quelloffene Abhängigkeiten. Ohne klare Prozesse und Zuständigkeiten entsteht so leicht ein blinder Fleck, mit den entsprechenden rechtlichen und sicherheitstechnischen Risiken.

Typische Quellen für Open-Source im Unternehmen:

• Eigene Entwickler, die Bibliotheken aus öffentlichen Repositories wie GitHub oder PyPI integrieren
• Freelancer und Agenturen, die bestehende Open-Source-Stacks mitbringen
• Gekaufte Produkte oder Tools, in denen Open Source enthalten ist
• Entwickler, die bestehende Software anpassen oder „forken“

In dieser frühen Phase fehlt häufig ein zentrales Bewusstsein für die Lizenzlage, die Sicherheitsqualität oder die regulatorische Relevanz der eingesetzten Komponenten. Genau hier setzen moderne Open-Source-Management-Strategien an, durch vertragliche Regelungen, technische Kontrollen und gezielte Schulungsmaßnahmen. Das alles am besten noch Toolunterstützt, um effizient zu arbeiten.

Rollen, Verträge, Kontrollen

Ein professioneller Umgang mit Open-Source beginnt mit klaren Verantwortlichkeiten. Unternehmen sollten definieren, wer überhaupt neue Open-Source-Komponenten einbringen und unter welchen Bedingungen dies geschehen darf. Bei externen Partnern empfiehlt es sich, bereits in Projektverträgen verbindliche Regelungen zu verankern, etwa:

• Offenlegungspflichten für eingesetzte Open-Source-Komponenten
• Zusicherungen zur Lizenzkonformität
• Verpflichtung zur Einhaltung unternehmensinterner Richtlinien
• Prüf- und Auditrechte

Technisch kann der Einsatz von Open-Source durch sogenannte Approval Workflows geregelt werden: Entwickler reichen eine neue Komponente zur Freigabe ein, bevor sie in produktive Umgebungen gelangt. Unterstützt wird dies durch SCA-Tools (Software Composition Analysis), die automatisch Lizenz- und Sicherheitsinformationen auslesen und mit den internen Vorgaben abgleichen.

Schulung und Awareness

Ein kritischer Erfolgsfaktor ist die Sensibilisierung der Beteiligten. Viele Entwickler und Projektverantwortliche sind sich nicht bewusst, dass sie mit dem Einbinden eines simplen Packages potenziell eine copyleft-Lizenz mit weitreichenden Bedingungen in die Software holen. Schulungen helfen, dieses Verständnis aufzubauen, nicht nur bei Entwicklern, sondern auch bei Legal, Einkauf und Management. Schulungen sollten praxisnah, regelmäßig und rollenspezifisch gestaltet werden. Es sollte ebenfalls sichergestellt werden, dass alle Projektmitglieder ein entsprechendes Wissen aufbauen, dazu zählen auch externe, sowie temporäre Projektmitglieder.

Throughput – Wie Open-Source intern genutzt und weiterentwickelt wird

Sobald Open Source im Unternehmen angekommen ist, beginnt der zweite Abschnitt des Flusses. Dazu zählt die Nutzung, Modifikation und die eigene Veröffentlichung von Open-Source-Software Komponenten. Genau hier liegt der eigentliche Hebel für Produktivität und Innovation, aber auch für potenzielle rechtliche Risiken.

OSS im Produkt

In den meisten Fällen werden Open-Source-Komponenten im Rahmen von Produktentwicklung verbaut. Eine Bibliothek wird als Teil eines Backends verwendet, ein Frontend-Framework liefert die Basis für das UI, oder eine Datenbanklösung wird als Service integriert. Das alles geschieht oft über viele Jahre hinweg mit Updates, Patches, Sicherheitsfixes.

Ohne klare Prozesse verliert das Unternehmen hier schnell die Übersicht. Wer weiß noch, welche Bibliothek in welcher Version verbaut wurde? Wer hat Modifikationen vorgenommen? Gibt es Sicherheitslücken? Und darf die Komponente überhaupt so verwendet werden?

Forks, Patches, Upstreams

Nicht selten werden Open-Source-Komponenten auch verändert, beispielsweise um sie an eigene Bedürfnisse anzupassen. Solche „Forks“ müssen rechtlich, technisch und organisatorisch sauber dokumentiert werden. Besonders relevant wird dies, wenn die veränderte Komponente später wieder veröffentlicht wird, sei es als Teil eines Produkts oder als eigenständiges Open-Source-Projekt. Hierbei ist sehr darauf zu achten, welche Lizenz das ursprüngliche Werk hatte und unter welcher Lizenz das neu geschaffene Werk veröffentlicht werden darf beziehungsweise sogar muss. Das Stichwort ist hier Copyleft-Effekt.

Verantwortung und Governance

Der Umgang mit Open-Source erfordert mehr als nur Tooling, es braucht klare Strukturen. In vielen Organisationen bewährt sich ein dediziertes Open-Source Office oder ein OSS Review Board, das Richtlinien definiert, Entscheidungen trifft und die Nutzung begleitet. Ein einfaches Rollenmodell kann etwa so aussehen:

• Entwickler: Bringen OSS ein, halten sich an Policies. Evaluieren, wie Lizenzvorgaben technisch umgesetzt werden können.
• Reviewer: Bewerten Lizenzrisiken und Sicherheitslage.
• Legal: Klärt Spezialfragen zu Lizenzen und Veröffentlichung.
• Security: Bewertet technische Risiken und CVEs.
• Management: Priorisiert und trifft Richtungsentscheidungen.

Gleichzeitig muss die Governance leben. Das heißt, Policies müssen erklärt, Schulungen durchgeführt und Verantwortlichkeiten regelmäßig überprüft werden. Einmalige Awareness-Kampagnen reichen nicht aus (sie reichen eigentlich bei keinem Thema je aus). Open Source erfordert kontinuierliche Kommunikation und Verbesserung.

Output Stream – Wenn das Produkt den Markt erreicht

Der dritte Abschnitt im Open-Source-Value-Stream ist der kritischste. Wenn ein Produkt das Unternehmen verlässt, sei es als Softwareprodukt, eingebettete Lösung oder SaaS-Plattform, trägt das Unternehmen volle Verantwortung für alle enthaltenen Komponenten. Das gilt, sowohl wenn das Softwareprodukt das finale Endprodukt ist, als auch wenn es weiterverarbeitet wird.

Lizenzpflichten ernst nehmen

Wird ein Produkt ausgeliefert, das Open-Source-Komponenten enthält, greifen meist konkrete Pflichten. Einige Lizenzen verlangen die Beilage von Lizenztexten, andere die Offenlegung von Änderungen oder gar des gesamten Quellcodes. Werden diese Vorgaben verletzt, drohen nicht nur rechtliche Konsequenzen, sondern auch Reputationsverluste. Zudem muss auch das Copyright des ursprünglichen Autors berücksichtigt werden.

Zur sauberen Umsetzung gehören:

• Die Erstellung vollständiger NOTICE-Dateien
• Die Beilage von Lizenztexten und Urheberhinweisen
• Die Offenlegung von Modifikationen, falls gefordert
• Individuelle Bewertung basierend darauf, wie die Software ausgeliefert wird

SBOMs und regulatorische Anforderungen

Mit neuen Vorgaben wie dem Cyber Resilience Act (CRA) rücken auch regulatorische Pflichten in den Vordergrund. Der CRA verpflichtet Hersteller dazu, detaillierte Informationen über Software-Komponenten bereitzustellen, etwa in Form einer Software Bill of Materials (SBOM). Wer hier keine strukturierte Übersicht über seine Open-Source-Komponenten pflegt, gerät schnell ins Hintertreffen.

Gleichzeitig bietet die ISO/IEC 5230 (OpenChain) einen praktikablen Rahmen, um ein standardisiertes OSS-Compliance-Management aufzubauen. Unternehmen, die sich frühzeitig daran orientieren, sind nicht nur rechtlich besser abgesichert, sie bauen auch Vertrauen auf.

Sonderfall: Weitergabe an Dritte

Besonders heikel wird es, wenn Produkte an Partnerunternehmen oder Integratoren weitergegeben werden, die selbst wieder Produkte daraus bauen. In solchen Fällen entstehen zusätzliche Verpflichtungen:

• Bereitstellung vollständiger SBOMs
• Verweis auf Lizenzbedingungen und Quellcode
• Vermeidung von Lizenzkollisionen (z. B. GPL in proprietären Umgebungen)
• Vertragsklauseln zur OSS-Weitergabe

Fazit – Open-Source als Prozess verstehen

Open-Source ist kein einmaliges Projekt, sondern ein kontinuierlicher Fluss, ein Value Stream, der technisches, organisatorisches und rechtliches Know-how miteinander verknüpft. Wer Open Source richtig nutzen will, braucht nicht nur Tools, sondern auch Klarheit über Rollen, Prozesse, Verantwortlichkeiten und Schulungen.

Drei zentrale Empfehlungen für Unternehmen:

1. Strukturen schaffen: Etablieren Sie klare Prozesse, Rollen und eine zentrale Governance für den Einsatz von OSS.
2. Transparenz herstellen: Setzen Sie auf automatisierte Tools (z. B. SCA, SBOM-Generatoren) und nachvollziehbare Dokumentation.
3. Wissen aufbauen: Schulen Sie Ihre Teams – regelmäßig, praxisnah und rollenspezifisch.