Anwendung semantischer Technologien für die Modellierung und Analyse von Lizenzen im Bereich der Open Source Software

Inhaltsverzeichnis

1 EINLEITUNG

2 GRUNDLAGEN
2.1 Lizenzen im Bereich der Open Source Software
2.1.1 Der Open Source-Begriff
2.1.2 Probleme bei der Weiterverwertung von OSS
2.1.3 Bedingungen ausgewählter Lizenztexte
2.1.3.1 General Public License V2
2.1.3.2 Lesser General Public License V2.1
2.1.3.3 Berkeley Software Distribution License
2.2 Expertensysteme
2.2.1 Logik
2.2.1.1 Aussagenlogik
2.2.1.2 Prädikatenlogik
2.2.1.3 Beschreibungslogik
2.2.2 Wissensrepräsentation
2.2.2.1 Anspruch und Technologie des Semantic Web
2.2.2.2 Das Resource Description Framework RDF
2.2.2.3 Die Web Ontology Language OWL
2.2.2.4 Die Semantic Web Rule Language SWRL
2.2.2.5 Abfragesprachen
2.2.3 Abfrage und Manipulation von Wissen
2.2.3.1 Protégé
2.2.3.2 KAON2

3 EIN EXPERTENSYSTEM FÜR OSS-LIZENZEN
3.1 Aufbau des Expertensystems
3.2 Lizenzkompatibilität im Rahmen des Systems
3.3 Modellierung der Wissensbasis
3.3.1 Lizenzwissen - Primitive Klassen und Klassenbeziehungen
3.3.2 Werke, Lizenzen, Bedingungen - Instanzen der Ontologie
3.3.3 Vervollständigung der Bedingungen durch Regeln
3.3.4 Wissenszuwachs durch definierte Klassen

4 VALIDIERUNG DER FORMALISIERUNG
4.1 Verwendetes System
4.2 Ergebnisse des Regel- und Reasoning-Prozesses
4.3 Bewertung der Ergebnisse

5 DIE LIZENZKOMPATIBILITÄTSSUCHE
5.1 Untersuchungsgegenstand
5.2 Domain Model
5.3 Use Case-Entwicklung
5.4 Spezifikation
5.4.1 Standards, Programmiersprachen und Datenquellen
5.4.2 Nicht-Funktionale Anforderungen

6 ZUSAMMENFASSUNG
6.1 Ergebnisse
6.2 Probleme und offene Fragen
6.3 Ausblick

ANHANG A

Use Case Diagramme

LITERATURVERZEICHNIS

Abbildungsverzeichnis

Abbildung 1: Modifiziertes Layer Cake Diagram

Abbildung 2: Beispiel für ein Triple

Abbildung 3: SWRL-Regeln

Abbildung 4: Expertensystem mit Kaon2 als Inference Engine

Abbildung 5: Zentrale Klasse Lizenz

Abbildung 6: Lizenzbedingung mit zugehörigen Klassen

Abbildung 7: Satz (LicenseParagraph) mit Eigenschaften

Abbildung 8: Lizenzbedingung mit Klassenbeziehungen

Abbildung 9: Formalisierte Lizenzbedingung aus Ziffer 1 der GPL in Protégé

Abbildung 10: Regel aus den Ziffern 4 und 5 der GPL im Protégé SWRL-Editor

Abbildung 11: Definierte Klasse in Protégé für eine Lizenzbedingung

Abbildung 12: Lizenz mit schwachem Copyleft-Effekt als definierte Klasse

Abbildung 13: Gefolgerte Instanzen nach Beendigung des Testlaufts

Abbildung 14: Lizenzkompatibilitätssuche

Abbildung 15: User bei der Suche nach kompatibler Software

Abbildung 16: Wartung und Update der Wissensbasis

1 Einleitung

Gemäß einer Studie zur wirtschaftlichen Bedeutung von Open Source Software im Auftrag der europäischen Kommission im November 2006 ist der Marktanteil dieser Software in den vergangenen fünf Jahren kontinuierlich gestiegen (Ghosh 2006: 11). Private und öffentliche Organisationen setzen Open Source Software vermehrt ein. Der öffentliche Sektor in Europa verbucht dabei vor Asien und Latein-Amerika die höchste Penetration weltweit.

Lizenzen stellen bezüglich der Weiterverwertung von Open Source Software einen entscheidenden Faktor dar. Alle Open Source- Lizenzen genügen den Richtlinien der Open Source Initiative, einer Non-profit- Gemeinschaft, die sich als Unterstützer, Fürsprecher und Integrator der Open Source- Gemeinde sieht, unterscheiden sich jedoch mehr oder weniger stark. Diese Abweichungen innerhalb der Lizenzen behindern den Prozess der Weiterentwicklung von Open Source Software und schaffen rechtliche Unsicherheit. Die Programme lassen sich nicht mehr beliebig kombinieren, sofern das Ergebnis weitergegeben werden soll.⁹ Die einzelnen Lizenzen in einem zusammengesetzten Werk treten in Wechselwirkung und erlauben aufgrund ihrer oft sehr restriktiven Bestimmungen keine freie Lizenzwahl. Um das Potential bei der Entwicklung freier Software vollständig auszuschöpfen, ist es für die Entwickler von entscheidender Bedeutung, zu wissen, welche Funktionen bereits bestehender Software sie in den von ihnen entwickelten Programmen nutzen können. Dieses Wissen kann jedoch nur durch Kenntnis der Lizenzbedingungen erlangt werden.

Diese Arbeit hat sich bezüglich des eben beschriebenen Problems zum Ziel gesetzt, ein Expertensystem zu beschreiben, dass die komplexen Abhängigkeiten verschiedener Lizenzmodelle im Bereich freier Software in einen maschinell verarbeitbaren semantischen Zusammenhang setzt. Informationen, welche Open Source- Lizenzen betreffen, sollen dabei in menschenlesbarer, wie auch in maschinell interpretierbarer Form auf Basis einer Ontologiesprache formell dargestellt und mit Hilfe einer Regelsprache zueinander in Beziehung gesetzt werden. Ein in diesem Zusammenhang entwickelter Formalisierungsansatz für Open Source- Lizenzen und die Realisierung einer daraus resultierenden Wissensbasis werden dabei im Zentrum der Betrachtung stehen. In einem Anwendungsszenario, welches konzeptuell beschrieben wird, soll die Suche einer kollaborativen Open Source- Entwicklungsplattform erweitert werden und dabei Informationen über Lizenzen, wie Lizenztyp, wichtige Lizenzbedingungen und mögliche Lizenzkompatibilität im Suchergebnis verfügbar werden. Auf dieser Grundlage sollen Entwickler freier Software auf Informationen über Lizenzen bestehender Anwendungen zugreifen und so eine vereinfachte Kompatibilitätsprüfung zwischen ihrer eigens angestrebten Lizenz und Lizenzen anderer Entwickler durchführen können. Als Ergebnis soll eine unverbindliche Empfehlung gegeben werden, wie sich Verbundwerke gegen eine Lizenz - Inkompatibilität absichern lassen.

Zur Umsetzung der Ziele wird zunächst das Thema Lizenzen im Bereich der Open Source Software kurz umrissen. Dabei werden Probleme, die sich bei der Nutzung dieser Software bezüglich der Lizenzen ergeben, dargestellt und drei Open Source- Lizenzen vorgestellt. Im weiteren Verlauf wird sich die Arbeit mit dem Aufbau von Expertensystemen im Semantic Web -Kontext beschäftigen und den Stand der Forschung darstellen. Formale Logik, Wissensrepräsentation, sowie Abfrage und Manipulation von Wissen sind zu betrachten. Der folgende Teil entwirft ein Expertensystem und die dazugehörige Wissens- und Regelbasis. Zu diesem Zweck werden drei repräsentative Open Source- Lizenzen analysiert und mit Hilfe einer Ontologie- und Regelsprache in einer Wissensbasis formalisiert. In einem Anwendungsbeispiel wird im weiteren Verlauf die anwendungsorientierte Nutzung der Wissensbasis gezeigt. Dazu sollen Domain Model, Use Cases und einkonzeptionelles Modell entworfen werden. Die Ergebnisse der einzelnen Umsetzungsschritte werden während der Untersuchung in dieser Arbeit schriftlich dargelegt.

2 Grundlagen

Der folgende Abschnitt soll in Bezug auf das zu entwickelnde System zwei Dinge leisten. Zuerst werden der Begriff Open Source Software im Zusammenhang mit Lizenzierung, die sich daraus ergebenden Probleme bei der Weiterverwertung, sowie einige Lizenztexte betrachtet. Ziel ist es, die Bedeutung von Open Source Software zu klären, den Begriff gegen andere Konzepte abzugrenzen und das Problem inkompatibler Lizenzen bei der Kombination von Softwarebestandteilen näher zu beschreiben. Anschließend werden Technologien und deren Grundlagen vorgestellt, die zur Entwicklung von Expertensystemen geeignet sind. Dabei handelt es sich um die Grundlagen formaler Logik und die technischen Möglichkeiten bei der Wissensrepräsentation, Wissensmanipulation und Wissensabfrage. In diesem Zusammenhang werden ausgewählte Bereiche der Semantic Web Vision beleuchtet, eine Ontologie - Sprache und eine Regelsprache vorgestellt, sowie Softwarelösungen zum Einlesen und Verarbeiten von Wissensbeständen betrachtet. Ziel ist es, die für den Hauptteil der Arbeit benötigten Voraussetzungen zu schaffen und das Thema greifbar zu machen.

2.1 Lizenzen im Bereich der Open Source Software

Urheber gelten als Schöpfer von Werken und genießen in Deutschland nach § 1 UrhG Schutz durch das Urheberrechtsgesetz. Da Entwicklungen im Softwarebereich gemäß dieses Gesetzes als Werke angesehen werden, unterliegen auch Computerprogramme seinen Bestimmungen. Nach § 15 Abs. 1 UrhG hat der Urheber das ausschließliche Recht sein Werk zu verwerten, kann Dritten aber nach §3]1 UrhG Nutzungsrechte einräumen. Werden diese vertraglich festgelegt, spricht man von Nutzungsverträgen oder Lizenzen. Bei einem Lizenzvertrag handelt es sich um einen durch das Bürgerliche Gesetzbuch (BGB) nicht näher definierten Vertragstyp^[1]. Dieser ermöglicht es z.B. dem Rechteinhaber, einem Lizenznehmer zustimmungsbedürftige Handlungen, wie z.B. die Vervielfältigung eines Computerprogramms, zu erlauben.

Geregelt wird dies in §69 UrhG durch „die Ausschließlichkeitsrechte des Rechtsinhabers, die den Verwertungsrechten bei anderen Werkformen, insbesondere den §§ 16, 17, 19a, 23 UrhG entsprechen und diese im Hinblick auf die Besonderheiten von Software präzisieren.“ (Jaeger/Metzger 2006: 76f)

Lizenzen sind im Open Source- Umfeld nicht ungewöhnlich. Außergewöhnlich ist lediglich ihr Charakter, der sie von anderen Softwarelizenzen unterscheidet. Was diesen besonderen Charakter ausmacht, welche Probleme die Weiterverwertung von Open Source Software mit sich bringt und welche Bedingungen wichtige Open Source - Lizenzen enthalten, sollen die folgenden Kapitel klären.

2.1.1 Der Open Source-Begriff

Grundsätzlich versteht man unter Open Source Software (OSS)^[2] Computerprogramme, die eine unbeschränkte Weiterverbreitung und Nutzung erlauben, sowie keine Lizenzgebühren verlangen. Der deutsche Gesetzgeber hat zu diesem Zweck extra einen Passus in die Rechtsprechung einfließen lassen, der es dem Urheber unter §32 Absatz 3, Satz 3 UrhG gestattet, ein unentgeltliches Nutzungsrecht für jedermann einzuräumen.

Der Quellcode von OSS muss nach den Richtlinien der Open Source Initiative (OSI)^[3] in irgendeiner Form zugänglich sein, sei es durch die direkte Auslieferung mit der Software oder indem er anderweitig frei zugänglich gemacht wird. Nutzungsverträge müssen eine unentgeltliche Weitergabe und auch die Veränderung der Software erlauben, ob nun zur Entwicklung neuer Funktionen oder zur Beseitigung von Fehlern. Zwar wird die Integrität des Autors gewahrt, d.h. er kann darauf bestehen, dass sein eigener Code getrennt von fremden Code, z.B. in Form von Patches, ausgeliefert wird, veränderte Programme einen anderen Namen erhalten und alle Veränderungen wieder unter der Ursprungslizenz verbreitet werden müssen, die Weiterentwicklung unterbinden darf er jedoch nicht. Darüber hinaus existiert eine Reihe von Bedingungen, die nicht an die Einräumung der Rechte bezüglich der Softwarenutzung geknüpft werden können. Insbesondere dürfen keine Personengruppen oder Einsatzbereiche von der Nutzung ausgeschlossen werden. Andere Software darf durch die Lizenzbedingungen nicht beschränkt werden. Die Lizenz muss unabhängig des Produktes gelten, von dem die Software möglicherweise einen Teil darstellt. Die Technologie - Neutralität ist zu wahren. Der Lizenztext darf also keine besondere Technologie für die Weiterentwicklung oder Verwendung vorschreiben.^[4]

OSS grenzt sich damit von ähnlich klingenden Konzepten, wie Freeware, Shareware und Public Domain Software ab,^[5] wobei es sich bei den beiden ersten Arten um Closed Source Software handelt, die entweder kostenlos oder vorübergehend kostenlos zum ausprobieren genutzt werden kann. Public Domain Software ist in keiner Weise geschützt, da der Autor auf seine Rechte verzichtet und das Werk damit, sofern es die Rechtsprechung zulässt, gemeinfrei wird (Fogel/Barkhau 2005: Lizenzen, Urheberrecht und Patente).

Der mit OSS in Zusammenhang stehende Gedanke geht auf die Anfänge der Computerentwicklung in den 1960er Jahren zurück, als Programme und Rechner als untrennbare Einheit aufgefasst wurden (Grassmuck 2004: 202). Zu dieser Zeit entwickelten Ingenieure und Programmierer Computer und Software in der Regel als Auftragsarbeit speziell zum Einsatz in bestimmten Projekten. Da der Source Code stets offen war, konnten Hersteller und Kunde die Programme zum gegenseitigen Nutzen weiterentwickeln. Ein in den USA angestrengtes Kartellverfahren gegen IBM wegen Bundling von Hard- und Software, sowie die Entwicklung von Computern für den Massenmarkt, führten in der Folgezeit zur Trennung des Hard- und Softwaremarktes (Jaeger/Metzger 2006: 9). Software wurde proprietär und als Betriebsgeheimnis gehütet. Als Reaktion auf dieses neue Paradigma in der Softwareentwicklung gründete Richard Stallmann 1984 das GNU-Projekt.^[6] Dabei schufen die Mitglieder ein alternatives Entwicklungsmodell, das jedem den freien Zugang zu der daraus hervorgehenden Software ermöglichen sollte. Um sich gegen Missbrauch abzusichern und das neue Prinzip voranzutreiben, gestaltete Stallmann 1989 zudem die General Public License (GPL) (Jaeger/Koglin/Kreutzer 2005: 1). Das Grundprinzip der GPL verbirgt sich hinter dem Begriff Copyleft. Die oben beschrieben Richtlinien von OSS sind von dem Copyleft-Gedanken abgeleitet und bilden damit gewissermaßen seine nachgelieferte Grundlage. Die Besonderheit beim Copyleft ist, dass die weitreichenden Bestimmungen der Copyleft-Lizenz auch bei der Weitergabe der Software in veränderter oder unveränderter Form erhalten bleiben, dem Empfänger also das Recht, die Software ebenfalls zu verändern und weiterzugeben, garantiert wird (Free Software Foundation 2005: What is Copyleft?). Als Linus Torvalds 1992 die erste Version von Linux unter die GPL stellte, wurde damit der Startschuss für die Entwicklung eines freien Betriebssystems gegeben, deren Entwicklungsprinzipien in der GPL eine rechtliche Absicherung fanden.

2.1.2 Probleme bei der Weiterverwertung von OSS

Die GPL hat zwar aufgrund ihrer weiten Verbreitung die größte Bedeutung unter den Open Source-Lizenzen, ist aber nicht die Einzige. Bis heute zählt die Open Source Initiative über 60 weitere Lizenzen.^[7] Prominente Beispiele sind die Mozilla Public License, die Lesser General Public License, und die New Berkeley Software Distribution License. Alle diese Lizenzen genügen den Richtlinien der OSI, unterscheiden sich jedoch mehr oder weniger stark. Dabei entsteht ein Problem, was die freie Weiterentwicklung von OSS nicht nur behindert, sondern rechtliche Unsicherheit schafft. OSS lässt sich nicht mehr beliebig kombinieren^[8], sofern das Ergebnis weitergegeben werden soll.^[9] „Die einzelnen Lizenzen in einem zusammengesetzten Werk treten in Wechselwirkung“ (Grassmuck 2004: 302) und erlauben aufgrund ihrer oft sehr restriktiven Bestimmungen keine freie Lizenzwahl. Das zeigt sich im besonderen Maße bei der GPL V2 in Ziffer 6: „You may not impose any further restrictions on the recipients' exercise of the rights granted herein.“ Das Verbot zusätzlicher Beschränkungen hat besondere praktische Relevanz für den Fall, dass ein GPL - Programm mit Software unter einer anderen Lizenz, auch einer anderen Open Source- Lizenz, zu einem neuen Programm verbunden wird (Jaeger/Metzger 2006: 29). Es kann keinesfalls davon ausgegangen werden, dass Software, die Open Source- Lizenzen unterliegt, problemlos kombiniert werden kann. Inwieweit eine Kombination möglich ist, hängt zum großen Teil vom Charakter der Lizenz ab. Aufgrund ihrer Lizenzbestimmungen führen Open Source -Lizenzen zu einem starken, schwachen oder überhaupt keinem Copyleft- Effekt. Die Frage, wann welcher Copyleft- Effekt vorliegt, kann nicht abschließend beantwortet werden, da die Übergänge fließend sind. Grundsätzlich lässt sich sagen, dass mit schwächer werdendem Copyleft- Effekt, die Fähigkeit, modifizierte Varianten einer Software gegen die Überführung in Entwicklungen unter anderen Lizenzen abzusichern, schwindet, eine Kombination von Programmteilen unter verschiedenen Lizenzen also erleichtert wird. Programme, die unter einem sehr strengen Copyleft stehen, lassen sich dagegen nicht einmal untereinander kombinieren: „Two different copyleft licenses are usually 'incompatible' [...]“ (Free Software Foundation 2007: Copylefted software).

Problemlos gestaltet sich dagegen die Entwicklung von Softwarebestandteilen, die als autonom angesehen werden können. Dies ist der Fall, wenn die Module beispielsweise durch Kommunikationsmechanismen, wie Pipes oder Sockets miteinander verbunden sind. Hier handelt es sich nicht um kombinierte Werke - es gilt das OSS - Prinzip, dass andere Software nicht durch OSS beschränkt werden darf. Lizenzrechtliche Probleme treten in diesem Fall nicht auf. Dahingegen sind einige Lizenzen mit starkem Copyleft, wie z.B. die GPL in der Version 2, im Sinne eines kombinierten Werkes nur zu sich selbst kompatibel, lassen also keine Bedingungen anderer Lizenzen zu. Die Entwickler stehen vor dem Problem, dass komplexe rechtliche Wechselwirkungen bei der Kombination verschiedener Softwarestücke mit unterschiedlichen Lizenzen zu erwarten sind.

2.1.3 Bedingungen ausgewählter Lizenztexte

Für den Entwurf von Kriterien für eine spätere Lizenzanalyse ist eine Untersuchung der im Lizenztext enthaltenen relevanten Inhalte notwendig. Dies bedeutet für das weitere Vorgehen, dass alle Bedingungen aus den Lizenztexten extrahiert werden müssen, um sie einer Untersuchung zugänglich zu machen.

Die Herausforderung besteht darin, unwichtige von wichtigen Passagen zu trennen. Für die Analyse unwichtige Passagen können z.B. nähere Erläuterungen zu den Bedingungen enthalten oder wiederholt auf schon genannte Punkte eingehen. Die wichtige Passagen enthalten Rechte, auf die sich die Lizenznehmer der Software berufen können, und Pflichten, die unter bestimmten Bedingungen erfüllt werden müssen, damit die zugestandenen Rechte nicht verloren gehen, sowie Anmerkungen, die den Anwendungsbereich der Lizenz betreffen.

Bei der nun folgenden Vorstellung der Lizenzen wird der Charakter der entsprechenden Lizenz erläutert und anschließend eine Beschreibung der relevanten Rechte, Pflichten und Anmerkungen vorgenommen.

2.1.3.1 General Public License V2

Die GPL, hier in der Version 2 betrachtet, stellt in vielerlei Hinsicht eine Besonderheit unter den Open Source- Lizenzen dar. Sie ist nicht nur die erste Lizenz ihrer Art und die juristische Umsetzung der Grundüberlegungen zu Freier Software durch die Free Software Foundation (Jaeger/Metzger 2006: 20), in ihr drückt sich auch der Wunsch nach Durchsetzung des OSS - Prinzips mit allen rechtlich festschreibbaren Mitteln aus. Dies zeigt sich vor allem in den Ziffern 2 b) und 6, in denen einerseits festgelegt wird, dass Arbeiten, die von GPL - Programmen abgeleitet wurden, wieder unter den Bedingungen der GPL stehen müssen und andererseits dem abgeleiteten Programm keine darüber hinausgehenden Beschränkungen auferlegt werden dürfen. Dirk Hohndel unterstreicht mit der Aussage, dass sich diese Lizenz „[...] in den Code reinfrisst und nie wieder daraus weggeht“ (Grassmuck 2004: 299), die besondere Radikalität der GPL, die auch als Copyleft bezeichnet wird und mit dem sie eine Abkehr von ihren eigenen Prinzipien zu verhindern sucht.

Auffällig bei der Nutzung von Programmen, die der GPL unterliegen, ist zunächst der Verzicht auf eine Einverständniserklärung mit der Lizenz, die dem Benutzer properitärer Software gewöhnlich vor der Nutzung abverlangt wird. Ziffer 5 weist hier explizit darauf hin, dass niemand, der GPL - Programme nutzt, verpflichtet ist, die zugehörige Lizenz anzunehmen. Das reine Ausführen der Software ist also überhaupt nicht von der Lizenz betroffen, wohl aber das Verändern, Verbreiten und Vervielfältigen. Dabei schließt der Rechteinhaber einen Vertrag mit dem Erwerber der Nutzungsrechte ab. (Jaeger/Koglin/Kreutzer 2005: 9)

Die GPL gewährt Nutzern von Software, die unter GPL - Bedingungen steht, umfangreiche Rechte. So können Kopien des Quelltextes angefertigt, öffentlich zugänglich gemacht und beliebig verbreitet werden. Auch eine Weitergabe veränderter Programme ist möglich (Jaeger/Metzger 2006: 21ff). Zusätzlich ist es erlaubt, wie in Ziffer 1 Satz 2 beschrieben, gegen Gebühr eine Garantie zu gewähren, sowie sich die Kopierkosten für das Programm erstatten zu lassen. Die Weitergabe der Software in binärer Form, verändert oder unverändert, ist nach Ziffer 3 ebenfalls gestattet. Allerdings sind all diese Rechte an bestimmte Pflichten geknüpft, die im Folgenden beschrieben werden sollen.

Die Pflichten, welche aus der Lizenz erwachsen, sind im wesentlichen in den Ziffern 1­3 geregelt. Die Ziffern 4 und 5 beschreiben noch einmal explizit, wann eine Handlung in den Anwendungsbereich der Lizenz fällt. Ziffer 6 unterstreicht den Copyleft- Charakter der GPL aus Ziffer 2b, während 7 und 8 sich mit der Durchsetzbarkeit der Rechte in verschiedenen Rechtsräumen auseinander setzen. Paragraph 9 regelt den Umgang mit neuen Versionen der GPL und 10 enthält Hinweise für Autoren, die Teile von GPL - Programmen unter abweichenden Bedingungen nutzen möchten. Die Paragraphen 11 und 12 beschreiben den Haftungsausschluss. Ein genauer Blick in die einzelnen Bedingungen soll nun Vorarbeit für die Formalisierung der Lizenztexte leisten.

Die Ziffer 1 beschreibt die Weitergabe der Software. Soll GPL - Software weitergegeben werden, dürfen die Original - Lizenzbedingungen, sowie der Haftungsausschluss nicht verändert werden, ein Copyrightvermerk, die Lizenzbedingungen und der Haftungsausschluss sind mit dem Programm zu veröffentlichen.

Alle eben genannten Bedingungen gelten ebenso für die Weitergabe einer veränderten Version des Programms, beschrieben in Ziffer 2. Laut Lizenztext handelt es sich dabei in der Regel um ein auf dem Programm basierendes Werk. Eigene Entwicklungen, die nicht auf dem Werk basieren, da sie eigenständige und unabhängige Einheiten darstellen, werden dagegen nicht von der GPL erfasst. Dies wird explizit in Ziffer 2 in den Abschnitten 2,3 und 4 geregelt: „If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.“ Damit unterstreicht die Lizenz den Open Source- Grundsatz, keine eigenständigen Arbeiten anderer zu beschränken (Coar 2007). Darüber hinaus ist bei der Weitergabe eines auf dem Programm basierenden Werkes ein Änderungsvermerk bezüglich der vorgenommen Modifikationen anzubringen und die Original - Lizenzbedingungen sind unverändert zu übernehmen. Wird das Programm interaktiv ausgeführt, ist zu Beginn der Copyrightvermerk, der Haftungsausschluss, ein Hinweis auf die Möglichkeit der Weitergabe der Software und ein Verweis auf den Ort, wo die Lizenz eingesehen werden kann, anzuzeigen.

Ziffer 3 regelt den Fall, dass ein Programm in ausführbarer Form weitergegeben werden soll, da ein wesentlicher Charakterzug von Open Source Software der Zugang zum Quellcode ist. Hier ist in erster Linie sicherzustellen, dass der Source Code zugänglich gemacht wird (Jaeger/Metzger 2006: 25). Dies kann auf unterschiedliche Art und Weise geschehen. Wichtig ist, dass der Code verfügbar ist. Darüber hinaus gelten die Bedingungen von Ziffer 1 und 2 bezüglich der Weitergabe und Veränderung von Programmen.

Paragraph 4 unterstreicht, dass ein Weiterverbreiten, Verändern und Vervielfältigen nur in der durch die Lizenz ausdrücklich gestatteten Weise erlaubt ist und alle anderen Handlungen zur Beendigung der Rechte aus der Lizenz führen. Diesbezüglich weist auch Ziffer 5 darauf hin, dass jeder Nutzer mit dem Akt der Verbreitung, Veränderung und Vervielfältigung die GPL in ihrem vollen Umfang akzeptiert. Damit enthält der Lizenztext eine konkrete Regel, wie im Falle einer Rechtsverletzung zu verfahren ist und bildet die Grundlage für Angebot und Annahme des Lizenzvertrages. Das Landgericht München hat diese Regelung auch nach deutschem Recht im Rahmen eines Rechtsstreites als gültig anerkannt und sieht in ihr eine auflösende Bedingung, mit deren Eintreten die Rechte in vollem Umfang an den Lizenzgeber zurückfallen. (Kreutzer 2004: Gründe für GPL-Urteil)

Ziffer 6 erweitert die Ziffer 2b in der Form, dass nicht nur die Bedingungen der GPL in vollem Umfang zu erfüllen sind, sondern das darüber hinaus keine weiteren Bedingungen hinzugefügt werden dürfen, die nicht in der GPL aufgeführt sind (Jaeger/Koglin/Kreutzer 2005: 17).

Die Ziffern 7 und 8 beschreiben die Anwendung der GPL in Rechtsräumen, die bestimmte Bedingungen, die aus ihr hervorgehen, nicht zulassen. Da an dieser Stelle aber eine davon unabhängige Betrachtung vorgenommen werden soll, ist dieser Teil für die Arbeit nicht relevant. Ebenso verhält es sich mit den Ziffern 9 und 10, die sich mit der Möglichkeit neuer Versionen der GPL beschäftigen und Hinweise für die Weiterverwendung von GPL-Bestandteilen, aber keine konkreten Bedingungen, enthalten.

Der Haftungsausschluss für GPL-Programme findet sich in den Ziffern 11 und 12. Hier wird darauf hingewiesen, dass keinerlei Gewährleistung für das Programm besteht, da es ohne Kosten lizensiert wird.

Zusammenfassung:

Abbildung in dieser Leseprobe nicht enthalten

2.1.3.2 Lesser General Public License V2.1

Die Lesser General Public License (LGPL) wurde speziell für die Besonderheiten von Softwarebibliotheken entworfen, um Anwendungen, die auf wichtige Bibliotheken des Betriebssystems zugreifen müssen, aber proprietär sind, verbesserte Einsatzmöglichkeiten einzuräumen (Jaeger/Metzger 2006: 57). Dabei soll einerseits die Möglichkeit geboten werden, die Bibliothek in Zusammenhang mit unfreier Software zu verwenden, gleichzeitig aber die Verpflichtung bestehen, dass die Bibliothek selbst immer frei bleibt und bei unfreien Erweiterungen ein „reverse engineering“ zulässt (Grassmuck 2004: 291). Dabei muss sichergestellt werden, dass ein zugreifendes Programm immer auch mit einer veränderten Version der Bibliothek nutzbar ist. Dies kann durch die Realisierung geeigneter Schnittstellen oder der Offenlegung des Sourcecodes geschehen (Jaeger/Koglin/Kreutzer 2005: 4). Die LGPL ist insgesamt weniger restriktiv als die GPL. Das zeigt sich in mehreren Ausnahmeregelungen, die z.B. den Wechsel zur einer anderen Lizenz gestatten, die Nutzung der Bibliothek durch proprietäre Anwendungen erlauben und unter den eben genannten Bedingungen sogar eine Kombination von Funktionseinheiten mit Funktionseinheiten der LGPL - Bibliothek ermöglichen, ohne dass das Gesamtwerk unter der LGPL stehen muss (Grassmuck 2004: 290). Diese Ausnahmen finden sich in Ziffer 3, 6 und 7. Ziffer 6 spricht von Werken, die eine LGPL - Bibliothek nutzen, jedoch kein auf ihr basierendes Werk darstellen. In diesem Fall wird dem Entwickler eines proprietären Werkes mit einigen Einschränkungen die Möglichkeit der Weitergabe des Gesamtwerkes unter abweichenden Bedingungen gestattet. Ansonsten ist die Lizenz sehr stark an die GPL angelegt und enthält weite Teile der GPL - Ziffern. Auch das strenge Copyleft gilt im Normalfall für die LGPL, was in Ziffer 2 c) und 10 zum Ausdruck kommt und von von einem abgeleiteten Werk fordert, es als ganzes unter die Bedingungen der LGPL zu stellen und keine weiteren Einschränkungen der zugestandenen Rechte vorzunehmen.

Die Rechte, die sich aus der LGPL ergeben, stimmen im Wesentlichen mit denen der GPL überein. Dem Nutzer ist es gestattet, die Software zu vervielfältigen und zu verbreiten. Dies gilt auch für veränderte Softwarebestandteile. Zudem kann unter bestimmten Bedingungen die Verbreitung als Objektcode erfolgen. Es ist dem Lizenzgeber außerdem erlaubt, eine Gewährleistung gegen Entgelt zu übernehmen und eine Erstattung der Kopierkosten zu verlangen. Eine Besonderheit enthält die Ziffer 3, die es dem Nutz erlaubt ein LGPL - Programm unter die GPL zu stellen (Jaeger/Metzger 2006: 58). Eine weitere Eigenart stellt der eben schon erwähnte Passus in Ziffer 6 dar, der die Lizenz einerseits zu einer Lizenz mit schwachem Copyleft macht, da er eine Kombination der Bibliothek mit proprietärerer Software erlaubt und in diesem Zuge eine Ausnahme definiert, die die in Ziffer 1-5 definierten Pflichten unter bestimmten Bedingungen außer Kraft setzt (Jaeger/Metzger 2006: 59f). Dazu soll bei der Beschreibung der Pflichten noch näher eingegangen werden.

Die LGPL definiert in Ziffer 0 zunächst einige grundlegende Begriffe, die für die Anwendung relevant sind - beispielsweise was unter einer Softwarebibliothek und einem angeleiteten Werk zu verstehen ist. Zudem wird hier bereits festgestellt, dass ein einfaches Ausführen des LGPL - Programms sowie das Ausführen eines anderen Programms unter Verwendung der LGPL - Bibliothek nicht in den Anwendungsbereich der Lizenz fällt.

Ziffer 1 weist darauf hin, dass bei der Verbreitung unveränderter Kopien

Copyrightvermerk und Haftungsausschluss anzuzeigen sind, die Orginal - Lizenzbedingung und Haftungsausschluss unverändert gelassen werden müssen und eine Kopie des Lizenztextes mitgegeben werden muss.

Ziffer 2 definiert bei veränderten und von der Form her abgeleiteten Werken strenge Regeln für die Weitergabe. So muss das Gesamtwerk wieder unter die originalen und unveränderten Lizenzbestimmungen fallen und zudem eine Softwarebibliothek sein, Änderungsvermerke sind an der modifizierten Kopie anzubringen und anwendungsbezogene Funktionen in einer Art und Weise einzubauen, die ein Funktionieren der Bibliothek auch dann noch ermöglichen, wenn das zugreifende Programm bestimmte Funktionen der Bibliothek nicht unterstützt. Auch diese Ziffer enthält einen Hinweis darauf, dass eigenständige, von der Bibliothek unabhängige, Werke nicht den Bestimmungen der LGPL unterworfen sind. Die Bestimmungen von Ziffer 1 gelten ebenfalls.

Ziffer 3 eröffnet dem Nutzer die Möglichkeit, jedes LGPL - Programm unter die Bedingungen der GPL zu stellen, sofern die Lizenzbedingungen entsprechend geändert wurden und stellt fest, dass diese Änderungen nicht mehr rücknehmbar sind.

Ziffer 4 beschäftigt sich mit der Weitergabe von Bibliotheken im Objektcode. Zunächst gelten die Bestimmungen der Ziffern 1 und 2. Da der Quellcode bei dieser Form der Weitergabe nicht eingesehen werden kann, muss er in diesem Fall gesondert mitgeliefert oder anderweitig zur Verfügung gestellt werden. Ziffer 5 führt eine Definition für besondere kombinierte Werke ein. So sind Programme, die eine LGPL-Bibliothek nutzen, als eigenständige Werke anzusehen, während Programme, die eine Bibliothek nutzen und mit ihr gelinkt werden, als abgeleitete Werke definiert und damit strengen Copyleft-Bestimmungen unterworfen sind.

Die Bestimmungen der Ziffer 6 sind die eigentliche Besonderheit der LGPL. Nicht nur das sie eine Verbindung von proprietärerer Software mit der Bibliothek erlauben, sie weisen außerdem darauf hin, dass die zuvor definierten Pflichten nicht wahrgenommen werden müssen, sofern die Pflichten dieser speziellen Ziffer erfüllt werden. Hier wird erlaubt, abgeleitete Werke unter von der LGPL abweichenden Bedingungen zu verbreiten, wenn erkennbar darauf hingewiesen wird, dass eine LGPL-Bibliothek genutzt, die Orginal-Lizenz mitgegeben und auf sie verwiesen wird. Zudem ist ein Copyrightvermerk für die LGPL-Bibliothek anzugeben, wenn das Programm interaktiv ausgeführt wird. Die Bibliothek selbst muss im Quellcode mitgeliefert und alle Änderungen an ihr müssen gemäß den Ziffern 1 und 2 vermerkt werden. Für das zugreifende Programm ist die eigentliche Ausnahme vorgesehen. Hier reicht es, den Objectcode auszuliefern. Die Art des Zugriffs auf die Bibliothek ist ebenfalls geregelt. So soll einen shared library-Mechanismus genutzt werden. Das bedeutet, dass die Bibliothek erst zur Laufzeit in das Programm einzubinden ist. Sofern andere proprietäre Bibliotheken eingebunden werden sollen, die im Widerspruch zu den genannten Bestimmungen stehen, dürfen diese nicht verwendet werden. All diese Bestimmungen sollen einem proprietären Programm den Zugriff auf eine LGPL-Bibliothek ermöglichen, gleichzeitig aber dafür sorgen, dass die Original-Bibliothek frei bleibt und nicht in Abhängigkeit mit dem zugreifenden Programm gebracht wird (Jaeger/Metzger 2006: 61).

Ähnlich gestaltet sich Ziffer 7. Hier wird die Kombination der Bibliothek mit proprietären Software-Bestandteilen erlaubt, sofern die beiden Bestandteile außerdem getrennt und unter ihren jeweiligen Bestimmungen verbreitet werden. Im Gegensatz zu Ziffer 6 ist es aber nicht möglich, dass Gesamtwerk unter abweichende Bedingungen zu stellen. Weiter muss ein Hinweis erfolgen, dass eine GPL - Bibliothek verwendet wurde und wo diese in eigenständiger Form gefunden werden kann.

Ziffer 8 besagt, dass ein Weiterverbreiten, Verändern und Vervielfältigen nur in der durch die Lizenz ausdrücklich gestatteten Weise erlaubt ist und alle anderen Handlungen zur Beendigung der Rechte aus der Lizenz führen. Die folgende Ziffer legt fest, dass jeder Nutzer mit dem Akt der Verbreitung, Veränderung und Vervielfältigung die LGPL in ihrem vollen Umfang akzeptiert.

Das starke Copyleft, dass bis auf Ausnahmen auch für die LGPL gilt, wird noch einmal in Ziffer 10 deutlich. Hier wird festgelegt, dass bei einer Weitergabe keine weiteren Einschränkungen an den Rechten des Empfängers vorgenommen werden dürfen.

Die folgenden Ziffern beschäftigen sich, wie schon in der GPL, mit der Durchsetzung der Rechte in unterschiedlichen Rechtsräumen sowie den Versionsnummern der Lizenz. Die Ziffern 15 und 16 bilden den Haftungsausschluss.

Zusammenfassung:

Abbildung in dieser Leseprobe nicht enthalten

2.1.3.3 Berkeley Software Distribution License

Vom Grad der gewährten Freiheit her betrachtet, kommt die BSD - Lizenz Entwicklern sehr entgegen, die für Erweiterungen eines BSD - Programms Lizenzen mit von ihr abweichenden Bedingungen verwenden möchten. Dies bringt aber auch Probleme mit sich und hatte z.B. zur Folge, „dass Microsoft so frei war, große Mengen FreeBSD - Code in Windows zu verwenden“ (Grassmuck 2004: 299), natürlich ohne das Windows dadurch freier geworden wäre. Die BSD - Lizenz ist eine typische Lizenz ohne Copyleft. Sie besitzt keinen Mechanismus, der eine freie Weiterentwicklung der unter ihr stehenden Software auch für veränderte Bestandteile vorschreibt. Lediglich für bereits vorhandene Bestandteile müssen Pflichten beachtet werden, für geänderten und hinzugefügten Code gibt es keine lizenzrechtlichen Vorgaben. (Jaeger/Metzger 2006: 62f) Veränderungen an der Software können also in proprietäre Entwicklungen überführt werden. Die Bestimmungen der BSD - Lizenz gelten für sie nicht mehr. In ihrer Ursprungsversion enthält die Lizenz eine Werbeklausel, die in allen Werbematerialien den Satz „This product includes software developed by the University of California, Berkeley and its contributors“ vorsieht. Die Neufassung der BSD - Lizenz von 1999, die auch hier betrachtet werden soll, enthält keine solche Klausel mehr (Jaeger/Metzger 2006 :62).

Die Lizenz selbst gewährt dem Nutzer das Recht, die unter ihr stehenden Programme weiterzuverbreiten, zu verwenden und zu verändern. Die Weiterverbreitung kann in binärer Form oder als Sourcecode erfolgen. Neu gegenüber GPL und LGPL ist, dass bereits das Ausführen eines Programms von der Lizenz betroffen ist.

Bei der Verbreitung unveränderter Kopien sind der Copyrightvermerk, eine Liste der Lizenzbedingungen, und der Haftungsausschluss im Quelltext oder als beiliegende Materialien bereitzustellen. Für veränderte Exemplare gilt, dass kein Bezug zur Universität Berkeley und der ursprünglich Beitragleistenden zur Kennzeichnung von daraus hervorgehenden Produkten oder zur Werbung hergestellt werden darf. Für veränderten und hinzugefügten Code existieren darüber hinaus keinerlei Pflichten, außerdem enthält die Lizenz keine Regelung für den Fall, dass der Lizenznehmer gegen die Bedingungen verstößt.

Abbildung in dieser Leseprobe nicht enthalten

2.2 Expertensysteme

Ein Expertensystem stellt eine Softwarelösung dar, deren Zweck es ist, seinem Anwender das darin enthaltene Wissen mithilfe einer Wissensbasis zur Verfügung zu stellen. Das Wissen wird auf Basis einer Logik aufbereitet und situationsabhängig ausgewertet bzw. aktualisiert. Dabei kommen Regeln zum Einsatz, weshalb ein solches System auch regelbasiertes System genannt wird. Von außen betrachtet, erfüllt es lediglich den Zweck, auf Anfragen zu antworten, intern präsentiert es sich jedoch als hochkomplexes Gebilde.

Um zu klären, wie ein solches System funktioniert, werden zunächst einige Prinzipien der formalen Logik als elementare Grundlage von Expertensystemen betrachtet, im folgenden Teil geklärt, wie sich Wissen formal repräsentieren lässt und zuletzt Möglichkeiten vorgestellt, Wissensbasen zu erstellen, abzufragen und zu manipulieren.

2.2.1 Logik

Logik, ursprünglich eine Disziplin der Philosophie, beschäftigt sich mit dem Problem, Gesetzmäßigkeiten des Denkens zu beschreiben (Zeitz/Mahr 2001: 223). Den Mittelpunkt der Untersuchung bilden Aussage und Wahrheit. Dabei geht es um die Verbindung von Aussagen und deren Prüfung auf Wahrheit, und zwar um allgemeingültige Wahrheiten, die unabhängig jeder Interpretation gelten. „In der formalen Logik wird untersucht, wie man Aussagen miteinander verknüpfen kann und auf welche Weise man formal Schlüsse zieht und Beweise durchführt“ (Schöning 1995:

11). In der Informatik wird auf diese Weise versucht, logische Schlüsse in eine Sprache zu übertragen, die sich im semantischen Sinn durch Wohlgeformtheit und syntaxseitig durch den Ausdruck von Bedeutung bzw. des Wahrheitsgehalts auszeichnet. Syntax und Semantik sind innerhalb der Logik streng getrennte Bereiche, wobei die Syntax festlegt, was als Aussage betrachtet wird, während die Semantik als Bedeutungslehre erklärt, wie Interpretationen fixiert werden und einer Aussage ein Wahrheitswert zugeordnet wird (Zeitz/Mahr 2001: 225). Auf diese Weise wird eine automatische Beweisführung und Logikprogrammierung möglich, die für regelbasierte Systeme elementar ist. Der folgende Abschnitt wird daher auf die Bereiche der formalen Logik eingehen, die für den Entwurf eines Expertensystems relevant sind.

2.2.1.1 Aussagenlogik

Die Aussagenlogik behandelt die elementaren Grundlagen der formalen Logik. Ihre Aussagen handeln von Sachverhalten, die in sich eine Menge atomarer, nicht mehr zerlegbarer, Sachverhalte beherbergen, welche durch Aussagensymbole dargestellt werden können. Mithilfe von Aussageverknüpfungen ergibt sich dabei eine Gesamtaussage. Die Aussagenlogik bedient sich der Syntax und Semantik. Betrachtet man die Aussagenlogik als Sprache, gilt: „Die Sätze dieser Sprache sind aussagenlogische Formeln. Ihre Bedeutung ist ein Wahrheitswert, der sich aus einer festgelegten Interpretationsvorschrift ergibt.“ (Zeitz/Mahr 2001: 225)

Dabei werden syntaxseitig Junktorensymbole, P als eine nichtleere Menge von Aussagesymbolen sowie runde Klammern verwendet, um komplexe Aussagen auszudrücken. Junktoren dienen der Verknüpfung von Aussagen. Aussagenlogische Formeln sind die Negation „nicht“ ( -iq ), die Konjunktion „und“ ( qAqJ ), die Adjunktion „oder“ ( qVqJ ), die Subjunktion „wenn ... dann ...“ ( q—' qJ ), die Äquivalenz „genau dann ... wenn ...“ als notwendige und hinreichende Bedingung (q≡qJ ), Verum als „wahr“ (⊤) und Falsum als „falsch“ (⊥). Zur Verbesserung der Lesbarkeit, aber auch zugunsten der Klarheit in den Ausdrücken, werden die Formeln in Klammern gesetzt, so das Konstrukte in der Art ((qVqJ)—' X) bzw. ((qVqJ)AX) entstehen. Die Semantikseite beschäftigt sich mit der Bedeutung formaler Ausdrücke und dort insbesondere damit, wie einer aussagenlogischen Formel ein Wahrheitswert zugeordnet werden kann. Dazu benötigt man P als eine Menge von Aussagesymbolen, sowie T und F als Wahrheitswerte. Eine Wahrheitsbelegung ist diesbezüglich eine Abbildung in der Form B: P -' { T ,F } , deren indizierte Abbildung eine Auswertung der aussagenlogischen Formel darstellt.

2.2.1.2 Prädikatenlogik

Die Prädikatenlogik ist eine Erweiterung eines Teils der Aussagenlogik, mit der sich Sachverhalte formal beschreiben und auf ihre Gültigkeit prüfen lassen. Ausdruckskraft, sowie Komplexität und Anwendungsmöglichkeiten nehmen durch die Verwendung von Prädikationen, Gleichheiten und Quantifikationen in Bezug auf Individuen zu. Es handelt sich dabei um Ausdrucksmittel, die es dem Anwender erlauben, über Individuen bzw. Gegenstände zu sprechen, sie zu identifizieren, aber auch funktionale und relationale Beziehungen zwischen ihnen darzustellen – kurz, Objekte zu beschreiben, die bestimmte Eigenschaften besitzen. Sachverhalte, die sich auf diese Weise als Eigenschaften der Gegenstände ergeben, können deutlich differenzierter als in der Aussagenlogik dargestellt werden. Als atomare Formeln kommen die schon aus der Aussagenlogik bekannten Aussagesymbole Verum und Falsum, sowie als neue Elemente Variablen, Konstantensymbole, die ihrerseits die Individuen bezeichnen, sowie Relationssymbole, Funktionssymbole und das Gleichheitszeichen zum Einsatz. In zusammengesetzten Formeln stehen zudem Junktoren zur Verfügung. Variablen lassen sich anstelle von Individuen setzten, die aus einer bestimmten Menge kommen und auf die eine spezielle Aussage zutrifft oder als Platzhalter für Individuen, die während der Interpretation einer Formel noch nicht festgelegt sind. (Zeitz/Mahr/Robering 2001: 328 ff)

Bezüglich einer Lizenz könnte die Aussage getroffen werden _ hat-einen-Lizenznamen. Innerhalb der Prädikatenlogik ergäbe sich für die GPL das Konstrukt hat_Lizenznamen(GPL), wobei die GPL das Konstantensymbol darstellt und hat_Lizenznamen das Relationssymbol, also die Eigenschaft einen Lizenznamen zu haben. Aussagen könnten auch in der Form ist_stark(Copyleft(GPL)) getroffen werden.

Gleichheit wird mit den Gleichheitszeichen ausgedrückt: (CopyleftEffekt(GPL)=CopyleftEffekt(OSL)). Konkret wird die innere Struktur solcher Aussagen, die Aussageverknüpfung, betrachtet. Im ersten Beispiel ist das Prädikat durch _ hat-einen-Lizenznamen festgelegt. Am Anfang der Wortgruppe existiert eine Leerstelle, die mit '_' gekennzeichnet wurde. Je nachdem, mit welchem Individuum diese Leerstelle gefüllt wird, ergibt sich eine wahre oder falsche Aussage. Da es sehr aufwändig wäre, für jedes einzelne Individuum eine Aussage zu treffen, existiert das Sprachmittel Quantor. Damit lässt sich festlegen, für wie viele Individuen eine Aussage zutrifft. Man unterscheidet den Existenzquantor ( ∃ ), welcher aussagt, dass ein Prädikat auf wenigstens ein Individuum zutrifft und den Allquantor ( ∀ ), der Verwendung findet, wenn ein Prädikat auf alle Individuen zutrifft. Somit ließe sich z.B. sagen: Es gibt mindestens ein Ding, für das gilt: Es hat einen Lizenznamen ( ∃ xL x). Diese Form der Logik wird auch Quantorenlogik genannt. Beziehen sich Quantoren nur auf Variablen, handelt es sich um Prädikatenlogik erster Ordnung oder First Order Logic (FOL). FOL hat den großen Vorteil, dass für sie vollständige Inferenzmechanismen existieren. Mit Resolutionsverfahren können Folgerungen maschinell bewiesen werden (Zeitz/Mahr/Robering 2001: 311 ff). Genauer gesagt, kann geprüft werden, ob eine Formel aus einer Wissensbasis ableitbar ist. Prädikatenlogik zweiter Ordnung, die Higher Order Logic (HOL) erweitert diese Variante. Quantoren können nun auch über Prädikate gelegt werden und Prädikate andere Prädikate als Argumente enthalten. Damit steigt die Ausdrucksstärke, aber auch die Komplexität.

Prädikatenlogik ist nicht zwangsläufig entscheidbar. Für einen gegebenen Sachverhalt kann nicht geprüft werden, ob ein gegebenes Faktum darin gilt, nicht gilt, oder gelten kann, es sei denn, es handelt sich um Prädikatenlogik, die mit maximal zwei Variablen arbeitet. (Pellegrini/Blumauer 2006: 489)

[...]

---

¹ Vergleiche dazu die Anmerkungen der Kanzlei „LÜBECK Steuerberater Rechtsanwälte“ zu Lizenzverträgen http://www.luebeckonline.com/mustervertraege/lizenzvertraege.html.

² Der Begriff Open Source Software entstand durch Abstimmung bei einer Tagung verschiedenerer Anhänger der Free Software -Szene 1998 in Palo Alto, Kalifornien (Tiemann 2006: The 'open source' label). Zu diesem Zeitpunkt waren Computerprogramme, die nun unter OSS zusammengefasst werden sollten, vorrangig als Free Software bekannt. Bis heute existieren beide Begriffe nebeneinander, wobei die Befürworter von Free Software sich eher als Idealisten sehen, die mit dem Konzept der freien Softwareentwicklung auch gesellschaftliche Ziele verfolgen, während der pragmatischere Begriff Open Source Software eine vorrangig technische Sicht auf das Wessen der Programme offenbart. Beide Begriffe, wie auch der Begriff Free and Open Source Software (FLOSS), der eine Brücke zwischen den beiden anderen Formulierungen zu schlagen versucht, bezeichnen die gleiche Art von Software.

³ Innerhalb dieser Arbeit wird die Open Source Definition der OSI für die Begriffsklärung herangezogen. Alternativ existiert die Definition der Free Software Foundation für F ree Software unter http://www.fsf.org/licensing/essays/free - sw.html.

⁴ Eine vollständige Definition des Open Source -Begriffs durch die Open Source Initiative findet sich auf http://opensource.org/docs/osd.

⁵ Zur näheren Definition dieser Konzepte vergl. Grassmuck 2004: 287f.

⁶ Eine Beschreibung des Projektes kann auf http://www.gnu.org/gnu/manifesto.html eingesehen werden.

⁷ Eine alphabetisch geordnete Liste anerkannter Open Source-Lizenzen der OSI ist auf http://www.opensource.org/licenses/alphabetical verfügbar.

⁸ Unter kombinierten oder abgeleiteten Werken versteht man, angelehnt an den Lizenztext der GPL, zum einen nicht voneinander abgeleitete Programme oder Softwarebestandteile, die ein Ganzes bilden, also keine eigenständig funktionierenden Einheiten darstellen und zum anderen voneinander abgeleitete Softwarebestandteile (Jaeger/Metzger 2006: 35) .

⁹ Für den privaten oder unternehmensinternen Gebrauch kann Software unter der GPL sehr wohl mit Code, der anderen Lizenzen unterliegt, kombiniert werden.