Open-Source-Compliance

Open-Source-Compliance ist ein Thema, dass viele Unternehmen wahrscheinlich nicht so richtig auf dem Schirm haben. Nach unserer Erfahrung jedenfalls, wird dieses Thema oft nicht so richtig beachtet. Seine praktische Bedeutung wird dadurch aber nicht weniger. Fast jedes Unternehmen setzt heute Open Source-Software ein. Dabei bedeutet “open” nicht gleich frei. Open-Source-Software ist nicht frei von Rechten. Die Nutzung darf – je nach Lizenz –  nur unter bestimmten Stattfinden.   ein Verstoß gegen die Lizenzbedingungen kann doch aus spürbare Folgen haben.   Wenn ihr Open-Source-Software unerlaubt nutzt stellt dies in der Regel eine Urheberrechtsverletzung dar. Hier drohen euch im schlimmsten Fall Unterlassungsansprüche bis hin zu Schadensersatz.

Was ist Open-Source-Compliance?

Unter Compliance ganz allgemein verstehen wir allgemein im Grunde nichts anderes als die Einhaltung von Gesetzen, Richtlinien und freiwilligen Verhaltensregeln.

Uns geht also im Grunde darum wie wir bestimmte Regeln und gesetzliche Vorschriften im Unternehmen sicher umsetzen und einhalten können. Damit das Ganze kein zahnloser Tiger bleibt der nur auf dem Papier existiert müssen wir bestimmte organisatorische Maßnahmen zur Umsetzung der Verhaltensregeln treffen. Open Source Compliance ist dabei regelmäßig ein Bestandteil der IT compliance. 

Warum brauchen wir ein Open-Source-Compliance-System

Es gibt keine gesetzliche Vorschrift die euch verpflichtet ein Open-Source-Compliance-System einzusetzen. Für größere Unternehmen können sich indirekt Verpflichtungen aus allgemeinen Sorgfaltsregelungen wie den §§ 76 Abs. 1, 91 Abs. 2, 93 Abs. 1 AktG, § 43 GmbHG ergeben. Wie detailliert Euch diese Regeln tatsächlich zum Aufbau einer Open Source Compliance verpflichtend wahrscheinlich auch von der Größe eures Unternehmens ab. 

Unabhängig von konkreten gesetzlichen Verpflichtung ist das Ziel 1 Open Source compliance die Verhinderung von Rechtsverstößen.  daran sollte euch ganz unabhängig von etwaigen gesetzlichen Pflichten so oder so gelegen sein. Ich hatte oben bereits angedeutet dass der Einsatz von Open Source Software ohne entsprechende Lizenz eine Urheberrechtsverletzung darstellen kann. Das gilt nicht nur, wenn ihr proprietäre Software unter Einsatz von Open Source Software erstellt. Es kann euch auch treffen wenn ihr Software mit Open-Source-Software Komponenten lediglich einsetzt. Ein Verstoß gegen die Lizenz kann dazu führen, dass das Nutzungsrecht erlischt. Im schlimmsten Fall begeht ihr dann bereits mit der Installation eine Urheberrechtsverletzung. Als Programmierer kann der fahrlässige Einsatz von Open-Source-Software ohne entsprechende OSC dazu führen, dass ihr verpflichtet seid den Quellcode offen zu legen. Aber auch für die Einräumung der Rechte an der Software spielt das Thema eine Rolle. Wenn euer Softwareprojekt vorsieht, dass der Kunde die ausschließlichen Nutzungsrechte an dem Projekt erhält, kann der Einsatz von Open-Open-Source-Software  ein unangenehmer Showstopper sein. 

Welche Konsequenzen drohen hängt einerseits stark von der jeweiligen Lizenz ab. Andererseits kommt es auch wirklich darauf an wie leicht Verstöße entdeckt werden können.  Hier solltet ihr aber nicht auf Risiko spielen.  insbesondere dann wenn euch bewusst ist, dass ein Problem besteht. Vorsätzliche Urheberrechtsverletzung können nämlich sogar strafrechtlich relevant sein.

Einzelheilen

Für die konkrete Ausgestaltung eines Open-Source-Compliance System kommt es auf eure individuellen Bedürfnisse. Hier spielt bereits die Frage eine Rolle, ob ihr reiner Nutzer von Software seit oder Programmierer. Auch die Größe eures Unternehmens und die Branche in der ihr Tätig seit kann bei der Ausgestaltung eine Rolle spielen.

Erwerber und Nutzer von Software

Wir hatten es bereits mehrfach erwähnt. Auch als Bluse erwerbe oder Nutzer von Software kann der Einsatz von Open-Source-Software problematisch sein. Bereits die Installation einer Software im ID System stellt in der Regel eine Vervielfältigung da. Hierfür benötigt ihr entsprechende Nutzungsrechte Punkt liegen diese nicht vor, weil z.b. gegen die USS Lizenz verstoßen würde begeht er eine Urheberrechtsverletzung. Bereits aus diesem Grund sollte euch also daran gelegen sein das Thema sauber zu behandeln. Weitaus größere Probleme könntet ihr bekommen, wenn ihr umfassende Rechte an der Software benötigt.   nehmen wir an, dass er ein Softwareprojekt individuell beauftragt. Ihren benötigt er ausschließliche Nutzungsrechte, weil wir das fertige Projekt gegebenenfalls weiterveräußern  wollt. Open-Source-Software können hier der Showstopper sein. Viel Lizenzen verbieten das Einräumen von ausschließlichen Nutzungsrechten. Werden solche Komponenten eingesetzt und werden sich über einen Copyleft auf eure Software aus, kann euch der Programmierer keine ausschließliche Nutzungsrechte einräumen.  

Programmierer

 Aus denselben Gründen sollten auch Programmierer peinlich genau darauf achten welche Open-Source-Software eingesetzt wird. Wenn ihr als Programmierer ausschließliche Nutzungsrechte zusichert, diese aber nicht einräumen dürft, macht ihr euch gegebenenfalls schadensersatzpflichtig. Darüber hinaus gibt es bestimmte Copyleft Lizenzen die euch im Grunde dazu verpflichten oder Softwareprojekt unter die selben Bedingungen zu stellen wie auch die verwendete Open-Source-Software. Das kann etwa beim Einsatz von Komponenten unter einer GPL-Lizenz schnell passieren. In diesem Fall seid ihr verpflichtet euer Projekt unter diese Lizenz zu stellen. Dabei seit ihr in der Regel auch verpflichtet euren Source-Code offenzulegen; eine Katastrophe für den Know-how-Schutz. 

Werden mehrere unterschiedliche Lizenzen nebeneinander eingesetzt müsst ihr zudem prüfen, ob diese Lizenzen miteinander kompatibel sind. Denn weil sich die Bedingungen gegenseitig ausschließen, vertragen sich viele Lizenzen nicht mit anderen Lizenzen. Auch das kann zu massiven Problemen führen.

Open-Source-Leitlinie

Für eine vernünftige Open-Source-Compliance solltet ihr in jedem Fall eine entsprechende Leitlinie oder Policy erstellen. Die genauen Anforderungen sind abhängig von eurem Unternehmen. Die Unterscheidung beginnt schon je nachdem ob ihr die Software lediglich nutz oder selbst Software unter Einsatz von Open-Source-Software erstellt. Ein paar Punkte sollten unabhängig davon dennoch nicht fehlen.

Es sollte ein Prozess etabliert werden, unter welchen Bedingungen Open-Source-Software zum Einsatz kommt. Das können zum Beispiel Regelung über den Anschaffungs- und Prüfprozess sein und über die Installation neuer Software. 

Dabei sollte Auch festgelegt werden, welche Software verwendet wird. das ganze sollte in einem entsprechende Verzeichnis festgehalten werden.

Die verwendeten Lizenzen sollten ebenfalls notiert werden mitsamt der Eigenschaften der jeweiligen Lizenz. Hier helfen euch Lizenz-Playbooks die Eigenschaften der gängigsten Lizenzen zusammenfassen und Matrizen zur Veranschaulichung der Kompatibilität. 

Mitarbeiterschulungen

Die beste Open-Source-Compliance Strategie nützt nichts, wenn eure Mitarbeiter nicht bescheid wissen. Daher sollten betroffene Mitarbeiter auf jeden Fall im Umgang mit Open-Source-Software geschult und für das Thema sensibilisiert werden. Betroffen sind dabei grundsätzlich alle eure Mitarbeiter die an der Erstellung der Software mitwirken. Betroffen sind aber auch Mitarbeiter die Software beschaffen und installieren. Eure Mitarbeiter werden wahrscheinlich nicht selbst prüfen, ob eine Open-Source-Software eingesetzt werden kann. Mit einer entsprechenden Sensiblisierung wird aber überhaupt erstmal erkannt, dass es ein Problem geben kann. Das ist ein erster Schritt. 

Open-Source-Scanner

Am Anfang müsst ihr euch fragen, ob ihr überhaupt Open-Source-Software verwendet. Diese Frage könnt ihr sicherlich noch recht einfach beantworten, wenn ihr die Software selbst herstellt. Ihr werdet in der Regel wissen, welche Komponenten und Bibliotheken ihr einbindet. Sofern ihr hier auf Subs oder Freelancer zurückgreifen solltet ihr sicherstellen, dass diese ebenfalls compliant arbeiten. Das Ganze solltet ihr zumindest vertraglich abgesichert. Zudem solltet ihr die Arbeit auch tatsächlich überprüfen.  

Schwieriger wird es wenn ihr eine fertige Software nutzt. Aus dem fertigen Programm kann man in der Regel nicht erkennen, ob Open-Source-Software eingebunden ist. Die Dekompilierung hilft hier – sofern zulässig – vielleicht auch nicht oder nur begrenzt. Die Lösung kann hier in sogenannten Open-Source-Scannern liegen. Diese Scanner prüfen Software auf Open-Source-Software Elemente und helfen euch die Bestandteile auf die verwendeten Lizenzen zu kategorisieren.

Die Scanner helfen euch aber auch, wenn ihr Software selbst programmiert. Hier können die Scanner unterstützen und Handlungsmöglichkeiten aufzeigen.  

Vertragliche Regelungen 

Neben internen Maßnahmen sollten für eine vernünftige OSC auch vertragliche Regelungen mit Dritten getroffen werden. Je nachdem in welcher Rolle ihr agiert, müssen diese natürlich unterschiedlich ausgestaltet werden. 

Als Erwerber oder Nutzer von Software solltet ihr sicherstellen, dass der Programmierer open-source-compliant arbeitet. Als Programmierer solltet ihr mit Subs oder anderweitigen Lieferanten von  Komponenten entsprechende Regelungen treffen. Solche Regelungen sind aber im Zweifel kein Freifahrtsschein. Es gibt durchaus Rechtsprechung, die durch den Erwerber von Nutzungsrechten eine lückenlose Aufklärung der Rechtekette verlangt.  Die Berufung auf Aussagen des Veräußerers nicht ausreichen lässt (LG München I, Urteil vom 15.11.2006, Az.: 21 O 506/05; BGH, Urteil vom 28.10.1987, Az.: I ZR 164/85)

Umgekehrt solltet ihr dem Kunden umfassend aufklären, ob und welche Open-Source-Software Komponenten eingesetzt werden. Das solltet ihr frühzeitig machen, da hiervon auch die Frage der Einräumung von Nutzungsrechten abhängt. Wenn ihr dem Kunden zusichert, dass er ein ausschließliches Nutzungsrecht erhält und das am Ende nicht einhalten könnt, kann das fatale Folgen haben. 

Wirkung nur zwischen den Parteien

Vertragliche Regelungen sind nützlich und sinnvoll. Euch muss aber bewusst sein, dass diese nur euch den Vertragspartner binden.Nehmen wir an, dass euch der Programmierer zusichert keine Open-Source-Software Komponenten einzusetzen. Tatsächlich macht er aber doch. Dabei hält er sich nicht an die Lizenzbestimmungen der Open-Source-Software. Hierdurch kann das Nutzungsrecht erlöschen. Wenn ihr die software jetzt nutzt, kann es passieren, dass ihr damit eine Urheberrechtsverletzung begeht. Die Absprache mit dem Programmierer schützt euch also nicht unbedingt vor den Ansprüchen Dritter. Aufgrund der vertraglichen Absprache könnt ihr zwar im Zweifel Schadensersatz beim Vertragspartner geltend machen. Das hilft euch aber erstens nicht beim Ärger mit Lizenzgeber der Open-Source-Software. Und Zweitens hilft es nur solange der Vertragspartner liquide ist. 

Fazit

Das Thema OSC haben viele Unternehmen noch immer nicht wirklich auf dem Schirm. Seiner praktischen Relevanz tut das aber keinen Abbruch. Ähnlich wie das Thema Datenschutz dürfte es – um ehrlich zu sein – für viele ein nerviges Thema sein. Mit zunehmender Verbreitung von Open-Source-Software wird das Thema aber immer präsenter. Gerade als Hersteller von Software solltet ihr das Thema nicht auf die leichte Schulter nehmen und euch besser früher als später damit beschäftigen. 

Mehr zum Thema:

Artikel: Einführung zum Thema Open Source: “Open Source Software – offen aber nicht frei”

Artikel: Open Source Compliance Handbuch

Artikel: Open Source Policy Examples and Templates