Open Source Geschäftsmodell für das Forschungsprojekt "Message to Anywhere"

INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS

1. EINLEITUNG
1.1 Problem
1.2 Zielsetzung und Aufbau

2. M2A - DAS PRODUKT
2.1 Produktvorstellung
2.2 Zielsetzung von M2A
2.3 Architektur
2.3.1. Abstrakt
2.3.2. Konkret
2.3.3. Gegenüberstellung von abstrakter und konkreter Architektur
2.4 Funktionsablauf
2.5 Technologieübersicht

3. BEGRIFFSBESTIMMUNGEN ZU OPEN SOURCE
3.1 Abgrenzung zu anderen Softwarelizenzmodellen
3.2 Definition von Open Source

4. LIZENZRECHT IM OPEN SOURCE BEREICH
4.1 Einführung
4.2 Überblick über den Einsatz von Open Source Lizenzen
4.3 Klassifizierung der Open Source Lizenzen
4.3.1 Lizenzen mit rigiden Copyleft Bestimmungen
4.3.2 Lizenzen mit beschränkten Copyleft Bestimmungen
4.3.3 Lizenzen ohne Copyleft Bestimmungen
4.3.4 Lizenzen mit Wahlmöglichkeiten
4.3.5 Lizenzen mit Sonderrechten
4.4 Open Source Lizenzen - Verwendung in einem Software Projekt

5. LIZENZRECHTLICHE BEEINFLUSSUNG VON M2A
5.1 Apache Cocoon Project 2.1.6
5.2 Apache Tomcat 5.5.4
5.3 Apache Project Avalon 4.2.0
5.4 CC/PP
5.5 Eclipse 2.1
5.6 EclipseUML 1.0.0
5.7 Java SDK 1.4.2
5.8 JBoss Application Server 4.0.1
5.9 JBoss IDE-Plugin 1.3.0
5.10 JMS
5.11 JMX
5.12 JUnit 3.8.1
5.13 Log4J 1.2.7
5.14 MySQL Database Server
5.15 Xerces 1.4.4
5.16 XML
5.17 Zusammenfassung

6. KONZEPT DER WETTBEWERBSSPEZIFISCHEN ZUSAMMENHÄNGE
6.1 Begriff des Geschäftsmodells und Einbettung im Konzept der wettbewerbsspezifischen Zusammenhänge
6.2 Wettbewerbssituation
6.2.1 Branchenstruktur
6.2.2 Interaktion der Marktteilnehmer
6.2.3 Entwicklungsdynamik der Branche
6.3 Wettbewerbsstrategie
6.3.1 Geschäftsfelder
6.3.2 Wettbewerbsposition
6.3.3 Wettbewerbsvorteil
6.3.4 Kernkomptenzen
6.3.5 Ressourcen und Fähigkeiten
6.4 Geschäftsmodell - Teilmodelle
6.4.1 Prozessmodell
6.4.2 Teilnehmermodell
6.4.3 Erlösmodell
6.4.4 Transaktionsmodell
6.5 Interdependenzen der wettbewerbsspezifischen Kräfte

7. GESCHÄFTSMODELLE IM OPEN SOURCE BEREICH
7.1 Praktizierte Open Source Geschäftsmodelle
7.2 Geschäftsmodelle von Produktherstellern
7.2.1 Distributor
7.2.2 Applikationsanbieter
7.2.3 Applianceanbieter
7.3 Geschäftsmodelle von Dienstleistern
7.3.1 Dienstleister
7.3.2 Mediator
7.4 Evaluierung des Geschäftsmodells
7.4.1 Generelle Auswahl der Geschäftsmodelle
7.4.2 Betrachtung im Gefüge der wettbewerbsspezifischen Zusammenhänge
7.4.3 Auswahl der Open Source Lizenz
7.5 Empfehlung

8. AUSBLICK

LITERATURVERZEICHNIS

ABBILDUNGSVERZEICHNIS

Abb. 1: Abstrakte Architektur von M2A

Abb. 2: Gegenüberstellung von abstrakter und konkreter Architektur

Abb. 3: Funktionsablauf von M2A

Abb. 4: Lizenzübersicht auf der Entwicklungsplattform Sourceforge

Abb. 5: Übersicht über die Open Source Lizenzen auf Sourceforge

Abb. 6: Konzept der wettbewerbsspezifischen Zusammenhänge

Abb. 7: Die fünf Kräfte des Wettbewerbs nach Porter

Abb. 8: Ansoff Matrix

Abb. 9: U - Kurve nach Porter

Abb. 10: Systematik der Ressourcen und Fähigkeiten

Abb. 11: Wertschöpfungskette

Abb. 12: Systematisches Erlösmodell

Abb. 13: Interdependenzen der wettbewerbsspezifischen Kräfte

Abb. 14: Open Source Geschäftsmodellübersicht

Abb. 15: Wertschöpfungskette des Distributors Geschäftsmodell

Abb. 16: Teilnehmermodell eines Distributors

Abb. 17: Erlösmodell eines Distributors

Abb. 18: Wertschöpfungskette eines Applikationsanbieter

Abb. 19: Teilnehmermodell eines Applikationsanbieters

Abb. 20: Erlösmodell für Software die einer nicht einschränkenden Open Source Lizenz unterliegt

Abb. 21: Erlösmodell für eine versionsbezogene Strategie

Abb. 22: Erlösmodell für ein leistungsspezifisches Gewinnmuster

Abb. 23: Wertschöpfungskette eines Applianceanbieters

Abb. 24: Teilnehmermodell eines Applianceanbieters

Abb. 25: Erlösmodell eines Applianceanbieter

Abb. 26: Wertschöpfungskette eines Dienstleisters

Abb. 27: Teilnehmermodell eines Dienstleisters

Abb. 28: Erlösmodell eines Dienstleisters

Abb. 29: Wertschöpfungskette eines Mediators

Abb. 30: Teilnehmermodell eines Mediators

Abb. 31: Erlösmodell eines Mediators

TABELLENVERZEICHNIS

Tab. 1: Übersicht über verschiedene Softwarelizenzmodelle

Tab. 2: Unterscheidungsmerkmale der verschiedenen Softwarelizenzen

Tab. 3: Übersicht über die Lizenzen von M2A und ihre Einteilung in die Lizenzkategorien

Tab. 4: Teilmodelle eines Geschäftsmodells

Tab. 5: Übersicht der Transaktionsmodelle

1. Einleitung

1.1 Problem

Die Weiterentwicklungen bei mobilen Endgeräten und die Fortschritte der Software- technologie haben in Verbindung mit dem Modernisierungsbedarf bei der Anlagen- steuerung in der Halbleiterindustrie dazu geführt, dass ein Konsortium mit der Ent- wicklung eines universellen und mobilen Kommunikationsframeworks beauftragt wur- de.

Auftraggeber ist das Bundesministerium für Wirtschaft und Arbeit im Rahmen eines Verbundprojekts zur „Förderung von innovativen Netzwerken“.¹ Überwacht wird das Forschungsprojekt vom VDI/VDE-IT².

Ziel des Projektes ist die „Entwicklung eines universellen und mobilen Kommuni- kationsframework ‚Message to Anywhere’ in Hightech-Branchen (M2A)“. Die Soft- ware soll ein modulares Kommunikationsframework, einen generischen Adapter, so- wie eine Anlagenvisualisierung enthalten. Mit diesem Aufbau soll die Lücke zwischen Equipment und dazugehöriger Anwendung innerhalb der Fertigungs- bzw. Laborum- welt geschlossen werden. Ebenso soll die Integration von neuen Anlagen in das bereits bestehende Framework zur Laufzeit mit keinem oder nur sehr geringem Programmier- aufwand bewältigt werden.

Die Nebenbestimmungen des Kooperationsvertrages legen fest, dass sich die Durchführung des Projektes am aktuellen Stand von Wissenschaft und Technik zu orientieren hat.³ Ferner fordern die Nebenbestimmungen eine Verwertungspflicht der Ergebnisse.⁴ Der Verwertungsplan des Projektes sieht eine weite Verbreitung und den Einsatz der neu entwickelten Technologie in der Industrie vor.

Um dieser Forderung gerecht zu werden, hat sich das Entwicklungskonsortium für eine Verbreitung der Software unter einer Open Source Lizenz entschieden. Das Kon- sortium sieht die weite und nahezu kostenfreie Streuung des Kommunikations- frameworks als Grundlage für ein darauf aufbauendes Geschäftsmodell.⁵ Das Geschäfts- modell wird von den Industriepartnern des Konsortiums übernommen und weiterge- führt. Somit soll das Geschäftsmodell den wirtschaftlichen Anforderungen der Praxis genügen, da bei einer ungeeigneten Festlegung erhebliche rechtliche und wirtschaftli- che Auswirkungen für die einzelnen Industriepartner entstehen könnten.

1.2 Zielsetzung und Aufbau

In dieser Arbeit soll ein Open Source Geschäftsmodell ermittelt werden, dass die rechtlichen Aspekte von Open Source Lizenzen mit den wirtschaftlichen Anforderungen eines Betriebes verknüpft.

Die vorliegende Schrift wird sich nicht an der technischen Entwicklung des Forschungsprojektes beteiligen, sie beschränkt sich auf die betriebswirtschaftliche Betrachtungsweise. Daher wird die Beschreibung der Software auf hohem Abstraktionsund niedrigem Detaillierungsgrad stattfinden. Meine Untersuchungen gehen davon aus, dass die vom Konsortium bereitgestellte Informationen bezüglich des Forschungsprojektes M2A der Richtigkeit entsprechen.

Der Aufbau der Arbeit wird nachfolgend erläutert. Im nächsten Kapitel wird das Produkt M2A vorgestellt. Insbesondere wird auf die im M2A Produkt verwendeten Standards, Softwarekomponenten und Produkte eingegangen, da sie in Kapitel 5 benö- tigt werden.

In den Kapitel 3 und 4 werden Informationen bezüglich Open Source und Open Source Lizenzen dargestellt. Die Open Source Lizenzen werden in Kapitel 4 kategorisiert. Ebenso sollen die Eigenschaften von verschiedenen Lizenzen in einem Software Projekt herausgearbeitet werden.

In Kapitel 5 sollen die im M2A Projekt eingesetzten Standards, Softwarekomponenten und Produkte hinsichtlich ihrer rechtlichen Einflussnahme auf die Lizenz des End- produkts untersucht werden.

Im 6. Kapitel werden die theoretischen Grundlagen für das 7. Kapitel gelegt. Der Schwerpunkt liegt in der Darstellung und Normierung der Geschäftsmodelle. Ferner findet eine Einordnung der Geschäftsmodelle in das Konzept der Wettbewerbsspezifischen Zusammenhänge statt.

Im anschließenden 7. Kapitel werden verschiedene Open Source Geschäftsmodelle beleuchtet und auf ihre Eignung im Hinblick auf das Softwareprodukt M2A bewertet. Den Abschluss des Kapitels bildet eine Empfehlung des Autors an das Konsortium. Diese Empfehlung beinhaltet ein Open Source Geschäftsmodell und eine damit abgestimmte Open Source Lizenz für das Produkt M2A.

Der Ausblick schließt mit einem kurzen Überblick über das weitere Vorgehen, das für eine erfolgreiche Umsetzung des Forschungsprojektes M2A notwendig ist.

2. M2A - Das Produkt

2.1 Produktvorstellung

M2A - DAS PRODUKT

Die Abkürzung M2A steht für Message to Anywhere. Hierbei handelt es sich um ein Forschungsprojekt für eine universelle Kommunikationsinfrastruktur zur Steuerung von Anlagen, Equipments und Applikationen in Hightech Branchen.⁶ Die zu entwickelnde Software sollte generell in jedem automatisierten Betrieb eingesetzt werden können. Abgestimmt wird die Software auf die Bedürfnisse der Halbleiterindustrie.

Message to Anywhere wird am Fraunhofer - Institut für Produktionstechnik und Automatisierung und der Universität Stuttgart - Institut für Automatisierungs- und Softwaretechnik in Zusammenarbeit mit fünf Projektpartner aus der Industrie entwickelt. Gefördert und getragen wird das Forschungsprojekt vom Bundesministerium für Wirtschaft und Arbeit⁷. Die Fraunhofer Gesellschaft und die Universität Stuttgart übernehmen die Forschung und Entwicklung des Kommunikationsframeworks. Die Projektpartner liefern praxisbezogenes Wissen, wobei sie die Anforderungen ihrer Kunden an das Produkt mit einfließen lassen. Nach erfolgreicher Entwicklung der Software wird den Projektpartnern die Software zur Nutzung überlassen. Damit soll eine wirtschaftliche Nutzung des Forschungsprojektes gewährleistet sein.

Das Projekt befand sich zum Zeitpunkt der Erstellung der vorliegenden Arbeit inmitten der Entwicklungsphase. Die Veröffentlichung der ersten lauffähigen Version von M2A ist für Mitte des Jahres 2005 geplant.

2.2 Zielsetzung von M2A

Ziel des Projektes ist es, den beteiligten Industriepartnern ein Kommunikations- framework zur Steuerung und Analyse von komplexen Fertigungs- und Laboranlagen zu liefern.⁸ Durch die Zusammenarbeit verschiedener Partner aus Wissenschaft und Forschung auf der einen und der Industrie auf der anderen Seite können komplexe Probleme und bisher unüberwundene Hindernisse gemeistert werden. Ein solches Pro- blem ist die Integration von Equipment in die bestehenden Systeme. Die Einbindung von neuen Komponenten, die zum Zeitpunkt der Softwareerstellung noch nicht am Markt vorhanden waren, ist oft mit erheblichem Programmieraufwand verbunden. Dieser kann durch den Einsatz des generischen Adaptertoolkit von M2A erheblich gesenkt werden. Zudem vereinfacht das Tool die Einbeziehung neuer Komponenten.

Die Bedürfnisse der Halbleiterindustrie beeinflussen die Software dahingehend, dass die von der Praxis geforderten Werte für Performance und Zuverlässigkeit mit in das Endprodukt einfließen.

Ein weiteres Ziel von M2A ist die Bereitstellung eines einheitlichen Kommunikationsnetzwerkes innerhalb der Produktion, das die häufig in Unternehmen vorherrschende Insellandschaft ersetzt soll. Darüber hinaus soll der Brückenschlag vollzogen werden, eine einheitliche Verbindung zwischen Anlagen in der Fertigung/Laborwelt und bestehenden Fertigungssystemen und Anwendungen zur Unterstützung und Steuerung des Fertigungsprozesses herzustellen. Eine konsistente Datenhaltung, verbunden mit einer vollständigen Einsicht aller Daten zu jeder Zeit an jedem Ort unabhängig vom Ausgabegerät des Operators, wird durch M2A ermöglicht.

2.3 Architektur

2.3.1 Abstrakt

Die Architektur von M2A wird in Abbildung 1 abstrakt dargestellt. Anhand der Ab- bildung wird ersichtlich, dass es sich bei M2A um ein Kommunikationsframework handelt, das zur Übersendung von Daten zwischen einem Ersteller und mindestens einem Empfänger fungiert.⁹ Der generische Adapter verbindet die Datenquellen mit dem Herzstück von M2A, dem Messaging Bus. Dieser ist für den logischen Transport der Daten zwischen den Datenquellen und den Datensenken zuständig. Der Funktions- umfang des Frameworkes ist mit Hilfe der M2A-Extensions erweiterbar. Es können beispielsweise Workflowsysteme oder Webclients angeschlossen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Abstrakte Architektur von M2A (Quelle: Knoll, G. (2004c), Folie 12) ¹⁰

2.3.2 Konkret

Mit M2A soll die Integration von Maschinen in eine bestehende Kommunikationsinfrastruktur erleichtert werden. Bisher liegt der Fokus auf der Halbleiterindustrie, genauer gesagt in der Reinst- und Mikroproduktion, eine spätere Ausweitung auf andere Branchen ist durchaus denkbar und gewünscht.

Zu Maschinen im Sinne dieser Arbeit zählen Roboter, Fließbänder und Produktions- anlagen. Entstand bei der Integration von neuem Equipment in bisherige Systeme ein hoher Zeitaufwand¹¹, eventuell verbunden mit einem kurzzeitigen Produktionsausfall, so ist eine Integration von neuem Equipment in die bestehende M2A Architektur zur Laufzeit möglich. Der Grund für die schnelle und flexible Anbindung von Clients jeg- licher Art liegt im generischen Adapter. Dieser wird durch ein Adaptertoolkit, das wie ein Werkzeugkasten für neu anzuschließende Clients funktioniert, generiert. Der Ad- apter stellt die Schnittstelle zur Kommunikation des neu angeschlossenen Clients an das bestehende Kommunikationsframework dar. Clients können beispielsweise Mobil- telefone, Personal Digital Assistants (PDAs), Laptops, Notebooks und Desktop Com- puter sein.

Der M2A-Messaging Bus besteht aus den Komponenten Routing und Naming und wird in dieser Arbeit als Kommunikationsframework bezeichnet. Der JBOSS-Server stellt eine Ausführungsumgebung für M2A dar und verwaltet die eingehenden Nach- richten in Queues. Das Routing, als Begriff innerhalb von M2A, stellt den Zugriff und die Auflösung der Nachrichten innerhalb des M2A Cores¹² sicher. Ebenso soll das Routing in späteren Versionen von M2A eine Schnittstelle für ein Workflowmanagementsystem bieten. Das Naming übernimmt die technische Weiterleitung der Nachrichten an die Empfänger. Unter den M2A Extensions befindet sich ein Apache Tomcat Server, der in Verbindung mit Cocoon als Webserver und Webframework fungiert. Auf diese Weise eröffnet sich die Möglichkeit, eine Statusabfrage, sowie eine Ferndiagnose der Syste- me via Browser durchzuführen. Je nach Einstellung und Maschine ist ebenfalls eine direkte Steuerung über M2A möglich.

2.3.3 Gegenüberstellung von abstrakter und konkreter Architektur

Abb. 2: Gegenüberstellung von abstrakter und konkreter Architektur (Quelle: In Anlehnung an: Knoll, G. (2004b), S. 32)

Abbildung in dieser Leseprobe nicht enthalten

Eine Gegenüberstellung von abstrakter Architektur und tatsächlicher Realisation von M2A wird in Abbildung 2 vorgenommen. Hierbei wurde darauf geachtet, dass die Software M2A getreu ihres modularen Aufbaus abgebildet wird.¹³ Innerhalb eines Moduls ist ein Wechsel zu einer vergleichbaren Technologie jederzeit ohne größeren zeitlichen und technischen Aufwand möglich.

Die linke Seite des Schaubildes stellt die abstrakte Architektur dar. In ihr werden die Oberbegriffe der verwendeten Technologien dargestellt. Die rechte Seite des Schaubildes spiegelt die tatsächlich eingesetzten Technologien wieder.

2.4 Funktionsablauf

Im Folgenden wird der Funktionsablauf der Software dargestellt und die dafür benötigten Programme, Server und Technologien genannt und sichtbar hervorgehoben.¹⁴ Diese Auflistung bildet die Grundlage für Kapitel 5.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Funktionsablauf von M2A (Quelle: Knoll, G. (2004a), S. 17 und Gespräche mit Knoll, G. (2005b) und Tischer, R. (2005))

Wie in Abbildung 3 zu sehen ist, wird der Client¹⁵ mittels Adapter mit dem JBoss Applikationsserver 4.0.1 verbunden. Der Adapter wird mit Hilfe des in Java pro- grammierten generischen Adaptertoolkits entwickelt. Administriert wird der Adapter über die Java Management Extension (JMX). Die Kommunikationsschnittstelle bildet der Java Messaging Service (JMS). Durch ein Application Programming Interface, kurz API genannt, übernimmt der Adapter das Versenden und Empfangen der Nach- richten für seinen Client. Beim erstmaligen Anschließen des Adapters an den Client registriert der Adapter sich und seinen Client beim Naming Service im M2A-Core. Des Weiteren übernimmt der Adapter Protokoll- und Formatkonvertierungsaufgaben.

Die Nachricht wird in Extensible Markup Language (XML), in Text- oder in Objekt- form verschickt. Darüber hinaus enthält jede Nachricht einen Empfänger und die Rou- te zum Empfänger. Die Route der Nachricht ist nach Priorität abgestimmt. Empfänger können Geräte oder Personen sein, die bei Wartungs- oder Störfällen zu alarmieren sind. Die Route legt in Verbindung mit der Priorität des auftretenden Störfalls das Aus- gabegerät fest. Damit ist sichergestellt, dass das Ausgabegerät von ihm verarbeitbare Daten erhält.

Sollte es sich um einen Störfall handeln, bei dem ein Techniker mit bestimmten Kenntnissen erreicht werden muss, so legt die Nachricht die kürzeste Route mit garantierter Zustellung fest. Das kann zum Beispiel eine Nachricht auf einen Personal Digital Assistant (PDA) mit mobilem JMS - Client sein.

Der sendende Adapter stellt die Nachricht in die M2A Queue des JBOSS Servers ein. Der Routing Service des M2A-Cores entnimmt die Nachricht, überprüft alle po- tenziell möglichen Empfänger und löst über den Naming Service die Empfänger - Adres- se - Beziehung auf. Danach wird die Empfängeradresse an die Nachricht angehängt. Im Anschluss übergibt der Routing Service die Nachricht dem Naming Service. Letz- terer kennt die tatsächlich angemeldeten Queues des Empfängers. Der Naming Service ruft die in einer persistenten MySQL Datenbank hinterlegten Adress - zu Namen - Zuordnungen ab und löst diese auf. Im Anschluss daran wird die Nachricht in die tem- poräre Queue des Empfängers eingestellt. Der Adapter des Empfängergeräts überwacht den Nachrichteneingang mithilfe einer Listenerfunktion. Eingehende Nachrichten wan- delt der Adapter in eine clientverständliche Sprache um und übergibt sie dem Client. Die Nachricht ist nun erfolgreich zugestellt.

Unter Einbeziehung einer M2A Webserver Extension kann der Benutzer mit Hilfe eines Webbrowsers eine Statusabfrage bzw. eine Ferndiagnose auf bestimmte Clients durchführen.

Hierzu wird der Apache Tomcat 5.5.4 Server benötigt, der in Verbindung mit dem Webframework Apache Cocoon 2.1.6 und dem Apache Projekt Avalon 4.2.0 die benötigten Funktionalitäten zur Verfügung stellt. Zudem wird durch Benutzung der genormten Composite Capabilities / Perference Profile (CC/PP) Sprache die standardisierte Beschreibung von Eigenschaften mobiler Endgeräte unterstützt.

Darüber hinaus wird das Framework Junit 3.8.1 zum Testen der Programmklassen verwendet. Die Simple API for XML (SAX) und das Document Objekt Model (DOM) werden innerhalb der M2A Extension über den DOM/SAX-Parser Xerces 1.4.4 einge- setzt. Als Entwicklungstools wird Eclipse 2.1 mit den Erweiterungen EclipseUML und JBOSS IDE Plugin 1.3.0 benutzt. Log4J 1.2.7 übernimmt die automatische Auf- zeichnung.

Auf die hervorgehobenen Begriffe wird in Kapitel 5 noch näher eingegangen.

2.5 Technologieübersicht

Die nachstehende Liste gibt eine Übersicht über eingesetzte Technologien in M2A.¹⁶

- Apache Cocoon Project 2.1.6
- Apache Tomcat 5.5.4
- Apache Project Avalon 4.2.0
- CC/PP (Composite Capabilities / Perference Profile)
- Eclipse 2.1
- EclipseUML 1.0.0
- Java SDK 1.4.2
- JBoss Application Server 4.0.1
- JBoss IDE-Plugin 1.3.0
- JMS (Java Messaging Service)
- JMX (Java Management Extension)
- JUnit 3.8.1
- Log4J 1.2.7
- MySQL Database Server
- Xerces 1.4.4
- XML (Extensible Markup Language)

Die aufgezählten Technologien beschreiben rechtlich geschützte Standards, Softwarekomponenten oder Produkte, die in das Endprodukt M2A integriert oder im Erstellungsprozess eingesetzt wurden. Sie sind daher für die Lizenzgestaltung des M2A Produkts von Bedeutung und könnten Einfluss auf das favorisierte Geschäftsmodell haben. Die Lizenzen dieser Standards, Softwarekomponenten oder Produkte, sowie sich daraus ergebende Probleme für M2A werden in Kapitel 5 überprüft.

3. Begriffsbestimmungen zu Open Source

3.1 Abgrenzung zu anderen Softwarelizenzmodellen

Der Begriff ’Open Source’ wurde erstmalig Ende der neunziger Jahre des vergangenen Jahrhunderts benutzt, einerseits um eine Unterscheidung zwischen kostenloser Software (Freeware) und freier Software (Free Software) vorzunehmen, andererseits als Begriff für die Offenlegung von Quellcode¹⁷.¹⁸

Getrieben durch die Weiterentwicklungen von GNU/Linux wurde von Bruce Perens und Eric S. Raymond die Open Source Initiative¹⁹ gegründet. Auf der ersten Versammlung, dem Open Source Kongress am 3. Februar 1998, wurde der Begriff ’Open Source’ als Warenzeichen und Zertifikat eingetragen.²⁰

Die Initiative soll die Lücke zwischen handelsüblicher, käuflicher und mit Lizenz- rechten versehener Software²¹ und freier im Sinne von quelloffener Software schließen. Ebenso soll sie als Bindeglied von Open Source Entwicklern und Unternehmen fungie- ren und Geschäftsmodelle zur wirtschaftlichen Nutzung von Open Source Produkten liefern.²²

Der Wortwechsel von free zu open wurde darüber hinaus durch das existierende Sprachverständnis notwendig, da free im Englischen meist mit gratis bzw. umsonst assoziiert wird.²³ Diese Bedeutungsreduzierung vernachlässigt signifikante charakteristische Merkmale von free bzw. open Source Software.

Übersetzt steht der englische Begriff Open Source für ’offene Quelle’ oder ’quelloffen’. Der Sinn hinter der Wortwahl wird am besten durch Gegenüberstellung der bisher am Markt vorhandenen Softwarelizenzmodelle veranschaulicht.

Zu den als proprietär bezeichnenden Typen zählt in Tabelle 1 Freeware, Shareware und die handelsübliche Software. Dem stehen die quelloffenen Softwaremodelle Free Software, Open Source Software und Public Domain entgegen. Bei diesen darf der Quellcode frei verändert werden. Somit liegt der Quellcode im Gegensatz zur propietären Ursprünglich eingeführt von Netscape für ihren Webbrowser.

Gruppe in einer für den Anwender dekomprimierbaren Form vor, was wiederum die Grundlage für das Verändern von Quellcode bildet. Infolgedessen kann grundsätzlich zwischen Software mit offenem und damit veränderbarem Quellcode und Software ohne offenen Quellcode unterschieden werden.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1:übersichtüber verschiedene Softwarelizenzmodelle (Quelle: In Anlehnung an Gehring, R. u.a. (2004), S. 10 f. und Jaeger, T. u.a. (2001), S. 7)

Folgend eine Kurzerläuterung der wesentlichen Merkmale der Softwaremodelle in Tabelle 1:²⁴

Free Software - zählt zu der Software mit veränderbarem Quellcode. Die Veränderungen müssen als offener Quellcode zur Verfügung stehen.

Open Source Software - dient als Weiterentwicklung von Free Software und erlaubt dem Benutzer den Quellcode zu verändern und kommerziell zu nutzen. Public Domain - Der Ersteller der Software verzichtet auf sein Copyright und gibt die von ihm geschaffene Software zur uneingeschränkten Nutzung frei. Sollte zudem der Quellcode zugänglich sein, so gilt Public Domain als Open Source Software.²⁵ Freeware - Der Quellcode liegt nicht in einer dekomprimierbaren und damit veränderbaren Form vor. Ansonsten ist die Software kostenfrei.

Shareware - Der Ersteller gibt die Software für einen bestimmten Zeitraum zur Nutzung frei. Nach Ablauf des Zeitraumes fallen Lizenzgebühren an.

Ü bliche proprietäre Software - verbietet die Modifikation am Quellcode und verlangt Lizenzgebühren vom Benutzer. Zudem untersagt sie dem Käufer die Weitergabe der Software.

Das eindeutige Abgrenzungskriterium von Open Source zur Gruppe der proprietären Software liegt in dem in dekompilierter Form vorliegenden Quelltext der Software. Die kompilierte Form der Software verhindert das Verändern von Quellcode, damit kann „… zwar die Funktion [der Software], nicht aber die Art des Funktionierens …“²⁶ nachvollzogen werden.²⁷ Weitere nicht eindeutige Abgrenzungspunkte für die Gruppe der proprietären Software zu Open Source sind die zum Teil zu entrichtenden Lizenz- gebühren für Shareware und proprietäre Software und zum anderen das Weitergabe- verbot der gekauften Software.

Der Unterschied zwischen Free Software und Open Source Software liegt in den Nutzungsbestimmungen für den vom Benutzer veränderten Quelltext.²⁸ Bei Free Software muss dem Derivat die gleiche Lizenz zugrunde gelegt werden, die der ursprünglichen Software zugrunde lag. Open Source Software gewährt dem Benutzer einen freieren Umgang mit der zu wählenden Lizenz.

3.2 Definition von Open Source

Folglich versteht man unter Open Source eine lizenzgebührenfreie und beliebig nutzund weiterverbreitbare Software, bei der der Quellcode in einer zugänglichen und damit veränderbaren Form vorliegt.²⁹ Das Verändern und die kommerzielle Nutzung der modifizierten Open Source Software sind nicht von vornherein ausgeschlossen, unterliegen aber bestimmten Lizenzrechten.³⁰

Um der wachsenden Open Source Gemeinde eine Hilfestellung für die Formulie- rung von Open Source Lizenzen zu geben, hat die Open Source Initiative eine umfas- sende Definition über die Gestaltung von Open Source Lizenzen veröffentlicht. Diese Definition beruht auf den von Bruce Perens veröffentlichten Debian Free Software Guidelines³¹.³²

Die Definition setzt die Standards für Open Source Lizenzen. Zum Zeitpunkt der Diplomarbeit lag die Definition in der Fassung 1.9 vor.³³ Im kommenden Abschnitt wird auf die verschiedenen Open Source Lizenzen und ihre Unterteilung eingegangen.

4. Lizenzrecht im Open Source Bereich

4.1 Einführung

Ein Charakteristikum von Open Source beziehungsweise Free Software bilden die Rechte und Pflichten, die sich aus der Lizenz ergeben, unter der die Software steht. Der Begriff ’Lizenz’ kommt ursprünglich aus dem lateinischen und bedeutet ins Deutsche übersetzt: erlauben.³⁴

In Anlehnung an die Patent- und Rechtsanwaltskanzlei Cohausz Dawidowicz Hannig & Partner wird der Begriff juristisch wie folgt definiert: Der Inhaber eines Rechtsgutes, beruhend auf einem gewerblichen Schutzrecht³⁵, räumt einem Dritten die Erlaubnis ein, dieses Recht zu nutzen.³⁶

Eine Verwechslungsgefahr besteht zwischen den Open Source Lizenzen und den seit Mitte 1990 überwiegend in proprietärer Software verwendeten End User License Agreements³⁷.

Open Source Lizenzverträge geben im Zeitpunkt des Vertragsschlusses beiden Parteien eine klare Darstellung über die dem Lizenznehmer entstehenden Rechte und Pflichten.³⁸ Die vollständigen Bedingungen der EULAs hingegen werden dem Käufer erst nach dem Kauf, in der Regel bei der ersten Nutzung der Software, offenbart. Ein Hersteller solcher Produkte behält sich somit vor, dem Benutzer nachträglich zusätzliche Klauseln aufzuerlegen, was juristisch fragwürdig ist.

Liegt bei proprietärer Software der Schutz der Software in Bezug auf die Anzahl der Kopien und Nutzer im Vordergrund, so liegt der Schwerpunkt in den Open Source Lizenzverträgen auf der Einhaltung der gewährten Freiheitsrechte hinsichtlich Benut- zung, Vervielfältigung und Veränderung der Software.³⁹ Diese Lizenzen schützen den Quellcode vor Übernahme in ein kommerzielles Softwareprodukt und stellen somit sicher, dass die gewährten Freiheitsrechte auch zukünftig gewahrt bleiben.

Durch die von der Open Source Initiative veröffentlichte Open Source Definition wird der Rahmen der Lizenzrechte im Open Source Bereich zum Teil vorgegeben. Allen Open Source Lizenzen ist das freie Nutzen, Verbreiten und Verändern der Soft- ware gemein.

Doch bei näherer Betrachtung der Lizenzen fällt der Umgang mit den Weiter- entwicklungen der Open Source Software als Unterscheidungskriterium ins Auge.⁴⁰ Un- terschieden werden kann zwischen Software, bei der die Nutzung und die Verbreitung keinen Auflagen und damit verbundenen rechtlichen Nutzungseinschränkungen unter- liegt und prorietärer Software, deren Nutzung und Verbreitung rechtlich eingeschränkt ist.⁴¹

4.2 Überblick über den Einsatz von Open Source Lizenzen

Einen Überblick über die verwendeten Software Lizenzen im Open Source Bereich liefert die größte Open Source Entwicklungsplattform Sourceforge, auf der zum Zeit- punkt der Diplomarbeitserstellung über 90.000 Projekte registriert waren.⁴² Von den 90.217 registrierten Projekten fand bei 58.975 bereits eine Einteilung in anerkannte Open Source Lizenzen, Public Domain oder andere Lizenzen statt. Die Verteilung der Lizenzen wird durch die Grafik 4 verdeutlicht und zeigt die mit 95 % angezeigte Do- minanz der Open Source konformen Lizenzen. Dieser Überblick wird lediglich zur Veranschaulichung der Tendenzen im Open Source Lizenzbereich herangezogen und lässt bewusst konkurrierende, aber vergleichbare Entwicklungsplattformen unberück- sichtigt.

Abb. 4: Lizenzübersicht auf der Entwicklungsplattform Sourceforge (Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Unter den anerkannten Open Source Lizenzen findet mit 39.204 Projekt- verwendungen die GNU General Public License (GPL) und mit 6.233 die GNU Lesser General Public License (LGPL)⁴³ Anwendung. Zusammen bilden 45.437 GNU Lizen- zen 81 Prozent der anerkannten Lizenzen ab. Sieben Prozent der Projekte oder 4.079 Lizenzen orientieren sich an den Berkeley Software Distribution (BSD) Lizenzen. Die Apache Software Lizenz und die Apache Lizenz V. 2.0 erreichen zusammen 1.142 Projektverwendungen und finden in ca. zwei Prozent der Projekte Anwendung, ebenso wie die Artistic Lizenz mit 1.139 Projektbezügen, die MIT Lizenz mit 1.010 Lizenzen und die Mozilla Public Lizenz V 1.0 und V 1.1 mit 906 Lizenzen. Die verbleibenden 2.739 Lizenzen unterteilen sich in eine Vielzahl von kleineren Lizenzen und bilden zusammen mit ungefähren fünf Prozent den letzten anerkannten Block von Open Source Lizenzen.⁴⁴ Die Übersicht über die Lizenzen wird in Abbildung 5 veranschaulicht.

Im folgenden Kapitel werden die Lizenzen und ihre Klassifizierungen genauer un- tersucht.

Abb. 5:übersichtüber die Open Source Lizenzen auf Sourceforge (Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Vormals Library General Public License genannt. Da der Ausdruck Library den in dieser Lizenz eingeschränkten Freiheitsgedanken der Software nicht stark genug betonte, wurde der Name auf Lesser geändert.

4.3 Klassifizierung der Open Source Lizenzen

Eine Einteilung der Lizenzen in Klassen kann anhand ihrer rechtlichen Rahmen- bedingungen und den damit zu erreichenden Zielen erfolgen.⁴⁵ Die Literatur teilt die Lizenzen im Open Source Bereich in zwei Kategorien ein. Zum einen in Copyleft Li- zenzen und zum anderen in Non-Copyleft Lizenzen.⁴⁶ Das hauptsächliche Unter- scheidungskriterium hierbei bildet der Umgang mit Weiterentwicklungen und Ände- rungen an der lizenzierten Software. Bei Weiterentwicklungen, die auf eine Software unter einer Copyleft Lizenz aufbauen, muss das veränderte Programm unter die glei- che Lizenz wie das ursprüngliche Produkt gestellt werden.⁴⁷ Software, der eine Non- Copyleft Lizenz zu Grunde lag, lässt dem Benutzer freie Lizenzwahl. Dies hat zur Folge, dass das veränderte Programm nun einer proprietären Lizenz unterliegen kann. Die Unterteilung in Copyleft und Non-Copyleft wird den Entwicklungen in der Open Source Lizenzwelt nicht mehr gerecht und wird folgend nur noch als grobe Unterglie- derung verstanden.

Eine detailliertere Einteilung nimmt das Institut für Rechtsfragen der Freien und Open Source Software vor. Die vorherrschende Lizenzlandschaft unterteilt sich dem Institut zufolge in Lizenzen mit rigiden Copyleft Bestimmungen, Lizenzen mit beschränktem Copyleft, Lizenzen ohne Copyleft, Lizenzen mit Wahlmöglichkeiten und Lizenzen mit Sonderrechten.

Einen umfassenden Überblick über die Lizenzen wird vom Institut für Rechtsfragen der Freien und Open Source Software geliefert.⁴⁸ In dieser Diplomarbeit wird aus Platzund Themengründen hierauf verzichtet und es werden im Folgenden zu jeder Klasse nur einige weit verbreitete Lizenzen exemplarisch erläutert.

4.3.1 Lizenzen mit rigiden Copyleft Bestimmungen

Die bekannteste Lizenz unter den Lizenzen mit rigiden Copyleft Bestimmungen ist die GNU General Public License (GPL)⁴⁹, die in weit über der Hälfte aller Open Source Projekte bei Sourceforge eingesetzt wird.⁵⁰ Die General Public License⁵¹ räumt den Lizenznehmern in Paragraph 1 des Lizenzvertrages das Recht der unveränderten Vervielfältigung und Verbreitung des Quellcodes ein. Allerdings nur unter der Voraus- setzung, dass jede Kopie einen Hinweis auf das Copyright und den Haftungsausschluss besitzt. Zudem muss die General Public License der Kopie beigefügt werden. In Para- graph 2 werden die rigiden Lizenzbestimmungen sichtbar, so darf eine veränderte Ko- pie oder Bestandteile aus dem originären Quellcode nur unter den in Paragraphen 1 genannten Bestimmungen verbreitet werden. Des Weiteren kommen noch ergänzende Bestimmungen hinzu, wie unter anderem die Kennzeichnungspflicht von verändertem Quellcode und die Klausel, dass der Autor von verändertem oder abgeleitetem Quell- code dafür Sorge zu tragen hat, dass der Quellcode kostenfrei und nur unter der Gene- ral Public License Dritten zugänglich gemacht wird. Somit wird in Verbindung mit den in der Lizenz nachfolgenden Paragraphen sichergestellt, dass der Quellcode zwar frei verändert und verbreitet werden darf, aber jegliches Derivat im Quellcode zugänglich sein muss, sowie das Derivat auch weiterhin den Lizenzbestimmungen der General Public License unterliegen muss.⁵²

4.3.2 Lizenzen mit beschränkten Copyleft Bestimmungen

Exemplarisch wäre die Mozilla Public License (MPL)⁵³, die zum Zeitpunkt der Diplomarbeitserstellung in der Version 1.1 vorlag, zu nennen.⁵⁴ Die vorliegende Lizenz besticht durch ihre detaillierte Ausgestaltung, in der sie den Brückenschlag zwischen der restriktiven General Public License und dem kommerzi- ellen Pendant vollzieht. Die Mozilla Public License wurde 1998 in Zusammenhang mit der Freigabe von Quellcode des Netscape Browsers ins Leben gerufen. Die Lizenz erlaubt die Kombination von Open Source Software und kommerzieller Software. Sie unterscheidet in veränderten Open Source Code, der bisher der MPL unterlag und auch weiterhin der MPL unterliegen muss und neuem Quellcode, der nicht in die bereits bestehenden Open Source Dateien eingefügt wurde und somit laut Lizenz als eigen- ständige proprietäre Software gilt. Somit wird der Grundgedanke von Open Source - die Inspizierung, Modifizierung und Weitergabe des Quellcodes - sichergestellt. Zeitgleich bietet sich durch Nummer 3.7 des Lizenzvertrages die Möglichkeit, dass Open Source Software in Kombination mit proprietärer Software zu einem „Larger Works“⁵⁵ zusammengefügt wird.⁵⁶ Der Hauptunterscheidungspunkt zur General Public License besteht darin, dass die MPL die Möglichkeit eröffnet, kommerzielle Software mit Open Source Software zu einem Larger Works zu kombinieren, wobei die kommerzielle Software nicht unter die Lizenzregeln der MPL fällt.

4.3.3 Lizenzen ohne Copyleft Bestimmungen

Die bekanntesten Lizenzen ohne Copyleft Bestimmungen sind die Berkeley Soft- ware Distribution (BSD)⁵⁷ Lizenz und die Apache Lizenzen⁵⁸. Die Klasse der Lizenzen ohne Copyleft Bestimmungen soll anhand der in Version 4.4 vorliegende Berkeley Software Distribution Lizenz erläutert werden.⁵⁹ Die kurz gefassten Lizenzbestimmungen der BSD räumen dem Nutzer die Möglichkeit der Veränderung und Verbreitung des Quellcodes ein. Allerdings beschneidet die Lizenz das einfache und unbeschränkte Nutzungsrecht durch nachfolgende Auflagen. So darf der Quellcode nur zusammen mit der BSD Lizenz, dem Haftungs- und Gewährleistungsauschluss und dem Hinweis auf den Urheber weitergegeben werden. Der maschinenlesbare Code in seiner binären Form muss alle oben genannten Anlagen entweder in Dokumentationsform zur Soft- ware oder in anderer Weise beinhalten. Somit schließt die BSD Lizenz durch ihre aus- drückliche Erlaubnis „Redistributions and use in source and binary forms, with or without modification, are permitted …“⁶⁰ auch den Gebrauch ihres Quellcodes in proprietärer Software mit ein, sofern die auferlegten Informationspflichten erfüllt sind.

[...]

---

¹ Vgl. Bundesministerium für Wirtschaft und Arbeit (1999), online

² Die Abkürzung VDI/VDE-IT steht für: Verein Deutscher Ingenieure e.V. / Verband der Elektrotechnik Elektronik Informationstechnik e.V.

³ Vgl. Bundesministerium für Wirtschaft und Arbeit (2003), S. 6

⁴ Vgl. Bundesministerium für Wirtschaft und Arbeit (2003), S. 7

⁵ Gespräch mit Knoll, G. (2005a)

⁶ Vgl. Knoll, G. u.a. (2004a), S. 3 f.

⁷ kurz BMWA

⁸ Vgl. Knoll, G. u.a. (2004a), S. 3ff

⁹ Vgl. Knoll, G. u.a. (2004a), S. 18 ff. und Gespräche mit Knoll, G. (2005b) und Tischer, R. (2005)

¹⁰ Vgl. Knoll, G. u.a. (2004a), S. 18 ff. und Gespräche mit Knoll, G. (2005b) und Tischer, R. (2005)

¹¹ von bis zu 30 Arbeitstagen

¹² Als M2A Core wird das Naming und Routing bezeichnet.

¹³ Vgl. Knoll, G. u.a. (2004b), S. 32

¹⁴ Vgl. Knoll, G. u.a. (2004b), S. 10 ff. und Knoll, G. u.a. (2004a), S. 12 ff. und Gespräche mit Knoll, G. (2005b) und Tischer, R. (2005)

¹⁵ Zum Beispiel: Roboter, Handy Smartphone, Desktop Computer, Laptop

¹⁶ Gespräche mit Knoll, G. (2005b) und Tischer, R. (2005)

¹⁷ Vgl. Gehring, R. u.a. (2004), S. 6 f. und Vgl. O’Reilly, T. (1999), S. 2 und Vgl. Open Source Initiative (2000), online

¹⁸ Die Open Source Initiative ist die Weiterentwicklung der 1985 von Richard Stallman gegründeten Free Software Foundation. (Vgl. Free Software Foundation (1999a), online und Vgl. Gehring, R. u.a. (2004), S. 5)

¹⁹ Vgl. Gehring, R. u.a. (2004), S. 7

²⁰ nachfolgend proprietäre Software genannt

²¹ Vgl. Gläßer, L. (2004), S. 22

²² Vgl. Technische Universität München (1995), online

²³ Die kommerzielle Weiterverbreitung von verändertem Code nicht gestattet. Hierfür muss eine kostenpflichtige Version der Software von Microsoft erworben werden.

²⁴ Sollte der Quelltext in modifizierbarer Form vorliegen, so wird aus Public Domain Software Open Source Software.

²⁵ Vgl. Gehring, R. u.a. (2004), S. 10 f.

²⁶ Vgl. Nüttgens, M. u.a. (2000a), S. 14

²⁷ Gehring, R. u.a. (2004), S. 3

²⁸ Vgl. Open Source Initiative (2000), online

²⁹ Vgl. Böken, A. (2004), S. 106

³⁰ Vgl. Schiffner, T. (2002), S. 4 ff. und Vgl. Gehring, R. u.a. (2004), S. 3

³¹ Mehr zu den Lizenzrechten und ihren Auflagen an den Nutzer werden im anschließenden Kapitel gegeben.

³² Vgl. Perens, B. (1997), online

³³ Vgl. Ronneburg, F. (1999), online

³⁴ Vgl. Open Source Initiative (2000), online

³⁵ Vgl. Computerbase (2004), online und Vgl. Cohausz, H. B. u.a. (2004), online

³⁶ Wie beispielsweise dem Urheberrecht.

³⁷ Vgl. Cohausz, H. B. u.a. (2004), online

³⁸ Abgekürzt: EULA Vgl. Computerbase (2004), online

³⁹ Vgl. Schäfer, D. u.a. (2004), online und Vgl. Computerbase (2004), online

⁴⁰ Vgl. Roehrl, A. (2002), S. 170 und Vgl. Landgericht München (2004), online

⁴¹ Vgl. Böken, A. (2004), S. 106

⁴² Vgl. Gläßer, L. (2004), S. 7

⁴³ Vgl. Open Source Technology Group (2001), online

⁴⁴ Vgl. Open Source Technology Group (2001), online

⁴⁵ Vgl. Böken, A. (2004), S. 106 f. und Vgl. Institut für Rechtsfragen der Freien und Open Source Software (2000), online und Vgl. Spindler, G. (2004), S. 342 und Vgl. Jaeger, T. (2000), online

⁴⁶ Vgl. Jaeger, T. (2000), online und Vgl. Jaeger, T. u.a. (2001), S 4 f.

⁴⁷ Vgl. Free Software Foundation (1989), online

⁴⁸ Vgl. Institut für Rechtsfragen der Freien und Open Source Software (2000), online

⁴⁹ Die Lizenz lag zum Zeitpunkt der Diplomarbeitserstellung in Version 2, vom Juni 1991 vor.

⁵⁰ Vgl. Kapitel 4.2

⁵¹ Vgl. Free Software Foundation (1989), online und Vgl. Lachmann, K. (2000), online und Vgl. Jaeger, T. u.a. (2001), S. 31 - 52

⁵² Vgl. Böken, A. (2004), S. 106

⁵³ Vgl. Mozilla Organization (1998), online

⁵⁴ Vgl. Mozilla Organization (1998), online und Vgl. Jaeger, T. u.a. (2001), S. 61 - 63

⁵⁵ Mozilla Organization (1998), online

⁵⁶ Vgl Mozilla Organization (1998), online und Vgl. Spindler, G. (2004), S. 346

⁵⁷ Vgl. University of California (1994), online

⁵⁸ Vgl. Apache Software Foundation (2004b), online

⁵⁹ Vgl. University of California (1994), online Vgl. Jaeger, T. u.a. (2001), S. 54 f. und Vgl. Bold, M. (2003), S. 28

⁶⁰ University of California (1994), online