Zum Umgang mit Lizenzen in der Open Source-Welt

Zum Umgang mit Lizenzen in der Open Source-Welt

Vorstände und Geschäftsführer von Unternehmen haben nicht nur die Aufgabe, geeignete Prozesse zur Unternehmens-Compliance zu implementieren, sondern müssen auch dafür sorgen, dass diese Prozesse tatsächlich eingehalten werden. Ansonsten drohen zivilrechtliche oder sogar strafrechtliche Folgen. Dass dies nicht nur eine theoretische Gefahr ist, zeigt sich in aktuellen Pressemeldungen.
Warum wird in einem Artikel in dieser Zeitschrift auf Unternehmens-Compliance hingewiesen? Die Antwort lautet: Unternehmens-Compliance bedeutet die Einhaltung von Gesetzen, Verträgen und ethischen Leitlinien und damit auch die Beachtung des Urheberrechts. Und da Embedded-Systeme Software benötigen und Software genau wie jede andere Art von schriftlich verfassten Werken dem Urheberrecht unterliegt, gilt es auch beim Kopieren und Weitergeben von Software, die Bestimmungen des Urheberrechts zu berücksichtigen. Dies bedeutet, dass in jedem Fall eine Lizenz für die Verbreitung der Software erforderlich ist; ansonsten begeht das Unternehmen einen Verstoß gegen das Urheberrecht, wofür die Geschäftsführung persönlich verantwortlich gemacht werden kann. Wie kann man sich nun am besten davor schützen, wegen einer Urheberrechtsverletzung bei der Weitergabe von Software belangt zu werden? Der erste Schritt, sich davor zu schützen, besteht darin, den Lizenzvertrag zu lesen und die darin auferlegten Pflichten ausnahmslos zu erfüllen. Dies gilt unabhängig davon, ob es sich um proprietäre Software oder um Open-Source-Software handelt. Da viele aktuelle Embedded-Systeme mindestens teilweise Open-Source-Software enthalten, geht es in diesem Artikel primär um die Lizenzierung von Open-Source-Software. Dies betrifft u.a. den Linuxkernel, der unter der General Public License Version 2 (GPL-2.0) steht. Wie erkennt man nun Rechte und Pflichten, die sich daraus ergeben? Am Beispiel von zwei Absätzen der GPL-2.0 lässt sich dies gut zeigen. Da die rechtsverbindliche Version dieser Lizenz in englischer Sprache geschrieben ist, wird diese auch hier zugrunde gelegt. Artikel 1 der GPL-2.0, der sich auf die Weitergabe von Quellcode bezieht, beginnt mit den Worten ‚You may copy and distribute‘ – also genau das, was das Urheberrecht normalerweise verbietet, wird hier nun erlaubt; es werden Rechte gewährt. Liest man weiter, kommt allerdings ein Satzteil, der mit ‚provided that‘ beginnt. Hier werden nun Pflichten auferlegt. Werden diese nicht erfüllt, können die vorher genannten Rechte nicht erworben werden; gibt man trotzdem weiter, wird ein Urheberrechtsverstoß begangen. Erfreulicherweise sind in diesem Fall von Artikel 1 der GPL-2.0 die Pflichten aber relativ leicht zu erfüllen. Denn es müssen Urhebervermerk und Erklärung zum Ausschluss von Gewährleistung verfügbar und sichtbar gemacht, und es muss der Lizenztext mitgeliefert werden. Vergleicht man den oft sehr hohen Wert der kostenlos verfügbar gemachten Open-Source-Software und die schwerwiegenden Folgen einer Urheberrechtsverletzung einerseits mit diesen relativ einfach zu erfüllenden Lizenzpflichten andererseits, gibt es wohl keinen vernünftigen Grund dafür, die Pflichten nicht zu erfüllen. Artikel 3 der GPL-2.0 beginnt wieder mit den Worten ‚You may copy and distribute‘, aber jetzt wird sogar die Verbreitung der Software als ausführbares Programm gestattet. Allerdings folgt auch hier wieder ein Satzteil mit ‚provided that‘, in dem die Voraussetzungen für die Gewährung der genannten Rechte ausgeführt werden. Es wird eine Auswahl angeboten, von denen mindestens eine umgesetzt werden muss. Es ist aber durchaus möglich und mitunter auch empfehlenswert, mehrere Pflichten umzusetzen. Die beiden wichtigsten Pflichten, zwischen denen ausgewählt werden kann, sind:

a) Das Produkt, das die GPL-lizenzierte Software enthält, muss mit einem üblicherweise zum Datenaustausch verwendeten Speichermedium, das den kompletten korrespondierenden Quellcode enthält, ausgestattet werden oder

b) Das Produkt, das die GPL-lizenzierte Software enthält, muss ein schriftliches Angebot enthalten, den kompletten korrespondierenden Quellcode auf einem üblicherweise zum Datenaustausch verwendeten Speichermedium auf Anfrage zum Selbstkostenpreis zur Verfügung zu stellen.

Wird keine der Pflichten erfüllt, gelten die Rechte zum Kopieren wiederum als nicht gewährt; wird trotzdem kopiert, handelt es sich auch hier um eine Urheberrechtsverletzung mit den oben genannten Folgen. Was in der Theorie einfach klingt, ist erfahrungsgemäß bei der praktischen Umsetzung nicht ganz so einfach. Zum einen muss der Lizenztext an einigen Stellen interpretiert werden, wofür anwaltliches Wissen erforderlich sein kann. Zum anderen gilt es nicht nur, die Bedingungen in einem bestimmten Moment zu erfüllen, sondern die Unternehmensprozesse, die für die Einhaltung der Lizenzpflichten eingerichtet werden, müssen dynamisch an sich ändernde Verhältnisse angepasst werden. Häufig beobachtete Fehler sind:

  • • Der Quellcode ist nicht komplett bzw. nicht korrespondierend.
  • • Der Quellcode ist nicht wie nach 3a) vorgesehen im Produkt enthalten.
  • • Die Adresse für die Anforderung des Quellcodes nach 3b) hat sich geändert.
  • • Die Postkarte mit der Quellcode-Anforderung nach 3b) wird nicht bearbeitet.
  • • Die AGB des Unternehmens wurden nicht an die Open-Source-Lizenz angepasst.

Durch die hohe Verbreitung einzelner Open-Source-Lizenzen ist es sicher nicht sinnvoll, Prozesse zur Verhinderung der genannten Fehler individuell im jeweiligen Unternehmen zu entwickeln, sondern es bietet sich an, Lizenz-Compliance von Open-Source-Software in einer Community zu bearbeiten – genau wie die Entwicklung dieser Software in einer Community erfolgt. Eine Organisation, in denen Mitglieder sich zu einer Community zusammengeschlossen und unmittelbar umsetzbare Best Practices entwickelt haben, ist die Open Source Automation Development Lab (OSADL) eG in Heidelberg.

Stimmen die Prozesse im Unternehmen?

Das OSADL hat in Zusammenarbeit mit einem Unternehmen einen Fragebogen entwickelt, der einerseits in der Vorbereitung auf ein Prozess-Audit verwendet wird, andererseits aber auch als erste Orientierung dienen kann, inwieweit geeignete Prozesse zur Lizenz-Compliance im Unternehmen implementiert sind. Der Fragebogen kann online im Internet ausgefüllt werden, es steht aber auch eine Printversion zur Verfügung. Interessenten erhalten Zugangsdaten zum Online-Fragebogen kostenlos vom OSADL. Wenn im Nachgang zur Online-Befragung ein Audit gewünscht wird, erfolgt eine Befragung der jeweils zuständigen Mitarbeiter am Standort des Unternehmens durch einen Rechtsanwalt und einen Softwarespezialisten sowie eine Sichtung der in diesem Zusammenhang relevanten Dokumente. Ähnlich wie bei der ISO9001-Zertifizierung geht es bei diesem Audit um die Erfassung, Bewertung und Begutachtung der einzelnen im Unternehmen implementierten Prozesse. Im Erfolgsfall wird ein Zertifikat ausgestellt, und die Wahrscheinlichkeit sinkt, dass die Geschäftsführung sich in unvorteilhaften Pressemeldungen wiederfindet.

Open Source Automation Development Lab (OSADL) eG
www.osadl.org

Das könnte Sie auch Interessieren