Inhalt einer Open-Source Policy

Warum Open-Source Governance immer wichtiger wird

Open-Source Software ist längst Standard, nicht nur in Start-ups, sondern in nahezu jedem Unternehmen, das digitale Produkte entwickelt oder anbietet. Das gilt für reine Softwareprodukte, aber auch für IoT Produkte. Gerade für den Embedded Bereich ist ein richtiger Umgang mit Open-Source elementar.

Ob Webshops, mobile Apps, IoT-Plattformen oder Embedded-Systeme, überall steckt Open-Source drin. Das ist kein Zufall, sondern die Nutzung von Open-Source bietet die folgenden Vorteile:

• schnellere Entwicklungszyklen, weil auf bestehenden Bibliotheken aufgebaut wird und nicht alles selbst entwickelt werden muss
• geringere Kosten, durch den Wegfall von kommerzieller Software und deren Lizenzgebühren
• höhere Qualität, weil sich weltweite Entwickler-Communitys um Fehlerbehebungen kümmern und Komponenten oftmals schon zahlreich implementiert und getestet wurden
• und Innovationen, weil Ideen offener geteilt werden und gemeinsam an Verbesserungen gearbeitet wird

Doch die Nutzung von Open Source bringt auch Pflichten und Risiken mit sich. Wer Open Source Software nicht sauber verwaltet, kann schnell in rechtliche Schwierigkeiten geraten, etwa wegen Lizenzverstößen, die Unterlassungserklärungen, Vertragsstrafen oder gar den Zwang zur Offenlegung des eigenen Source Codes nach sich ziehen.

Eine Open Source Policy ist deshalb kein „Nice-to-have“, sondern ein entscheidendes Steuerungsinstrument, um Open Source sicher, strategisch und regelkonform zu verwenden. Eine Open-Source Policy ist der Grundbaustein für die Open-Source Governance.

Die zentralen Inhalte einer Open Source Policy

Eine gute Open Source Policy beantwortet im Wesentlichen die folgenden Fragen:

• Wie nutzen wir Open Source und wie passt dies in den Unternehmenskontext und zu den Unternehmenszielen?
• Wer ist verantwortlich für welche Aktivitäten?
• Wie stellen wir sicher, dass wir die Lizenzen einhalten?
• Wie reagieren wir, wenn es zu Problemen kommt?
• Welche Lizenzen sind erlaubt und welche nicht?
• Wie bauen wir Wissen im Unternehmen auf?
• Wie überprüfen wir die Inhalte unserer Policy?

Wenn man sich die Fragen anschaut, wird schnell klar, dass die Open-Source Policy sich sowohl in den vorgegebenen Unternehmenskontext integrieren als auch konkrete praktische Anweisungen geben muss. Je nach Unternehmen kann unterschieden werden, wie detailliert die Anweisungen, also die konkrete Umsetzung sein sollen. Das hängt maßgeblich davon ab, wie schnell die Open-Source Policy geändert werden kann. Ist eine flexible Anpassung nicht möglich, ist es sinnvoller, sich mehr auf das “Was gibt es zu beachten / zu erledigen”, als sich auf das “Wie setze ich das konkret um”, zu fokussieren. Wichtig hierbei ist dann jedoch eine Verlinkung zu den konkreten Umsetzungshinweisen.

Neben den oben genannten Fragen besteht eine typische Open-Source aus den folgenden Kapiteln:

Einleitung und Zielsetzung

Hier sollte das Unternehmen betonen, warum es Open-Source nutzt und welche strategischen Ziele damit verbunden sind. Wichtig hierbei ist immer der Link zum Unternehmenskontext und den Unternehmenszielen. Sowohl die Informationssicherheit als auch die Open-Source Compliance Vorgaben müssen immer die Unternehmensziele unterstützen und dürfen daher nicht isoliert betrachtet werden.

Anbei einige Beispielsätze für die Erläuterung der Ziele, welche mit Open-Source verfolgt werden:

• „Wir setzen auf Open-Source, um Entwicklungskosten zu reduzieren, Innovation zu fördern und lock-in bei Anbietern zu vermeiden.“
• „Wir möchten durch aktiven Beitrag zu Open-Source Communities unser technisches Know-how vertiefen und unsere Marke als technologischer Vorreiter stärken.“

Geltungsbereich und Anpassbarkeit

Eine Open Source Policy sollte klar festlegen, für welche Bereiche sie gilt. In den meisten Fällen betrifft das:

• alle Softwareprodukte, die das Unternehmen extern bereitstellt (z. B. via Download, API oder SaaS)
• aber oft auch interne Projekte, die auf OSS basieren

Je nach Unternehmensgröße und Branche kann dieser Geltungsbereich angepasst werden. Manche Firmen regeln Open Source streng nur für externe Auslieferungen, andere binden auch interne Entwicklungsprojekte ein, um später die Software kommerziell einsetzen zu können. Wie auch bei der Implementierung eines ISMS nach der ISO 27001 ist der Aufbau eines Open-Source Compliance Programs ein nicht zu unterschätzender Aufwand. Daher ist es sinnvoll, den Scope zu Beginn klein zu halten und diesen iterativ zu erweitern.

Klare Begriffsdefinitionen und Abkürzungen

Damit alle im Unternehmen dieselbe Sprache sprechen, lohnt es sich, wichtige Begriffe in der Policy zu definieren. Die folgende Liste zeigt einige Beispiele und ist nicht vollständig:

• Open-Source Software (OSS): Software, die unter einer Lizenz steht, die die freie Nutzung, Modifikation und Weitergabe erlaubt (etwa nach Definition der Open Source Initiative).
• Compliance-Artefakte: Alle Dokumente, Quelltexte und Nachweise, die zeigen, dass das Unternehmen die Lizenzpflichten eingehalten hat, etwa Lizenztexte, Copyright-Hinweise oder Stücklisten (BOMs).
• Supplied Software: Alles, was das Unternehmen an Dritte liefert oder bereitstellt, z. B. als Binary, Quellcode-Archiv oder über einen Webservice.

Diese Definitionen sollten auf den Unternehmenskontext abgestimmt sein. Es macht einen Unterschied, ob ein Start-up mit Fokus auf SaaS agiert oder ein Industriekonzern Embedded-Software an OEMs liefert. Zusätzlich sollten auch unternehmensinterne Abkürzungen oder Begriffe aufgegriffen werden.

Verantwortlichkeiten und Rollen

Damit eine Open-Source Policy nicht nur auf dem Papier existiert, sondern auch im Tagesgeschäft gelebt wird, müssen Rollen, Aufgaben und Entscheidungsbefugnisse präzise definiert sein. Eine RACI-Matrix bietet hier ein bewährtes Instrument, um Verantwortlichkeiten transparent zu machen und sicherzustellen. Das Ziel ist es, dass alle wissen, wofür sie oder sie verantwortlich ist.

In vielen Organisationen haben sich bestimmte Rollen etabliert:

• Open-Source Compliance Lead: Die zentrale Person, die den Überblick über alle OSS-Nutzungen behält, Lizenzprüfungen durchführt und Ansprechpartner für Teams und Management ist.
• Open-Source Liaison: Eine Schnittstelle nach außen, beispielsweise zu Open Source Projekten, Communitys oder falls rechtliche Anfragen kommen.
• Produktverantwortliche, Entwicklungs- und QA-Teams: Sie müssen OSS-Vorgaben praktisch umsetzen und sind häufig für das richtige Tool Set-Up verantwortlich.

Wichtig ist, dass die Policy nicht nur Rollen benennt, sondern auch beschreibt, wie sie organisatorisch verankert sind und welche Eskalationswege es gibt. Natürlich können und sollten Unternehmen hier eigene Titel und Verantwortungsstrukturen wählen.

Schulungen und Bewusstsein

Damit Open-Source im Unternehmen nicht zum Stolperstein wird, müssen alle Beteiligten wissen, worauf es ankommt. Schulungen sind dafür das A und O, und zwar nicht nur einmal am Anfang, sondern immer wieder und genau da, wo sie gebraucht werden. Entwickler brauchen oft andere Infos als Produktmanager oder Legal-Teams. Eine gute Policy und natürlich die entsprechende Implementierung sorgen deshalb dafür, dass alle genau die Trainings bekommen, die zu ihren Aufgaben passen. Und klar Wissen ist Macht. Wer versteht, wie Open Source tickt, kann sicherer damit umgehen und macht weniger Fehler. Wichtig ist aber auch, dass dafür genug Zeit eingeplant wird, Schulungen dürfen kein lästiger Zusatzjob sein, sondern gehören selbstverständlich zum Arbeitsalltag und sind absolut elementar.

Daher sollten die folgenden Aspekte in der Open-Source Policy berücksichtigt werden:

• welche Rollen, welche Trainings absolvieren müssen (z. B. zu Open Source Lizenzen, Risikoerkennung, Umgang mit Dritten)
• wie Schulungsnachweise dokumentiert werden
• und in welchen Abständen Wiederholungen stattfinden
• das Commitment vom Management, dass die entsprechende Zeit zur Verfügung gestellt wird

Wichtig hierbei ist es auch, dass nicht nur interne Mitarbeiter geschult werden. Das Bewusst und das Wissen muss auch bei externen Parteien (Lieferanten, Freelancer) sichergestellt werden.

Lizenzprüfung und Dokumentation

Open Source Lizenzen sind alles andere als gleich. Es gibt sehr permissive Lizenzen wie die MIT- oder BSD-Lizenz, die fast keine Einschränkungen machen und eine weitgehend freie kommerzielle Nutzung ermöglichen. Auf der anderen Seite stehen sogenannte Copyleft-Lizenzen wie die GPL, die bestimmte Bedingungen an die Weitergabe knüpfen beispielsweise, dass der eigene Quellcode offengelegt werden muss, wenn Software weitervertrieben wird. Manche Lizenzen legen besonderen Wert auf Namensnennung und Haftungsausschluss, andere verlangen, dass Änderungen am ursprünglichen Code klar ausgewiesen werden. Außerdem gibt es Mischformen und Sonderfälle, die etwa nur für nicht-kommerzielle Zwecke kostenlos sind oder bei SaaS-Angeboten besondere Auflagen machen. Deshalb ist es so wichtig, die Lizenzbedingungen jeder eingebundenen Komponente genau zu prüfen und zu verstehen, bevor sie in ein Produkt einfließt.

Die Policy sollte daher einen klaren Prozess beschreiben, wie Open-Source-Komponenten und ihre Lizenzen geprüft werden. Typischerweise umfasst das folgende Schritte:

• Transparenz schaffen: Zuerst wird festgehalten, welche Open-Source-Komponenten überhaupt verwendet werden und in welchem Produkt- oder Projektkontext sie eingesetzt werden sollen. Nur so lässt sich später nachvollziehen, wo welche Abhängigkeiten bestehen.

• Lizenz erkennen: Anschließend wird die konkrete Lizenz jeder Komponente ermittelt. Hierbei helfen Tools, die automatisch Software-BOMs und Lizenz-Reports erstellen, ebenso wie manuelle Checks in Repositories.

• Lizenz prüfen: Danach wird bewertet, ob die gefundene Lizenz mit den eigenen Geschäftsmodellen und internen Regeln kompatibel ist. Zum Beispiel: Erlaubt die Lizenz eine kommerzielle Nutzung, oder gibt es Copyleft-Auflagen, die problematisch wären?

• Offene Fragen klären: Falls Unklarheiten bestehen, etwa bei Mischlizenzen oder ungewöhnlichen Lizenztexten, werden diese mit der Rechtsabteilung oder externen Spezialisten besprochen.

• Alles dokumentieren: Abschließend wird die Entscheidung, inklusive Begründung, sauber dokumentiert. So lässt sich auch später noch nachweisen, warum eine bestimmte Komponente unter welchen Voraussetzungen ins Produkt aufgenommen wurde.

Aufnahme neuer Open Source Komponenten

Wann darf ein Entwickler einfach ein GitHub-Repo klonen und verwenden? Kurze Antwort: am besten nie ohne vorherige Genehmigung oder klares Ergebnis durch vorhandene Policies. Damit Open Source sicher und strategisch ins Unternehmen eingebunden wird, sollte die Policy klar festlegen, nach welchen Kriterien neue Komponenten geprüft und zugelassen werden.

Ein wichtiger Punkt ist die Prüfung der Herkunft. Stammt die Komponente aus einem offiziellen Release eines bekannten Projekts oder aus einem beliebigen Fork, der vielleicht gar nicht mehr gepflegt wird? Gerade die langfristige Wartbarkeit hängt oft davon ab, wie stabil und aktiv die Ursprungsquelle ist.

Danach folgt die Bewertung der Lizenzverträglichkeit. Passt die Lizenz überhaupt zu den eigenen Geschäftsmodellen und Distributionsplänen? Nicht jede Lizenz erlaubt eine uneingeschränkte kommerzielle Nutzung, und gerade Copyleft kann schnell zu Überraschungen führen, wenn man nicht genau hinschaut.

Auch eine Analyse möglicher Sicherheitslücken und des Wartungszustands gehört dazu. Gibt es bekannte Schwachstellen? Wird das Projekt regelmäßig aktualisiert? Eine gut gepflegte Komponente mit einer aktiven Community ist immer ein Pluspunkt.

Oft nutzen Unternehmen für all das standardisierte Checklisten oder Tools, die automatisch Software-BOMs erzeugen und bekannte Lizenz- oder Sicherheitsrisiken melden. So bleibt der Prozess effizient, transparent und niemand muss später mühsam rekonstruieren, warum eine bestimmte Bibliothek ins Produkt aufgenommen wurde.

Erstellen und Liefern von Compliance-Nachweisen

Viele Open Source Lizenzen fordern konkrete Maßnahmen, sobald Software verteilt oder an Dritte weitergegeben wird. Das ist einer der häufigsten Punkte, an dem Unternehmen unabsichtlich in Schwierigkeiten geraten, einfach weil diese Anforderungen oft übersehen oder unterschätzt werden. Gerade, wenn noch keine Automatisierung für die Erstellung der Notice Files vorhanden ist, kann die manuelle Aufarbeitung dieser Files einen riesengroßen Mehraufwand darstellen. Es lohnt sich, daher so früh wie möglich in Automatisierung zu investieren.

Einige typische Verpflichtungen sind:

• Bereitstellen des Lizenztexts:
  Bei eher „lockeren“ Lizenzen wie MIT oder BSD reicht es oft schon, den vollständigen Lizenztext beizulegen. So ist klar dokumentiert, unter welchen Bedingungen die Komponente genutzt werden darf. Wichtig ist hierbei zu unterscheiden, ob es der Originallizenztext sein muss oder der allgemeine Lizenztext der jeweiligen Lizenz ausreichend ist.

• Hinweis auf Copyright-Holder:
  Fast alle Lizenzen verlangen, dass die ursprünglichen Urheber genannt werden. Damit wird transparent, wer die Software entwickelt hat, und die Leistung der Open-Source Community wird angemessen gewürdigt.

• Quellcode-Angebot bei Copyleft:
  Deutlich strenger sind Copyleft-Lizenzen wie die GPL. Hier reicht es nicht, nur Lizenztexte und Urheberhinweise mitzuliefern. Es muss zusätzlich der vollständige Quellcode bereitgestellt werden oder zumindest ein schriftliches Angebot enthalten sein, wie und wo der Quellcode angefordert werden kann.

Deshalb sollte die Open Source Policy genau festlegen:

• wer dafür verantwortlich ist, diese Anforderungen umzusetzen,
• wie und an welchen Stellen Lizenztexte und Urheberangaben in Produkte und Dokumentationen eingebunden werden,
• und wann gegebenenfalls ein Quellcode-Angebot gemacht werden muss.

So wird sichergestellt, dass Compliance kein Zufallsprodukt ist, sondern fester Bestandteil des Release-Prozesses bleibt.

Eine Open Source Policy beschreibt, wie solche Compliance-Artefakte erstellt und gepflegt werden. Häufig wird dafür der Begriff „Compliance Log Book“ verwendet, also eine strukturierte Sammlung aller relevanten Dokumente zu einem Software-Release.

Umgang mit Verstößen oder Auffälligkeiten

Was passiert, wenn eine Lizenzverletzung entdeckt wird? Etwa weil ein Kunde nachfragt, wo der GPL-Quellcode bleibt? Auf solche Anfragen sollte schnell und kompetent reagiert werden. Daher ist es sinnvoll sich bereits im Vorfeld dazu Gedanken zu machen und einen Prozess zu etablieren.

Hier hilft ein standardisiertes Vorgehen:

1. Eingang bestätigen, damit Stakeholder wissen, dass sich jemand kümmert.
2. Prüfen, ob tatsächlich ein Problem vorliegt.
3. Priorisieren, zum Beispiel nach Schwere des Verstoßes oder rechtlicher Dringlichkeit.
4. Maßnahmen umsetzen, z. B. Nachliefern von Quellcode, Anpassen von Lizenzhinweisen.
5. Alles dokumentieren, um im Streitfall belastbare Nachweise zu haben.

Zusammenarbeit mit Open Source Projekten

Viele Unternehmen möchten nicht nur konsumieren, sondern auch aktiv zu Open Source beitragen. Eine Policy sollte daher klarstellen:

• unter welchen Voraussetzungen Mitarbeit an Projekten möglich ist
• wer Beiträge freigeben muss
• und welche Dokumente eventuell zu unterzeichnen sind (z. B. Developer Certificate of Origin oder Contributor License Agreements)

Oft ist die Regelung hier weniger strikt als bei der Aufnahme von OSS in eigene Produkte, dennoch muss klar sein, wie mit geistigem Eigentum und Vertraulichkeit umgegangen wird. Wichtig ist hierbei, dass kein Intellectual Property der Firma versehentlich veröffentlicht wird.

Orientierung an internationalen Standards

Immer mehr Organisationen orientieren sich am OpenChain-Standard (ISO/IEC 5230). Dieser definiert Mindestanforderungen für OSS-Compliance-Programme, von der Schulung über die Lizenzprüfung bis zur transparenten Dokumentation.

Eine gute Open Source Policy erfüllt diese Anforderungen oft automatisch, wenn sie sauber strukturiert ist. Viele Unternehmen veröffentlichen dann auch eine Selbstverpflichtung („We are OpenChain conformant“), um Partnern und Kunden Vertrauen zu geben.

Fazit

Eine Open Source Policy ist weit mehr als ein juristisches Dokument. Sie ist ein praktisches Regelwerk, das Entwicklern, Produktmanagern, Rechtsabteilungen und dem Management hilft, Open Source Software sicher und strategisch zu nutzen.

Dabei gilt:

• Lieber pragmatisch starten und die Policy iterativ verbessern, als auf den „perfekten“ Wurf zu warten.
• Den Scope für die Policy zunächst klein zu halten und step by step weiter auszuweiten.
• Genaue Zuständigkeiten definieren und die Mitarbeiter darauf bestmöglich vorbereiten (z.B. Schulungen)
• Im Vorfeld transparent dokumentieren, als später mühsam Belege zusammensuchen zu müssen.

So wird aus Open Source nicht nur ein Kosten- und Innovationsvorteil mit klarem Rechtsrahmen und ohne böse Überraschungen.