Warum jetzt handeln?
Open-Source-Compliance ist längst kein reines Entwicklerthema mehr. Der Cyber Resilience Act, Pflichten zu SBOM und Lifecycle-Sicherheit, die neue EU-Produkthaftungsrichtlinie und die Anforderungen der eigenen Kunden treffen jedes Unternehmen, das Software entwickelt oder ausliefert.
Scanning-Tools decken nur den ersten Schritt ab: Sie zeigen, welche Komponenten und Lizenztexte im Produkt stecken. Die eigentliche Arbeit für Projektverantwortliche und Inhouse Counsel beginnt danach. Welche Pflichten löst eine Lizenz im konkreten Anwendungsfall aus? Welcher Auslegung folgen, wenn die Rechtslage umstritten ist? Und was tun im Fall von Lizenzkonflikten?
Beantworten lässt sich das nur juristisch. Unsere Anwältinnen und Anwälte, die täglich mit Open-Source-Lizenzen arbeiten, haben ihre Bewertungen deshalb nicht in Einzelgutachten abgelegt, sondern verdichtet, begründet und auswertbar gemacht. Um OSS-Compliance so effizient wie möglich zu gestalten, haben wir ein Tool entwickelt: Die FOSSmatrix.
Was ist die FOSSmatrix?
Die FOSSmatrix bringt Beides zusammen: die Systematik eines Tools und die Bewertung einer der im Bereich Open Source führenden Wirtschaftskanzleien, die seit über 15 Jahren OSS-Mandate betreut. Was heißt das genau?
Die FOSSmatrix ist eine Compliance-Plattform für den Einsatz von Open-Source-Software – entwickelt von den Anwältinnen und Anwälten von Osborne Clarke. Sie macht den eigenen Lizenzbestand sichtbar, ordnet jeder Lizenz die Pflichten dem konkreten Use Case zu, bewertet Risiken prozentgenau und hält jede Entscheidung im Audit Trail fest.
Grundlage ist unsere Knowledge Database: über 200 OSS-Lizenzen, juristisch bewertet gegen 68 rechtliche Attribute und hinterlegt mit umfangreichen Erläuterungen. Die Bewertungen wachsen laufend mit der Rechtsentwicklung – zuletzt etwa um Attribute zum Einsatz von Open Source in KI- und ML-Projekten.
Wie damit arbeiten? Einmal das System einrichten und dabei die Grundsatzentscheidungen treffen. Danach ist jede weitere Prüfung ein Klick.
Dann melden Sie sich jetzt für unsere Webinare an, in denen wir Ihnen tiefere Einblicke und eine praktische Vorführung bieten!
Dienstag, 29.09.2026 10:00–11:00 Uhr oder
Dienstag, 06.10.2026 10:00–11:00 Uhr
If so, sign up now for our webinars, where we’ll provide you with in-depth insights and a practical demonstration!
Wednesday, 30 September 2026, 10:00–11:00 am CEST or
Wednesday, 28 October 2026, 10:00–11:00 am CEST
Was habe ich davon?
Schritt 1: Use Cases festlegen
Vier fertige Musterprofile – von uns entwickelt für Standard-Use-Cases Distribution, ASP/SaaS, interne Nutzung und die Veröffentlichung eigener Open-Source-Software (Outbound Licensing) – bringen einen sofort an den Start. Jedes Profil lässt sich kopieren, anpassen und als eigene Vorlage speichern, bis es den eigenen Anwendungsfall exakt abbildet – auch als Unterprofil, das seine Einstellungen vom übergeordneten Profil erbt. Für jedes Attribut wird festgelegt, was gelten soll: Was ist erlaubt, wo will ich gewarnt werden und was ist ein Show-Stopper? Und wie streng gehe ich mit umstrittenen Auslegungsfragen um? Alles direkt in der Oberfläche.
Schritt 2: Die eigene Policy in der Lizenzbasis hinterlegen
Die Auslegung einer Lizenz wird anders als die herrschende Meinung gesehen? Eine Konzernvorgabe soll verbindlich umgesetzt werden? Einfach die Bewertung einmal zentral auf Ebene einer Lizenz, einer Komponente oder eines Projekts anpassen – mit Begründung, Bearbeiter und Timestamp. Diese Entscheidung gilt anschließend für jedes Projekt und jede Prüfung. Neue Projekte erben die Konfiguration, ohne dass jemand sie erneut einstellen muss. Aus einer Grundsatzentscheidung wird unternehmensweite Praxis.
Schritt 3: Komponenten importieren
Die SBOM oder Lizenzliste kommt per Web-Oberfläche, als CSV oder via API in die Plattform. Über die API hängt sich die FOSSmatrix direkt in die CI/CD-Pipeline ein und prüft dort automatisch mit. Ob ein Projekt dauerhaft angelegt oder eine Liste einmalig gegengecheckt wird – die importierten Lizenzen werden sofort zugeordnet.
Schritt 4: Das Ergebnis
Ein Klick, und für jede Lizenz werden Flag, Score und Begründung angezeigt. Für die schnelle Vorabprüfung – etwa, wenn der Software Stack noch nicht final ist – genügt ein Blick auf die Ampel.
Kritisch sind unklare Fälle, und genau dort liegt die Stärke der Plattform. Wo die Auslegung umstritten ist, weisen wir die Mindermeinung neben der herrschenden Meinung aus, und man entscheidet selbst, welcher gefolgt wird. Wo eine Lizenz schweigt, können Annahmen greifen, die in Phase 1 gesetzt wurden. Ob eine Pflicht ausgelöst wird, hängt vom Use Case ab: Was beim Vertrieb eines Geräts kritisch ist, kann im SaaS-Betrieb folgenlos bleiben – die Scores berücksichtigen das. Und wo ein Konflikt auftaucht, schlägt die Plattform konkrete Wege vor, ihn zu entschärfen. So werden anstelle binärer Bewertungen auch Graubereiche sichtbar – die sich dennoch automatisiert weiterverarbeiten lassen.
Schritt 5: Konflikte auflösen und dokumentieren
Red Flags sind kein Endzustand, sondern Aufgaben. Gelöst werden sie in der Sache: Die Komponente wird ausgetauscht, die Art der Einbindung geändert oder der Quellcode mitgeliefert – und diese Maßnahme wird als Resolution hinterlegt. Das Ergebnis ändert sich damit nicht per Knopfdruck, sondern weil dokumentiert ist, warum der Konflikt nicht mehr besteht. Resolutions lassen sich auf drei Ebenen hinterlegen: bei der Lizenz selbst, bei einer konkreten Komponente oder nur in einem einzelnen Projekt – jeweils mit Begründung, Bearbeiter und Timestamp.
Schritt 6: Der Audit Report
Am Ende steht ein Bericht, der nicht nur das Ergebnis zeigt, sondern den Weg dorthin: Wer wann was auf welcher Ebene entschieden hat – von der unternehmensweiten Vorgabe bis zur einzelnen Ausnahme in einem Projekt. Für interne Reviews, für Kundenaudits und für die Dokumentation, die der CRA verlangt: SBOM, Audit Trail und Decision Log an einer Stelle.
