5,0/5 Google · 167 BewertungenBewertungen über uns auf anderen Plattformen, die wir nicht wörtlich zitieren, prüfen wir nicht auf ihre Echtheit. Sie können daher auch von Personen stammen, die nicht unsere Mandanten sind. Es gelten die Regeln der jeweiligen Plattform. Bewertungen, die wir auf unserer Website wörtlich zitieren, haben wir dagegen auf ihre Echtheit im Sinne des § 5b Abs. 3 UWG geprüft: Wir haben die Namen der Bewertenden mit unserem Mandantenverzeichnis abgeglichen. Außerdem haben wir die jeweilige Plattform gebeten, die Bewertungen auf ihre Echtheit zu prüfen.Zeitraum: Oktober 2016 bis heute · Stand: 12.11.2026
Open-Source-Compliance-Audit für Software
OSS-Nachweise liefern, bevor der Deal kippt
Wenn SBOM, Notices, Copyleft-Fragen, Source-Offer oder Lieferantenzusagen plötzlich zählen, reicht ein Scanner-Report nicht. Wir liefern die rechtliche Einordnung mit klarem Freigabe- und Maßnahmenbild.
Bitte geben Sie zuerst eine kurze Beschreibung ein.
Der Erstkontakt ist kostenfrei. Wir machen Sie ausdrücklich darauf aufmerksam, bevor Kosten anfallen.
Rückmeldung an Werktagen innerhalb von 24 Stunden
Stand: 23.10.2026
Freigabestatus1 von 5
- SBOM mit Build-BezugLiegt vor
- AGPL-Komponente im BackendPrüfen
- Third-Party-NoticesFehlt
- Kundenzusicherung VertragPrüfen
- Lieferanten-ArtefakteFehlt
Prüfstelle: Zusicherung im Vertrag passt nicht zur SBOM
- 1Lagebild sichernScans, SBOM, Verträge
- 2Risiken priorisierenPflichten im Modell
- 3Freigabe vorbereitenMaßnahmenbild
Schematische Darstellung eines OSS-Audits. Beispiel vereinfacht.
Wir prüfen Open Source für
- SaaS-Anbieter
- OEM-Zulieferer
- Scale-ups
- Investoren
- Ein Scanner-Report ersetzt keine Freigabeentscheidung.
- ITMR prüft, wo Ihr Produkt, SaaS-Angebot, SDK, API oder Embedded-Setup angreifbar ist und welche Pflichten sofort erfüllt werden müssen.
- Sie erfahren, welche Unterlagen Sie Kunden, Investoren, Käufern oder OEMs guten Gewissens vorlegen können.
- Ergebnis ist eine Entscheidungsvorlage, die intern verwendbar und extern belastbar ist.
- Ansprechpartner ist Dr. Alexander Pleh und sein Team. Er ist Fachanwalt für IT-Recht und Familienrecht. Rückmeldung an Werktagen innerhalb von 24 Stunden.
- SaaS
- Software as a Service. Software, die über das Internet genutzt und nicht installiert wird.
- Open Source
- Software mit offenem Quellcode. Die Nutzung richtet sich nach der jeweiligen Lizenz.
Mandatsanlass
Wann wird Open Source freigaberelevant?
Die Eskalation beginnt nach unserer Erfahrung selten im Repository.
Aus einem Entwicklerdetail wird eine Managementfrage.
Sie beginnt, wenn ein Produkt live gehen soll, ein Enterprise-Kunde belastbare Unterlagen verlangt, ein Investor den Datenraum öffnet oder ein OEM wissen will, wie Ihr OSS-Stack gesteuert wird.
Diese Spezialseite ist für Situationen gebaut, in denen kurzfristig entschieden werden muss, ob ein Softwareprodukt, ein SaaS-Setup oder eine eingebettete Software mit vertretbarem Risiko freigegeben, offengelegt oder nachgeschärft werden kann. Allgemeine OSS-Grundlagen behandelt sie bewusst nicht.
Grundsatzfragen zu Verträgen, digitalen Leistungen und IT-Projekten beantwortet unsere Hauptseite IT-Recht. Ein konkretes Open-Source-Problem lässt sich hier zunächst kurz einordnen, bevor ein vollständiges Audit beauftragt wird.
Bei Produkten mit digitalen Elementen wächst der Druck zusätzlich, weil Sicherheits-, Aktualisierungs- und Lieferkettenthemen enger mit der OSS-Nachweisfähigkeit zusammenlaufen. Wer Open Source allein als Lizenzfrage behandelt, setzt an der falschen Stelle zu klein an.
- Anlass
- Release, Enterprise-Deal, Due Diligence, OEM
- Prüfgegenstand
- Lizenzen, SBOM, Notices, Verträge
- Ergebnis
- Risikomatrix und Maßnahmenplan
- Rechtsgrundlage
- §§ 31, 69c UrhG, Lizenzbedingungen
Schildern Sie Ihr OSS-Problem über das Formular. Wir melden uns an Werktagen innerhalb von 24 Stunden.
So läuft es ab
Wie läuft das Open-Source-Audit ab?
Drei Schritte vom Lagebild zur Freigabe.
01
Lagebild sichern Wir ziehen vorhandene Scans, SBOM, Notices, Verträge, Lieferantenzusagen und den konkreten Vertriebs- oder Transaktionskontext zusammen.
02
Risiken priorisieren Nicht alles ist gleich kritisch. Maßgeblich ist, welche Lizenzpflichten, Copyleft-Fragen, Offenlegungsthemen oder Vertragslücken im konkreten Modell durchschlagen.
03
Freigabe vorbereiten Sie erhalten eine Entscheidungsgrundlage mit Maßnahmenbild, Offenlegungsplan und klaren nächsten Schritten für Management, Legal, Produkt und Vertrieb.
Was das Audit konkret prüft
- 1
Produkt und Version Welche OSS-Komponenten sind im relevanten Build, Produkt oder SaaS-Stack enthalten, gibt es lokale Anpassungen und ist der Release-Pfad nachvollziehbar dokumentiert?
- 2
Lizenz- und Pflichtenmatrix
Bekannte Kürzel allein helfen nicht. Wir bewerten, welche Pflichten im Nutzungs- und Vertriebsmodell ausgelöst werden, wo Copyleft kritisch wird und wo sich Risiken relativieren.
- 3
Verträge und Lieferkette Viele OSS-Probleme entstehen an unpräzisen Kundenzusicherungen, schwachen Lieferantenpflichten, fehlenden Audit-Rechten oder unklarer Verantwortung entlang der Kette.
- 4
Freigabe und Offenlegung Welche Artefakte müssen sofort stehen, was sollte offengelegt werden, was ist vor Signing oder Release zu heilen und was kann bewusst mit Restrisiko entschieden werden?
Wie lange dauert es? Die meisten Arbeitsschritte erledigen wir innerhalb weniger Werktage. Wie schnell es geht, hängt vom Umfang und von Ihren Rückmeldungen ab. Haben Sie einen festen Termin, etwa einen Launch? Nennen Sie ihn uns gleich bei der Anfrage, dann planen wir ihn ein.
Arbeitsprodukt
Was haben Sie am Ende in der Hand?
Leistungspaket OSS-Compliance-Audit
Priorisierte Risikomatrix Sie sehen, welche Punkte freigabekritisch sind, welche nur dokumentiert werden müssen und wo späterer Handlungsbedarf reicht.
Konkreter Maßnahmenplan Notices, Lizenztexte, Source-Offer, SBOM, Vertragsklauseln, Lieferantenanforderungen und interne Freigaben in nachvollziehbarer Reihenfolge. Vorab hilft der Open-Source-/SBOM-Check.
Offenlegung und Gesprächsgrundlage Für Kunden, Investoren, Käufer oder OEMs wird klar, was offengelegt, was erläutert und was nicht vorschnell zugesichert werden sollte.
Brücke zu Vertrag, DD oder Konflikt
Geht die Lage über ein Audit hinaus, überführen wir sie in Vertragsumbau, Transaktionsbegleitung, Lieferkettensteuerung oder streitige Reaktion.
- Für wen
- Softwareunternehmen mit Prüfungsdruck
- Erste Rückmeldung
- an Werktagen innerhalb von 24 Stunden
- Kosten
- Wir nennen Ihnen die Kosten vor Mandatserteilung transparent.
- Nicht im Paket
- Technische Scans. Diese liefern Ihr Team oder Ihre Dienstleister.
- Scan-Reports und SBOM
- Third-Party-Notices
- Kundenfragebögen und Verträge
- Beschreibung von Produkt oder SaaS-Modell
- Lizenz- und Pflichtenbewertung
- Vertragsprüfung
- Risikomatrix und Maßnahmenplan
- Offenlegungsstrategie
- Ihr Management über die Freigabe
- Bei Streit das Gericht
- 1
Erste Einschätzung Sie schildern Ihr Problem über das Formular. Wir ordnen ein, ob ein Audit nötig ist.
- 2
Angebot Vor Beginn des Audits nennen wir Ihnen Umfang und Kosten transparent.
- 3
Gerichtliche Schritte gesondert Gerichtsverfahren und die Vertretung in Konflikten vereinbaren wir gesondert.
Mandantenmomente
In welchen Momenten entsteht Prüfungsdruck?
Vier Anlässe, aus denen Audits nach unserer Erfahrung entstehen.
Es gibt Scannergebnisse oder einzelne Listen, aber keine sichere Aussage, welche Builds betroffen sind, welche Pflichten ausgelöst werden und ob Notices, Lizenztexte oder Source-Offer zum Release passen.
Fragebögen, Vertragszusicherungen, Audit-Rechte oder Sicherheitsanforderungen legen offen, dass OSS genutzt wird, die Dokumentation aber nicht auf Kundenniveau vorbereitet ist.
Käufer, Investoren oder Berater wollen erkennen, welche Prozesse existieren, welche Risiken bekannt sind und wie Nachbesserung im Zweifel funktioniert.
In arbeitsteiligen Produktketten reichen pauschale Zusicherungen nicht. Gefragt sind releasegenaue Nachweise, klare Verantwortlichkeiten und Verträge, die Regress und Nachbesserung regeln.
Reibungsverluste
Wo verlieren Unternehmen Zeit und Spielraum?
Typische Fehlerbilder, die Verhandlungsspielraum und Glaubwürdigkeit kosten.
Viele Teams haben technische Reports, aber keine belastbare Aussage, was davon rechtlich und vertraglich im aktuellen Produktkontext zählt.
Eine Liste hilft nur, wenn sie dem konkreten Produktstand zugeordnet werden kann. Alles andere schafft im Audit eher neue Fragen als Sicherheit.
SaaS vorschnell als unkritisch
Auch wenn klassische Distributionsregeln bei SaaS nicht eins zu eins greifen, bleiben AGPL-nahe Konstellationen, Zusicherungen, Dokumentation und Lieferkettenpflichten hochrelevant.
Pauschale Compliance-Statements von Lieferanten helfen in Einkauf, DD oder Regress wenig, wenn Notices, SBOM, Auditspuren oder klare Nachbesserungspflichten fehlen.
Konstellationen
Für welche Unternehmen passt das Audit?
Geeignet für Softwareunternehmen mit echtem Prüfungsdruck.
Sinnvoll, wenn Vertrieb, Kundenzusicherungen und Release-Takt eng zusammenliegen und ein späterer Rückzug wirtschaftlich teuer wäre.
Hier zählt neben der internen Ordnung die Nachweis- und Vertragsfähigkeit gegenüber Dritten in einer haftungssensiblen Kette.
Je näher Software an der Bewertung hängt, desto schneller werden fehlende Freigabeprozesse und schwache Dokumentation zum Deal-Thema.
Wenn der Vertrieb schneller skaliert als die Governance, hilft eine frühe juristische Sortierung, Zusagen nicht aus dem Bauch heraus zu machen.
Abgrenzung
Wo endet diese Seite und wo geht es weiter?
Breite Grundsatzfragen zu IT-Projekten und Vertragsarchitektur gehören auf IT-Recht. Lizenzfamilien, Copyleft-Dogmatik, Rechtekette, Abmahnung oder strategische OSS-Nutzung vertieft das Open-Source-Recht. Diese Seite bleibt bei auditierbaren Freigabe- und Nachweisfragen.
IT-Vertrag und Softwarevertrag
Wenn Zusicherungen, Audit-Rechte, Freistellungen, Unterauftragnehmer oder Exit-Regeln vertraglich nachgezogen werden müssen.
Wenn OSS-Nachweise mit Sicherheits-, Aktualisierungs-, Vorfall- oder regulatorischem Druck zusammenfallen.
Wenn sichtbar werden soll, wie schnell OSS-Compliance in Gewährleistung, Regress und operative Eskalation kippen kann.
Rechtsrahmen
Welche Rechtsgrundlagen gelten bei Open Source?
Software ist nach § 69a UrhG geschützt. Wer sie vervielfältigt, bearbeitet oder verbreitet, braucht nach § 69c UrhG ein Nutzungsrecht. Open-Source-Lizenzen räumen dieses Recht nur unter Bedingungen ein.
Werden Lizenzbedingungen wie Notices, Lizenztexte oder die Offenlegung des Quellcodes verletzt, kann das Nutzungsrecht entfallen. Dann drohen Unterlassungs- und Schadensersatzansprüche nach § 97 UrhG.
Copyleft-Lizenzen wie die GPL verlangen bei Weitergabe die Offenlegung abgeleiteter Werke. Die AGPL erstreckt diese Pflicht auf die Bereitstellung über ein Netzwerk und betrifft damit auch SaaS-Modelle.
- § 69c UrhG Zustimmungsbedürftige Handlungen bei Software.
- § 97 UrhG Unterlassung und Schadensersatz.
- § 69a UrhG Urheberrechtlicher Schutz von Computerprogrammen.
Grenzen
Was leistet das Audit nicht?
Wir bewerten rechtlich und vertraglich. Einige Punkte bleiben bei Ihnen.
- 1
Keine technischen Scans Die Tatsachengrundlage liefern Ihr Team oder Scanner-Dienstleister.
- 2
Kein Freibrief Nicht jede Auffälligkeit stoppt Release oder Deal. Kritisch wird es, wo Pflichten ausgelöst werden oder Zusicherungen nicht mehr haltbar sind.
- 3
Restrisiko bleibt Entscheidung Welche Punkte bewusst mit Restrisiko freigegeben werden, entscheidet Ihr Management.
Was Sie bereithalten sollten
- Scan-Reports, SBOM und Notices.
- Release- oder Build-Bezug.
- Kundenfragebögen und Vertragszusicherungen.
- Lieferantenverträge.
Rechtsanwalt · Partner · Fachanwalt für IT-Recht · Fachanwalt für Familienrecht
Profil von Dr. Alexander Pleh Düsseldorf, Schirmerstraße 80 · Hamburg, Palmaille 124
5,0 von 5 · 71 Bewertungen auf anwalt.deZeitraum: Oktober 2018 bis heute · Stand: 12.11.2026
„Herr Pleh hat uns hervorragend beraten war sehr aufmerksam und hat sich viel Zeit für uns genommen. So stellt man sich anwaltliche Betreuung vor.“
„Sehr hilfsbereit und schnell“
„Kompetent und freundlich in der Beratung. Kontaktaufnahme verlief sehr unkompliziert und der Kerl weiß, was er tut. Bei rechtlichen Problemen immer wieder einen Anruf wert.“
FAQ
Welche Fragen stellen Unternehmen zum OSS-Audit?
Wann ist ein Open-Source-Compliance-Audit sinnvoll?
Wenn Release, Enterprise-Vertrag, OEM-Freigabe, Audit oder Due Diligence kurzfristig belastbare Aussagen zu OSS-Komponenten, Lizenzpflichten, SBOM, Notices oder Source-Offer verlangen. Je später diese Fragen auftauchen, desto teurer wird die Reaktion.
Reicht ein Scanner oder eine SBOM allein aus?
Nein. Scanner und SBOM sind wichtige Tatsachengrundlagen. Sie beantworten aber nicht, welche Pflichten im konkreten Vertriebsmodell ausgelöst werden, welche Vertragsaussagen riskant sind und welche Nachweise im Außenverhältnis belastbar sind.
Ist SaaS bei Open Source automatisch unkritisch?
Nein. Auch ohne klassische Distribution bleiben vertragliche Zusicherungen, Lieferkettenpflichten, Dokumentation und je nach Lizenztyp zusätzliche Risiken relevant. AGPL-nahe Konstellationen sollten Sie nicht aus Gewohnheit freigeben.
Was sollten wir zum Erstgespräch bereithalten?
Hilfreich sind Scan-Reports, SBOMs, Third-Party-Notices, Release- oder Build-Bezug, Kundenfragebögen, Vertragszusicherungen, Lieferantenverträge und eine kurze Beschreibung des Produkts. Vollständigkeit ist nicht nötig. Die Lage soll schnell greifbar werden.
Lässt sich eine schwache Dokumentation vor einer Due Diligence noch aufräumen?
Nach unserer Erfahrung in vielen Fällen ja, aber nicht beliebig. Maßgeblich ist, ob technische Zuordnung, Dokumentation und Verantwortlichkeiten noch nachvollziehbar hergestellt werden können. Je früher die Lücken sichtbar werden, desto eher bleibt Verhandlungsspielraum erhalten.
Was passiert, wenn im Audit ein kritischer Punkt auftaucht?
Dann braucht es Priorisierung statt Panik. Nicht jede Auffälligkeit stoppt automatisch Release oder Deal. Kritisch wird es, wo Pflichten ausgelöst werden, Zusicherungen nicht mehr haltbar sind oder externe Nachweise kurzfristig fehlen. Dafür ist das Audit da.
Nächster Schritt
Wollen Sie Ihr Freigaberisiko jetzt einordnen?
Berühren OSS-Fragen gerade Release, Enterprise-Vertrag, Lieferkette oder Datenraum, ist Tempo wichtig, aber nicht auf Kosten der Belastbarkeit. ITMR schärft das Lagebild, priorisiert Risiken und macht aus verstreuten Unterlagen eine Freigabe- oder Nachbesserungsentscheidung. Open Source wird wirtschaftlich relevant, wenn IT-Recht, Verträge, Urheberrecht, Lieferkette und Produktsteuerung zusammenlaufen. Bei ITMR arbeiten an dieser Schnittstelle Dr. Alexander Pleh, Fachanwalt für IT-Recht, und Christoph Schleusener, MBA, mit Schwerpunkt IT-Verträge, Urheberrecht und Open-Source-Strategien.
Für die Anfrage hilfreich
- Produkt und Release
- Anlass und Termin
- Vorhandene Scans oder SBOM
- Betroffene Verträge
Vertrauliche Unterlagen können Sie nach dem Erstkontakt nachreichen.
OSS-Problem kurz einordnen
Für Softwareunternehmen mit konkretem Prüfungsdruck.
Vertrauliche Unterlagen wie SBOM, Scan-Report, Kundenfragebogen, Vertragsklauseln oder Notices können nach dem Erstkontakt strukturiert nachgereicht werden.
Verwandte Leistungen
Open-Source-Recht Lizenzen, Copyleft, Konflikte.Open-Source-/SBOM-Check Vorab strukturieren.IT-Vertrag / Softwarevertrag Zusicherungen und Audit-Rechte.Cybersecurity Sicherheits- und Regulierungsdruck.IT-Recht Grundsatzfragen.Softwarelizenzvertrag prüfen Lizenzumfang prüfen.
Aus unserem Blog: MG4 und Open Source · CRA und Open Source