Rechtliche Risiken und Lösungswege beim Einsatz von Open Source Software (Teil 4)

Da der Einsatz von Open Source Software (OSS), auch als Bestandteil von propietärer Software, immer mehr zunimmt, verfasste Dr. Wolf Günther, Fachanwalt für IT-Recht und Gewerblichen Rechtsschutz, eine Reihe bezüglich der rechtlichen Risiken und Lösungswege bei der Verwendung von OSS. Nach der Haftungsthematik hinsichtlich Fehler in der OSS, die Verletzung von Rechten Dritter und der Frage, wie verhindert werden kann, dass der IT-Freelancer bei Verwendung von OSS gezwungen wird, auch seine Eigenentwicklung als OSS zu vertreiben, geht es in diesem vierten und letzten Teil um die persönliche Haftung des IT-Freelancers (auch wenn er als GmbH oder UG handelt) beim Einsatz von Open Source Software.

Open Source Software und die persönliche Haftung des IT-Freelancers

Da die Urheber bei OSS nicht bestimmbar sind und nicht nachvollzogen werden kann, ob die OSS nicht ein Patent oder ein anderes Schutzrecht eines Dritten verletzt, könnte der Einsatz von OSS grob fahrlässig sein. Der Ausschluss der Haftung für grobe Fahrlässigkeit ist in AGB nicht möglich. Deshalb besteht die Gefahr, dass man gegenüber den eigenen Kunden für solche Schäden unbeschränkt haftet, die den Kunden im Zusammenhang mit der Verwendung von OSS oder durch ein gerichtliches Verbot der Verwendung der OSS entstehen. Aufgrund der rechtlichen Unsicherheiten bei der Verwendung von OSS besteht zudem die Gefahr, dass sich die IT-Freelancer durch die Freigabe der Nutzung von OSS persönlich haftbar machen.

Hier ist aber wohl zumindest zwischen Linux und anderer OSS zu unterscheiden. Denn hinsichtlich der eben genannten Gefahren kann man bei OSS wegen der entsprechenden Verbreitung wahrscheinlich davon ausgehen, dass hier die Risiken begrenzt sind. Zu diesem Ergebnis ist auch die Stadt München nach Einholung eines entsprechenden Gutachtens gekommen, sodass der IT-Freelancer sich hier – je nach Einzelfall – auch darauf berufen kann. Bei SUSE Linux macht Microsoft zudem keine Patentverletzungen gegenüber Kunden von Novell geltend.

Allerdings gibt es weitere Risiken: Grundsätzlich gibt es keine verpflichtend definierten Qualitätssicherungsmechanismen bei der Entwicklung von OSS. Für einen vorsichtigen Kaufmann ist es eventuell nicht angemessen, auf Software zu vertrauen, deren Autoren – zum Teil – unbekannt sind und deren Entwicklung nicht sicher zurückverfolgt werden kann. Folgende Maßnahmen können hier das Risiko weiter minimieren:

• Zunächst muss OSS durch den IT-Freelancer für das vorgesehene Anwendungsgebiet selbst getestet werden.
• Es sollte eine gewisse Zeit und Verbreitung nach Freigabe der neusten Version der OSS abgewartet werden, bevor diese eingesetzt wird (siehe das obige Linux-Beispiel).
• Soweit möglich soll OSS technisch von der übrigen Hardware getrennt werden:
  • So sollte OSS nicht direkt in die relevante Hardware (z.B. in den Controller) eingefügt werden.
  • Es ist vielmehr zu versuchen, separate Hardwaremodule (z.B. CF-Cards, EPROMs etc.) zu nutzen, in welcher OSS gespeichert ist und welche mit der Einheit für das Uploaden von OSS verbunden werden kann. Dann ist der Austausch bei einer Patentverletzung einfacher.
  • Oder OSS sollte auf Datenträger (DVD etc.) geliefert werden, sodass der Kunde es selbst aufspielen kann.
• Die Trennung von der übrigen Hardware hat auch den weiteren Vorteil, dass damit noch einmal deutlich wird, dass die Software, die der IT-Freelancer liefert, gänzlich getrennt von OSS zu sehen ist. Das hilft auch bei den übrigen in den vorhergehenden Teilen angesprochenen Problemkreisen. Denn damit kann noch einmal deutlich gemacht werden, dass die Haftungsregelungen isoliert zu betrachten sind und dass die übrige Software ein „derivative work“ ist, sodass diese nicht unter die GPL gestellt werden muss und sodass auch die Verpflichtung zur Offenlegung des Quellcodes nicht gilt.

Zusammenfassend ist festzuhalten, dass der Einsatz von Embedded OSS zwar mit Risiken verbunden ist, dass es aber auch Maßnahmen gibt, die diese Risiken minimieren können.