Aktuelle Herausforderungen Open Source Compliance
Warum organisieren sich SAP, Siemens, Fujittsu, Toyota oder Orange unter dem Schirm der Linux Foundation im OpenChain-Projekt, das Standards im Umgang mit Open Source setzen will? Mit der zunehmenden Verbreitung von Software in alle Gegenstände und dem stetig steigenden Open Source Anteil, steigt auch die Notwendigkeit einer rechtlich konformen Dokumentation. Doch was verbirgt sich hinter der Anforderung? Warum ist das plötzlich so wichtig?
Zunächst zur Motivation; drei wesentliche Treiber tragen zur wachsenden Dringlichkeit bei:
- Wachsende Verteilung von Software-Komponenten
- Gleichzeitig steigt der Anteil von Open Source Software
- Zunehmende Automatisierung der Software-Entwicklung und Verbreitung von Continuous Integration und Delivery-Ansätzen
Aus dieser Gemengelage entsteht ein sensibles Umfeld. B erhöht zwar die Geschwindigkeit der Lieferung, verlagert aber gleichzeitig Teile der Wertschöpfung in die Hände Dritter. In Verbindung mit C kann bei jedem neuen Bau der Software eine neue Zusammensetzung entstehen, da ja alle Beteiligten – also auch die Dritten – stets weiterentwickeln.
Open Source Compliance - Risiken kennen
Dabei muss man sich vergegenwärtigen, dass solche Abhängigkeitsbäume nicht nur zwei oder drei Ebenen haben, sondern in der Regel bereits bei einem einfachen Modul mehrere hundert Komponenten und durchaus vier bis sieben Hierarchiestufen umfassen. In größeren Projekten sind’s schnell mehrere tausend Komponenten.
Ändert sich nun die Lizenz einer der Sub-Komponenten oder es wird eine Abhängigkeit mit MIT -Lizenz durch eine mit Apache-Lizenz ersetzt, entstehen für diese Subkomponente neue Veröffentlichungspflichten (Attribution = Zuschreiben des Werkes zum Autor). Und gerade die Veröffentlichungspflichten sind es, die gerne unterlassen werden.
Dabei ist auch hier Vorsicht geboten! Wie viele andere Open Source Lizenzen berechtigt auch die Apache-Lizenz den Gebrauch nur unter der Voraussetzung, dass die Lizenz und Veränderungen entsprechend deklariert werden. Wer eine Komponente unter Apache-Lizenz einsetzt, es jedoch versäumt, dies zu erwähnen, den und den Lizenztext beizulegen oder seine Anpassungen zu deklarieren, verliert das Recht, die Komponente zu nutzen!
Die rechtlich Folgen einer Missachtung können erheblich sein. Versäumt es ein Unternehmen, entsprechende Mechanismen zu schaffen, die geeignet sind, ein fehlerhaftes Inverkehrbringen zu unterbinden, so steht der verantwortliche Bereichsleiter bzw. Geschäftsführer in der Haftung. Solche Urheberrechtsverletzungen im gewerblichen Kontext sind keine Kavaliersdelikte, sondern eine Straftat, welche bei Bekanntwerden die Staatsanwaltschaft auf den Plan ruft. Als Strafe droht für die betroffenen Verantwortlichen in Deutschland ein Gefängnisaufenthalt.
Durch die zunehmende Verbreitung von Software in alle Arten von Geräten (A) verschärft sich das Risiko, da die Möglichkeit, Zugang zu der Software zu erhalten und sie in ihre Bestandteile zu zerlegen, ebenfalls steigen. Es ist vermutlich nur eine Frage der Zeit, bis windige Gestalten hieraus ein Geschäftsmodell ableiten. Auch für enttäuschte Mitarbeiter bietet dieser Bereich ein geeignetes Feld für einen Rachefeldzug.
Auszug Apache 2.0 Lizenz:
(…) 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (…)
Im Kontext von Serienprodukten liegt die enorme Bedrohung dabei nicht unbedingt nur in der strafrechtlichen Konsequenz für den betroffenen Manager, auch ein Rückruf der in Umlauf gebrachten Produkte könnte eine zwingende Folge sein, wenn sich das Problem nicht anderweitig heilen lässt, beispielsweise durch Nachreichen einer Dokumentation an alle bisherigen Käufer oder vergleichbarer Ansätze.
Wie einen dies treffen kann, hat Dr. Ibrahim Haddad (Samsung Open Source) in seiner Präsentation „Guide to Open Source Compliance“ (2) dargestellt. Er beschreibt einen Fall von Cisco. Cisco kaufte 2003 die Firma Linksys für gut 500 Mil USD. Linksys hatte in seinem WRT54G Broadband-Router ein Chipset von Broadcom verbaut. Dieses wiederum nutzte angepassten Linux-Code, den die Firma CyberTAN Broadcom zur Verfügung gestellt hatte. Linux ist GPL-lizensiert, damit sind Anpassungen und damit verbundener Code veröffentlichungspflichtig. Die FSF hat geklagt und am Ende hatte Cisco nicht nur viel schlechte Presse, sondern auch einen Schaden von gut 50 Mil USD und musste seinen Code und damit eine Menge teuer erworbenes Intellectual Property ebenfalls veröffentlichen.
Bleibt also die Frage, wie sich diese Risiken eliminieren lassen?
OS Compliance - Pflichten erfüllen
Es gibt bereits eine Vielzahl von Herangehensweisen und Prozessen. Den aus unserer Sicht vollständigsten Ansatz beschreibt die OpenChain Spezifikation(3). OpenChain (4) ist ein Projekt der Linux-Foundation. Es hat sich zum Ziel gesetzt, Sicherheit und Vertrauen bezüglich des Einsatzes von OpenSource entlang der Software-Wertschöpfungskette zu gestalten. Die Spezifikation liegt derweil in der Version 2 vor und ist auf dem Weg, zu einem ISO-Standard erhoben zu werden.
Sie beschreibt ein Set von sechs Zielen und den Anforderungen, um diese Ziele zu erfüllen. Unternehmen, die diese Ziele erfüllen, können als OpenChain-konform angesehen werden und haben somit ein entsprechendes Compliance-System in ihrer Organisation verankert. Nachstehendes Bild gibt einen Überblick der Anforderungen.
Neben der Anforderung an die organisatorische und prozessuale Gestaltung lässt OpenChain jedoch die Art der zu erzeugen Dokumentationsartefakte offen. Um diese Lücke zu schließen, sind im Folgenden die Elemente vorgestellt, mit deren Bereitstellung sich die oben beschriebenen Risiken vermeiden lassen.
Zum einen ist es erforderlich, Transparenz über den Inhalt zu schaffen, also eine Art Stückliste mitzuliefern. Diese Stücklisten, oder auch als Bill of Materials bezeichnet, haben bereits einen Standard für die Beschreibung erhalten, im ebenfalls unter der Linux Foundation gestaltetem SPDX-Projekt (5). Dort wird ein maschinenlesbares Format beschrieben, welches die Inhalte einer Komponente beschreibt. Es erlaubt eine entsprechend feingranulare Darstellung der Inhalte und eignet sich für die Repräsentation einer Stückliste.
Für jede OSS-Komponente in dieser Stückliste sind dann zusammenzustellen:
- Informationen, die die Software konkret identifizieren (Version)
- Die Lizenz, unter der die Komponente eingesetzt wird (s. u. Mehrfachlizenz)
- Änderungen, die an der Komponenten vorgenommen wurden, wenn die Lizenz dies erfordert
- In einigen Fällen erfordern Lizenzen auch die Nennung der Autoren (Copyright-holder)
Wir unterstützen Unternehmen dabei, die Prozesse und Verantwortlichkeiten zu identifizieren und spezifikationskonform aufzusetzen. TrustSource integriert dem konformen Prozess optimal in die Arbeit des Entwicklers und erleichert somit das Erfüllen der OpenChain Anforderungen.
Im Kontext einer Distribution ist darüber hinaus in einigen Fällen der Lizenztext hinzuzufügen. Weiterhin gibt es einige Lizenzen, die auch im Kontext einer binären Distribution die Bereitstellung des Quelltextes erfordern. In diesem Fall wäre ein Angebot zur Übermittlung der Quellen beizulegen, die sogenannte „Written offer“.
Diese Informationen lassen sich nicht immer einfach ermitteln. Es ist aber möglich, einige davon aus den unterschiedlichen Quellen und Repositories der jeweiligen Projekte zusammenzutragen. TrustSource kenn beispielsweise die Abhängigkeiten von gut 20 Mil Open Source Komponenten in allen Versionen, was wiederum gut 500 Mil Abhängigkeiten darstellt. Hier ist schon eine Menge Arbeit getan, jedoch wächst der Pool an Open Source Software täglich. Daher stehen diverse Prüf- und Verifikationsmechanismen zur Verfügung.
Um diese Aufgaben zu erleichtern, hat TrustSource den Notice-File-Generator entwickelt. TrustSource setzt im Paket-Manager der jeweiligen Entwicklungsumgebung an und erzeugt das Bill of Materials der tatsächlich eingesetzten Software-Komponenten. Dieses wird anschließend vom Legal Check Service, der die Lizenzen kennt, im Kontext des Projektes auf Veröffentlichungspflichten sowie andere Verpflichtungen geprüft. Im Ergebnis entsteht eine Ampel, die es erlaubt, automatisiert den Build zu stoppen, wenn Verletzungen auftreten.
Weiterhin verfügt TrustSource über einen Notice-File-Generator. Dieser erzeugt basierend auf dem Bill of Materials und den Erkenntnissen aus dem Legal Check das Grundgerüst für das Notice File. Diese Vorlage wird anschließend mit den Informationen zu den Komponenten aus der geteilten Datenbank gefüllt. Somit bleibt dem Bearbeiter nur noch die bestehenden Lücken zu schließen. Seine Eingaben werden wiederum der Komponenten DB hinzugefügt und stehen dem nächsten zur Verfügung.Einfacher lässt sich eine rechtlich konforme Dokumentation derzeit nicht herstellen.
Open Source Compliance - Sonderfälle klären
Nun ist die Welt leider nicht rund und es gibt noch tieferliegende Herausforderungen im Bereich der Compliance.
Multi-License
So gibt es beispielsweise Komponenten, die nicht nur unter einer Lizenz, sondern unter mehreren veröffentlicht werden. In einem solchen Fall muss sich der Entwickler festlegen, unter welcher Lizenz er die Komponente einsetzen will. Diese Entscheidung sollte sich im Notice-File entsprechend wiederfinden, da ja hier die entsprechenden Anforderungen zu erfüllen sind.
TrustSource weist auf diesen Multi-License-Fall hin, fordert eine Entscheidung ein und verwendet anschließend die gewählte Lizenz, bis sie wieder geändert wird. Die Entscheidung wird dokumentiert und kann begründet werden.
Deklariert vs effektiv
Ein anderer, sehr kritischer Fall, sind fälschlich deklarierte Lizenzen. So kann es beispielsweise vorkommen, dass ein Paket als Apache 2.0 Lizenz deklariert ist, jedoch weitere Drittbausteine einsetzt, die einer anderen Lizenz unterliegen. Das ist eher die Ausnahme als die Regel, aber es birgt ein erhebliches Risiko. Beispielsweise die Komponente Mapfish kommt als BSD lizensiert daher. Dennoch setzt sie unter anderem das Sencha-Framework ein, welches eine kommerzielle Lizenz erfordert.
Für die rechtliche Wirkung ist die effektive Lizenzierung wichtig, nicht die deklarierte. Die effektive Lizenzierung entsteht durch die Bemerkungen im Quellcode. Der Hinweis „AGPL-2.0“ in einer einzelnen Quelldatei kann ausreichen, eine effektive Lizenzierung dieser Datei unter AGPL zu erzeugen. Natürlich gilt, „Wo kein Kläger, da kein Richter“. Wer jedoch ein Produkt in den Markt bringt, sollte sich von diesen Gedanken nicht leiten lassen.
Um diese Risiken auszuschalten, hat TrustSource den Service DeepScan entwickelt. Mit Hilfe von DeepScan kann ein Repository bzw. eine Reihe von Repositories noch einmal überprüft werden. Dies erlaubt es, eine gesamte Dependency-Hierarchie vollständig auf Hinweise nach Lizenzen zu untersuchen. Die Ergebnisse werden übersichtlich in einer Zusammenfassung angezeigt und kritische Elemente lassen sich direkt aus dieser Übersicht ansteuern.
Keine Lizenz
Eine weitere Sondersituation ist der „No license“-Fall. Tatsächlich gibt es einige Komponenten, die über gar keine Lizenzdeklaration verfügen. Einige Autoren haben ihre Ergebnisse „public domain gestellt“. Es mag hier zum Ausdruck kommen, dass sie ganz philantrophisch die Komponente allen zugänglich machen wollen. Das ist nett und auch sehr löblich. Leider ist es aus rechtlicher Perspektive eine Katastrophe, da „public domain“ vielleicht im englischsprachigen Raum eine Bedeutung haben mag, jedoch weder im angelsächsischen Recht noch im deutschen gibt es hierzu eine Rechtsfestlegung. Auch ist „public domain“ keine bekannte, gültige Lizenz.
Somit liegen trotz der Deklaration alle Rechte beim Urheber. Es ist rechtstechnisch gesehen, verboten, diese Komponenten zu nutzen, zu verändern zu verteilen oder gar zu verkaufen! Die „No license“ gehört auf jede Black-Liste ganz nach oben.
Um solche Fälle aufzulösen, bietet es sich an, den Autoren zu kontaktieren. Man kann ihm freundlich die Thematik erklären und ihn bitten, eine Lizenz, gegebenenfalls sogar einen Vorschlag anbei, hinzuzufügen. Erfolgt dies jedoch nicht, birgt die Verwendung ein hohes Risiko. Denn auch wenn jemand heute die Annahme vertritt, er möchte großzügig sein, ist ein Leben gerne mal wechselhaft und die Meinung kann sich ändern. Wer sein IP nicht gefährden will, sollte Abstand von solchen Komponenten halten.
TrustSource weist Komponenten ohne Lizenzen stets als Verletzung aus. Auch hier lässt sich der Hinweis durch den Benutzer übersteuern, wenn er das Risiko eingehen möchte, ein Compliance Manager erhält jedoch stets den Hinweis, dass solche Komponenten in dem zu begutachtenden Konstrukt verbaut sind.
Fazit
Zusammenfassen lässt sich erkennen, dass Open Source Compliance zwar eine wachsende Herausforderung darstellt, es jedoch auch hinreichend Initiativen und Lösungen gibt, den daraus entstehenden Aufwand erheblich zu reduzieren.
Die Gestaltung einer Open Source Policy – also der Definition von Verhaltensregeln, Vorgehen und Verantwortlichkeiten bei er Nutzung von Open Source – kann ein erster Schritt sein. Unter https://www.trustsource.io/resources finden sich Vorlagen und Hinweise, wie sich eine Open Source Governance erfolgreich aufsetzen lässt. Die SaaS-Lösung TrustSource stellt eine erhebliche Unterstützung für die Einführung und Aufrechterhaltung einer effektiven Open Source Governance dar.
Literaturhinweise:
(1) Welche Herausforderungen die Compliance beantworten muss, findet sich in dem Artikel „Aktuelle Herausforderungen der Open Source Compliance“.
(2) Dr. Ibrahim Haddad (Samsung), „Guide to Open Source Compliance“, https://de.slideshare.net/SamsungOSG/guide-to-open-source-compliance , Slide 62
(3) OpenChain Spezifikation v2.0 (deutsche Übersetzung) https://github.com/OpenChain-Project/Specification-Translations/tree/master/de/2.0.
(4) OpenChain Projekt s. https://www.openchainproject.org ACHTUNG! Nicht zu verwechseln mit dem gleichnamigen OpenSource Blockchain-Projekt!
(5) SPDX-Projekt, s. https://spdx.org
Microsoft erweitert Githubs integrierte Vulnerability Management Fähigkeiten
Software eats the world - Microsoft eats Software?
Mit der Übernahme von Github hat Microsoft ein klares zeichen gesetzt, dass es seinen Führungsanspruch in der Gestaltung von Software nicht nur erhalten, sondern ausbauen will. Mit den nun in aller Eile geschaffenen Vulnerability-Werkzeugen in Github untermauert Microsoft seinen Anspruch als Platzhirsch in der Software-Entwicklung.
Github hat mit seiner erfolgreichen Mirror-Strategie den Anspruch als quasi-Standard-Repository für Software erfolgreich platzieren können. Neben einer stabilen und smarten Versionierungs- und Synchronisationslösung für Quellcode hat das Mirroring sämtlicher Open-Source-Projekte dazu beigetragen, das Gefühl von Größe geschickt zu vermitteln. Github wurde der Platz, an dem man Software findet.
Microsoft hat dies erkannt. Zudem haben Satya Nadella – und/oder sein Team – erkannt, welche Themen gerade in der Software-Entwicklung Relevanz entwickeln. Nachdem sich mit IoT letztlich Software in alle Arten von Gegenständen verbreitet, bekommen Schwachstellen (Vulnerabilities) und rechtliche Konformität (legal Compliance) eine erheblich höhere Bedeutung.
Mit Macht besetzt Microsoft nun dieses Thema. Durch die Übernahme von Github hosted Microsoft über Nacht einen Großteil der offenen Quellcodes dieser Welt. Die Software-Industrie hat mit CI/CD-Lösungen schon viel für ihre Qualitätssicherung getan und diese nahtlos an Github angeschlossen. Immerhin gibt es in diesem Segment noch eine handvoll alternative Lösungen.
Das leidige Thema „Schwachstellen- und Patch-Management“ ist derzeit noch etwas unsortiert, da es zum einen keiner gerne macht, zum anderen auch ein sehr zähes und unproduktives Geschäft ist. Dennoch haben Equifax und andere Fälle eindringlich aufgezeigt, was Folgen des Unterlassens sein können. Also beschäftigt sich inzwischen jeder notgedrungen damit.
Mit den in den letzten Wochen bekanntgegebenen Lösungen rund um das Multi-Language-Package-Management, die freien Vulnerability-Alerts – jetzt auch gestützt durch die Whitesource Vulnerability-Database für Enterprise Kunden — und durch die Übernahme von Dependabot – für eine Versionskontrolle á la Versioneye – stopft Microsoft diese Lücke und zementiert somit die Führungsposition von Github als Heimat allen Quellcodes.
Wer sollte sich jetzt noch mit diesen leidigen Aufgaben beschäftigen wollen, wenn er sie quasi freihaus durch ein Hosting bei Github erledigt bekommt? Vermutlich nur Verschwörungstheoretiker und Technikverliebte.
Letzten Endes bleibt es eine Vertrauenssache, wem man zutraut, die richtigen Abhängigkeiten bzw. Vulnerabilities zu identifizieren:
- Werden hier meine tatsächlich zum Einsatz kommenden Abhängigkeiten analysiert oder dient nur das Original als Vorlage für die Alarme?
- Können die aufgezeigten Vulnerability-Alerts tatsächlich einen Mehrwert bringen oder erzeugen sie aufgrund des hohen Lärmpegels, der mit meiner Bedrohungssituation nichts mehr zu tun hat nur ein ohrenbetäubendes Rauschen, welches meine Entwickler von der Arbeit abhält?
Die Antworten zu diesen Fragen werden die nächsten Monate liefern. Ansatz und Ambition dieses Schrittes erscheinen mir jedoch brillant! Wesentlich substanzieller als die bereits überraschende Übernahme von RedHat durch IBM.
Wenn man Einfluss und Informationsgewinn vergleicht, erschient die Cost-Impact-Ratio bei MS etwas günstiger auszufallen. Unabhängig davon verfügt Microsoft über hinreichend Capability to achieve, um das Vorhaben mittelfristig zu einem Erfolgsmodell zu drehen und den Platz als „Heimat allen Quellcodes“ zu behaupten. Was das wiederum für die Offenheit von Open Source bedeutet, mag jeder für sich selbst beurteilen.
Was bedeutet das für TrustSource?
Kurz nach dem Announcement haben mich erste Kunden gefragt, was das für uns bedeutet. Nach einiger Überlegung bin ich zu dem Schluss gekommen, dass uns diese Ergebnisse das Leben einfacher machen werden.
Zum einen ist die Maintenance so vieler Package-Manager – wir unterstützen derzeit 13 – auf Dauer ein aufwändiges Unterfangen. Open Source hin oder her, am Ende liegt die Maintenance dennoch beim Hauptsponsor.
Zum anderen erwarten wir eine verbesserte Informationslage aus den neue APIs. Derzeit ist die Information mehr als oft noch gruselig dürftig. Die Option, das Vulnerability-Assignment uns schenken zu können, ließe uns jubeln. Ich sehe das zwar noch nicht, da die Grundlage für das Vulnerability-Assignment neben einer sehr
Zudem fokussiert TrustSource auf den Compliance-Aspekt. Wir bieten eine OpenChain-konformen Prozess, samt Policy-Propagation, Trainings, einer automatisierten Legal-Analyse, die Compliance-Artefakt-Generierung, und und und. Das sind Berge von Aufgaben, die auch ein Clearly Defined nicht abbildet.
Auch erscheint mir eine Repository-basierte Analyse von Schwachstellen und Abhängigkeiten nicht unbedingt geeignet, den Lebenszyklus und die rechtliche Eignung einer Komponente im Anwendungskontext zu beurteilen. Immerhin ergibt sich die Eignung der Komponente nicht aus dem Repository, sondern dem gewählten Einsatzzweck in Verbindung mit einem kommerziellen Kontext. Dies lässt sich auf Repository-Ebene schlicht nicht abbilden.
Wir freue uns daher darauf, in den kommenden Monaten die neuen APIs zu integrieren, damit (hoffentlich) unseren Kunden eine verbesserte Informationslage zu bieten und ggf. die letzte Lücke in der Kette der Software-Herstellung zu schließen. Zudem unterstreicht es unsere Auffassung, dass wir in einem relevanten Segment aktiv sind, dass derzeit viel in Bewegung ist.
Sie wollen Ihre Open Source Compliance stärken, wissen aber nicht, wie starten?
OpenChain Specification v1.2 in Deutsch verfügbar!
Dank der Arbeit einer Hand voll Freiwilliger, gibt es jetzt die gegenwärtig aktuelle OpenChain Spezifikation in der Version 1.2 auch in deutscher Sprache!
https://www.openchainproject.org/news/2018/11/07/openchain-specification-in-german
Wir danken den Mitgliedern des Übersetzungs-Teams - sind ein wenig stolz darauf, auch einen Beitrag geleistet zu haben - und wünschen viel Spaß mit dem Umsetzen! Falls es Fragen gibt, stehen wir Ihnen gerne zur Seite!
TrustSource @ BFOSS 2018
Am 18.9. findet in Erfurt die diesjährige Bitkom FOSS-Konferenz statt. Das bereits seit einigen Jahren immer wieder trubelige Forum ist auch dieses Jahr wieder mit hochkarätigen Rednern und spannenden Vorträgen rund um das Thema Open Source Compliance vertreten. Details und Agenda finden sich auf der Seite des Bitkom.
Wir gehören zu den Veranstaltern und präsentieren TrustSource auf dem Forum. Gerne begrüßen wir Sie dort und geben Ihnen eine inddividuelle Einführung.
Vereinbaren Sie schon jetzt einen Termin!
In dem Termin haben Sie die Möglichkeit, die unterschiedlichen, außerordentlichen Fähigkeiten von TrustSource live zu erleben. Unter anderem werden wir zeigen:
- Auswertung einer Lizenz-Konstellation abhängig vom Kontext
- Automatisches Generieren eines BoM
- Prüfen der rechtlichen EIgnung einer Komponente im Projektkontext
- Auffinden von Lizenzinformationen in einem Repository
- Sicherstellen der Comlpiance anhand des Audit-Logs
Wir freuen uns auf Ihren Besuch! Nutzen Sie gerne eine der reservierten Zeiten für ein individuelles Gespräch!
Wie TrustSource Ihnen hilft, Ihre Organisation OpenChain compliant auszurichten
Wenn Sie mehr zu OpenChain erfahren wollen, lesen Sie zunächst unseren Beitrag "OpenChain in a nutshell".
Die OpenChain-Spezifikation definiert sechs Ziele. Inhaltlich stellen fünf Ziele den nachhaltigen Umgang mit Open Source Software sicher. Dabei fokussieren vier auf die hausinterne Organisation und das fünfte auf die Unterstützungsleistung von Open Source Projekten. Das sechste Ziel betrifft die Bereitschaft, nach außen zu erklären, dass man sich an den inhaltlichen Zielen messen lassen will, also die Bereitschaft zu einer Zertifizierung hat.
Dieser Beitrag stellt die Ziele kurz vor und erläutert, wie TrustSource dabei hilft, die Ziele zu erreichen
Ziel 1: Klären und Bewusstsein der Verantwortung
In einem ersten Schritt geht es darum, die Aufgaben und Verpflichtungen innerhalb der Organisation zu klären. Dies findet üblicherweise seinen Niederschlag in einer Regelung (Policy), einer Gebrauchsanweisung für den Umgang mit Open Source Software. Diese beschreibt die Rollen sowie deren Verantwortung, klärt, wie mit einzelnen Fällen umzugehen ist und beschreibt die Prozesse, welche zu befolgen sind.
TrustSource stellt eine Standard-Policy zu Verfügung. Sie kann als Ausgangslage für die Definition Ihrer eigenen Policy dienen.
OpenChain fordert weiterhin, dass nicht nur eine Policy existiert, sondern dass diese auch dem Personal bekannt ist, sie also gelebt werden kann. Hierzu ist sicherzustellen, dass ein Großteil (min 85%) der Entwicklung nachweislich von dieser Policy Kenntnis haben.
TrustSource integriert ab Version 1.7 eine Learning-Plattform mit einem Satz an Kursen, welche den Ansprüchen eines OpenChain-konformen Kurstrainings gerecht werden und Lernkontrollen ermöglichen.
Ergänzend wird gefordert, dass Prozeduren für die Erhebung und Identifikation der genutzten Open Source Komponenten sowie die Ermittlung der damit einhergehenden Rechte, Pflichten als auch Verbindlichkeiten existieren.
TrustSource stellt einen Mechanismus bereit, der den Projektkontext erhebt und die Pflichten sowie Verbindlichkeiten aus dem Einsatz vor diesem Hintergrund auflöst. Änderungen sowohl an Bestand als auch den Zielen werden automatisch dokumentiert.
Ziel 2: Zuweisen von Verantwortlichkeiten
Da die gegenwärtige Dokumentationslage im Bereich der Open Source Komponenten stark zu wünschen übrig lässt, ist mit Rückfragen und Klärungsbedarf seitens der Downstream-Nutzer zu rechnen. Das kann Rückfragen zur Nutzung bzw. den Einsatzmöglichkeiten aber auch die Bestandteile selbst betreffen. Um den Anfragen zu begegnen, bzw. diese auf einfache Art qualifiziert entgegenzunehmen, fordert die Spezifikation die Definition und Kommunikation eines benannten Kontaktes, den „FOSS-Liaison“ oder im Deutschen eher passend: „FOSS-Kontakt“.
Weiterhin fordert die Spezifikation, dass die Kommunikation nach zuvor definierten Regeln zu erfolgen hat und hinreichend dokumentiert sein sollte. Dies ist insbesondere für später ggf. anhängige Gerichtsverfahren ausgesprochen wertvoll.
Mit Hilfe von TrustSource können Sie diese Aufgabe nach außen delegieren. Sie richten eine Mail-Adresse ein und alle Incoming-Requests werden vom TrustSource HelpDesk strukturiert bzw. nach den mit Ihnen erarbeiteten Verfahren abgearbeitet.
Um den Anforderungen dabei gerecht zu werden, ist es als erheblich für den Prozess anzusehen, dass eine hinreichende rechtliche Expertise auf dem einschlägigen Gebiet vorhanden ist. Diese darf gemäß Spezifikation sowohl durch interne als auch externe Ressourcen gestellt werden.
Ziel 3: Wahrnehmen der FOSS-Aufgaben
Das dritte Ziel widmet sich der Dokumentation der erzeugten Software, bzw. der eingesetzten Artefakte. Der Prozess, um eine Stückliste (Bill of Materials, kurz BoM) zu erzeugen, sollte hinreichend qualifiziert und dokumentiert sein. Qualifiziert bedeutet, dass der Prozess sich dazu eignet, die tatsächlich eingesetzten Komponenten aufzuzeigen und sicherzustellen, dass diese Information auch im BoM auftaucht.
Das soll jedoch nicht nur einmalig zu einem Zeitpunkt passieren, sondern muss kontinuierlich für jedes Release erfolgen. Insbesondere im Zuge von Continuous Deployment entsteht hieraus eine erhebliche Verpflichtung für die Aktualität und die Archivierung der Dokumentation, bzw. der BoMs. Eine manuelle Durchführung ist im hier nicht mehr denkbar.
TrustSource kann hier optimal unterstützen. Durch die Integration mit den Entwicklungswerkzeugen lässt sich zu jedem Zeitpunkt ein BoM erzeugen. Die einzelnen Versionen lassen sich speichern und archivieren. Durch den „Freeze Release“ Mechanismus können bestimmte Versionen gezielt via API exponiert bzw. als SPDX exportiert werden. Ein aktuelles BoM ist somit stets gegeben.
Die Spezifikation macht keine Vorgaben bezüglich der Inhalte eines BoM. Jedoch hat im Kontext der Linux-Foundation die Arbeitsgruppe SPDX - Software Package Data Exchange - Vorgaben für die Lizenzdokumentation einer Anwendung erarbeitet. Diese lösen das Problem nicht abschließend, bilden jedoch eine gute Grundlage für eine technische Dokumentation.
Das Erstellen des BoM allein reicht jedoch nicht aus, um einen sicheren Umgang mit FOSS zu gewährleisten. Je nach Anwendungsfall können die Bestimmungen der inzwischen gut 396 bekannten Lizenzen unterschiedliche Verpflichtungen auslösen. So spielen der Einsatzzweck, die Art der Kommerzialisierung oder auch die Form der Distribution eine erhebliche Rolle bei der Identifikation der zu erfüllenden Verbindlichkeiten oder der ausgelösten Pflichten.
Das ist insbesondere deshalb wichtig, weil einige Lizenzen bei Nichterfüllung der Verbindlichkeiten oder Pflichten das Nutzungsrecht entziehen. In anderen Worten: Das Recht zur Nutzung der Komponente erlischt, wenn die Verpflichtungen nicht erfüllt werden. Und der Einsatz ohne Nutzungsrecht im kommerziellen Kontext, ist kein Kavaliersdelikt mehr.
OpenChain fordert daher, dass eine rechtliche Prüfung stattfindet, welche Verbindlichkeiten und Verpflichtungen in dem jeweiligen Einsatzszenario zu erfüllen sind, um eine rechtskonforme Anwendung im jeweiligen Szenario sicherzustellen.
Hier spielt TrustSource seine besondere Stärke aus. Durch Kenntnis der Bedingungen und Verpflichtungen aus mehreren hundert Lizenzen und einer strukturierten Erfassung des rechtlichen Kontextes kann die TrustSource Regel-Engine die Bedingungen für die Nutzung automatisiert fallspezifisch ableiten und somit als List of Obligations für eine Abarbeitung zur Verfügung stellen.
Ziel 4: FOSS Compliance Artefakte bereitstellen
In dem vierten Ziel geht es darum, dass die Compliance Artefakte nicht nur erzeugt, sondern auch mit der erzeugten Software ausgeliefert werden. Es ist also sicherzustellen, dass die Artefakte vollständig und Teil der Software sind.
TrustSource unterstützt dies durch die Bereitstellung eines SPDX Dokuments des entsprechenden Moduls oder Projektes. Zukünftig wird neben dem SPDX auch ein komplettes Notice-File kompiliert und bereitgestellt.
Um rechtlich konform zu agieren, ist es erforderlich, Revisionssicherheit herzustellen. Das bedeutet, alte Versionen sind zumindest solange aufzuheben, bis sichergestellt ist, dass keine alte Version mehr im Umlauf ist. Das ist erforderlich, damit sich Fragen zu einem älteren Versionsstand auch auf einer gesicherten Dokumentenlage beantworten lassen.
TrustSource kann die Information zu allen in TrustSource erzeugten Version jederzeit wieder bereitstellen.
Auf dieser Basis ist es stets möglich, zu identifizieren, welche Komponenten wo eingesetzt wurden und unter welchen Bedingungen. Einerseits macht Dokumentation angreifbar, da auch dokumentiert ist, was nicht getan wurde. Andererseits führt es aber auch zu der Sicherheit, tatsächlich alles Erforderliche unternommen zu haben, um Rechtssicherheit herzustellen. Fehler sollten bei einem solchen Vorgehen rechtzeitig aufgedeckt werden können.
Ziel 5: Verstehen der Community-Verpflichtungen
Open Source ist keine Einbahnstraße. Man sollte nicht nur nehmen, alle Nutzer von Open Source sind eigeladen, auch mitzugestalten. Dies geschieht über Mitarbeit in den open Source Projekten, sogenannten Contributions.
Hierzu werden üblicherweise für ein Engagement hausinterne Ressourcen für das Open Source Projekt abgestellt, die entweder ganz oder teilweise an dem Projekt mitarbeiten. Je nach Intensität kann dies auf gelegentlicher Basis in Form von Bugfixes oder freiwilligen Ergänzungen oder aber als definierte Abordnung zum Kern des Projektes erfolgen. Je nach Intensität eröffnet es dem beitragenden Unternehmen Einfluss auf die Gestaltung des Produktes. Es ist auch denkbar, dass das Unternehmen ein eigenes Open Source Projekt ins Leben ruft.
Ob gelegentlich oder gezielt und strukturiert, welche Form auch immer gewählt wird, die Beiträge sind klar zu regeln. Dabei geht es um rechtliche Fragen wie Trennung von Arbeitszeit und Freizeit, Ansprüchen und Rechten aus den Beteiligungen sowie dem Prozess, zur Bereitstellung von Beteiligungen.
Das fünfte Ziel nimmt sich dem Thema des Rückspielens in die Open Source Community an und verlangt, dass es eine Policy gibt, welche den Umgang bzw. die Beiträge zu Open Source Projekten regelt. Analog zur Regelung für den Einsatz von Open Source im Unternehmen, ist auch hier auch für die hinreichende Verbreitung und Bekanntheit der Regelungen zu sorgen.
Auch die Regelung zur Beteiligung an Open Source Initiativen kann mit Hilfe der gleichen Mechanismen wie die Unterstützung zu G1 genutzt werden. Auch für die Gestaltung von Beiträgen bietet TrustSource eine Sample-Policy als Grundlage.
Es kann sein, dass die Regelung eine Beteiligung an Open Source Projekten verbietet. Für diesen Fall ist nur die Bekanntheit des Verbotes zu propagieren. Aus unserer Erfahrung bietet sich ein Verbot jedoch nicht an. Sobald ernsthaft Open Source eingesetzt wird, ist mit Fehlern in der eingesetzten Software zu rechnen. Diese aufgrund eines Verbotes für Beiträge nicht beheben zu können, wäre fahrlässig.
Es ist demnach ein Governance Prozess für die Beiträge zu definieren. Im Idealfall unterscheidet sich dieser nicht wesentlich von dem für eigene Produkte, um es für alle Beteiligten einfach in der Handhabung zu machen.
TrustSource stelle eine für beide Einsatzformen einheitliche Plattform mit umfangreichen Werkzeugen für die Prozessunterstützung zur Verfügung.
Ziel 6: Bestreben, die Konformität zu zertifizieren
Das sechste Ziel fordert die Bereitschaft der Organisation die Umsetzung der Anforderungen aus den Zielen 1-5 zu bestätigen. Dies ist derzeit mit Hilfe eines Self-Audits möglich. Die Webseite der OpenChain bietet hierzu einen Fragebogen und entsprechende OpenChain-Partner unterstützen die Umsetzung.
TrustSource bietet eine geeignete Plattform, um die Prozesse sicherzustellen. Dies ist bei den einschlägigen Parteien bekannt und vereinfacht die Klärung der Prüfungen.
Zusammenfassung
Zusammenfassend lässt sich erkennen, dass der unternehmensweite Einsatz von TrustSource einen Großteil der Komplexität einer OpenChain-konformen Ausrichtung einer auch größeren Organisation erheblich reduzieren kann. Es bleibt aber auch festzuhalten, dass OpenChain die Einführung von Prozessen und die Veränderung von Abläufen erfordert. Dies ist immer ein aufwändiges Unterfangen, das Zeit und Fokus erfordert.
Wir empfehlen daher, den Scope gezielt zu wählen. Es mag durchaus sinnvoll sein, nicht gleich auf Konzernebene mit der Einführung anzufangen, sondern sich zunächst auf einen einzelnen Entity zu konzentrieren. Mit den Erfahrungen und Erfolgsgeschichten lässt sich die Einführung in einem zweiten Bereich wesentlich schneller erreichen.
Auch hier kann TrustSource in der Enterprise-Version mit der Multi-Entiy-Option helfen. Diese ermöglicht es, einzelne Einheiten/Bereiche in einem Konto zusammenzufassen und übergreifend zu administrieren, jedoch mit bereichsspezifischen Policies oder Black- und White-listen zu versehen.
Auch für Unternehmen, die bereits in eineigen Bereichen andere Scanning-Werkzeuge nutzen, kann TrustSource zur Vereinheitlichung der Ergebnisse dienen. Durch die Möglichkeit, Scan-Ergebnisse an das TrustSource-API zu übermitteln bzw. SPDX-Dokumente zu importieren, kann TrustSource das Bindeglied über mehrere, ggf. bereits existierende, bereichsspezifische Werkzeuge dienen. Somit lässt sich die Prozesskonformität und somit eine einheitliche Governance unternehmensweit sicherstellen.
OpenChain in a nutshell
In den letzten Wochen erhalten wir immer öfter Anfragen zu OpenChain. Was ist das? Ist das wichtig?
Daher wollen wir hier eine kurze Zusammenfassung geben. Wer mehr darüber wissen möchte, ist herzlich eingeladen, uns direkt zu kontaktieren.OpenChain ist ein Projekt der Linux Foundation, welches sich zum Ziel gesetzt hat, das Vertrauen in den Einsatz von Open Source Software zu stärken. Hierzu hat die OpenChain einen Satz anAnforderungen entwickelt, deren Einhaltung den nachhaltigen Umgang mit Open Source sicherstellen.
„Open Source Komponenten einer OpenChain zertifizierten Organisation kann man vertrauen“
Die Spezifikation der Anforderungen ist öffentlich und kann auf der Webseite der OpenChain heruntergeladen werden. Sie definiert sechs Ziele, die sich wiederum in zehn wesentliche Anforderungen herunter brechen lassen. Besonders an der Spezifikation ist, dass Sie nicht nur die Anforderungen definiert, sondern auch Kriterien, welche das Erreichen der Anforderung sicherstellen.
Nachstehende Abbildung fasst die gesamte Spezifikation auf einer Seite zusammen. Bitte beachten Sie, dass für diese Darstellung einige inhaltliche Kürzungen erfordelrich waren. Um die Grundgedanken der Spezifikation zu verstehen, ist die Übersicht jedoch hinreichend.
Was bedeutet das im Allgemeinen?
Mit der Spezifikation ist ein erster Ansatz geschaffen, eine neue Orientierung im Umgang mit Open Source zu geben. Zwar ist es derzeit so, dass kaum eine Organisation ohne Open Source auskommt, dennoch behandeln die meisten Open Source noch recht stiefmütterlich. Das wiederum führt dazu dass die Nutzung von Open Source selbst aber auch die Nutzung von Produkten immer wieder rechtliche Probleme aufwirft.
Die Spezifikation ist dafür geeignet, einen nachhaltigen Umgang mit Open Source zu erzeugen. In größeren Organisationen, die es gewohnt sind, Vorgänge zu strukturieren, gewinnt diese Ansicht bereits an Akzeptanz. Es ist davon auszugehen, dass sich diese Erkenntnis auch mittelfristig im Einkauf der großen Organisationen durchsetzen und somit das Vorgehen an Bedeutung gewinnen wird.
Was bedeutet das für mich?
Wenn Sie Software erzeugen und oder diese an Dritte ausliefern, sollten Sie sich mit den Anforderungen der OpenChain vertraut machen. Die Wahrscheinlichkeit, dass der nächste Abnehmer eine OpenChain-Zertfizierung verlangt ist nur eine Frage der Zeit. Der Prozess zur Zertfiizierung ist ein langer Prozess, der sich nicht in wenigen Wochen erzwingen lässt. Daher ist eine frühzeitige Beschäftigung mit dem Thema zu empfehlen.
Holen Sie sich die Übersichtsgrafik als Poster!
Wenn Sie mehr bezüglich der OpenChain Zertfizierung derzeit eine Zertfizierung im Selbst-Zertfizierungsformat – benötigen, finden Sie diese auf der Webseite der OpenChain unter OpenChain/conformace.
Wenn Sie Kontakt zu uns zur Klärung von Fragen einer OpenChain-Zertifizierung aufnehmen wollen, können Sie uns hier kontaktieren.
Wenn Sie erfahren wollen, wie TrustSource Ihnen bei der Ausrichtung nach OpenChain hilft, lesen Sie hier mehr.
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.