Was ist eine Open-Source-Strategie?

Eine Open-Source-Strategie ist ein verbindliches Regelwerk, das festlegt, wie eine Organisation offene Software beschafft, prüft, betreibt, verändert und selbst veröffentlicht – und wer diese Entscheidungen trifft. Sie besteht aus vier Teilen: Regeln für eingehende Komponenten (Inbound), Regeln für eigene Veröffentlichungen (Outbound), einer Policy für Beiträge von Mitarbeitenden an fremde Projekte und einem laufenden Prozess für Abhängigkeiten, Schwachstellen und Nachweispflichten. Alles andere – Werkzeuge, Scanner, Lizenzlisten – ist Umsetzung dieser vier Teile.

Das grenzt sie deutlich von dem ab, was in den meisten Organisationen tatsächlich existiert: „Wir benutzen Open Source.“ Das ist keine Strategie, sondern eine Beobachtung. Praktisch jedes Softwareprojekt zieht heute transitive Abhängigkeiten aus offenen Quellen nach, und ihre Zahl kennt niemand aus dem Gedächtnis; belastbar bestimmen lässt sie sich nur aus dem aufgelösten Lock-Stand oder aus einer Stückliste des gebauten Artefakts. Die Frage ist nicht, ob offene Software eingesetzt wird, sondern ob jemand weiß, welche, unter welchen Lizenzbedingungen, in welcher Version, mit welchem Patch-Stand und mit welcher Ausfallwahrscheinlichkeit des jeweiligen Upstream-Projekts.

Dieser Artikel definiert den Begriff, beschreibt die einzelnen Bestandteile mit konkreten Entscheidungsregeln, zeigt messbare Kriterien für die Bewertung von Projektgesundheit und gibt eine schrittweise Einführungsreihenfolge für Organisationen, die heute noch nichts dokumentiert haben.

Die Definition und die Abgrenzung vom Nutzungszustand

Open-Source-Strategie

Dokumentierte, entscheidungsfähige Regeln einer Organisation zu Auswahl, Prüfung, Betrieb, Änderung und Veröffentlichung von Software unter offenen Lizenzen, inklusive der Zuordnung von Verantwortlichkeiten und der Nachweisführung gegenüber Kunden, Auditoren und Aufsichtsbehörden.

Drei Merkmale unterscheiden eine Strategie von einer Gewohnheit. Erstens ist sie schriftlich und versioniert – idealerweise im gleichen Git-Repository wie der Code, damit Änderungen reviewbar sind. Zweitens ist sie entscheidungsfähig: Sie liefert für konkrete Fälle ein Ja, ein Nein oder einen benannten Eskalationsweg, nicht Absichtserklärungen. Drittens ist sie durchsetzbar, also an mindestens einer Stelle im Build oder in der Auslieferung technisch verankert.

Der Unterschied wird an einem alltäglichen Fall sichtbar. Eine Entwicklerin braucht eine Bibliothek zur PDF-Erzeugung und findet eine, die unter AGPL-3.0 steht. Ohne Strategie entscheidet sie selbst, meist zugunsten der Funktion. Mit Strategie steht die Antwort schon fest: AGPL ist für ein SaaS-Produkt der prüfungspflichtige Fall, weil § 13 der Lizenz verlangt, allen Nutzern, die eine veränderte Version über ein Netzwerk erreichen, den entsprechenden Quellcode dieser Version anzubieten – bei einem internen Werkzeug ohne solche Nutzer stellt sich die Frage nicht. Die Strategie sagt nicht „AGPL ist böse“, sondern: In diesem Auslieferungskontext nein, in jenem ja, Ausnahmen entscheidet Rolle X.

Inbound: Was hereinkommen darf, unter welcher Lizenz, geprüft von wem

Inbound-Regeln beantworten drei Fragen: Welche Lizenzen sind zulässig, in welchem Verwendungskontext, und wer prüft.

Der praktikable Ansatz ist eine dreistufige Liste nach SPDX-Identifiern, gestaffelt nach Auslieferungsform. Entscheidend ist nicht die Lizenz allein, sondern ihre Kombination mit der Distributionsart: Copyleft-Pflichten greifen typischerweise erst bei Weitergabe, nicht bei reiner interner Nutzung.

Lizenzklasse	Beispiele (SPDX)	Interne Nutzung	SaaS-Betrieb	Ausgelieferte Software
Permissiv	MIT, BSD-3-Clause, Apache-2.0, ISC	erlaubt	erlaubt	erlaubt, Hinweistexte mitliefern
Schwaches Copyleft	LGPL-2.1-or-later, MPL-2.0, EPL-2.0	erlaubt	erlaubt	erlaubt bei dynamischem Linken, Datei-/Modulgrenzen dokumentieren
Starkes Copyleft	GPL-2.0-only, GPL-3.0-or-later	erlaubt	erlaubt, sofern kein AGPL-Anteil	nur nach Freigabe, vollständige Quellcode-Bereitstellung
Netzwerk-Copyleft	AGPL-3.0-only, AGPL-3.0-or-later	erlaubt	nur nach Freigabe, Quellcodepflicht gegenüber Nutzern	nur nach Freigabe
Quellverfügbar, nicht Open Source	BUSL-1.1, SSPL-1.0, Elastic-2.0	Einzelfallprüfung	in der Regel gesperrt	in der Regel gesperrt
Unklar oder fehlend	keine LICENSE-Datei, widersprüchliche Header	gesperrt	gesperrt	gesperrt

Die letzte Zeile ist in der Praxis die wichtigste. Eine Komponente ohne klare Lizenzangabe ist rechtlich unbrauchbar, unabhängig davon, wie gut sie funktioniert – ohne Rechteeinräumung gilt das Urheberrecht in seiner Grundform. Solche Fälle gehören blockiert, nicht diskutiert.

Die Prüfung muss automatisiert stattfinden, sonst findet sie nicht statt. Ein Gate in der CI-Pipeline, das die Abhängigkeitsliste gegen die Lizenzklassen abgleicht, ist mit wenigen Zeilen realisierbar. Für ein Node-Projekt etwa mit einer Allowlist:

# Lizenzen aller produktiven Abhängigkeiten gegen Allowlist prüfen
npx license-checker-rseidelsohn \
  --production \
  --onlyAllow "MIT;ISC;BSD-2-Clause;BSD-3-Clause;Apache-2.0;0BSD;CC0-1.0" \
  --excludePrivatePackages \
  --summary

Für polyglotte Repositories ist ein sprachunabhängiger Weg über die SBOM sinnvoller: SBOM erzeugen, dann per Regelwerk auswerten. Das entkoppelt die Prüfung vom Paketmanager und liefert gleichzeitig das Artefakt, das man später ohnehin braucht.

# .github/workflows/inbound-gate.yml (Auszug)
name: inbound-gate
on: [pull_request]
jobs:
  licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SBOM erzeugen (CycloneDX)
        run: syft dir:. -o cyclonedx-json > sbom.cdx.json
      - name: Lizenzklassen prüfen
        run: python3 tools/license_gate.py sbom.cdx.json policy/licenses.yaml
      - name: Bekannte Schwachstellen prüfen
        run: grype sbom:sbom.cdx.json --fail-on high

Zur Prüfzuständigkeit: Der technische Check gehört in die Pipeline, die Ausnahmeentscheidung zu einer benannten Rolle. Was nicht funktioniert, ist eine Rechtsabteilung als Durchlaufstation für jede neue Bibliothek. Der Durchsatz reicht nicht, und das Ergebnis ist, dass Entwickler die Regel umgehen. Praktikabel ist das Gegenteil: Die Allowlist deckt den weit überwiegenden Teil der Fälle ohne Rückfrage ab, und nur die verbleibenden Fälle gehen in eine dokumentierte Einzelfallprüfung.

Outbound: Was veröffentlicht wird, unter welcher Lizenz, entschieden von wem

Outbound-Regeln sind der Teil, den Organisationen am häufigsten auslassen – und der am meisten Reibung erzeugt, wenn er fehlt. Ohne sie wird jede Veröffentlichung zu einer Einzelverhandlung mit unklarem Ausgang, und Teams verzichten aus Unsicherheit.

Eine Outbound-Policy braucht vier Festlegungen. Erstens eine Standardlizenz für eigene Veröffentlichungen, damit nicht jedes Mal diskutiert wird; Apache-2.0 ist für Organisationen häufig die pragmatische Wahl, weil sie eine ausdrückliche Patentlizenz enthält (§ 3) und eine Defensivklausel bei Patentklagen. Zweitens eine Klassifikation, was überhaupt veröffentlichungsfähig ist. Drittens einen technischen Freigabe-Check. Viertens eine benannte Entscheidungsrolle für Grenzfälle.

Die Klassifikation lässt sich meist auf drei Kategorien reduzieren:

Der technische Freigabe-Check ist nicht optional, weil das Risiko selten in der Logik liegt, sondern in Rückständen: versehentlich eingecheckte Zugangsdaten, interne Hostnamen, Kundennamen in Testfixtures, produktive Endpunkte in Beispielkonfigurationen. Und zwar in der gesamten Historie, nicht nur im aktuellen Stand – ein git filter-repo nach der Veröffentlichung ist Schadensbegrenzung, kein Prozess.

# Vollständige Historie auf Secrets prüfen, bevor das Repository öffentlich wird
gitleaks detect --source . --log-opts="--all" --redact --verbose

# Interne Bezüge in allen Commits suchen
git log --all -p | grep -nEi 'intern\.example\.com|10\.(0|1)\.[0-9]+\.[0-9]+|BEGIN (RSA|OPENSSH|EC) PRIVATE KEY'

# Autorenliste prüfen: private Adressen, unerwartete Beitragende
git log --all --format='%aN <%aE>' | sort -u

Zur Lizenz gehören zwei Dateien, die oft fehlen: eine vollständige LICENSE im Repository-Wurzelverzeichnis und ein NOTICE, wenn Apache-2.0 verwendet wird und Dritt-Anteile enthalten sind. Zusätzlich eine SECURITY.md mit Meldeweg und Reaktionszeit – wer veröffentlicht, wird irgendwann Meldungen erhalten, und eine unbeantwortete Schwachstellenmeldung ist ein Reputationsschaden, der leicht vermeidbar wäre. Wie wir Veröffentlichungen und Upstream-Arbeit technisch begleiten, beschreibt unsere Leistung Open-Source-Entwicklung im Detail.

Contribution-Policy: Beiträge von Mitarbeitenden an fremde Projekte

Der häufigste Fehler ist hier das Schweigen. Wenn eine Organisation nicht sagt, ob Beiträge zu Upstream-Projekten erlaubt sind, entstehen zwei Probleme gleichzeitig: Mitarbeitende tragen aus Unsicherheit nicht bei und pflegen stattdessen interne Forks – die technische Schuld, die jeden Upgrade teuer macht –, oder sie tragen bei und die Rechtslage bleibt ungeklärt.

Eine belastbare Contribution-Policy klärt fünf Punkte:

• Erlaubnisrahmen: Beiträge zu Projekten, die die Organisation einsetzt, sind während der Arbeitszeit ausdrücklich erlaubt und erwünscht, sofern sie im Zusammenhang mit der eigenen Arbeit stehen.
• Rechteeinräumung: Wer im Auftrag beiträgt, benötigt die Befugnis, die Lizenz des Zielprojekts einzuräumen. Bei Software, die in Wahrnehmung der Aufgaben oder nach Anweisung des Arbeitgebers entsteht, ist in Deutschland nach § 69b UrhG der Arbeitgeber ausschließlich zur Ausübung der vermögensrechtlichen Befugnisse berechtigt, sofern nichts anderes vereinbart ist – die Freigabe muss deshalb organisationsseitig erfolgen, nicht privat.
• CLA- und DCO-Umgang: Ein Developer Certificate of Origin (Signed-off-by) ist eine Bestätigung der Herkunft und in der Regel unkritisch. Ein Contributor License Agreement, das Rechte an einen Dritten überträgt oder ein Rücklizenzierungsrecht einräumt, ist eine Vertragsentscheidung und gehört nicht in die Hand einzelner Entwickler.
• Identität: Firmen-Adresse oder private Adresse im Commit, mit oder ohne Arbeitgeberbezug – festlegen und begründen. Für die Nachvollziehbarkeit in Sicherheitsvorfällen ist Konsistenz mehr wert als jede einzelne Variante.
• Fork-Regel: Interne Patches sind ein temporärer Zustand mit Upstream-Ziel und einem Verantwortlichen, nicht ein Dauerzustand. Wer forkt, dokumentiert die Absicht, den Patch einzureichen, oder begründet, warum nicht.

Abhängigkeiten, Schwachstellen und SBOM-Pflichten

Dieser Teil der Strategie ist der einzige, der dauerhaft Arbeit erzeugt – und der einzige, dessen Fehlen unmittelbar ausfällt. Eine Lizenzfrage kann Monate warten; eine Schwachstelle in einer Bibliothek, die im Auslieferungspfad liegt, kann es nicht.

Abhängigkeitspflege als Kadenz, nicht als Reaktion

Der entscheidende Unterschied zwischen funktionierenden und nicht funktionierenden Organisationen ist die Frequenz. Wer wöchentlich kleine Versionssprünge macht, hat pro Update wenige Zeilen Änderung. Wer jährlich aktualisiert, steht vor Major-Sprüngen mit Breaking Changes in mehreren Bibliotheken gleichzeitig und verschiebt das Update erneut. Automatisierte Pull Requests – Dependabot, Renovate – lösen das nur, wenn eine Regel definiert, wer sie mergt und in welchem Zeitfenster; sonst entsteht nur ein neuer Rückstand in der PR-Liste.

Sinnvoll sind Reaktionsfenster nach Ausnutzbarkeit im eigenen Kontext, nicht nach CVSS allein:

Einordnung	Kriterium	Reaktionsfenster
Akut	Öffentlich ausgenutzt, Komponente im Auslieferungspfad erreichbar	Patch oder Mitigation innerhalb von 24 Stunden
Hoch	CVSS ab 7.0, Codepfad nachweislich erreichbar	Patch innerhalb von 7 Tagen
Mittel	CVSS 4.0 bis 6.9 oder Pfad nicht erreichbar	nächster regulärer Release-Zyklus
Niedrig	Nur Build- oder Testabhängigkeit, kein Produktivpfad	Sammelupdate, dokumentiert

Die Spalte „Codepfad erreichbar“ verhindert das häufigste Scheitern: Ein Scanner, der 300 Findings ohne Erreichbarkeitsanalyse meldet, wird nach zwei Wochen ignoriert. Reachability-Analyse und eine dokumentierte Ausnahmeliste sind kein Luxus, sondern die Bedingung dafür, dass der Prozess überlebt. Für die Absicherung der gesamten Kette – von der Quelle über den Build bis zum Deployment – haben wir das Vorgehen in Software-Supply-Chain absichern ausführlicher beschrieben.

SBOM: Format, Erzeugungszeitpunkt, Aufbewahrung

Eine Software Bill of Materials ist die maschinenlesbare Stückliste aller Komponenten eines Artefakts. Zwei Formate sind etabliert: SPDX (ISO/IEC 5962:2021) und CycloneDX (OWASP, seit 2024 auch als ECMA-424 standardisiert). Beide sind für Lizenz- und Schwachstellenauswertung tauglich; CycloneDX hat den stärkeren Fokus auf Security-Anwendungsfälle, SPDX den stärkeren auf Lizenz-Compliance.

Drei Regeln entscheiden über die Nützlichkeit:

# SBOM für das gebaute Image erzeugen und dem Digest zuordnen
IMAGE="registry.example.org/app@sha256:${DIGEST}"
syft "$IMAGE" -o spdx-json > app.spdx.json
syft "$IMAGE" -o cyclonedx-json > app.cdx.json

# SBOM als signierte Attestierung an das Image binden
cosign attest --predicate app.cdx.json \
  --type cyclonedx \
  --key env://COSIGN_PRIVATE_KEY \
  "$IMAGE"

Die Rolle eines OSPO – auch ohne eigenes Team

Ein Open Source Program Office ist die organisatorische Stelle, an der die vier Teile der Strategie zusammenlaufen. Der Begriff klingt nach Konzernstruktur, beschreibt aber eine Funktion, nicht eine Abteilungsgröße. In kleinen Organisationen ist ein OSPO eine benannte Person mit einem definierten Zeitbudget – ein Tag pro Woche ist ein realistischer Startwert – und einem klaren Mandat.

Vier Aufgaben genügen für den Anfang:

• Regeln pflegen: Lizenzlisten, Outbound-Klassifikation und Ausnahmeliste aktuell halten und Änderungen als Pull Request reviewen lassen.
• Grenzfälle entscheiden: Der eine Anlaufpunkt, wenn die Allowlist nicht greift. Wichtiger als die Qualität jeder Einzelentscheidung ist, dass sie überhaupt getroffen und dokumentiert wird.
• Nachweise bereithalten: SBOMs, Lizenzberichte, Hinweistexte auf Anfrage lieferbar halten. In Ausschreibungen und Kundenaudits ist das der Punkt, an dem sich die Investition unmittelbar auszahlt.
• Upstream-Beziehungen halten: Wissen, an welchen Projekten die eigene Auslieferung hängt, und dort sichtbar sein – durch Issues, Patches, gelegentlich Finanzierung.

Was ein OSPO nicht sein sollte, ist eine Freigabeinstanz für jede Bibliothek. Sobald die Rolle zum Nadelöhr wird, entstehen Umgehungswege, und die Strategie verliert ihre Wirkung genau dort, wo sie zählt. Das Ziel ist, dass 95 Prozent der Entscheidungen ohne Rückfrage aus dem Regelwerk folgen.

Kriterien zur Bewertung von Projektgesundheit

Die Lizenz sagt, was man mit einer Komponente rechtlich darf. Sie sagt nichts darüber, ob das Projekt in drei Jahren noch Sicherheitsupdates liefert. Für diese Frage braucht die Strategie eigene, überprüfbare Kriterien – anzuwenden vor jeder Aufnahme einer neuen Abhängigkeit und regelmäßig für die tragenden Komponenten im Bestand.

Kriterium	Was gemessen wird	Warnschwelle
Bus-Faktor	Zahl der Personen, die zusammen die Mehrheit der Commits der letzten 12 Monate verantworten	1 – ein einzelner Maintainer trägt das Projekt
Release-Kadenz	Abstand der letzten drei Releases	über 18 Monate ohne Release bei aktiver Nutzung
Reaktionszeit	Median bis zur ersten Antwort auf Issues und Pull Requests	über 90 Tage, viele Issues ohne jede Reaktion
Security-Policy	Vorhandensein von SECURITY.md, dokumentierter Meldeweg, CVE-Historie	keine Angabe, wie Schwachstellen gemeldet werden
Governance-Modell	Dokumentierte Entscheidungsregeln, Stiftung oder Einzelfirma, Lizenzänderungsrisiko	Einzelfirma mit CLA und Rechteübertragung
Testabdeckung und CI	Sichtbare CI-Läufe, Tests bei Pull Requests, reproduzierbare Builds	keine CI, Merges ohne Prüfung
Abhängigkeitstiefe	Zahl transitiver Abhängigkeiten, die das Paket selbst mitbringt	ein triviales Paket mit dutzenden Abhängigkeiten

Ein Teil davon ist automatisierbar. OpenSSF Scorecard prüft eine Reihe dieser Praktiken – Branch Protection, signierte Releases, Abhängigkeitsaktualisierung, Fuzzing, Umgang mit gefährlichen Workflow-Mustern – und liefert eine Bewertung von 0 bis 10 pro Kriterium:

# Repository-Praktiken automatisiert bewerten
scorecard --repo=github.com/example/library --format=json > scorecard.json

# Bus-Faktor grob abschätzen: Commit-Verteilung der letzten 12 Monate
git log --since='12 months ago' --format='%aE' | sort | uniq -c | sort -rn | head -10

Der Zusammenhang zur Lieferantenbindung ist direkt: Ein Projekt mit breiter Trägerschaft, offener Governance und permissiver Lizenz erzeugt strukturell weniger Abhängigkeit als ein quellverfügbares Produkt eines einzelnen Anbieters. Die Argumente dazu haben wir in Vendor-Lock-in vermeiden ausgeführt, ebenso die grundsätzliche Abwägung in Open Source vs. proprietäre Software.

Einführungsreihenfolge für eine Organisation ohne Strategie

Der verbreitetste Fehler beim Start ist, mit dem Dokument zu beginnen. Ein 30-seitiges Policy-Papier, das niemand liest und das an keiner Stelle im Build verankert ist, ändert nichts. Die tragfähige Reihenfolge beginnt mit Sichtbarkeit und endet mit Formalisierung.

Die Schritte 1 bis 4 sind in wenigen Wochen erreichbar und decken den größten Teil des Risikos ab. Schritte 5 bis 10 sind Aufbauarbeit über Monate. Wer versucht, alles gleichzeitig einzuführen, bekommt meist nichts davon in Betrieb. Wenn Sie diese Reihenfolge auf eine bestehende Architektur und Auslieferungskette abbilden möchten, ist das genau der Gegenstand unserer Open-Source-Beratung – und die technische Verankerung in der Pipeline gehört zu DevOps und Cloud.

Fazit

Eine Open-Source-Strategie ist kein Compliance-Dokument, sondern ein Satz von Entscheidungen, die einmal getroffen und dann automatisiert durchgesetzt werden. Ihr Wert zeigt sich nicht im Normalbetrieb, sondern an drei Punkten: wenn ein Kundenaudit die Komponentenliste verlangt, wenn eine kritische Schwachstelle in einer transitiven Abhängigkeit gemeldet wird, und wenn ein Upstream-Projekt seine Lizenz ändert oder die Wartung einstellt. Wer diese drei Fälle vorbereitet hat, beantwortet sie in Stunden statt in Wochen. Der Einstieg ist dabei kleiner, als der Begriff „Strategie“ vermuten lässt: eine SBOM, eine einseitige Lizenzliste, ein Pipeline-Gate und eine benannte Person. Alles Weitere folgt aus dem, was diese vier Schritte sichtbar machen.