Open Source Software in der öffentlichen Verwaltung: Eine juristische Risikoanalyse

Software” – der Begriff ist in aller Munde. In Anbetracht der knappen öffentlichen Kassen wird in vielen Bereichen der öffentlichen Verwaltung bereits Open Source Software eingesetzt oder der Einsatz wird geplant. 

Aber was genau ist Open Source oder Free Software?

Open Source Software () sind einzelne Anwendungsprogramme oder ganze Betriebsysteme, deren Quellcode veröffentlicht ist und die frei genutzt, vervielfältigt und verändert werden können. Wobei “frei” nicht zwingend “kostenfrei” bedeutet. Zwar erfolgt die Verbreitung der über das Internet kostenfrei, allerdings ist die geschäftsmäßige Distribution durch Vertragshändler mit zusätzlichem Service (Installation, Schulung, Handbücher, Garantieleistungen etc.) durchaus kostenpflichtig.

Entstanden ist die Idee von der “freien Software” aus dem Bedürfnis vieler Programmierer, die auf dem Markt vorhandene Software an ihre eigenen Bedürfnisse anpassen zu können, wozu sie aber (lizenz-) rechtlich nicht befugt waren. Daher gründete der US-Amerikaner Richard Stallmann die “Free Software Foundation” (FSF) 1983, mit dem Ziel, ein vollkommen freies, uneingeschränkt nutzbares System von UNIX-kompatibler Software zu schaffen, das sog. GNU-System. Ihre Eigendynamik und damit entscheidenden Einfluss auf die gesamte Computerindustrie hat die OSS allerdings erst durch den LINUX Erfinder Linus Torvalds gewonnen. Torvalds machte 1991 den Linux-Quellcode über das Internet mit dem Ziel zugänglich, dass andere Programmierer LINUX verändern und verbessern und ebenfalls die veränderten und verbesserten Versionen frei zugänglich veröffentlichen. Seitdem hat die Verbreitung von OSS erheblich zugenommen und immer mehr Computer werden mit OSS verkauft. Weit über 25% der weltweit und 44% der in Deutschland betriebenen Server laufen mittlerweile auf OSS-Systemen. Für das Jahre 2003 wird der Umsatz von LINUX Produkten und Dienstleistungen auf 12 Billionen US-Dollar geschätzt. Auf Basis des OSS-Lizenz-Konzpetes ist also stetig ein weltweites Netz von Programmierern mit der Lösung aktueller Probleme beschäftigt.

 

Im Gegensatz zu OSS sind die meisten proprietären Softwarelizenzen dahingehend ausgerichtet, die Freiheit der Nutzung, Verbreitung und Veränderung der Software einzuschränken. Hinter diesen Restriktionen steht vorrangig das Interesse der Softwarehersteller, eine angemessene finanzielle „Entschädigung“ für die Entwicklungsleistungen zu erhalten und die Software vor ungewollter Veränderung zu schützen. Dafür gewähren die deutschen und ebenso die ausländischen Urhebergesetze dem Ersteller einer Software ein ausschließliches am Werk „Software“. So kann der Software-Ersteller über das Ob und Wie der Werknutzung, Vervielfältigung und des Vertriebs entscheiden.

 

Trotz der Bezeichnung “Freie Software”, müssen bei der Nutzung von OSS urheber- und lizenzrechtliche Regelungen beachtet werden. Im nachfolgenden soll der Inhalt von OSS-Lizenzen näher beleuchtet (unter 1.). Weiterhin wird auf urheber- (unter 2.) und haftungsrechtliche Aspekte (unter 3. und 4.) eingegangen.

 

Die bekannteste OSS-Lizenz ist die “GNU General Public Licence” (GPL) der Free Software Foundation, die unter anderem auf Linux angewandt wird. Anhand dieser Lizenzbedingungen sollen die rechtlichen Aspekte erörtert werden.

 

1.         Inhalt der GNU General Public Licence

Die GNU GPL regelt drei Nutzungsformen der Software: das Vervielfältigen (copying), das Vertreiben (distribution) und das Verändern (modifying). Das Ausführen des Programms als Nutzung von Software im eigentlichen Sinne ist nicht eingeschränkt. Es ist nicht von der Lizenz erfasst (outside the scope). Im deutschen Urheberrecht ist dagegen bereits das Zwischenspeichern eines Programms in den Arbeitsspeicher urheberrechtlich relevant und muss vom Urheber explizit gestattet werden.

 

Anwendbar ist die GNU GPL auf jede Software, die mit einem Hinweis des Urhebers versehen ist, dass das nachfolgende Werk gemäß der GPL vertrieben werden darf (Abschnitt O der Lizenzbestimmungen).

 

Im ersten Abschnitt der GPL-Bestimmungen wird die Erlaubnis erteilt, den Quelltext des Programms unverändert zu kopieren und zu verbreiten. Voraussetzung ist ein ausdrücklicher Copyright-Vermerk und ein Haftungsausschluss. Nach US-amerikanischem Recht entsteht das schützende Urheberrecht nur dann, wenn das Werk einen ausdrücklichen Copyright-Vermerk enthält. Weiterhin ist immer eine Kopie der Lizenz an den Empfänger der Programme mit zu senden. Meist sind die Lizenzbestimmungen im Anhang der Programmdatei enthalten oder es findet sich ein Verweis auf die Homepage der Open Source Foundation. Die Lizenzen werden dezentral weitergegeben, d.h. nicht vom Urheber selbst, sondern von Nutzer zu Nutzer.

 

Werden die Lizenzbedingungen nicht eingehalten, liegt ein Lizenzverstoß vor. Der Lizenzgeber kann gegen den Verletzer zivil- oder strafrechtlich vorgehen. Unklar ist allerdings sowohl nach deutschem als auch nach US-amerikanischem Recht, ob die Free Software Foundation Inhaberin der ursprünglichen Urheberrechte an der OSS ist. Denkbar ist auch, das derjenige Inhaber der Urheberrechte ist, der jeweils die Lizenz weitergibt. Zurzeit ist nicht eindeutig geklärt, wer befugt ist, Lizenzverstöße gerichtlich zu verfolgen. Nach deutschem Recht ist Torvalds in Bezug auf Linux Inhaber der ursprünlichen Urheberrechte. Die nachfolgend an der Weiterentwicklung beteiligten Programmierer können je nach Umständen Miturheber (§ 8 UrhG), Urheber eines verbundenen Werkes (§ 9 UrhG) oder lediglich Bearbeiter sein. Dies führt in der Praxis dazu, dass nur der ursprüngliche Urheber faktisch die Möglichkeit hat, Lizenzverstöße zu verfolgen.

 

Der zweite Abschnitt der Lizenz regelt, dass eine Veränderung am Programm vorgenommen und das abgeänderte Werk wiederum frei verbreitet und vervielfältigt werden kann. Voraussetzung dafür ist, dass die weitergegebene Version einen Copyright-Vermerk und einen Haftungsausschluss enthält. Außerdem muss die weitergegebene Version den deutlich sichtbaren Hinweis enthalten, welche Veränderungen vorgenommen wurden. Das Datum der Veränderung ist einzufügen.

 

Hervorzuheben ist, dass die Softwarenutzer durch GPL verpflichtet werden, das jeweils abgeänderte OSS-Programm wiederum als Open Source Software für jedermann verfügbar zu machen. Das Urheberrecht, das der Programmierer an den Veränderungen erwirbt, wird also von vornherein eingeschränkt, da er sich verpflichtet das Werk wiederum zur freien Vervielfältigung, Verbreitung und Veränderung freizugeben.

 

Abschnitt 11 GPL schließt jegliche für das Programm “soweit gesetzlich zulässig” aus, “da die Software kostenlos zur Verfügung gestellt worden ist.” Dies entspricht zwar der Rechtslage in den USA, ist aber aus deutscher Sicht durchaus problematisch.

 

2.            Urheberrechtliche Fragen

In der Praxis stellt sich die Frage: Kann die GNU GPL in Deutschland rechtlich durchgesetzt werden?

 

Da die GPL in den USA erstellt wurde, muss für den deutschen Anwender erst einmal geklärt werden, welches Recht auf die Lizenz anwendbar ist. Einig ist sich die juristische Literatur, dass bei grenzüberschreitenden Streitigkeiten über den Inhalt und den Schutz von Urheberrechten das Recht des Landes maßgebend ist, indem der Schutz beansprucht wird.

 

Fraglich ist allerdings, ob es zulässig ist, ein einfaches Nutzungsrecht an der OSS, an die Bedingung zu knüpfen, die bearbeiteten Werke wieder als freie Software verfügbar zu machen? Würde sich beispielsweise ein Linux-Nutzer weigern, den Quellcode seiner verbesserten Version zu veröffentlichen oder dafür eine Lizenzgebühr einfordern, führt dieser Verstoß gegen die GPL-Bedingungen zum nachträglichen Erlöschen der eingeräumten Lizenz. Derartige bedingt eingeräumte Nutzungsrechte sind nach deutschem Recht zulässig.

 

Weiterhin sind die Lizenzbedingungen auf einer “take it or leave it” Basis ausgerichtet, d.h. sie sind festgelegt und zwischen den Nutzern nicht frei verhandelbar. Nach den Bedingungen erwirbt zwar derjenige, der ein OSS-Program verändert an diesem neuen Werk ein Urheberrecht. Jedoch kann er eine über die ursprüngliche Lizenz hinausgehenden Nutzungsbeschränkungen nicht durchsetzen, da er insoweit an die Vorgaben der GPL gebunden. Diese Einschränkung läuft letztlich auf ein Verbot hinaus, seine Geschäftsbedingungen mit Dritten auszuhandeln.

 

3.            Gewährleistung und Haftung

Das Thema „Gewährleistung“ und „Haftung“ ist für den Einsatz in der öffentlichen Verwaltung von besonderem Interesse. Die GPL schließen Ansprüche des Anwenders vor dem Hintergrund aus, dass der Entwickler unentgeltlich tätig wird und auf Entwicklungsleistungen anderer aufbaut. Soweit ausländisches Recht gilt und dieses einen vollständigen Haftungsausschluss zulässt, stehen dem Endnutzer weder Ansprüche auf Schadenersatz, noch auf Nachlieferung oder Minderung zu.

 

Findet hingegen deutsches Recht Anwendung, so halten die Bestimmungen einer AGB-rechtlichen Kontrolle nicht stand. Die Haftung darf nach den § 309 ff BGB allenfalls für leichte Fahrlässigkeit ausgeschlossen werden. Auch ein kompletter Ausschluss der Gewährleistungsrechte ist nicht zulässig, da die Software i.d.R einer neu hergestellten Sache gleichsteht. Daraus folgt, dass die beschränkenden Bestimmungen der GPL als Ganzes unwirksam sind.

 

An deren Stelle treten die gesetzlichen Regeln: Wegen der Unentgeltlichkeit ist die reine Überlassung von OSS regelmäßig als gemischter Schenkungsvertrag einzuordnen. Der Entwickler haftet damit nur für Vorsatz und grobe Fahrlässigkeit. Gewährleistungspflichten treffen ihn nur, wenn er Mängel der Software arglistig verschwiegen hat. Eine Arglist ist in Praxis allerdings nur schwer zu beweisen. Somit sind auch unter der Geltung deutschen Rechts Ansprüche gegen den Entwickler aus einem Schenkungsvertrag kaum realisierbar. Andere vertragliche Konstellationen können im Einzelfall zu Gewährleistungsrechten führen.

 

Etwas anders stellt sich die Situation in Bezug auf den Distributor dar. Soweit er Eigenleistungen, insbesondere im Bereich der Zusammenstellung, der Installationsroutinen oder der Dokumentation erbringt, verlangt er im Gegenzug regelmäßig eine Vergütung. In der Folge richten sich die Rechte der Beteiligten nach Kaufrecht oder Werkvertragsrecht. Die Verwaltung kann dann die bekannten Gewährleistungsansprüche nach dem Bürgerlichen Gesetzbuch (BGB) wie Nacherfüllung, Minderung, Rücktritt und/oder Schadenersatz geltend machen. Voraussetzung ist das Vorliegen eines Mangels, beispielsweise wenn die ausgewählten Komponenten inkompatibel sind oder Installationsroutinen nicht ordnungsgemäß funktionieren.

 

Zur Lösung des Problems bieten sich verschiedene Ansätze an. Zum einen könnte ein externes Unternehmen mit der Auswahl, Beschaffung und Installation der OSS beauftragt werden. Dann haftet das Unternehmen entsprechend den vertraglichen Regelungen als Generalunternehmer. Eine andere Möglichkeit eröffnen einige Distributoren selbst: Gegen eine entsprechende Vergütung übernehmen Sie die Gewährleistung und bieten Ihren Kunden so ein gewisses Maß an rechtlicher Sicherheit.

 

4.            Weiterentwicklungen der öffentlichen Hand

Bei Weiterentwicklungen bestehen für die öffentliche Hand wie für Entwickler aufgrund der OSS-Konzeption Risiken. Wie bereits ausgeführt, darf der Nutzer die OSS nur unter der Prämisse verändern, dass er seinerseits das Arbeitsergebnis unter die Geltung der GPL stellt. Ihm ist daher die wirtschaftliche Verwertung seiner Weiterentwicklung verwehrt. Gleichzeitig besteht die Pflicht, sein Arbeitsergebnis zugänglich zu machen und den Quellcode zur Verfügung zu stellen. Bei Zuwiderhandlungen überschreitet er seine Nutzungsrechte und sieht sich ggf. Schadenersatz- und Unterlassungsansprüchen des Urhebers ausgesetzt.

 

Brisanz erlangt dieser Mechanismus, wenn man bedenkt, wie schnell auch die Verwaltung in die Rolle eines Entwicklers gedrängt werden kann. Die GPL soll für alle Arbeitsergebnisse Geltung erlangen, solange sie nur  „a work based on the program“ darstellen. Nach der insoweit sehr weiten Definition in der GPL reicht es schon aus, dass das Programm oder ein Teil davon in veränderter oder unveränderter Form im Arbeitsergebnis enthalten ist. Zwar wird damit das Dokument, welches mit einer OSS-Textverarbeitung erstellt wurde, noch nicht zu einem auf dem Programm basierenden Werk, da es keine Züge des Ausgangswerkes  übernimmt. Schwieriger wird die Einordnung aber schon dann, wenn das erstellte Dokument auch auf anderen Systemen autark laufen soll. Zu diesem Zweck muss es mit ausführbaren Elementen verknüpft werden, die von der Erstellungssoftware herrühren und einen Teil derselben darstellen. 

 

Eine unter die GPL fallende Bearbeitung liegt jedenfalls dann vor, wenn die Software durch Änderungen des Quellcodes an die eigenen Erfordernisse angepasst oder aber Elemente aus OSS-Programmbibliotheken für die eigene Software übernommen wird. Unter Geltung der strengen GPL-Vorschriften bestünde damit die Pflicht, diese Arbeitsergebnisse der Öffentlichkeit zugänglich zu machen. Dies läuft den vitalen Interessen der öffentlichen Hand zumindest dann zuwider, wenn in die Bearbeitung der Software geheimes Know-How oder andere Geschäftsgeheimnisse eingeflossen sind.

 

Anders ist die Situation dann zu bewerten, wenn ein eigenständiges Programm erstellt wird, dass beispielsweise unter einem OSS-Betriebssystem arbeitet. Eine solche Konstellation führt nicht zu einer Anwendung der GPL auf das eigenständige Programm.

 

Schlusspunkt

„Freie Software“ darf keinesfalls dahingehend verstanden werden, dass im Umgang mit ihr keinerlei Rechte zu beachten sind. Vielmehr empfiehlt es sich, auch bei Open Source Software das gleiche Maß an Sorgfalt walten zu lassen, wie bei proprietärer Software. Da einige Rechtsfragen nach wie vor ungeklärt sind, ist besonderer Wert auf eine sorgfältige Gestaltung der Verträge und Rechtsbeziehungen zu legen.

 

 
1 Star2 Stars3 Stars4 Stars5 Stars (Noch keine Bewertungen)
Loading...

Rechtsanwalt Thomas Feil in den Medien

Schreibe einen Kommentar
Deine E-Mail-Adresse wird nicht veröffentlicht.

Sie können folgende HTML-Tags benutzen:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

*
*