INHALTSVERZEICHNIS

   I

Inhaltsverzeichnis   

ABBILDUNGSVERZEICHNIS   

   IV

TABELLENVERZEICHNIS   

   V

1.  EINLEITUNG  

   1

1.1  Problem  1

1.2  Zielsetzung und Aufbau  2

2.  M2A - DAS PRODUKT  

   4

2.1  Produktvorstellung  4

2.2  Zielsetzung von M2A  4

2.3  Architektur  5

2.3.1.  Abstrakt  5

2.3.2.  Konkret  6

2.3.3.  Gegenüberstellung von abstrakter und konkreter Architektur  7

2.4  Funktionsablauf  8

2.5  Technologieübersicht  10

3.  BEGRIFFSBESTIMMUNGEN ZU OPEN SOURCE  

   11

3.1  Abgrenzung zu anderen Softwarelizenzmodellen  11

3.2  Definition von Open Source  13

4.  LIZENZRECHT IM OPEN SOURCE BEREICH  

   15

4.1  Einführung  15

4.2  Überblick über den Einsatz von Open Source Lizenzen  16

4.3  Klassifizierung der Open Source Lizenzen  18

4.3.1  Lizenzen mit rigiden Copyleft Bestimmungen  18

4.3.2  Lizenzen mit beschränkten Copyleft Bestimmungen  19

4.3.3  Lizenzen ohne Copyleft Bestimmungen  20

4.3.4  Lizenzen mit Wahlmöglichkeiten  21

4.3.5  Lizenzen mit Sonderrechten  22

4.4  Open Source Lizenzen - Verwendung in einem Software Projekt  22

INHALTSVERZEICHNIS

   II

5.  LIZENZRECHTLICHE BEEINFLUSSUNG VON M2A  

   26

5.1  Apache Cocoon Project 2.1.6  26

5.2  Apache Tomcat 5.5.4  27

5.3  Apache Project Avalon 4.2.0  27

5.4  CC/PP  27

5.5  Eclipse 2.1  28

5.6  EclipseUML 1.0.0  28

5.7  Java SDK 1.4.2  29

5.8  JBoss Application Server 4.0.1  30

5.9  JBoss IDE-Plugin 1.3.0  31

5.10  JMS  31

5.11  JMX  32

5.12  JUnit 3.8.1  32

5.13  Log4J 1.2.7  33

5.14  MySQL Database Server  33

5.15  Xerces 1.4.4  34

5.16  XML  34

5.17  Zusammenfassung  35

6.  KONZEPT DER WETTBEWERBSSPEZIFISCHEN ZUSAMMENHÄNGE  

   37

6.1  Begriff des Geschäftsmodells und Einbettung im Konzept der  

wettbewerbsspezifischen  Zusammenhänge  37

6.2  Wettbewerbssituation  39

6.2.1  Branchenstruktur  40

6.2.2  Interaktion der Marktteilnehmer  42

6.2.3  Entwicklungsdynamik der Branche  43

6.3  Wettbewerbsstrategie  43

6.3.1  Geschäftsfelder  43

6.3.2  Wettbewerbsposition  44

6.3.3  Wettbewerbsvorteil  45

6.3.4  Kernkomptenzen  46

6.3.5  Ressourcen und Fähigkeiten  46

INHALTSVERZEICHNIS

   III

6.4  Geschäftsmodell - Teilmodelle  47

6.4.1  Prozessmodell  47

6.4.2  Teilnehmermodell  48

6.4.3  Erlösmodell  48

6.4.4  Transaktionsmodell  49

6.5  Interdependenzen der wettbewerbsspezifischen Kräfte  50

7.  GESCHÄFTSMODELLE IM OPEN SOURCE BEREICH  

   52

7.1  Praktizierte Open Source Geschäftsmodelle  52

7.2  Geschäftsmodelle von Produktherstellern  53

7.2.1  Distributor  53

7.2.2  Applikationsanbieter  55

7.2.3  Applianceanbieter  61

7.3  Geschäftsmodelle von Dienstleistern  63

7.3.1  Dienstleister  63

7.3.2  Mediator  66

7.4  Evaluierung des Geschäftsmodells  69

7.4.1  Generelle Auswahl der Geschäftsmodelle  70

7.4.2  Betrachtung im Gefüge der wettbewerbsspezifischen  

Zusammenh  änge  74

7.4.3  Auswahl der Open Source Lizenz  78

7.5  Empfehlung  80

8.  AUSBLICK  

   81

LITERATURVERZEICHNIS   

VI

ABBILDUNGSVERZEICHNIS   

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 12 Tab. 2: Unterscheidungsmerkmale der verschiedenen Softwarelizenzen 23 Tab. 3: Übersicht über die Lizenzen von M2A und ihre Einteilung in die Lizenzkategorien 35 Tab. 4: Teilmodelle eines Geschäftsmodells 38 Tab. 5: Übersicht der Transaktionsmodelle 49

1. Einleitung

1.1 Problem

Die Weiterentwicklungen bei mobilen Endgeräten und die Fortschritte der Softwaretechnologie haben in Verbindung mit dem Modernisierungsbedarf bei der Anlagensteuerung in der Halbleiterindustrie dazu geführt, dass ein Konsortium mit der Entwicklung eines universellen und mobilen Kommunikationsframeworks beauftragt wurde.

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 Software soll ein modulares Kommunikationsframework, einen generischen Adapter, sowie eine Anlagenvisualisierung enthalten. Mit diesem Aufbau soll die Lücke zwischen Equipment und dazugehöriger Anwendung innerhalb der Fertigungs- bzw. Laborumwelt 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- Vgl.Bundesministerium für Wirtschaft und Arbeit (1999), online 1

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

Elektrotechnik Elektronik Informationstechnik e.V.

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

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

sortium sieht die weite und nahezu kostenfreie Streuung des Kommunikations-frameworks als Grundlage für ein darauf aufbauendes Geschäftsmodell. ¹ Das Geschäftsmodell wird von den Industriepartnern des Konsortiums übernommen und weitergeführt. Somit soll das Geschäftsmodell den wirtschaftlichen Anforderungen der Praxis genügen, da bei einer ungeeigneten Festlegung erhebliche rechtliche und wirtschaftliche 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 Abstraktions-und 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-

Gesprächmit Knoll, G. (2005a) 1

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

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 Problem ist die Integration von Equipment in die bestehenden Systeme. Die Einbindung

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

kurz BMWA 2

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

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 Abbildung 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 Funktionsumfang des Frameworkes ist mit Hilfe der M2A-Extensions erweiterbar. Es können beispielsweise Workflowsysteme oder Webclients angeschlossen werden.

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

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

2.3.2 Konkret 1

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 Produktionsanlagen. 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 jeglicher Art liegt im generischen Adapter. Dieser wird durch ein Adaptertoolkit, das wie ein Werkzeugkasten für neu anzuschließende Clients funktioniert, generiert. Der Adapter stellt die Schnittstelle zur Kommunikation des neu angeschlossenen Clients an das bestehende Kommunikationsframework dar. Clients können beispielsweise Mobiltelefone, Personal Digital Assistants (PDAs), Laptops, Notebooks und Desktop Computer 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 Nachrichten in Queues. Das Routing, als Begriff innerhalb von M2A, stellt den Zugriff und Vgl. Knoll, G. u.a. (2004a), S. 18 ff. und Gespräche mit Knoll, G. (2005b) und Tischer, R. (2005) 1

von bis zu 30 Arbeitstagen 2

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 Systeme 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

an: Knoll, G. (2004b), S. 32)

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.

Als M2A Core wird das Naming und Routing bezeichnet. 1

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

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.

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 programmierten 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 Nachrichten 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 Route 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- Vgl.Knoll, G. u.a. (2004b), S. 10 ff. und Knoll, G. u.a. (2004a), S. 12 ff. und Gespräche mit Knoll, 1

G. (2005b) und Tischer, R. (2005)

Zum Beispiel: Roboter, Handy Smartphone, Desktop Computer, Laptop 2

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 potenziell möglichen Empfänger und löst über den Naming Service die Empfänger - Adresse - Beziehung auf. Danach wird die Empfängeradresse an die Nachricht angehängt. Im Anschluss übergibt der Routing Service die Nachricht dem Naming Service. Letzterer 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 wandelt 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 ge-normten 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 eingesetzt. 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. 1

· 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.

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

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 ¹ . 2

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. 4

Die Initiative soll die Lücke zwischen handelsüblicher, käuflicher und mit Lizenzrechten versehener Software ⁵ und freier im Sinne von quelloffener Software schließen. Ebenso soll sie als Bindeglied von Open Source Entwicklern und Unternehmen fungieren und Geschäftsmodelle zur wirtschaftlichen Nutzung von Open Source Produkten liefern. 6

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. 1

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

Initiative (2000), online

Die Open Source Initiative ist die Weiterentwicklung der 1985 von Richard Stallman gegründeten 3

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 4

nachfolgend proprietäre Software genannt 5

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

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

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.

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: 3

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.

Die kommerzielle Weiterverbreitung von verändertem Code nicht gestattet. Hierfür muss eine 1

kostenpflichtige Version der Software von Microsoft erworben werden.

Sollte der Quelltext in modifizierbarer Form vorliegen, so wird aus Public Domain Software 2

Open Source Software.

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

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

Ü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 Lizenzgebühren für Shareware und proprietäre Software und zum anderen das Weitergabeverbot 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 nutz-und 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. 5

Um der wachsenden Open Source Gemeinde eine Hilfestellung für die Formulierung von Open Source Lizenzen zu geben, hat die Open Source Initiative eine umfassende Definition über die Gestaltung von Open Source Lizenzen veröffentlicht. Diese Definition beruht auf den von Bruce Perens veröffentlichten Debian Free Software

Gehring, R. u.a. (2004), S. 3 1

Vgl. Open Source Initiative (2000), online 2

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

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

Mehr zu den Lizenzrechten und ihren Auflagen an den Nutzer werden im anschließenden Kapitel 5

gegeben.