Case Study: Open Source Software in Kombination mit proprietärer Software

Der Auftrag, einen Software-Lizenzvertrag aufzusetzen, scheint eine Routineangelegenheit zu sein. Die anwaltliche Praxis zeigt jedoch, dass es immer wieder erforderlich ist, auf neue Aspekte, geänderte Technik oder besondere Bedürfnisse des Mandanten einzugehen. Gerade bei der Nutzung von Open Source Software ergeben sich eine Reihe von Besonderheiten, die bei der Vertragsgestaltung zu beachten sind. Das folgende Beispiel zeigt deutlich, dass es eben nicht genügt, Formularverträge zu übernehmen oder alte Vorlagen anzupassen.

Die Aufgabe

Software-Lizenzverträge beruhen im zumeist auf folgendem Geschäftsmodell: Der Softwarehersteller und Lizenzgeber generiert seine Einnahmen aus Lizenzgebühren, die er abhängig von der Stückzahl der an den Endkunden veräußerten Exemplare der Standardsoftware erhält. Bei der Entwicklung speziell angepasster Programme handelt es sich zumeist um eine einmalige Vergütung. Zum Teil wird die Software auch im Wege des SaaS angeboten, um wiederkehrende Einnahmen zu erhalten.

Eine wichtige Aufgabe für den Anwalt besteht folglich darin, seinen Mandanten davor zu bewahren, dass er die Kontrolle über die Vergabe der Rechte an der Software verliert, etwa durch eine zu umfangreiche Lizenzierung an den Vertragspartner. Die wirtschaftlich relevanten Nutzungsmöglichkeiten des Lizenznehmers sollen sich in der Vergütung widerspiegeln.

Einen anderen Ansatz mit zunehmend praktischer Bedeutung verfolgte hingegen ein Mandant, der ein Softwareprodukt anbietet, das zu einem Teil aus herkömmlicher, sogenannter proprietärer, Software besteht, zu einem Teil aber aus Open Source Software. Die Besonderheit von Open Source Software oder „Freier Software“ besteht darin, dass sie von jedermann vervielfältigt, verbreitet und verändert werden darf, ohne dass dafür Lizenzgebühren verlangt werden.

Die Geschäftsidee des Mandanten beruhte darauf, auf bereits bestehende Open Source Software zurückgreifen, ohne das eigene Produkt dafür mit Lizenzgebühren an Dritthersteller belasten zu müssen. Zudem zielte die eigene Software auf den sich stark entwickelnden Markt um das erfolgreiche Betriebssystem GNU/Linux. Einnahmen sollten einerseits aus Support für den Endkunden generiert werden, andererseits aus Lizenzgebühren, die Hardwarehersteller für jedes Exemplar entrichten, das sie mit der Software ausstatten.

Eine Reihe von Probleme waren zu berücksichtigen:

  • Wie kann proprietäre Software neben Open Source Software lizenziert werden?
  • Welche Softwarebestandteile müssen zwingend unter eine Open Source-Lizenz gestellt werden?
  • Welche der zahlreichen Lizenzformen passt auf das eigene Modell am Besten?
  • Welche besonderen Vertriebspflichten bestehen bei Open Source Software?
  • Wie kann ein tragfähiges Konzept für den internationalen Markt entwickelt werden?

Die Umsetzung

Der Vertragsentwurf war in englischer Sprache und unter Berücksichtigung der Gepflogenheiten des anglo-amerikanischen Rechtsraums zu erstellen, um im internationalen Verkehr verwendbar zu sein. Wichtige Punkte bei der Berücksichtigung der Interessen der Vertragspartner waren Rechtswahl- und Gerichtsstandvereinbarungen sowie die Währung und steuerliche Aspekte hinsichtlich der Vergütung.

Urheberrechtliche Fragen spielten die Hauptrolle bei der Abschichtung von proprietären und Open Source-Bestandteilen. Zunächst waren die verschiedenen Open Source-Lizenzen daraufhin zu untersuchen, ob sie die freie Nutzung mit zusätzlichen Bedingungen verknüpfen, wie dies bei der GNU General Public License (GPL) der Fall ist. Das sog. „Copyleft-Prinzip“ verlangt, dass Bearbeitungen des eingesetzten GPL-Programms beim Weitervertrieb ebenfalls wieder unter den Lizenzbedingungen der GPL angeboten werden. Damit war für einen rechtssicheren und lizenzkonformen Vertrieb zu prüfen, ob und in welchem Umfang eigene Programmbestandteile unter einer eigenen, proprietären Lizenz vertrieben werden durften und welche Komponenten als Open Source Software freigegeben werden mussten.

Es zeigte sich, dass für einige Softwarebestandteile eine klare Aussage getroffen werden konnte, während aufgrund der Unklarheiten in der Open Source-Lizenz für andere Softwarekomponenten eine Unsicherheit verblieb. Dem entsprechend wurden Weiterentwicklungen und Änderungen der betroffenen Treiber des Mandanten ebenfalls wieder unter der GPL lizenziert. Ähnliche Überprüfungen wurden bei den verwendeten Programmbibliotheken notwendig.

Schließlich war hinsichtlich der Eigenentwicklungen, die nicht unter der GPL lizenziert werden mussten, abzuwägen, ob und inwieweit sie unter eine freie oder proprietäre Lizenz gestellt werden sollten. Zu bedenken und mit dem Mandanten abzustimmen waren Gesichtspunkte des Marketings, der Technik und der Marktansprache.

Als problematisch für die Geschäftstätigkeit, insbesondere im Ausland, stellte sich die Gefahr der unbewussten Verletzung von Softwarepatenten dar. Für ein konkret bekanntes Patent wurde ein Patentanwalt vermittelt, um zu überprüfen, ob das patentierte Verfahren tatsächlich in der Software Verwendung findet. Mangels wirtschaftlich sinnvoller Möglichkeiten zu einer Patentrecherche musste im Übrigen eine Freistellungsklausel mit dem Vertragspartner verhandelt werden.

Neben den urheberrechtlich relevanten Klauseln mussten noch allgemeine Vertragsfragen geklärt werden, darunter der Umfang von Haftung und Gewährleistung, die Produkthaftung, Geheimhaltungsregelungen, AGB-Recht und die Verbindung mit Supportverträgen. Auch hier waren jeweils die Auswirkungen zu berücksichtigen, die sich aus der Kombination von Open Source Software mit proprietären Bestandteilen ergeben.

Das fertige Vertragswerk versetzt den Mandanten nun in die Lage, seine Software auf rechtlich sicherer Basis anzubieten.