Die Open-Source-Falle beginnt bei den Lizenzbedingungen

Die Euphorie rund um das 20-jährige Open-Source-Jubiläum ist groß. Allerdings ist nicht alles Gold, was glänzt, meint IT-Dienstleister und Open-Source-Experte Consol. Schon die Lizenzbedingungen bei Open-Source-Software sollten detailliert überprüft werden, schließlich sind sie kein Freibrief für jede kommerzielle Nutzung und Lizenzverstöße können kostspielig werden.

Illustration: Absmeier, Tweetyspics

Open Source kann auf einen beispiellosen Siegeszug zurückblicken, auch wenn bei einigen Anbietern noch proprietäre Lösungen dominieren. Seit Jahren wird das Angebot an Open-Source-Lösungen immer größer und unübersichtlicher. Neben bekannten und millionenfach eingesetzten Systemen wie Linux, Android, Eclipse oder Mozilla Firefox gibt es Tausende weniger bekannte Lösungen, die allerdings nicht immer bedenkenlos genutzt werden sollten. Durch fehlerhafte Programmierung, mangelnde Kontrolle, unzureichende Tests oder den absichtlichen Einbau von schädlichem Code können Sicherheitslücken, aber auch Qualitätsprobleme wie Softwareabstürze entstehen, die zu gravierenden Schäden bei den Anwendern führen können.

 

»Vor der Einführung einer bestimmten Open-Source-Software muss ein Unternehmen prüfen, wer die entsprechende Software anbietet und wer die Pflege und den Support der Software zu welchen Konditionen übernimmt«, betont Gunther Zerbes, Senior IT Consultant bei Consol. »Ein wichtiger Punkt wird dabei oft vergessen: die Lizenzbedingungen. Sie sollten genauestens unter die Lupe genommen werden, um möglichen Lizenzverstößen vorzubeugen.«

 

Bei den Lizenzbedingungen ist zunächst darauf zu achten, dass sie einem der etablierten Standards entsprechen. Beispiele sind die GNU General Public License (GPL V2 oder V3), die GNU Lesser General Public License (LGPL), die Apache License (V2), BSD, MIT, Eclipse, die Common Public License (CPL), die Mozilla Public License (MPL) oder die European Union Public License (EUPL).

 

Dabei ist insbesondere zu prüfen, wie das Thema »Copyleft« geregelt ist:

 

  • Strenge Copyleft-Lizenzen wie die GPL fordern, dass alle von der ursprünglichen Software abgeleiteten Werke unter den Bedingungen der Ursprungslizenz stehen.
  • Lizenzen ohne Copyleft-Effekt wie Apache, BSD oder MIT machen hingegen dem Lizenznehmer keine Vorgaben hinsichtlich der Lizenzierung seiner abgeleiteten Software.
  • Lizenzen mit eingeschränktem Copyleft setzen zwar grundsätzlich die Weitergabe der proprietären Software unter der ursprünglichen Open-Source-Lizenz voraus, unter bestimmten Prämissen können aber abgewandelte Programmteile unter proprietäre Lizenzbedingungen gestellt werden.

 

Das Thema Copyleft ist deshalb von großer Bedeutung, da der Rechteinhaber bei einer lizenzwidrigen Nutzung von Software Unterlassungs-, Beseitigungs- und Schadensersatzansprüche gegen den Verletzer geltend machen kann – und das kann nicht nur zu erheblichen Schadensersatzzahlungen, sondern auch dazu führen, dass die Software nicht mehr verwendet werden darf.

 

»Unter Umständen wird sich bei der Bewertung der Lizenzbedingungen herauskristallisieren, dass man von bestimmten Programmen vielleicht doch lieber die Finger lässt – und dafür vielleicht eine alternative Lösung sucht, sei es ebenfalls im Open-Source- oder auch im Closed-Source-Bereich. Bei letzterem fallen zwar Lizenzgebühren an und es droht ein Vendor Lock-in, der Hersteller steht aber andererseits für Support und Pflege bereit und haftet für Schäden aufgrund von Sicherheits- oder Qualitätsmängeln der eingesetzten Software«, so Zerbes. »Geht aber ein Unternehmen den Open-Source-Weg, sollte es grundsätzlich einen kompetenten Dienstleister hinzuziehen, der über Erfahrung im Einsatz von Open-Source-Software verfügt und der im Idealfall selbst an der Entwicklung solcher Lösungen beteiligt ist.«

 


 

Open Source: Kollaboration und Transparenz für eine offene Kultur

IT-Infrastruktur: Cloud und Open Source liegen vorn

Open Source als herausragende Architektur und Innovationstreiber

Open Source als Schlüsselelement erfolgreicher DevOps-Strategien

Open Source: Sicherheit durch Transparenz

Sicherheitsrisiko Security-Software: Angreifbar durch Open-Source-Komponenten