Modul 3

Open Source Governance

Modul 3 - Open Source Governance

Dieses Modul adressiert die Grundlagen der Open Source Governance. Neben den Rollen und ihren Verantwortlichkeiten werden typische Prozesse und Organisationsmuster für unterschiedliche Organisationsgrößen eingeführt:

  • Bausteine einer Open Source Governance
  • Verteilung von Rollen und Verantwortlichkeiten
  • Inhalte einer Open Source Policy

Dauer: ca. 90 Minuten

Zielgruppe: Entwickler, Projekt Manager, Product Owner, Compliance Manager, Architekten, Auditoren


Reflexion BFOSS 2018

In guter Gesellschaft, die Sponsoren der Veranstaltung

Das war sie nun, gestern, die BFOSS 2018. Beachtlich, wie voll der Erfurter Kaisersaal geworden ist. Gegenüber dem letzten Mal ist wiederum eine erhebliche Steigerung der Teilnehmerzahl festzuhalten. Das entspricht dem gefühlten Druck, der zunehmend auf dem Thema liegt.

Ausgehend von einer Einführung in die Problematik wurden durch die Redner unterschiedliche Erfahrungen und Ansätze vorgestellt, wie sich Herstellerfirmen den Herausforderungen der OS-Governance (OSG) nähern. Mit 8 Vorträgen war das Programm voll und intensiv.

Interessant war zu sehen, dass sich die vorgestellten Ansätze zwar in Fokus, Gestaltungstiefe und jeweiliger Ausführung unterschieden, jedoch in der Ambition und dem Lösungsprozess vergleichbar sind:

  • Integration der Governance in die Tool- bzw. Build-Chain (Fail-fast)
  • Automatisierung bei der Analyse der relevanten Lizenzinformationen
  • Möglichst automatisierte Komposition der BoM
  • Bereitstellen einmal ermittelter Informationen für spätere Nutzung

Erstaunlich war für mich, wie wenig Fokus auf den Governance-Prozess an sich gelegt wurde. Das mag zum einen an den nach wie vor hohen fachlichen Anforderungen an die Werkzeuge liegen, die noch zu lösen sind. Zum anderen an den Protagonisten, die ja zumeist aus den technischen Bereichen stammen und sich daher mehr mit der technischen Lösung als mit dem Nachhalten der Ergebnisse beschäftigen.

unser Stand
Unser Stand hatte den Fokus auf Legal Compliance & Governance

Sehr erfreulich, insbesondere für uns als TrustSource, ist die übergreifende Erkenntnis, dass dieser Schritt ohne Werkzeugunterstützung nicht abbildbar ist. Aus meiner Sicht ist uns Ansatz, alles rund um die Stellen zu automatisieren, die man kennt und die rote Lampe zu zünden, wenn es manuelles Eingreifen braucht aufgrund der gegenwärtigen Situation vermutlich auch der pragmatische und zuverlässige. Ergänzend zu dieser Betrachtung, wurden darüber hinaus diese drei wesentlichen Herausforderungen immer wieder unterstrichen:

  • Einführung von Open-Source Governance ist eine Aufgabe für sich. 
Obwohl es eigentlich eine Selbstverständlichkeit sein sollte, wie das Händewaschen oder das Verständnis, niemandem etwas wegzunehmen, so ist die Notwendigkeit von IP-Schutz / OSG  doch nicht allen präsent. Diese Bewusstseinsbildung ist in einer Organisation ein harter und zäher Prozess, der viel Aufmerksamkeit erfordert.
  • Informationslage ist oft unzureichend. Software-Entwickler sind keine Rechtsanwälte und dementsprechend sind stellenweise die Grundlagen für die rechtssichere Nutzung, bzw. Bereitstellung von Komponenten gar nicht hinreichend vorhanden. Aus den Gesprächen lässt sich eine Tendenz ableiten, je hardware-näher bzw. älter die Komponenten, desto aufwänder die Aufbereitung der erforderlichen Information.
  • Unternehmensübergreifende Zusammenarbeit wird zum Thema. 
Zwar kam eine Großzahl der Vorträge aus dem Siemens/Bosch-Umfeld, jedoch lies sich generell der Wunsch nach mehr Unterstützung in der Governance-Arbeit vernehmen. Dabei wurden unternehmensübergreifende Ansätze für Repositories wie bspw. ClearlyDefined in den Fokus gerückt. Folgerichtig hat sich der AK Open Source des Bitkom dieses Thema auch als Fokus für nächstes Jahr vorgenommen.

Gerade der letzte Aspekt wurde auch in den vergangenen Monaten bereits des öfteren diskutiert. Grundsätzlich ist die Idee gut, Open Source-Mechanismen zu nutzen, um Open Source besser zu organisieren. Aber was bedeutet das?

Shared clearing - Gedankensammlung

Im Grunde genommen geht es primär um das „Clearing“ der Lizenzinformationen für das Notice-File, also die Begleitinformation, die einem Produkt, welches Open Source einsetzt, beigelegt werden muss, um die Nutzungsrechte an der eingesetzten Software sicherzustellen.

Das Konzept

Hierbei sind aufgrund der nicht standardisierten Grundlage und den stellenweise unklaren, unvollständigen oder auch fehlerhaften Lizenzbedingungen der ggf. zum Einsatz kommenden OS-Artefakte erhebliche Klimmzüge zu veranstalten, um eine rechtlich korrekte Dokumentationslage als Einsatzvoraussetzung zu schaffen.

Die Idee ist nun, dass ein Unternehmen A nach den Klimmzügen die Früchte seiner Arbeit einem crowd-sourcing-artigen Gremium überträgt und somit den anderen Unternehmen diese Arbeit abnimmt. Analog könnte das partizipierende Unternehmen aus dem bereitgestellten Pool schöpfen, um sich selbst Arbeit zu ersparen. Wenn der Pool öffentlich wäre, gäbe es hier auch keine wettbewerbsbeschränkenden Aspekte zu beachten.

Vertrauen als Basis

Dieser Ansatz erfordert jedoch nicht nur die Bereitschaft, seine Arbeitsergebnisse zu teilen, es erfordert auch Vertrauen. B muss A vertrauen, dass er seine Arbeit richtig und vollständig gemacht hat. Andernfalls müsste B die Ergebnisse von A zumindest noch einmal prüfen, was vermutlich dem eigenen Clearing nicht wesentlich nachsteht, will man es „vollständig“ prüfen.

Alternativ könnte man sich einen mehrstufigen Reifeprozess vorstellen. A stellt eine Ergebnis ein, B prüft es (weniger Aufwand als A) und bestätigt es, wenn die Prüfung erfolgreich ist. Somit könnte C tatsächlich mit recht hohem Vertrauen auf das Ergebnis zugreifen.

Anforderungen an das Clearing

Bleibt die Frage, ob ein Clearing unabhängig vom Anwendungsfall erfolgen kann. Denn das Arbeitsergebnis kann für einen spezifischen Anwendungsfall vollständig „cleared“ sein, für einen anderen noch nicht. Das ergibt sich aus den erheblich abweichenden Anforderungen, die sich aus der Kommerzialisierung, der technischen Nutzung oder der Art der Distribution ergeben.

Da es vermutlich wenige Lizenzen gibt, die eine Dokumentation untersagen, könnte man sich beim Shared-Clearing auch darauf einigen, immer die maximale Dokumentation herzustellen. Das bedeutet, immer für alle Komponenten die alle üblicherweise erforderliche Dokumentation einzufordern. Somit wäre sichergestellt, dass ein einmal eingestelltes Paket, alle Anwendungsfälle abdeckt.

Da dies wiederum erheblich erhöhte Aufwände für den Erstbereitsteller bedeuten könnte, könnte sich diese Forderung negativ auf die . Um dennoch den Ansatz nicht fallen zu lassen, wäre ggf. zu überlegen, ob nicht die Dokumentation des Anwendungsfalles, für den es erzeugt wurde, eine zu wichtige Meta-Information an dem Artefakt wäre. Damit wäre es einem Nutzer möglich, die Eignung bzw. das Risiko für den eigenen Anwendungsfall abzuschätzen.

Haftung im Shared-Clearing

Da der Einsatz hier ja in einem unternehmensübergreifenden Kontext stattfindet, stellt sich die Frage nach der Haftung. Was passiert, wenn B einen Produktrückruf aufgrund des nachweislich unvollständigen, bzw. fälschlichem Clearings durch A zu verkraften hat?
Der natürliche Reflex jedes wirtschaftlich Handelnden ist es, außerordentlichen Aufwände an möglichst an Dritte weiterzureichen. Ist A für diese Information haftbar? Das ist sicherlich etwas, das es im Rahmen des Contributor Agreements zu klären gilt. ClearlyDefined hat dies durch den Open-Source-typischen Haftungsausschluss und eine Schadenslimitierung auf 5 USD. gelöst.

Das ist sicherlich die gute Voraussetzung, um die Bereitschaft für Kontributionen zu erhöhen. Es führt jedoch wieder zur verbleibenden Prüflast seitens des Benutzers. Somit bleibt die Frage offen, welche Arbeit ihm durch die Wiederwendung erspart bleibt. Die Vorstellung den Linux-Kernel einem Clearing zu unterziehen ist sicherlich gruselig. Die Vorstellung, eine als cleared bereitgestellte Version stichhaltig zu prüfen, erscheint mir jedoch nicht weniger gruselig.

Zertifizierung als Ergänzung bzw. Alternative?

Die Idee der verteilten Zusammenarbeit ist zwar gut und passt ins Genre, tangiert jedoch ein Thema, das sich komplett außerhalb dieser Welt bewegt. Dementsprechend schwierig gestaltet sich der Anpassungsprozess.

Möglicherweise wäre eine Zertifizierungsstelle der geeignetere Ansatz? Angenommen es gäbe einen Body, der sich den Schuh der Prüfung bzgl. eines Anwendungsfalles anziehen und eine Garantie für die Vollständigkeit bzw. Korrektheit des Clearings in Form eines Zertifikates abgeben würde.
Hierdurch würden sich die Bedürfnisse beider Welten vereinen lassen. Zum einen ließen sich die Ergebnisse teilen und wiederverwenden, zum anderen wären sie hinreichend überprüf- und belastbar, um tatsächlich Einsparungen zu erzeugen.

Diskutieren Sie mit uns!

Gerne lernen wir Ihre Sicht auf diese Aspekte kennenlernen. Diskutieren Sie mit uns oder teilen Sie uns mit, was Sie für richtig halten.


EACG wird OpenChain-Partner

Frankfurt, 8.Juni 2018, EACG - die Mutter von TrustSource - und Linux Foundation zeichnen eine Partnerschaftsvereinbarung zur Zusammenarbeit im Projekt OpenChain.

EACG ist bereits seit einigen Jahren im Umfeld der Open Source Governnace und Compliance aktiv. Durch eigene Großprojekte auf die Problematik sensibilisiert, ist das heutige TrustSource entstanden, die Plattform für die Automation der Open Source Governance."Wir sind noch nicht ganz am Ziel, aber auf einem guten Weg", meint Jan Thielscher, der das Unterfangen federführend treibt.

"Unsere Plattform liefert den technischen Teil: scanning, mapping, Dokumentation und Berichte. Governance ist aber mehr, als ein Werkzeug leisten kann. Um wirklich rechtskonform ud sicher Software zu erstellen und auszuliefern, ist es auch erforderlich, Prozesse und Kultur anzupassen. Hier kommt OpenChain ins Spiel. Die vielen, wohlüberlegten Anforderungen fürhren zu dem erforderlichen Wandel. Wir begrüßen das und bauen die Workflow-Unterstützung der Pplattform so aus, dass sie die Anforderungen bestmöglich unterstützt."

EACG bietet Beratungsleistungen zum Thema Open Source Compliance und Governance an, sowie die Lösungsplattform TrustSource als SaaS. Es gibt unterschiedliche Editionen, von einer freien Lösung für einzelne Entwickler bis hin zur Enterprise-Lösung on premises. Ausprobieren lässt sich die Löung hier.

In Zuge der Zusammenarbeit wird EACG zunächst die Übersetzung der OpenChain Spezifikation v1.2 in die deutsche Sprache unterstützen und anschließend deutschsprachige Seminare anbieten. Interessierte können sich gerne direkt an uns wenden.


Warum ist eine Lizenz so wichtig?

„Wenn jemand sein Zeug bei GitHub in ein Public-repository lädt, muss er doch damit rechnen, dass es auch genutzt wird!“

Diese kritische Fehleinschätzung der Sachlage hören wir gelegentlich, wenn wir im zuge von Analysen auf Open Source Komponenten im Quellcode treffen, die nicht hinireichend deklariert sind. Es erscheint daher sinnvoll, noch einmal die Grundlagen zu klären.

In unserer westlichen Welt hat der Schutz des geistigen Eigentums einen hohen Wert. Innvoation ist der Grundstein unserer Zivilisation und wurde daher auch mit den Urheber-Rechten entsprechend geschützt. Diese Erkenntnis existiert bereits recht lange und ist inziwschen im internationalen Rechtsraum auch durch die Berner Konventionen weitgehend harmonisiert.

Grundüberlegungen dabei sind, dass ein Urheber stets die Rechte bzgl. Nutzung, Verbreitung und Veränderung an seinem Werk haben soll. Dies gilt – je nach Gegegenstand – für eine gewisse Zeit nach der Schöpfung als Urheberrecht. Nun kann natürlich ein Urheber diese Rechte auch anderen übertragen. Die typische Ausdrucksform hierfür ist eine Lizenz.

Liegt keine Lizenz vor, gelten zum Schutze des Urhebers die Rechte als nicht erteilt!

Liegt eine solche nicht vor, gelten zum Schutze des Urhebers die Rechte als nicht erteilt. Somit bewegt sich jeder Benutzer von Komponenten ohne Lizenz auf unsicherem Terrain. Vermutlich wird zunächst auch kein direktes Problem entstehen. Jedoch ist die gegenwärtige Situation eines, die zukünftige Situation etwas anderes. So kann der Wunsch nach einer entgeltfreien Bereitstellung sich mit der Zeit ändern. Wohl dem Anwender, der sich auf eine Lizenz berufen kann, wehe dem, der eine Distribution ohne klare Bedingungen vorgenommen hat.

Ebenfalls ist es in unserem Rechtsraum üblich, die unrechtmäßige Nutzung als Straftrat zu betrachten. Somit stehen nicht nur mögliche finanzielle Schäden durch Rückruf oder Image-Verlust im Raum, auch eine strafrechtliche Verfolgung der Nutzung ohne Rechte kann die Folge sein. Letztere benötigt nicht mal einen Kläger, denn das übernimmt die Staatsnawaltaschaft im Zuge ihrer Aufgaben bei hinreichendem Verdacht. Hierzu reicht eine Indikation zur Sachlage, egal von wem sie kommt (Wettbewerber, ehemaliger Mitarbeiter, eigentlicher Rechteinhaber, etc.)

Zur Abwendung von Schaden empfiehlt es sich daher, stets auf das Vorhandensein von Lizenzen zu achten!

Zur Abwendung von Schaden empfiehlt es sich daher, stets auf das Vorhandensein von Lizenzen zu achten. Um dies jedoch zu ermöglichen, ist es erforderlich, genau zu wissen, was wurde verbaut und unter welchen Bedingungen.

TrustSource wurde entwickelt, um diese Aufgabe zu automatisieren. Mit Hilfe der automatisierten Scans können Sie frühzeitig erkennen, welche Komponenten in Ihrer Software verbaut sind und welche Lizenzen – oder auch nicht – mit diesen einhergehen.

Unsere Architekten helfen Ihnen auch dabei, kritische Fälle zu klären oder alternative Lösungen zu finden. Zögern Sie nicht, beginnen Sie noch heute mit der Aufklärung!


TrustSource v1.4 released

Wir freuen uns, die Verfügbarkeit der Version v1.4 anzukündigen!

Endlich ist es soweit. Nach viel Arbeit, Schweiß und Tests haben wir die v1.4 released. Es sind eine Vielzahl von Neuerungen dabei, die die Arbeit mit TrustSource erheblich effizienter machen werden:

  • Eine Inbox nimmt zukünftig alle Kommunikation auf, damit nichts mehr verloren geht.
  • Vulnerability-Feeds ermöglichen das frühzeitge Erkennen von möglichen Porblemen
  • CVS-Scores und Angriffsvektoren helfen bei der Einschätzung der Kritikalität identifizierter Schwachstellen.
  • Erweiterte Verpflichtungsanalyse - Es ist jetzt möglich, direkt von dem Obligation-Report auf die verursachenden Komponenten zu springen. Zudem kann der Bericht auch direkt aus der Modulansicht heraus aufgerufen werden.
  • Eignungsprüfung - Um den SHIFT-LEFT-Effekt weiter zu unterstützen, haben wir ein Test-Feature für noch nicht verbaute Lizenzen und/oder Komponenten eingeführt. Damit können Entwickler bereits _vor_ Einsatz einer Komponente die Auswirkungen projekt- und modulspezifisch prüfen. Die Funktionen werden auch im API bereitgestellt.
  • Private Lizenzen - Es ist nun möglich, eigene Lizenzschlüssel anzulegen, um eigene Lizenzen nicht mehr zwingend als commercial klassifizieren zu müssen.

Zudem wurden einige Verbesserungen und Fixes durchgeführt. unter anderem wurde ein Matching-Problem im Vulnerability Scanner behoben.

Weitere Informationen und Details zu dem Release finden sich auch hier.


19.6. Compliance Breakfast @ Frankfurt a.M.

Um innovative Produkte und Lösungen schnell und kostengünstig an den Markt zu bringen, ist der Einsatz von Software und insbesondere Open Source Software überlebensnotwendig.

Open Source Software ist jedoch kein Free Lunch!

Welche Verbindlichkeiten mit dem Einsatz von Open Source Software einhergehen, was sie auslöst und was daraus folgt sowie wie man die daraus resultierenden Risiken beherrschbar hält, ist Gegenstand dieser Informationsveranstaltung. Neben einem Überblick zur aktuellen Rechtsprechung stellen die Referenten praktische Erfahrungen aus der Einführung von Open Source Governance vor.

0830-0900 Welcome Kaffee & Tee

0900-0915 Begrüßung durch Gastgeber (EACG) und Vorstellung der Referenten

0915-0945 Aktuelle, rechtliche Entwicklungen (Heinzke)

0945-1000 Fragen und Diskussion

1000-1045 Erfahrungsbericht Einführung Open Source Governance im Konzern (Thielscher)

1045-1100 Fragen und Diskussion

Reservierung von Plätzen (verbindliche Teilnahme) ist hier möglich. Um die Teilnahme gewinnbringend zu gestalten, ist die Teilnehmerzahl auf 25 begrenzt.