Jusletter IT

Umgang mit Open Source Software im Unternehmen

  • Author: Katharina Bisset
  • Category: Articles
  • Region: Austria
  • Field of law: IP Law
  • Collection: Conference Proceedings IRIS 2015
  • Citation: Katharina Bisset, Umgang mit Open Source Software im Unternehmen, in: Jusletter IT 26 February 2015
Ob man als Unternehmen Software verwendet oder diese verkauft – früher oder später stellt sich die Frage nach der Verwendung von Open Source Software (OSS). Diese bietet oft die Möglichkeit, intern oder in der Softwareentwicklung Kosten zu sparen. Als IT-Leiter, Produktmanager oder Programmierer stellt sich die Herausforderung, unter welchen Bedingungen und zu welchem Zweck man OSS im Unternehmen einsetzen kann.

Inhaltsverzeichnis

  • 1. Open Source Software (OSS) im Unternehmen 
  • 1.1. Warum OSS?
  • 1.2. Praktische Fragen und Probleme
  • 1.3. Die Open Source Lizenz
  • 2. Nutzung von OSS 
  • 2.1. Interne Nutzung
  • 2.2. Nutzung in Kundenprojekten
  • 2.3. Rechtliche Auswirkung in Kundenprojekten
  • 3. Umgang mit OSS 
  • 3.1. Audits und Prozesse
  • 3.2. Datenbanken
  • 3.3. Umgang mit OSS in Kundenprojekten
  • 4. Conclusio 

1.

Open Source Software (OSS) im Unternehmen  ^

1.1.

Warum OSS? ^

[1]

Als OSS wird landläufig Software(-komponenten) bezeichnet, welche kostenlos im Internet inklusive Source Code zum Download zur Verfügung steht. Die Open Source Initiative hat sich als nonprofit Organisation zum Ziel gemacht, die Definition von OSS zu verwalten und wird von der OSS Community anerkannt, um neue OSS Lizenzen zu überprüfen und zu genehmigen.1 Mit der Nutzung stimmt man den beigelegten Lizenzbedingungen zu und unterwirft sich diesen auch für eine weitere Verwendung der Software. OSS wird sowohl von Unternehmern als auch Privatpersonen immer mehr genutzt. Die Vorteile liegen primär in der Kostenersparnis und der Möglichkeit, die Software nach eigenen Vorstellungen zu modifizieren. Es ist für einen Programmierer wesentlich einfacher, bestehende Softwarekomponenten als OSS aus dem Internet herunterzuladen, als selbst neu zu programmieren. Darüber hinaus gibt es für viele OSS eine Community im Internet, welche an der ständigen Verbesserung und Erweiterung der Software arbeitet.

[2]
Für Softwareentwickler ist es auch eine übliche Vorgehensweise, OSS in der eigenen Arbeit zur verwenden. Diese stellt eine große Arbeitserleichterung dar, da es viele Standardkomponenten als OSS gibt, und das sprichwörtliche Rad nicht neu erfunden werden muss.

1.2.

Praktische Fragen und Probleme ^

[3]
Die erste Frage bei einer Nutzung ist immer, genauso wie bei kommerzieller Software, unter welchen Bedingungen OSS verwendet werden kann, ob und allenfalls in welchem Ausmaß diese weitergegeben werden kann. Hinter einer OSS steht meist kein Softwareunternehmen, welches Wartung oder Support anbietet, sondern eine Online Community, welche nicht für das Funktionieren der Software einsteht. Es gibt auch keine Garantie, dass OSS für neue Betriebssysteme aktualisiert wird oder mit neuer Hardware funktioniert. Darüber hinaus kann OSS auch ein Sicherheitsrisiko darstellen, wenn diese nicht von der Community regelmäßig aktualisiert wird.
[4]
Bei der Bearbeitung und Weitergabe muss erneut geprüft werden, welchen Lizenzbedingungen die OSS unterliegt oder unterliegen kann. Bei kommerzieller Software werden genau diese Punkte in der Regel bereits beim Kauf geprüft, da diese mit für die Kaufentscheidung verantwortlich sind.
[5]
Wird in der Software-Entwicklung mit OSS gearbeitet, ist es oft die Entscheidung eines Programmierers, diese zu verwenden. Da dem Unternehmen keine direkten Kosten entstehen, gibt es vielmals keinen Freigabeprozess, der durchlaufen werden muss, um OSS zu verwenden. Nun können aber gerade die Lizenzbedingungen einer OSS – werden diese in einem Kundenprojekt verwendet – auf dieses einen großen Einfluss haben.

1.3.

Die Open Source Lizenz ^

[6]
OSS wird immer mit dazugehöriger Lizenz angeboten, damit die weitere Nutzung klar geregelt ist.2 Sie muss jedoch einige Voraussetzungen erfüllen, um als Open Source zu gelten. Der Source Code muss offengelegt werden, die Software muss vom Lizenznehmer beliebig bearbeitet, genutzt und weitergegeben werden können.3
[7]
Die genaue Ausprägung der Lizenz kann oft verschieden sein, aber die Grundidee bleibt dieselbe. Die größten praktischen Unterschiede liegen in den Fragen, ob die bearbeitete OSS wieder der Community zur Verfügung gestellt werden muss, ob die OSS Lizenz bei Weitergabe der Software ebenfalls weitergegeben werden muss (d.h. auch nicht einschränken kann) und ob man bearbeitete OSS kommerziell verwerten kann. Von großer praktischer Bedeutung ist auch die Frage, ob und wie weit bestehende Software bei Verknüpfung mit OSS deren Lizenz übernehmen (müssen).
[8]
Hier reicht das Spektrum von strengen Copyleft Lizenzen (wie die GNU General Public License4) deren Ziel es ist, dass sich die Lizenzbedingungen der OSS nicht ändern, zu freizügigen OSS Lizenzen (wie MIT Lizenz5), bei denen auch eine Einschränkung möglich ist.

2.

Nutzung von OSS  ^

2.1.

Interne Nutzung ^

[9]
Für viele Unternehmer ist eine interne Nutzung von OSS eine gelebte alternative zu kommerzieller Software. In Unternehmen, in denen Mitarbeiter Software relativ frei auf ihren Dienstcomputern installieren können, greifen diese oft zu kostenloser Software, um sich die Arbeit zu erleichtern. Gerade aus Sicherheitsgründen wird jedoch die Softwarenutzung auf Dienstcomputern oft stark eingeschränkt, was auch die Nutzung von OSS beinhaltet.
[10]
Aus rechtlicher Sicht treten bei interner Nutzung von OSS am wenigsten praktische Probleme auf, da diese die freie Nutzung erlauben, nicht weitergegeben und nur für interne Zwecke verwendet wird.

2.2.

Nutzung in Kundenprojekten ^

[11]
Wird OSS bei der Softwareentwicklung verwendet, ist vielmals kaum Kontrolle oder Protokollierung der genutzten Komponenten gegeben. Softwareentwickler finden Hinweise zu neuer und innovativer OSS meist online, in Foren und durch andere Entwickler. Wie Eingangs erwähnt, erleichtert OSS das Programmieren und lässt Entwickler effizienter arbeiten.
[12]
Hier ist es aber, wo Unternehmen in der Praxis das größte Risiko bei der Nutzung von OSS haben, da oft nicht klar ist, welche OSS in einem Kundenprodukt verwendet wurde und es keinen Prozess gibt, welcher die Nutzung bereits beim Entwickler protokolliert und überprüft.

2.3.

Rechtliche Auswirkung in Kundenprojekten ^

[13]
Die Auswirkung, welche die falsche Verwendung von OSS im Kundenprojekt haben kann, lässt sich am besten an einem Beispiel festmachen.
[14]

Der Unternehmer und sein Kunde schließen einen Vertrag über die Erstellung einer Software ab, an welcher der Kunde das Werknutzungsrecht (also exklusiv alle Rechte) erhalten soll. Die Spezifikationen werden an die Softwareentwicklung weitergegeben. Der Softwareentwickler weiß, für einen großen Teil der Kundensoftware gibt es OSS, welche «nur» verändert und mit anderen Komponenten zusammengefügt werden muss. Auch Bearbeitungen müssen unter den Lizenzbedingungen der OSS weitergegeben werden und der bearbeitete Source Code muss darüber hinaus der Community zur Verfügung gestellt (im Internet veröffentlicht) werden.

[15]
Das bedeutet nun rechtlich, dass die Lizenz nicht-exklusiv ist und ebenso weitergegeben werden muss, d.h. der Kunde nicht die Rechte an der Software erhält, welche vertraglich vereinbart waren. Gerade bei exklusiven Entwicklungen für einen Kunden bezahlt dieser gerade auch für die Tatsache, dass der Unternehmer (Hersteller) die Software nicht erneut verkaufen kann. Es kämen hier zum Beispiel Gewährleistungsansprüche des Kunden in Frage.
[16]
Der Urheber der OSS hätte ebenso Ansprüche gegen den Unternehmer, wenn der bearbeitete Source Code nicht veröffentlicht wird und gegen die Lizenzbedingungen verstoßen wurde. Da OSS meist mehrere Urheber hat, reicht die Klage eines einzelnen bereits aus, um den Verstoß zu verfolgen.6

3.

Umgang mit OSS  ^

3.1.

Audits und Prozesse ^

[17]
Der Wichtigste Schritt für einen sicheren Umgang mit OSS im Unternehmen ist die Schaffung von Awareness – in der Führungsebene, bei den Mitarbeitern und natürlich auch bei den einzelnen Entwicklern. Die Risiken müssen bekannt sein, ohne dass die Entwickler alles neu programmieren müssen (ohne die Verwendung von OSS).
[18]

Praktisch umgesetzt heißt das, es muss erst sichergestellt werden, dass bisher keine OSS genutzt wurde, welche dem Unternehmen nicht bekannt war und deren Lizenzbedingungen noch nicht geprüft wurden, und dass die Nutzung in Zukunft kontrolliert wird.

[19]
Für ein Audit bestehender Software gibt es kommerzielle Anbieter7, welche Source Code auf OSS Komponenten durchsuchen, und das Ergebnis mit dazugehöriger Lizenz berichten können. Es ist auch möglich, ein derartiges Tool selbst zu entwickeln. Hier können dann auch selbst entwickelte Komponenten, welche wiederverwendet werden, gefunden werden.
[20]
Will ein Mitarbeiter OSS auf seinem Firmenrechner installieren, sollte dies von der internen IT schon aus Sicherheitsgründen vor der Nutzung geprüft und freigegeben werden.
[21]
Im Software-Entwicklungsprozess müssen die Entwickler wissen, dass die Verwendung von OSS freigegeben werden muss und wie er mit dieser umgehen muss. Er muss bereits beim Programmieren wissen, ob Copyright-Vermerke im Code beibehalten werden müssen oder ob OSS anstatt in bestehende Software eingebaut nur verlinkt werden muss. Er muss auch die Möglichkeit haben, neue OSS intern prüfen zu lassen, damit er diese möglichst schnell verwenden kann.

3.2.

Datenbanken ^

[22]

Die Ergebnisse der Analysen und regelmäßigen Meldungen von OSS müssen jederzeit zugänglich sein. Der Unternehmensjurist muss die Möglichkeit haben, zu wissen, welchen Lizenzen ein Produkt unterliegt, um beurteilen zu können, ob dies rechtlich den Wünschen der Kunden entspricht. Der Entwickler kann OSS schneller verwenden, wenn es bereits eine Liste der freigegebenen Komponenten gibt.

[23]
Am leichtesten kann dies durch eine Datenbank erreicht werden, in denen Produkte mit beinhalteter Software und dazugehöriger Lizenz verwaltet werden.

3.3.

Umgang mit OSS in Kundenprojekten ^

[24]

Gerade in öffentlichen Ausschreibungssituationen gibt es für den Unternehmer oft wenig Spielraum, die Wünsche des Kunden an Nutzungsrechten zu ändern oder zu verhandeln. In der Praxis gibt es jedoch immer mehr Kunden (privat und öffentlich), welche Open Source Software in der Definition der Nutzungsrechte berücksichtigen. Eine Offenlegung der verwendeten OSS und dazugehöriger Lizenzen ist jedoch jedenfalls notwendig. Diese Liste wäre auch bei einer Escrow-Hinterlegung der Software nötig, da insbesondere spezialisierte Software-Escrow-Anbieter eine dahingehende Offenlegung verlangen.

[25]
Sind die gewünschten Nutzungsrechte ohne Berücksichtigung von OSS definiert, müssen alle anwendbaren Lizenzen des Produktes bekannt sein, um einen rechtskonformen Vertrag zu ermöglichen.

4.

Conclusio  ^

[26]

Die Nutzung von OSS ist heutzutage sowohl bei Entwicklern als auch anderen Computernutzern weit verbreitet. Durch den Kostenfaktor und das weitreichende Angebot von OSS sind diese aus der täglichen IT-Arbeit nicht mehr wegzudenken. Der Kostenfaktor darf jedoch nicht davon ablenken, dass trotzdem Nutzungsrechte beachtet werden müssen, deren Verstoß rechtliche Folgen nach sich ziehen können. Dies kann in der Praxis von Gewährleistungsansprüchen des Kunden reichen, welchem man nicht die vereinbarten Nutzungsrechte geliefert hat, bis zu urheberrechtlichen Ansprüchen des OSS Rechtehalters, dessen Rechte verletzt wurden.


 

Katharina Bisset, Legal Counsel, Frequentis AG, Innovationsstrasse 1, 1100 Wien, AT, katharina.bisset@frequentis.com; www.frequentis.com

  1. 1 http://opensource.org/ (20. Januar 2015).
  2. 2 Die OSS Lizenz wird dabei Vertragsbestandteil – LG München I, Urteil vom 19. Mai 2004, Az: 21 O 6123/04 (http://www.internetrecht-rostock.de/urheberrecht23-gpl-lg-muenchen.htm).
  3. 3 http://de.wikipedia.org/wiki/Open_Source (10. Januar 2015).
  4. 4 http://www.gnu.org/licenses/gpl-3.0.html (10. Januar 2015).
  5. 5 http://opensource.org/licenses/mit-license.php (10. Januar 2015).
  6. 6 Dass in der Praxis Verstöße gegen OSS Lizenzen gerichtlich verfolgt werden, zeigt anschaulich die Liste der deutschen Anwaltskanzlei Jun: http://www.kanzlei-jun.de/aktuelle-publikumsfaelle/open-source-im-unternehmen/urteile-zu-open-source?start=9 (10. Januar 2015).
  7. 7 Wie z.B. Protecode (www.protecode.com (20. Januar 2015)) oder Black Duck (www.blackducksoftware.de (20. Januar 2015)).