Open-Source-Software

„Open Source“ in der Industrie und was der Maschinenbauer wissen sollte

25.09.2008 | Autor / Redakteur: Carsten Emde* / Reinhard Kluger

Beispiel einer „Alleinstellungspyramide“, in der die verschiedenen Know-how-Bereiche eines Unternehmen aufgeführt sind.
Beispiel einer „Alleinstellungspyramide“, in der die verschiedenen Know-how-Bereiche eines Unternehmen aufgeführt sind.

Firmen zum Thema

Open Source? Ja, aber wie? Für die Weitergabe von Freier Software und Open Source Software gilt: Nicht alles ist kostenlos. Dienstleistungen darf man sich bezahlen lassen, die Lizenzierung nicht. So sind die Regeln.

Viele der heute angewendeten Open-Source-Lizenzen − wie zum Beispiel die GNU General Public License (GNU GPL) − räumen dem Empfänger einer so lizenzierten Software eine Reihe wichtiger Rechte ein; aber der Lizenznehmer akzeptiert auch eine bedeutsame Pflicht, die zum Tragen kommt, wenn die Software weitergegeben wird. Diese Pflicht wird „Copyleft“ im Gegensatz zu „Copyright“ genannt. Während das Copyright in einem solchen Fall die Weitergabe ohne besondere Erlaubnis des Rechtsinhabers ausschließt, erlaubt das Copyleft die Weitergabe - aber sie erlaubt diese nicht einfach, sondern macht sie abhängig davon, dass Bearbeitungen der Software bei der Weitergabe ebenfalls frei genutzt werden dürfen. Dabei gilt diese Forderung nicht nur für die ursprüngliche Version der Software sondern auch für sämtliche daran vorgenommenen Änderungen und Erweiterungen. Letzteres stellt eine Besonderheit dar, weil das Urheberrecht dem Lizenznehmer normalerweise die Entscheidung frei überlassen würde, unter welche Lizenz er die vorgenommenen Änderungen und Erweiterungen stellt. Aber mit der Annahme einer Copyleft-beinhaltenden Lizenz akzeptiert der Lizenznehmer diese besondere Auflage, die bei Weitergabe der Software wirksam wird.

Die Rechte, welche die GNU GPL dem Lizenznehmer einräumt, erlauben es, die betroffene Software

  • 1. uneingeschränkt einzusetzen,
  • 2. zu analysieren und für eigene Bedürfnisse anzupassen,
  • 3. an andere weiterzugeben,
  • 4. zu verändern und die Veränderungen zu veröffentlichen.

Die Pflicht zur Offenlegung bei der Weitergabe ergibt sich daraus, dass der zweite und der vierte Punkt Zugang zum Quellcode erfordern. Dieser Zugang zum Quellcode ist damit eine notwendige, aber keine hinreichende Bedingung für die Eigenschaft als Open-Source-Software. Andere Open-Source-Lizenzen wie z.B. die Lizenz der Berkeley Software Distribution (BSD) räumen vergleichbare Rechte ein, verzichten aber auf das Copyleft.

Entgegen häufig geäußerter Vorstellung darf die Weitergabe von Freier Software und Open-Source-Software (FOSS) durchaus entgeltlich erfolgen, wobei aber klar geregelt ist, dass dieses Entgelt nicht für die Lizenzierung selbst sondern nur für begleitende Leistungen wie zum Beispiel für den mit der Weitergabe verbundenen Aufwand erhoben werden darf. Unabhängig davon darf natürlich ein Dienstleister die von ihm für Weiterentwicklung und Pflege von FOSS erbrachten Tätigkeiten seinem Kunden in Rechnung stellen.

Die im Copyleft enthaltene besondere Regelung der Offenlegung des Quellcodes − einschließlich der von der ursprünglich erhaltenen Software abgeleiteten Komponenten − ist für Maschinenbauer und andere im Bereich der Automatisierungsindustrie tätige Unternehmen durchaus wichtig. Denn die Verpflichtung zur Offenlegung ist natürlich nur in den Fällen annehmbar, in denen das Unternehmen dadurch kein schützenswertes Know-how preisgibt.

Wird eine Open-Source-Software verwendet, deren Lizenz wie die BSD-Lizenz in keiner Weise die Offenlegung des Quellcodes bei Weitergabe fordert, sind die folgenden Überlegungen irrelevant. Dies gilt auch für den Fall, dass FOSS nicht in einem Produkt, sondern nur innerhalb eines Unternehmens eingesetzt wird; unter diesen Umständen entfällt auch bei der GNU GPL die Offenlegungspflicht.

Die „Alleinstellungspyramide“

Zur Verdeutlichung der verschiedenen Arten von Know-how, die im Wissens-und Erfahrungsschatz eines Unternehmens enthalten sind, werden diese am besten in einer Pyramide, der sogenannten „Alleinstellungs-Pyramide“, übereinander geschichtet dargestellt. Ein Beispiel einer solchen „Alleinstellungs-Pyramide“ zeigt: 1. Am Fuße der Pyramide liegen die eher allgemein verfügbaren Komponenten wie z.B. das Betriebssystem, weiter oben befindet sich das eher individuelle Know-how eines Unternehmens wie z.B. Applikationen mit darin enthaltenen Verfahrenstechnologien, graphische Bedienoberflächen, Testprozeduren, Qualitäts-Management usw.

Irgendwo zwischen Fuß und Spitze der Pyramide liegt nun die für ein Unternehmen individuelle „Alleinstellungsgrenze“, die es zu bestimmen gilt. Die unterhalb dieser Grenze liegenden Bereiche erlauben dem Unternehmen keine Unterscheidbarkeit vom Mitbewerber, weswegen dieser Bereich auch als „nicht-differenzierendes Know-how“ bezeichnet wird. Im Gegensatz dazu macht das Wissen an der Spitze der Pyramide die Produkte eines Unternehmens von denen der Mitbewerber unterscheidbar und wird entsprechend „differenzierendes Know-how“ genannt. Je weiter oben in der Pyramide diese Grenze liegt, d.h. je mehr Bereiche allgemein verfügbare Komponenten und Technologien betreffen, desto sinnvoller ist für das jeweilige Unternehmen der Einsatz von FOSS (grüne Linien). Liegt diese Grenze sehr weit am Fuß der Pyramide, d.h. fast alles Wissen ist proprietär und marktrelevant, dann scheidet die Verwendung von FOSS mit einer Copyleft-beinhaltenden Lizenz praktisch aus (rote Linie).

Unter den aktuellen Aspekten von offener Wissensökonomie und kontrolliertem Einsatz von Entwicklungs-Ressource kann man sogar soweit gehen, die genannte „Alleinstellungsgrenze“ auch als „Grenze für individuelle Investitionen“ zu bezeichnen. Denn ein Unternehmen sollte möglichst alle verfügbaren Ressourcen in die Entwicklung und Pflege von differenzierendem Know-how investieren und dagegen jegliche Entwicklung von nicht-differenzierendem Know-how nur im Verbund mit anderen ebenfalls an diesen Basistechnologien interessierten Marktteilnehmern vornehmen.

Praktische Vorgehensweise

Vor der Entscheidung zur Teilnahme an einem FOSS-Projekt muss analysiert werden, inwieweit das betreffende Projekt - wenn auch nur teilweise - Wissens- und Erfahrungsschatz betrifft, der nicht preisgegeben werden kann, ohne die Marktposition des Unternehmens zu gefährden. Hierfür lassen sich zwar branchentypische Richtwerte angeben, aber im Einzelfall können durchaus erhebliche Abweichungen bestehen. Typischerweise gehören Maschinenbauer zu denjenigen Unternehmen, die in der Regel keine Alleinstellungsmerkmale aus den Eigenschaften des Betriebssystems und dessen Programmierschnittstelle beziehen. Man kann sich auf der anderen Seite aber auch vorstellen, dass spezielle Steuerungen für außergewöhnliche Anforderungen es erfordern, Betriebssystemkomponenten zu entwickeln, die dann Alleinstellungsmerkmale für den jeweiligen Maschinenbauer enthalten. In einem solchen Fall käme natürlich die Offenlegung des Quellcodes nicht in Frage, so dass ein FOSS-Betriebssystem mit Copyleft-Lizenz nicht eingesetzt werden kann. Auf der anderen Seite ist es aber auch möglich, dass eine zunächst als schützenswert angesehene Software sich bei näherer Analyse doch nicht als als eine solche entpuppt, und die Vorteile einer offenen Weiterentwicklung dann die Freigabe der Software in einem FOSS-Projekt rechtfertigen.

Ist die Entscheidung gefallen, FOSS in einem Produkt einzusetzen oder sogar ein eigenes FOSS-Projekt ins Leben zu rufen, sollte man in jedem Fall Rechtsberatung einholen. Diese bezieht sich auf die Art und Weise, wie der Kunde informiert werden muss, dass in einem bestimmten Produkt FOSS eingesetzt wird, wie und in welchem Umfang die Offenlegung des Quellcodes am besten zu realisieren ist und welche Rechte und Pflichten mit der jeweils gewählten FOSS-Lizenz verbunden sind. Auch sollte genau geprüft werden, inwieweit auf die Geltendmachung von Patenten - zumindest bei deren Verwendung in einem FOSS-Projekt - verzichtet werden muss. In der Regel handelt es sich aber nur um Spielregeln und Handlungsweisen, die bei deren Kenntnis leicht einzuhalten sind. Hilfestellung leisten z.B. Rechtsanwälte, die sich auf FOSS spezialisiert haben, oder auch das private Institut für Rechtsfragen der Freien und Open Source Software (ifrOSS, http://ifross.de/), das zahlreiche Publikationen zum Thema zur Verfügung stellt. Darüber hinaus sollte auch die Mitgliedschaft in einer Interessenvereinigung erwogen werden. Hier bietet sich zum Beispiel das Open Source Automation Development Lab (OSADL) an, das die Verwendung von FOSS in der Autmatisierungsindustrie fördert und koordiniert.

Dr. Carsten Emde, OSADL

*Der Autor dankt Herrn RA Dr. Till Jaeger für die Durchsicht des Manuskripts und Anregungen zu lizenzrechtlichen Aspekten.

 

Service &Support

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 265152 / Engineering-Software)