Universität der Künste Berlin

Fakultät Gestaltung

Institute of Electronic Business

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

Vorgelegt von:

Markus Schmidt

Abgabedatum:

August 2008

---

---

Inhaltsverzeichnis

1 EINLEITUNG 6

2 GRUNDLAGEN .8

2.1 Lizenzen im Bereich der Open Source Software .8

2.1.1 Der Open Source-Begriff 9

2.1.2 Probleme bei der Weiterverwertung von OSS 11

2.1.3 Bedingungen ausgewählter Lizenztexte 13

2.1.3.1 General Public License V2 13

2.1.3.2 Lesser General Public License V2.1 17

2.1.3.3 Berkeley Software Distribution License 21

2.2 Expertensysteme 22

2.2.1 Logik 22

2.2.1.1 Aussagenlogik 23

2.2.1.2 Prädikatenlogik 24

2.2.1.3 Beschreibungslogik 25

2.2.2 Wissensrepräsentation 26

2.2.2.1 Anspruch und Technologie des Semantic Web 28

2.2.2.2 Das Resource Description Framework RDF 31

2.2.2.3 Die Web Ontology Language OWL 32

2.2.2.4 Die Semantic Web Rule Language SWRL 33

2.2.2.5 Abfragesprachen 35

2.2.3 Abfrage und Manipulation von Wissen 35

2.2.3.1 Protégé 36

2.2.3.2 KAON2 37

3 EIN EXPERTENSYSTEM FÜR OSS-LIZENZEN 39

3.1 Aufbau des Expertensystems . . .40

3.2 Lizenzkompatibilität im Rahmen des Systems .42

3.3 Modellierung der Wissensbasis 44

3.3.1 Lizenzwissen - Primitive Klassen und Klassenbeziehungen 45

3.3.2 Werke, Lizenzen, Bedingungen - Instanzen der Ontologie 54

3.3.3 Vervollständigung der Bedingungen durch Regeln 59

3.3.4 Wissenszuwachs durch definierte Klassen 64

4 VALIDIERUNG DER FORMALISIERUNG . .71

4.1 Verwendetes System 71

4.2 Ergebnisse des Regel- und Reasoning-Prozesses . . 71

4.3 Bewertung der Ergebnisse 73

5 DIE LIZENZKOMPATIBILITÄTSSUCHE 74

---

5.1 Untersuchungsgegenstand .74

5.2 Domain Model .75

5.3 Use Case-Entwicklung .79

5.4 Spezifikation . . 81

5.4.1 Standards, Programmiersprachen und Datenquellen 81

5.4.2 Nicht-Funktionale Anforderungen 82

6 ZUSAMMENFASSUNG .84

6.1 Ergebnisse .84

6.2 Probleme und offene Fragen . . . 86

6.3 Ausblick . .89

ANHANG A

Use Case Diagramme

LITERATURVERZEICHNIS

---

Abbildungsverzeichnis

Abbildung 1: Modifiziertes Layer Cake Diagram 29

Abbildung 2: Beispiel für ein Triple 31

Abbildung 3: SWRL-Regeln 34

Abbildung 4: Expertensystem mit Kaon2 als Inference Engine 41

Abbildung 5: Zentrale Klasse Lizenz 46

Abbildung 6: Lizenzbedingung mit zugehörigen Klassen 49

Abbildung 7: Satz (LicenseParagraph) mit Eigenschaften 52

Abbildung 8: Lizenzbedingung mit Klassenbeziehungen 55

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

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

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

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

Abbildung 13: Gefolgerte Instanzen nach Beendigung des Testlaufts 73

Abbildung 14: Lizenzkompatibilitätssuche 76

Abbildung 15: User bei der Suche nach kompatibler Software 79

Abbildung 16: Wartung und Update der Wissensbasis 80

---

Einleitung

1 Einleitung

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

6

---

Einleitung

1 Einleitung

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 ein

konzeptionelles Modell entworfen werden. Die Ergebnisse der einzelnen

Umsetzungsschritte werden während der Untersuchung in dieser Arbeit schriftlich

dargelegt.

7

---

Grundlagen

2 Grundlagen

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 §31 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 Vertragstyp1. Dieser

ermöglicht es z.B. dem Rechteinhaber, einem Lizenznehmer zustimmungsbedürftige

Handlungen, wie z.B. die Vervielfältigung eines Computerprogramms, zu erlauben.

1 Vergleiche dazu die Anmerkungen der Kanzlei ,,LÜBECK Steuerberater Rechtsanwälte" zu

Lizenzverträgen <http://www.luebeckonline.com/mustervertraege/lizenzvertraege.html>.

8

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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

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

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

9

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source 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

4 Eine vollständige Definition des

Open Source

-Begriffs durch die

Open Source Initiative

findet sich auf

<http://opensource.org/docs/osd>.

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

10

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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 kombinieren8,

6 Eine Beschreibung des Projektes kann auf <http://www.gnu.org/gnu/manifesto.html> eingesehen

werden.

7 Eine alphabetisch geordnete Liste anerkannter

Open Source

-Lizenzen der OSI ist auf

<http://www.opensource.org/licenses/alphabetical> verfügbar.

8 Unter kombinierten oder abgeleiteten Werken versteht man, angelehnt an den Lizenztext der GPL,

11

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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

,

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

9 Für den privaten oder unternehmensinternen Gebrauch kann Software unter der GPL sehr wohl mit

Code, der anderen Lizenzen unterliegt, kombiniert werden.

12

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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

13

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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

14

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source 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

15

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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:

Lizenzname

· General Public License V2

Welche Rechte ergeben sich aus

· Nutzung des Programms

der Lizenz?

· Verbreiten des Programms (Source, Binary)

Auf welche Formen

· Unveränderte Kopien (Alle Pflichten)

weiterzugebender Programme können

· Abgeleitete Werke (Alle Pflichten)

sich diese Rechte beziehen und

· Voneinander unabhängige Teilwerke (keine Pflichten)

welche Pflichten bezüglich der
Urspungslizenz müssen beachtet
werden?

Welchen Copyleft-Effekt ergibt

· Starker Copyleft

-

Effekt

sich aufgrund der Pflichten bei

· Ziffer 2b (Weitergabe unter den Originalbestimmungen)

Annahme des Lizenzvertrages?

· Ziffer 6 (Verbot zusätzlicher Beschränkungen)

16

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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

17

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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.

18

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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

19

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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:

Lizenzname

· Lesser General Public License 2.1

Welche Rechte ergeben sich aus

· Nutzung des Programms

der Lizenz?

· Verbreiten des Programms (Source, Binary)

Auf welche Formen

· Unveränderte Kopien (Alle Pflichten)

weiterzugebender Programme können

· Abgeleitete Werke (Alle Pflichten)

sich diese Rechte beziehen und

· Voneinander unabhängige Teilwerke (keine Pflichten)

welche Pflichten bezüglich der

· Werke, die das LGPL-Programm nutzen, aber von ihm isoliert

Urspungslizenz müssen beachtet

sind (keine Pflichten)

werden?

· Werke, die das LGPL-Programm nutzen und mit ihm kombiniert

wurden (besondere Pflichten)

· Werke, die das LGPL-Programm nutzen und mit ihm gelinkt

wurden (besondere Pflichten)

Welchen Copyleft-Effect ergibt

· Starker Copyleft-Effekt

sich aufgrund der Pflichten bei

- Ziffer 2c (Weitergabe unter den Original-Bestimmungen)

Annahme des Lizenzvertrages?

- Ziffer 10 (Verbot zusätzlicher Beschränkungen)

· Schwacher Copyleft-Effekt

- Ziffer 5 (Möglichkeit zur Verbreitung von Werken, die das

LGPL-Programm nutzen, aber von ihm isoliert vorliegen)

- Ziffer 6 (Möglichkeit zur Verbreitung kombinierter

Software unter beliebigen Bedingungen bei Beachtung einer

Reihe besonderer Pflichten)

20

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

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.

21

---

Grundlagen

2.1 Lizenzen im Bereich der Open Source Software

Zusammenfassung:

Lizenzname

· Berkeley Software Distribution License (New Version)

Welche Rechte ergeben sich aus

· Nutzung des Programms

der Lizenz?

· Verbreiten des Programms (Source, Binary)

Auf welche Formen

· Unveränderte Kopien (Alle Pflichten)

weiterzugebender Programme können

· Abgeleitete Werke (keine Pflichten)

sich diese Rechte beziehen und
welche Pflichten bezüglich der
Urspungslizenz müssen beachtet
werden?

Welchen Copyleft-Effect ergibt

· Kein Copyleft-Effekt

sich aufgrund der Pflichten bei

· Für alle bearbeiteten Programmversionen werden keine

Annahme des Lizenzvertrages?

relevanten Pflichten definiert

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:

22

---

Grundlagen

2.2 Expertensysteme

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" ( ¬

), die Konjunktion ,,und" (

), die

Adjunktion ,,oder" (

), die Subjunktion ,,wenn ... dann ..." (

), die

Äquivalenz ,,genau dann ... wenn ..." als notwendige und hinreichende Bedingung

(

), 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

x

bzw.

x

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,

23

---

Grundlagen

2.2 Expertensysteme

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

24

---

Grundlagen

2.2 Expertensysteme

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)

2.2.1.3 Beschreibungslogik

Die Beschreibungslogik oder

Description Logic

basiert in den meisten Fällen auf

Prädikatenlogik erster Ordnung. Sie kennt jedoch keine Variablen. Im Mittelpunkt

dieser Familie logikbasierter Formalismen stehen Konzepte und individuelle Objekte,

die zur Erstellung einer Wissensbasis geeignet sind. Das Konzept stellt dabei einen

Begriff dar, der für sich selbst steht, sich also nicht mehr weiter zerlegen lässt (z.B.

Lizenz oder Lizenzname). Unter den Eigenschaften werden binäre Relationen

verstanden, die zwei Begriffe miteinander verbinden (z.B.

_hat-Lizenzname

, bezogen

auf die Lizenz). Durch solche Eigenschaften lassen sich Konzepte beschreiben,

25

---

Grundlagen

2.2 Expertensysteme

außerdem ergeben sich Rollen für diese Konzepte. Bei individuellen Objekten handelt

es sich um Instanzen, auf die sich Begriffe und Eigenschaften beziehen, also z.B. die

GPL.

Man unterteilt die so zusammengesetzte Wissensbasis in Terminologie (TBox), die

eine Anwendungsdomäne beschreibt, das sogenannte intensionale Wissen über

Konzepte, und

Assertions

(ABox), wobei es sich um eine Beschreibung der einzelnen

Instanzen oder individuellen Objekte handelt (Pellegrini/Blumauer 2006: 493f). Die

Besonderheit dieses Ansatzes, der vom Prinzip her dem einer relationalen Datenbank

ähnelt, liegt darin, dass die in der TBox enthaltenen Informationen über Konzepte

direkt für Schlussfolgerungen bezüglich der in der Abox vorhandenen Instanzen oder

Entitäten genutzt werden können. Wäre in der TBox das Konzept Lizenz mit der

notwendigen und hinreichenden Bedingung, mindestens einen Lizenznamen zu haben (

Lizenz

hatLizenzname

) vorhanden, würde das Ergebnis einer Anfrage zu

Instanzen, die Lizenznamen haben u.a. GPL ergeben - sofern in der ABox bekannt ist,

dass die GPL eine Lizenz ist. Dabei muss kein explizites Wissen innerhalb der ABox

existieren, dass die GPL einen Lizenznamen hat. Das spezielle Wissen wird aus dem

allgemeinen Wissen in der TBox, Lizenzen haben mindestens einen Lizenznamen und

etwas, was einen Lizenznamen hat, ist zwangsläufig eine Lizenz, abgeleitet.

Die Beschreibungslogik besitzt eine wohldefinierte, logikbasierte Semantik. Alles was

in

Description Logic

beschrieben wurde, kann auch in Prädikatenlogik ausdrückt

werden, alles ist mithilfe von ein- oder zweistelligen Prädikaten und maximal zwei

Variablen erfassbar und damit entscheidbar. Aus diesem Grund eignet sich diese Form

der Logik für automatische Schlussfolgerungen und zur Wissensrepräsentation.

2.2.2 Wissensrepräsentation

Wissen meint die ,,begründbare und begründete Erkenntnis." (Brockhaus 1986:

Wissen) Die Erkenntnis soll dabei im wissenschaftlichen Sinne bestimmten

Überprüfungspostulaten unterliegen und grenzt sich daher von der Meinung, der

Annahme und dem Glauben ab. ,,Sprachlich verfügbares Wissen wird heute in

zunehmendem Maße in Form von Daten und Programmen repräsentiert, maschinell

gespeichert und zum maschinengestützten Problemlösen und Informieren sowie zur

Rationalisierung und Automation von Arbeit genutzt." (Schneider 1991: 896)

26

---

Grundlagen

2.2 Expertensysteme

Repräsentation bedeutet in diesem Zusammenhang die Darstellung des Wissens. Dies

kann beispielsweise in einer Wissensrepräsentationssprache erfolgen und führt zu der

wichtigsten Voraussetzung für ein Wissensrepräsentationssystem, der Wissensbasis

oder

Knowledge Base

. Diese enthält das in der Wissensrepräsentationssprache

formulierte Wissen über ein Anwendungsgebiet, welches in jedem

Wissensrepräsentationssystem vorhanden sein muss (Schneider 1991: 899). Das

Wissensrepräsentationssystem selbst vereint dann Wissensbasis und eine auf die

Wissensrepräsentationssprache ausgelegte

Inference Engine

, die aus explizit

gegebenem Wissen weiteres Wissen erschließen kann.

Für ein System, welches Begriffe und ihre Beziehungen zueinander in einer

Wissensrepräsentationssprache als Wissensbasis repräsentiert, hat sich in der

Informatik der Begriff Ontologie durchgesetzt. Die Philosophie versteht darunter die

,,Lehre von dem Wesen und den Eigenschaften des Seinenden, die zu zeigen hat, was

allen Seienden als solchen gemeinsam ist." (Digel/Kwiatkowski 1980: Ontologie) Sie

beschäftigt sich mit der Klassifikation der Dinge, die sie in Modellen abzubilden

versucht. In der Informatik bezeichnet Ontologie ,,an explicit specification of a

conceptualization." (Gruber 1993: Introduction) Im Wesentlichen geht es dabei um

eine Beschreibung von Wissen über Konzepte und Zusammenhänge, was eine

Klassifizierung von Objekten anhand von Eigenschaften ermöglicht. Das Wissen über

die Konzeptzugehörigkeit eines Objektes lässt dann weitere Schlüsse über das Objekt

und die Beziehung zu seiner Umwelt zu (Pellegrini/Blumauer 2006: 488). Wissen,

dass sich nicht durch bestimmte Begriffe ableiten lässt, wird bei Ontologien mithilfe

von Axiomen ausgedrückt. Es handelt sich dabei um Aussagen, die innerhalb einer

Ontologie stets wahr sind. Im engen Zusammenhang mit dem Ansatz der Ontologie

steht das sogenannte

Reasoning

. Der Begriff ,,bedeutet insbesondere, die Semantik, d.h.

Bedeutung bezüglich einer Anwendung von Dingen zu nutzen, und sich dabei auf

einer festen Basis, einer Logik zu bewegen." (Pellegrini/Blumauer 2006: 485).

Praktische Anwendung finden die Konzepte der formalen Wissensrepräsentation im

Semantic Web

. Darunter versteht man eine Zukunftsvision für das Web, bei der Daten

nicht mehr nur von einzelnen Anwendungen interpretiert und dadurch kontrolliert

werden können, sondern durch die Verknüpfung mit einer allgemein verständlichen

Bedeutung gewissermaßen dem Web an sich zur Verfügung stehen. Was dies im

27

---

Grundlagen

2.2 Expertensysteme

Einzelnen bedeutet und welche Bereiche des

Semantic Web

für diese Arbeit relevant

sind, soll in den nächsten Abschnitten geklärt werden.

2.2.2.1 Anspruch und Technologie des Semantic Web

Das Internet enthält eine Fülle von Informationen, die als elektronische Dokumente in

Form von Dateien vorliegen. Diese werden in verschiedenen Designs, Sprachen und

Formaten präsentiert und sind über Suchmaschinen auffindbar. Der Mensch macht

sich diese Informationen zunutze, indem er sie auswertet und in einen logischen

Zusammenhang bringt. Bei der Suche nach Informationen mit Suchmaschinen entsteht

jedoch ein praktisches Problem, was Tim Berners

-

Lee wie folgt formuliert: ,,While

search engines which index HTML pages find many answers to searches and cover a

huge part of the Web, then return many inappropriate answers. There is no notion of

′correctness′ to such searches." (Berners-Lee 1998: Engines of the Future) Die

Ergebnisse ergeben oft keinen Sinn, da sie mit keiner für die Suchmaschine

verständlichen Bedeutung verknüpft sind. Sinnvoll wäre es dagegen, Daten mit einer

allgemein verständlichen, vertrauenswürdigen und maschinenlesbaren Semantik zu

verknüpfen, um diese für automatische Prozesse verfügbar zu machen. Das Ziel des

Semantic Web

ist es dann, eine Struktur in diese aussagekräftigen Inhalte von

Webseiten zu bringen und damit eine Umgebung zu schaffen, in der

Software

-

Agenten selbstständig komplexe Aufträge für ihre Benutzer ausführen

können (Berners-Lee/Hendler/Lassila 2001: Expressing Meaning) oder abstrakter

ausgedrückt, ein Umfeld zu bieten, dass es Maschinen ermöglicht, automatisch

Informationen mit ausdrücklich zugewiesener Bedeutung zu verarbeiten und

zusammenzuführen.

Um eine Vorstellung des

Semantic Web

zu erhalten, wurden und werden immer wieder

neue Versionen eines Schichtenmodells, dem sogenannten

Layer Cake Diagram

10

entworfen, welches eine abstrakte Vorstellung von den dahinter liegenden

Technologien vermitteln soll. Jede Schicht baut auf den Funktionalitäten der darunter

liegenden Schicht auf und bietet Stück für Stück erweiterte Möglichkeiten im Rahmen

des Gesamtsystems. Abbildung 1 ist an das derzeit aktuelle

Layer Cake Diagram

angelehnt und soll im Folgenden kurz beschrieben werden. Die farbliche Codierung

10 Die aktuelle Version des

Layer Cake Diagram

s findet sich im

Semantic Web

-Bereich des W3C

<http://www.w3.org/2001/sw/> unter ,,Links".

28

---

Grundlagen

2.2 Expertensysteme

trifft keine Aussagen über das Systemmodell, vielmehr soll die Relevanz der einzelnen

Systemelemente für die in der Arbeit dargestellte Entwicklung verdeutlicht werden.

Die grünen Bereiche sind Elementar. Ihr Verständnis ist für die folgende Betrachtung

von entscheidender Bedeutung. Dunkelgraun steht für Standards und Formate, die

zwar für die Realisierung des Systems eine wichtige Voraussetzung darstellen, jedoch

eher Mittel zum Zweck sind und kein tiefer gehendes Verständnis erfordern. Sie

werden nur kurz beschrieben. Die grauen Bereiche sind Teile der

Semantic Web Vision

,

finden aber innerhalb dieser Arbeit keine Anwendung und werden daher auch nicht

betrachtet, sondern lediglich erwähnt.

Trust

Proof

Unifying Logic

C

Ontology

r

Query

Rule

y

RDFS

p

t

o

Data interchange

XML

URI / IRI

Abbildung 1: Modifiziertes

Layer Cake Diagram

Die untere Schicht, die als URI/IRI bezeichnet wird, dient der Adressierung. URI und

IRI sind

Resource Identifiers

, wobei der

Internationalized Resource Identifier

eine

Erweiterung des URI

-

Standards darstellt. Beide bestehen aus einer eindeutigen

Zeichenfolge, die sich aus einem Präfix, dem Schemateil und einem Suffix, dem

schemaspezifischen Teil, zusammensetzt und so eine abstrakte Ressource, wie

beispielsweise ein Dokument, identifiziert. Der IRI ermöglicht dabei eine Codierung

nach dem

Universal Character Set

(Duerst/Suignard 2005: Summary of IRI Syntax),

29

---

Grundlagen

2.2 Expertensysteme

während sich der URI auf den US

-

ASCII

-

Standard beschränkt. (Berners-Lee 2005:

Characters) Darauf baut die

eXtensible Markup Language

(XML), eine erweiterbare

Auszeichnungssprache, die das Verarbeiten, Senden und Empfangen von generischem

SGML über das

World Wide Web

ermöglicht, auf. Innerhalb des

Semantic Web

kommt

ihr die Funktion des Syntax Layers zu, da sie lediglich Namen von Elementen

definiert, ihnen jedoch keine Bedeutung zuordnet. Das Thema

Data interchange

wird

durch das

Resource Description Framework

(RDF) realisiert. Dieses wurde zu den Zweck

geschaffen, Informationen im Web in einer einheitlichen Syntax auf Basis eines

grundlegenden Datenmodells darzustellen (Klyne/Carroll/McBride 2004:

Motivations and Goals). Dieser Teil wird auch

Data Layer

genannt. Die darüber

liegende Schicht setzt sich aus

Query

,

Ontology

/RDFS und

Rule

zusammen. Mit

Query

ist eine Abfragesprache für Wissensbasen gemeint, wie z.B. SPARQL oder modifizierte

SWRL

-

Varianten. Die Ontologie definiert Relationen zwischen Klassen und Instanzen

auf Basis einer Taxonomie. Dabei werden Begriffe in hierarchischen Strukturen

angeordnet und über definierte Assoziationen auf Basis einer Ontologie-Sprache, wie

OWL, dargestellt und mit einer XML

-

Syntax kodiert.

Rule

bezieht sich auf das

Rule

Interchange Format

RIF, dass den Transfer von Regeln zwischen verschiedenen

Regelsystemen und Regelsprachen ermöglichen soll (Boley/Kifer 2007: Abstract). RIF

befindet sich derzeit noch in der Entwicklung. Als eine aktuelle Implementierung kann

SWRL angesehen werden. Dabei handelt es sich um eine Regelsprache, die eine

abstrakte Horn

-

artige Syntax nutzt, mit der sie auf Ausdrücken diverser

OWL

-

DL

-

Konzepte, wie Klassen, Eigenschaften und Instanzen, aufsetzt (O′Connor

2007: What is SWRL). Hier soll auf XML-Basis die beschreibende Logik von OWL,

die vornehmlich der Darstellung von Zusammenhängen zwischen Konzepten dient

(Pellegrini/Blumauer 2006: 492f), um logische Regeln ergänzt werden. Die

Unifying Logic

umfasst das gesamte Gebiet der bis hierher vorgestellten Bereiche, mit

dem

Resource Description Framework

, sowie den Abfrage-, Ontologie- und

Regelsprachen. Alle weiteren Elemente dienen der Sicherheit und Nachweisbarkeit

von Informationen.

Für eine tiefer gehende Analyse werden nun die im

Layer Cake Diagram

grün

gekennzeichneten Bereichen und die damit in Zusammenhang stehenden Technologien

vorgestellt.

30

---

Grundlagen

2.2 Expertensysteme

2.2.2.2 Das Resource Description Framework RDF

Das

Resource Description Framework

besitzt seit 2004 den Status einer

World Wide Web

consortiom

(W3C)

Recommendation

. Eine

Recommendation

ist vergleichbar mit einem

Standard und stellt eine Spezifikation dar, die nach einem intensiven

Entwicklungsprozess verschiedene Status durchlaufen und die Zustimmung der

W3C

-

Mitglieder sowie ihrem Direktor erhalten hat (Jacobs 2003: Kap. 7.1.1). RDF ist

eine formale Sprache und dient dazu, Informationen in einer einheitlichen Syntax auf

Basis eines einfachen Datenmodells darzustellen. Diese Informationen sind simple

Fakten, die aus sogenannten

Triples

bestehen (McBride 2004: Graph Data Model).

License

has LicenseParagraph

License

Paragraph

Abbildung 2: Beispiel für ein Triple

Jedes

Triple

setzt sich aus Subjekt, Prädikat, auch

Property

genannt, und Objekt

zusammen. Eine Menge von

Triples

ergibt einen RDF

-

Graphen, der vorerst

unabhängig von einer konkreten Syntax existiert. In der Praxis kann er in XML als

RDF/XML kodiert werden. Die Graphen drücken eine Anzahl von Fakten aus.

Beziehungen zwischen den Subjekten und dem Objekten werden durch eine

Property

angezeigt, die eine binäre Relation darstellt (McBride 2004: RDF Expression of

Simple Facts).

Das genutzte Vokabular basiert auf URIs. Die Teile des Graphen bestehen aus URI

und optional aus einer URI

-

Referenz, einem Literal oder

Blank nodes

. Das Prädikat

kann nur aus URI und URI

-

Referenz bestehen. Eine URI

-

Referenz ist ein

Unicode string

, ähnlich einem Verweisziel innerhalb eines HTML

-

Dokumentes. Unter

Literalen versteht man Zeichenfolgen, die zur Darstellung der Werte von Basistypen,

wie Strings oder Ganzzahlen genutzt werden.

Blank nodes

können n

-

stufige Relationen

beschreiben, auf die RDF intern jedoch nicht referenzieren kann, das sie keinen Teil

des abstrakten RDF

-

Syntax darstellen (McBride 2004: Blank Nodes).

31

---

Grundlagen

2.2 Expertensysteme

2.2.2.3 Die Web Ontology Language OWL

Die

Web Ontology Language

ist seit 2003 eine W3C

-Recommendation

. Ziel dieser

′Spezifikation′ ist es, einen einheitlichen Standard für Ontologien im

World Wide Web

zu

schaffen, um damit den Inhalt von Informationen zu verarbeiten, anstatt sie nur zu

präsentieren (McGuinness/Van Harmelen 2004: Introduction). Zu diesem Zweck

werden in OWL die Bedeutung von Termen und ihre Verknüpfungen in Vokabularien

repräsentiert.

Die wesentlichen Elemente, mit den OWL arbeitet, sind Klassen, Eigenschaften,

Instanzen von Klassen und Beziehungen zwischen Instanzen. Der Begriff Klasse

kommt aus der Mengenlehre und bezeichnet eine Zusammenfassung von Mengen, in

OWL eine Gruppe von Instanzen, die zusammengehören, weil sie bestimmte

Eigenschaften gemeinsam besitzen. Da es in OWL möglich ist, Klassenhierarchien zu

erzeugen, lassen sich Klassen auch als Unterklassen definieren. Instanzen sind die

Mitglieder von Klassen, die durch ihre Mitgliedschaft auch die Eigenschaften der

Klasse erben. Eigenschaften dienen der Darstellung von Beziehungen zwischen

Instanzen oder zwischen Instanzen und Werten (McGuinness/Van Harmelen 2004:

Language Description of OWL Lite). Sie treten als

ObjectProperty

und

DatatypeProperty

auf, wobei die erste

Property

Relationen zwischen Instanzen und

RDF

-

Literalen sowie XML

-

Schema Datentypen darstellt, während die zweite

Property

Relationen zwischen Instanzen von zwei Klassen verkörpert

(Smith/Welty/McGuinness 2004: Defining Properties). Mit Hilfe von

Klasseneigenschaften lassen sich Schlussfolgerungen über Instanzen ziehen. Auch

Instanzen selbst können spezielle Eigenschaften haben. Ihre Aussagekraft in Bezug

auf das Gesamtsystem ist aber deutlich geringer.

OWL nutzt Möglichkeiten von RDF und RDF

-

Schema durch die Verwendung der

Prefixe

rdf

und

rdfs

in der Syntax, erweitert aber das Vokabular um OWL

-

Ausdrücke

zur Beschreibung von Eigenschaften und Klassen durch das Präfix owl. Somit lassen

sich Relationen zwischen Klassen, wie beispielsweise Disjunktheit darstellen,

Kardinalitäten, Äquivalenzen und

Property

-Typen definieren. Auch die Charakteristika

von Eigenschaften lässt sich festlegen. (McGuinness/Van Harmelen 2004: Why

OWL?) Damit steigen die

Reasoning-

Fähigkeiten gegenüber RDF und RDFS in einer

32

---

Grundlagen

2.2 Expertensysteme

Art, dass die Beschreibung von Daten mittels Metadaten logische Konsequenzen hat.

Die Grundlage bildet dabei die Beschreibungslogik oder

Description Logic

(DL).

OWL ist in drei Untersprachen mit steigender Ausdrucksmächtigkeit gegliedert:

OWL

Lite

, OWL DL und OWL

Full

. OWL

Lite

und OWL DL unterscheiden sich

hinsichtlich ihres Vokabulars und ihrer Kardinalitätsrestriktionen. OWL

Lite

kann nur

Kardinalitätwerte von 1 und 0 darstellen. Das sind lokale Restriktionen, die sich unter

Berücksichtigung einer speziellen Klasse auf eine

Property

anwenden lassen. Bei

OWL DL sind Kardinalitäten von zwei und mehr möglich, außerdem erweitert sie die

Lite-

Variante um einige Vokabularien, die hier nicht explizit besprochen werden

sollen. Wichtig ist, dass OWL DL die maximale Ausdrucksstärke von OWL nutzt,

trotzdem aber vollständige Verarbeitbarkeit und Entscheidbarkeit garantiert. Dies ist

bei OWL

Full

nicht der Fall, da es dem Anwender die syntaktischen Freiheiten von

RDF ermöglicht. OWL

Full

kann daher als Erweiterung von RDF gesehen werden,

während die anderen Varianten nur Erweiterung eines beschränkten RDF sein

können. Der größte Nachteil von OWL

Full

äußert sich darin, dass aufgrund seiner

Freiheiten die Unterstützung aller Features durch eine Software unmöglich erscheint

(McGuinness/Van Harmelen 2004:The three sublanguages of OWL).

2.2.2.4 Die Semantic Web Rule Language SWRL

SWRL kann als Weiterentwicklung von entscheidbaren OWL

-

Varianten mithilfe von

Fragmenten der Prädikatenlogik erster Ordnung betrachtet werden. OWL selbst

,,sieht weder nichtmonotone Vererbung (Default

-

Werte) noch Regeln (oder, formal

gesehen, jegliche Konstrukte, die Variablen benötigen) im allgemeinen Sinn vor."

(Pellegrini/Blumauer 2006: 499) Daher ist zur Realisierung eines regelbasierten

Reasonings

ein Mechanismus notwendig, der logische Regeln über OWL

-

Atomen

definiert. So gesehen stellt SWRL eine Erweiterung der OWL

-

Untersprachen

OWL

Lite

und OWL DL sowie der

Rule

ML, die wiederum eine Implementierung der

Rule Markup Language

in XML

-

Schema ist, dar (Horrocks/Patel-Schneider/Boley

2004: Abstract). Die Regeln lassen sich durchaus als ein Teil der Ontologie betrachten.

Grundlegend nutzt SWRL eine Horn

-

artige Syntax, mit der sie sich auf

OWL

-

Klassen, -Eigenschaften und -Instanzen mithilfe von Variablen bezieht und

neues Wissen über Instanzen durch

Reasoning

generiert. Die dabei genutzten Klauseln

33

---

Grundlagen

2.2 Expertensysteme

sind Disjunktionen atomarer Aussagen. Variablen werden durch ein vorangestelltes

Fragezeichen kenntlich gemacht. Ebenso lassen sich Literale, eine Reihe von

Built-ins

und OWL

-

Restriktionen benutzen. Durch den erweiterbaren

Built-in-

Mechanismus

kann SWRL von einer Regelsprache in eine Abfragesprache verwandelt werden.

Abbildung 3 zeigt einige Beispiele solcher Regeln.

hasParent(?x, ?y) ^ hasBrother(?y, ?z)

hasUncle(?x, ?z)

Person(?p) ^ hasAge(?p,?age) ^ swrlb:greaterThan(?age,17)

Adult(?p)

Person(?p) ^ hasAge(?p,?age) ^ swrlb:greaterThan(?age,17)

query:select(?p, ?age)

Abbildung 3: SWRL

-

Regeln (von oben nach unten): Einfache Regel, Regel mit

Built

-

in und Literal, Regel als Abfrage

Die Regeln bestehen aus dem

Antecedent part

, der Teil, auf den sich später die

Schlussfolgerung bezieht und der auch als

Body

bezeichnet wird und dem

Consequent part

, der die Konsequenz aus der vorangestellten Teil der Regel beinhaltet,

der sogenannte

Head

(Horrocks/Patel-Schneider/Boley 2004: Rules). Zu beiden Teilen

lässt sich folgendes sagen: ,,Both the body and head consist of positive conjunctions of

atoms. SWRL does not support negated atoms or disjunction. Informally, a SWRL rule

may be read as meaning that if all the atoms in the antecedent are true, then the

consequent must also be true." (O′Connor 2007: What ist SWRL) Für die erste Regel

in Abbildung 3 gilt: Wenn ein Individuum X ein Individuum Y als Elternteil hat und

der Bruder von Individuum Y das Individuum Z ist, dann bedeutet dies auch, dass

Individuum Z der Onkel von Individuum X ist, oder anders gesagt, der Bruder des

Vaters einer Person ist der Onkel dieser Person. Tatsächlich kann in der hier

vorgestellten Form kein SWRL in OWL

-

Dateien kodiert werden. Es handelt sich

hierbei nur um eine für Menschen lesbaren Ausdrucksvariante, die auch von einigen

Tools für die einfache Erstellung von Regeln, genutzt wird. Konkret werden wie bei

34

---

Grundlagen

2.2 Expertensysteme

OWL die Möglichkeiten von XML

-

Schema, diesmal mit den Prefix swrlx genutzt, um

die Regeln in einer XML

-

Syntax zu kodieren.

2.2.2.5 Abfragesprachen

Abfragesprachen sind zwar unter dem Punkt

Query

im

Layer Cake

erfasst, haben aber

mit den bis dahin vorgestellten Bereichen, die sich mit der Repräsentation von Wissen

befassen, nur indirekt etwas zu tun. Sie verkörpern vielmehr einen Standard, mit dem

später eine

Query Engine

einen Wissensbestand abfragen soll, stehen also logisch

gesehen zwischen dem erfassten Wissen und der

Query Engine

.

Bei der Vorstellung von SWRL wurde schon gezeigt, dass sich diese Regelsprache

durch

Built-ins

in eine Abfragesprache verwandeln lässt. Auch SPARQL stellt

Möglichkeiten für die Abfrage von Wissensbeständen bereit und wird durch das W3C

als

Query Language

forciert. Es handelt sich dabei um eine Abfragesprache für RDF, die

nach Mustern in Graphen sucht, die ihrerseits aus

Triples

bestehen

(Prud′hommeaux/Seaborne 2007: Making Simple Queries). Dabei wird ein

SPARQL

-query string

und optional eine RDF

-dataset description

abgesetzt. Die Syntax

mit

SELECT

- und

WHERE-

Klauseln erinnert stark an SQL und soll wohl auch daran

angelehnt sein. Das Ergebnis einer solchen Suche kann eine Menge von

RDF

-

Graphen sein. Nachteil, von SPARQL ist, dass sich damit nur auf einem

begrenzten Gebiet Anfragen stellen lassen und kein SWRL

-Reasoning

möglich ist.

Allgemein stellen die beiden hier gezeigten Sprachen ausschließlich Funktionen bereit,

die sich auch durch ein

Manipulation-Framework

, also einer Software, die sich auf die

Abfrage und Manipulation von Wissensbasen versteht, gebündelt mit wesentlich

weiter reichenden Möglichkeiten auf der Basis einer eigenen Syntax erledigen lassen.

2.2.3 Abfrage und Manipulation von Wissen

Die Möglichkeiten der formalen Wissensrepräsentation wären reichlich uninteressant,

wenn es nicht gelänge, die Wissensbestände auch abzufragen, sie zu verändern und die

enthaltenen Regeln anzuwenden. Um diese Dinge zu betrachten, ist es notwendig, die

Struktur des

Layer Cake Diagram

zu verlassen und sich mit der praktischen Nutzung

der bisher vorgestellten Bereiche des

Semantic Web

auseinander zu setzten, mit

Programmen, die Wissensbasen verwalten können.

35

---

Grundlagen

2.2 Expertensysteme

Man unterscheidet dabei Programme, die das Erstellen und Verändern von

Wissensbasen ermöglichen und

Frameworks

, die eine Infrastruktur für das Einlesen

und Verarbeiten von Wissensbeständen bereitstellen. Im ersten Fall handelt es sich

um Tools mit grafischer Oberfläche, die dem Nutzer beim Modellieren von Ontologien

die Schwierigkeiten im Umgang mit kryptischer XML

-

Syntax ersparen sollen, die

zweite Gruppe von Software konzentriert sich auf die Realisierung von

Inferenzmaschinen, auch

Reasoner

oder Theorem

-

Beweiser genannt. In der Regel

stellen diese Systeme API′s bereit, die Entwicklern eine Programmierschnittstelle für

eigene Projekte bieten. Man unterscheidet bei den Inferenzmaschinen zwei Arten des

Schlussfolgerns, die datengetriebene Inferenz und die zielorientierte Inferenz. Die

erste Variante arbeitet auf Basis einer Vorwärtsverkettung von Regeln (

Forward

Chaining

). Aus einem Faktum wird durch eine Regel eine Schlussfolgerung gezogen.

Das Ergebnis kann dann als Voraussetzung für eine weitere Schlussfolgerung mittels

einer weiteren Regel genutzt werden. Diese Methode bietet sich für die einmalige

Berechnung aller Fakten an. Die zweite Form des

Reasoning

s wird

Rückwärtsverkettung oder

Backward Chaining

genannt. Auch hier erfolgt eine

transitive Verknüpfung von Regeln. Ausgangspunkt ist jedoch das Zielobjekt, wobei

analysiert wird, welche Regeln das Ziel als Schlussfolgerung haben. Ist die

Voraussetzung der Regel oder der Wert eines Objektes unbekannt, wird dies aus

anderen Regeln hergeleitet, sofern solche existieren. Damit lassen sich Anfragen

besonders schnell auswerten. Schwierigkeiten bereitet allerdings die Serialisierung

aller Fakten.

Im folgenden Abschnitt wird das Programm

Protégé

vorgestellt, welches sich für die

Modellierung von Wissensbasen eignet und anschließend die datengetriebene

Inferenzmaschine

KAON2

, die eine API für die Anwendungsentwicklung zur

Verfügung stellt.

2.2.3.1 Protégé

Protégé

ist eine plattformunabhängige, auf JAVA basierende, grafische

Open
Source-

Anwendung zum Erstellen und Editieren von Wissensbasen. Sie wurde an der

Stanford University entwickelt und steht unter der

Mozilla Public License

. Damit ist sie

36

---

Grundlagen

2.2 Expertensysteme

kostenlos und frei verfügbar.11

Protégé

nutzt eine erweiterbare

Plugin-

Architektur, die

dem Grundsystem eine Reihe nützlicher

Add-Ons

beschert. Das Bearbeiten von

Wissensbasen auf der Grundlage von OWL wird beispielsweise mithilfe der

OWL

-Extension

über eine gemeinsame Oberfläche realisiert. Damit ist es möglich

Ontologien im RDF- und OWL

-

Format zu speichern, sowie Klassen, Eigenschaften,

und SWRL

-

Regeln zu editieren und zu visualisieren.

Somit lassen sich auf einem relativ einfachen Weg Ontologien modellieren und zur

Weiterverarbeitung abspeichern.

Protégé

ist zudem gut dokumentiert. Es existieren

Wikis, FAQs, Dokumentationen, Folien von Vorträgen, Tutorials, eine Mailingliste

und weiterführende Links auf der Internetseite, sowohl zur Bedienung der Software

selbst, als auch für die damit im Zusammenhang stehenden Bereiche, wie SWRL oder

OWL.

2.2.3.2 KAON2

KAON2 stellt Entwicklern eine

Closed Source-

API zum Verwalten von OWL DL,

SWRL und F

-Logic

bereit, die den Zugriff auf Ontologien ermöglicht. Diese ist im

universitären Rahmen bei nichtkommerziellen Projekten frei verfügbar.12 Es handelt

sich dabei um JAVA

-

Klassen für das Öffnen und Schließen von Ontologien,

Registrieren und Abfragen von Eigenschaften, Klassen und Instanzen, Variablen und

Literalen, sowie für die Erstellung und Ausführung von SWRL-Abfragen, um nur

einige Beispiele zu nennen. Das System verfügt darüber hinaus über einen Server, an

den Anfragen mittels JAVA

-

RMI oder einem DIG

-

Interface gestellt werden können.

Das sind entfernte Methodenaufrufe über die Kaon2

-

API, mit denen die Manipulation

der vom Server bereitgestellten Ontologien von verschiedenen Seiten möglich ist.

Veränderungen in der Ontologie werden vom Server gespeichert und sind bei der

nächsten Anfrage aktiv. Ein weiteres Feature ist die Möglichkeit der Überführung von

Instanzen einer Ontologie in eine relationalen Datenbank.

Technisch gesehen stellt Kaon2 eine datengetriebene Inferenzmaschine zur

Verfügung, die für das schnelle Beantworten von Anfragen ausgelegt ist. Eine

11

Protégé

kann über folgenden Link bezogen werden:

<http://protege.stanford.edu/download/download.html>.

12 Eine stabile Version von Kaon2 findet sich auf <http://kaon2.semanticweb.org/>.

37

---

Grundlagen

2.2 Expertensysteme

Dokumentation ist rudimentär in Form von zehn einfachen Beispielen vorhanden, die

verschiedene Anwendungsfelder abdecken, aber keinesfalls den vollen Umfang der

Möglichkeiten widerspiegeln. Darüber hinaus existiert eine Dokumentation der

JAVA

-

Klassen (

Javadoc

), die für den Einstieg in das System aber sehr komplex

gestaltet ist. Eine richtige Dokumentation, ein Tutorium, ein Wiki, oder eine

Mailingliste fehlen hingegen völlig.

38

---

Ein Expertensystem für OSS-Lizenzen

3 Ein Expertensystem für OSS-Lizenzen

3 Ein Expertensystem für OSS-Lizenzen

Ziel des Abschnitts, der den Hauptteil dieser Arbeit darstellt, ist die Beschreibung

eines Expertensystems, welches Informationen über

Open Source

-Lizenzen bereitstellt

und Anfragen bezüglich ihrer Kompatibilität beantwortet. Außerdem soll der Begriff

Kompatibilität im Zusammenhang mit

Open Source

-Lizenzen geklärt werden. Dazu

wird dieser Abschnitt der Arbeit in drei Teile untergliedert.

Zunächst wird der Aufbau des Expertensystems unter Verwendung bestimmter, in

Kapitel 2.2 vorgestellter Technologien, beschrieben. Es handelt sich hier um kein

verallgemeinertes Modell, sondern um eine spezielle Implementierungsvariante auf

Grundlage einer zuvor gewählten

Inference Engine

.

Anschließend folgt die Klärung des Begriffs Kompatibilität im Umfeld von

Open Source

-Lizenzen. Um eine Wissensbasis mit Schlussfolgerungsmechanismen zu

erstellen, muss klar sein, was Kompatibilität in diesem Zusammenhang bedeuten soll.

Die Wissensbasis wird im dritten Schritt modelliert. Zeigt der Aufbau des

Expertensystems lediglich die Verwendung bestimmter Technologien und die

Wissensbasis in abstrakter Form, wird jetzt ein spezielles Wissensgebiet

aufgenommen: Das Wissens über

Open Source

-Lizenzen. Dazu werden beispielhaft drei

Open Source

-Lizenzen mit unterschiedlichen Charakteren formalisiert und in die

Wissensbasis geschrieben. Auf diese Weise erhält das Expertensystem Informationen,

Wissen über Konzepte und Regeln, die es in die Lage versetzen, ein

Reasoning

durchzuführen. Zu Modellierung der Wissensbasis wird die grafische Anwendung

Protégé

herangezogen. Der OWL-Editor erwies sich bei der praktischen Anwendung

als stabil und einfach zu handhaben. Er ist gut dokumentiert, verfügt über eine große

Community, Wikis, Anwendungsbeispiele und FAQs. Entscheidend für die

Verwendung des Editors bei der Realisierung der Wissensbasis war vor allem der

bereits als Plugin integrierte OWL-

Reasoner

Pellet

, die Möglichkeit zur Integration der

Jess Rule Engine

für die Anwendung der SWRL-Regeln, sowie ein bereits vorhandener

SWRL-Editor. So lassen sich bei Test alle notwendigen Prozesse, wie OWL-

Reasoning

und die Anwendung der Regeln mithilfe einer einzigen Oberfläche durchführen. Die

Ergebnisse des Prozesses werden in der Wissensbasis verfügbar und können

anschließend zu Analysezwecken herangezogen werden.

39

---

Ein Expertensystem für OSS-Lizenzen

3 Ein Expertensystem für OSS-Lizenzen

Ergebnis des Abschnitts wird eine Wissensbasis sein, die zum Zweck einer

Kompatibilitätsuntersuchung den

Copyleft-

Effekt von

Open Source

-Lizenzen bestimmen

kann, sowie die schriftliche Dokumentation der Formalisierung von drei ausgewählten

Open Source

-Lizenzen.

3.1 Aufbau des Expertensystems

Alle Elemente, die zum Aufbau eines Expertensystems notwendig sind, wurden bereits

in Kapitel 2.2 besprochen. Nun sollen sie zusammengesetzt und in einer speziellen

Kombination vereint werden.

Grundsätzlich besteht das Expertensystem aus

User Interface

,

Inference Engine

und

Knowledge Base

.

Das

User Interface

bildet die Schnittstelle zum Benutzer. Darüber wird in einer

bestimmten Form eine Anfrage gestellt. Hat der Benutzer seine Anfrage mit Hilfe des

User Interface

an die

Inference Engine

übergeben, wird ein Algorithmus in Gang gesetzt,

mit dem auf Grundlage des in der

Knowledge Base

gespeichertem Wissens

Schlussfolgerungen gezogen werden. Im Ergebnis wird dem Benutzer eine Antwort

oder Lösung bezüglich der Anfrage übermittelt.

Die

Inference Engine

bildet zusammen mit der Wissensbasis den Kernbestandteil des

Systems. Realisiert wird sie im oben gezeigten Fall durch KAON2 einer Infrastuktur

zum Verwalten von OWL DL, SWRL, und F-Logic Ontologien. KAON2 ist in der

Lage

Reasoning

auf der Basis von SHIQ(D), einer Teilmenge von OWL DL

durchzuführen und nutzt DL-

safe

, eine Teilmenge von SWRL, für regelbasiertes

Schlussfolgern.13 KAON2 wurde komplett in JAVA 1.5 implementiert und liegt für die

Anwendungsentwicklung in Form von JAVA-Klassen vor. Damit lassen sich

Operationen auf einer Wissensbasis, wie das Öffnen von Ontologien,

Reasoning

,

verschiedene Abfragen und das Speichern von Ontologien realisieren. Der

Reasoner

selbst arbeitet mit 3 Komponenten, der

Ontology Clausification Component

, dem

Theorem Prover

und der

Disjunctive Datalog Engine

. Dabei werden die Inhalte aus der

TBox der Wissensbasis in ein Set bestehend aus Prädikatenlogik erster Ordnung

13 Vergleiche dazu <http://kaon2.semanticweb.org/>.

40

---

Ein Expertensystem für OSS-Lizenzen

3.1 Aufbau des Expertensystems

übersetzt und anschließend der

Superposition calculus

14 für das

Reasoning

implementiert.

Das Ergebnis sind Regeln, die zusammen mit den Inhalten der ABox, also den

Beschreibungen der einzelnen Instanzen, die

Disjunctive Datalog Engine

in die Lage

versetzen, Anfragen zu beantworten (Motic 2006: 2004).

User Interface

und

Inference Engine

werden durch einen

System Engineer

entwickelt bzw. implementiert.

Request

Solution

User

User Interface

System Engineer

Inference Engine

Reasoning Engine (Kaon2)

Ontology

Theorem

Disjunctive

Clausification

Prover

Datalog

Engine

TBox axioms

Abox assertions

Knowledge Expert

Knowledge Base

Ontology (OWL)

Rules (SWRL)

Individuals

Rule 1

Classes

Rule 2

Properties

Rule 3

Abbildung 4: Expertensystem mit Kaon2 als

Inference Engine

Die Wissensbasis selbst wird auf der Grundlage von OWL DL und SWRL umgesetzt

14 Mithilfe dieses Algorithmus ist es möglich, ein

Reasoning

für ausgeglichene Prädikatenlogik erster

Ordnung durchzuführen.

41

---

Ein Expertensystem für OSS-Lizenzen

3.1 Aufbau des Expertensystems

und ist, wie auch der Informationsfluss zur

Inference Engine

, in Abbildung 4 grün

dargestellt. Es handelt sich dabei um XML-Dateien, die eine Ontologie und Regeln

enthalten. Klassen, Eigenschaften und Instanzen bilden darin ein bestimmtes

Wissensgebiet ab, welches außerdem durch Regeln ergänzt wird. Dazu ist ein Experte

notwendig, der in als

Knowledge Expert

bezeichnet wird. Ihm obliegt es, vorliegendes

Wissen zu formalisieren und es in die Wissensbasis zu übertragen. Erst dann kann es

von der

Inference Engine

für Schlussfolgerungen genutzt werden.

3.2 Lizenzkompatibilität im Rahmen des
Systems

Zu Kompatibilität und

Copyleft

wurden bereits in Kapitel 2.1 einige Anmerkungen

gemacht. An dieser Stelle soll der Begriff

Copyleft

noch einmal genauer betrachtet

werden, da die Stärke des

Copyleft

-Effekts etwas über die Kombinierbarkeit von

weiterzugebenden und darüber hinaus modifizierten Werken aussagt. Ziel ist es, neben

der genaueren Betrachtung der Begriffe

Copyleft

und Kompatibilität auch festzulegen,

was innerhalb dieser Arbeit darunter zu verstehen ist.

Während Werke, die unter Lizenzen mit starkem

Copyleft

-Effekt

stehen, in so gut wie

keiner Art und Weise mit Werken unter anderen Lizenzen kombiniert werden können,

ohne das Gesamtwerk unter die

Copyleft

-Lizenz zu stellen, besteht für

Open Source

-Lizenzen mit schwachen oder ohne

Copyleft

-Effekt die Möglichkeit, dies

unter bestimmten Umständen zu tun. Die Stärke des

Copyleft

-Effekts ist also in

gewisser Weise ein Gradmesser für die Kompatibilität zwischen Lizenzen. Mit

kompatiblen Lizenzen sind in dieser Arbeit Lizenzen gemeint, deren zugehörige

Programme in rechtlich vertretbarer Form miteinander kombiniert werden können.

Dabei kann es Auflagen geben, die festlegen, in welcher Weise eine Kombination

erfolgen muss. Diese Auflagen müssen im Rahmen der jeweiligen Lizenztexte für alle

beteiligten Lizenzen wechselseitig erfüllbar sein. Aufgrund dieser Festlegung muss

von einem komplizierten Wechselspiel zwischen den Lizenztexten und deren

Auslegung im nationalen Recht ausgegangen werden, was kein Gegenstand der hier

vorgenommenen Betrachtung sein wird.

Um sich einer Aussage über Kompatibilität zwischen Lizenzen dennoch zu nähern, soll

42

---

Ein Expertensystem für OSS-Lizenzen

3.2 Lizenzkompatibilität im Rahmen des Systems

versucht werden, die Kombinierbarkeit von Werken, aufgrund des

Copyleft

-Effekts der

Lizenzen mithilfe definierter Klassen innerhalb einer Wissensbasis, einzuschätzen.

Ergebnis dieser Betrachtung sollen drei Kategorien von Lizenzen sein. Lizenzen, die

keinesfalls zu anderen Lizenzen kompatibel sind (starker

Copyleft

-Effekt), Lizenzen, die

bestimmte Auflagen für die Kombination der ihr unterstehenden Programme geben,

eine Weitergabe modifizierter Programme aber prinzipiell unter von der

Ursprungslizenz abweichenden Bedingungen erlauben (schwacher

Copyleft

-Effekt) und

Lizenzen, die keine Auflagen für veränderte und weitergegebene Werke geben (kein

Copyleft

-Effekt). Zwar sagen diese Kategorien nichts über die tatsächliche

Kompatibilität zweiter Lizenzen aus, geben aber Aufschluss darüber, ob ein Programm

gar nicht, möglicherweise oder auf jeden Fall mit Programmen unter anderen

Lizenzen kombiniert werden kann. Mit dieser Aussage und einem Verweis auf die

Bedingungen, sowie den Stellen aus dem Original-Lizenztext, die zu diesem Ergebnis

geführt haben, kann eine spätere Anwendung den Anwender einen guten

Ausgangspunkt für weitere Recherchen bieten.

Die Frage ist nun, wie der

Copyleft-

Effekt auf Grundlage formalisierten Lizenzwissens

eingeschätzt werden kann? Diese Frage soll das nächste Kapitel klären, jedoch sollen

vor der Formalisierung noch einige Überlegungen darüber angestellt werden, welche

Informationen aus den Lizenztexten für diese Frage wichtig sind, damit Indizien, die

für einen bestimmten

Copyleft-

Effekt sprechen, in die Otologie geschrieben werden

können und somit innerhalb der Wissensbasis identifizierbar werden.

Zum Beispiel muss es später in der Wissensbasis möglich sein, ein bearbeitetes Werk

zu identifizieren. Darüber hinaus ist wichtig zu wissen, ob ein kombiniertes Werk

vorliegt und ob es lizenzrechtliche Relevanz hat, da auch Lizenzbedingungen

existieren, die Aussagen zu in sich unabhängigen Werken machen und diese für den

Copyleft-

Effekt nicht entscheidend sind. Da Lizenzen auch Bedingungen für Teile von

weiterzugebenden Werken festlegen, muss es innerhalb der Wissensbasis möglich

sein, Teilwerke zu erkennen. Hierbei handelt es sich typischerweise um unveränderte,

modifizierte oder neu erstellte Teile des Programms.

Weitere Anforderungen, die - über die

Copyleft

-Frage hinaus - praktische Relevanz für

die Erstellung einer Lizenz-Ontologie haben, werden innerhalb des nächsten Kapitels

43

---

Ein Expertensystem für OSS-Lizenzen

3.2 Lizenzkompatibilität im Rahmen des Systems

definiert. Die Modellierung der Wissensbasis wird dabei ebenfalls vollzogen.

3.3 Modellierung der Wissensbasis

Die Modellierung der Wissensbasis ist eine Grundvoraussetzung für ein

funktionierendes Expertensystem. Im hier betrachteten Fall soll Wissen über

OSS-Lizenzen aufgenommen werden. Die zu diesem Zweck notwendige

Formalisierung des Lizenzwissens auf Basis der in Kapitel 2.1.3 vorgestellten Analyse

ausgewählter Lizenzen und den Anforderungen zur Identifikation des

Copyleft-

Effekts,

stellt zweifelsfrei den schwierigsten Part beim Aufbau der Wissensbasis dar. Die von

der

Inference Engine

zurückgelieferten Lösungen werden nur verwertbar sein, wenn

das Wissen zuvor korrekt formalisiert wurde.

Interessant erscheint auch die Frage nach dem Rechtsraum - genauer gesagt, wie eine

bestimmte Lizenzbedingung im nationalen Recht ausgelegt werden muss. Diese Frage

wird die vorliegende Arbeit nicht beantworten können, da lediglich der Inhalt der

Lizenzen selbst betrachtet wird. Dabei wird bei Erklärungen teilweise Bezug auf das

deutsche Rechtssystem genommen. Bezüglich der Formalisierung selbst spielen solche

Aspekte keine Rolle.

Bei der Formalisierung von Lizenzen werden zunächst Klassen benötigt, die

gewissermaßen den Container für die in ihnen vorkommenden Instanzen bilden und

Eigenschaften in Form von Relationen zwischen Instanzen oder zwischen Instanzen

und Datentypen. Zu diesem Zweck ist zu analysieren, welche Elemente später für die

Ontologie benötigt werden und in welcher Beziehung sie zueinander stehen. Da kein

Versuch für die Formalisierung von OSS-Lizenzen bekannt ist, gibt es keinen

definierten oder festgelegten Weg. Viele Varianten sind denkbar. Wichtig ist es, eine

Ontologie aufzubauen, welche ein Expertensystem in die Lage versetzt,

Schlussfolgerungen über Lizenzen zu ziehen. Wie dieses konkret aussehen kann, wird

in den nächsten Abschnitten beschrieben. Zur Verbesserung der Übersichtlichkeit,

werden alle zu Anschauungszwecken in OWL oder SWRL kodierten Abschnitte sowie

im Text verwendete Klassen und Eigenschaften, die sich auf diese Abschnitte

beziehen, in einer vom Textkörper abweichenden Schriftart und Formatierung

dargestellt.

44

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

3.3.1 Lizenzwissen - Primitive Klassen und

Klassenbeziehungen

Zentrales Element der Ontologie wird die Lizenz selbst sein. Sie ist es, über die

letztendlich Aussagen getroffen werden sollen, steht damit im Zentrum des Systems

und wird im hier betrachteten Fall die erste Basisklasse bilden. Diese Klasse wird

später die verschiedenen Lizenzen in Form von Instanzen aufnehmen und in OWL

folgendermaßen definiert:

<owl:Class rdf:ID="License"/>

Die einzelnen Lizenzen werden als Instanzen der Klasse License aufgefasst, da sie

bezüglich des Anwendungszwecks der Ontologie die kleinstmöglichen Einheiten

bilden. Es wäre auch möglich, sie als Klasse und damit als Menge aller tatsächlich

gegeben Kopien der Lizenz zu sehen. Ein solcher Ansatz könnte sinnvoll sein, wenn

mithilfe der Ontologie die Verbreitung bestimmter Lizenzen ermittelt werden müsste.

Im hier betrachteten Fall spielt jedoch der Inhalt der Lizenztexte die herausragende

Rolle, der für alle gegebenen Kopien der Lizenz gleich ist, da es sich um keine neue

Variante, sondern tatsächlich nur um eine Kopie der immer gleichen Instanz handelt.

Im jetzigen Zustand ist über die Klasse nichts bekannt, außer dass sie existiert. Für die

Lizenz-Ontologie ist es notwendig, weitere Klassen zu definieren, die ihrerseits

Instanzen aufnehmen können und sich dann mit anderen Instanzen auf der Basis

binärer Relationen verknüpfen lassen. Als weitere Klassen werden Work,

LicenseParagraph, LicenseCondition und Trademark definiert. LicenseParagraph steht hier für die

kleinste Einheit, in die eine Lizenz nach dem System Ziffer/Satz zerlegt werden kann

und entspricht im Englischen

Section/Paragraph

.

<owl:Class rdf:ID="Work"/>

<owl:Class rdf:ID="LicenseParagraph"/>

<owl:Class rdf:ID="LicenseCondition"/>

<owl:Class rdf:ID="Trademark"/>

Die Liste der Klassen ist an dieser Stelle noch nicht vollständig. Es lassen sich jedoch

erste Beziehungen formulieren. Da nun klar ist, dass Werke, Lizenzen, Sätze,

Warenzeichen und Lizenzbedingungen existieren, können Verbindungen definiert

werden. Diese ergeben sich zwischen License und Work, License und LicenseParagraph,

45

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

License und Trademark, sowie License und LicenseCondition. Die letzte Beziehung ist in

gewisser Weise ein Sonderfall. Lizenzen haben Sätze, sie haben aber auch

Bedingungen. Genauer betrachtet sind Bedingungen und Sätze Varianten, um

Lizenzen in logische Einheiten zu zerlegen. Die jeweilige Beziehung zu der Lizenz hat

sich als notwendig erwiesen, da beide in der Ontologie für gewisse Schlüsse

erforderlich sind, es aber unmöglich erscheint, eine Bedingung aus einem einzigen Satz

abzuleiten, oder einen Satz nur einer Bedingung zuzuordnen. Eine bestimmte

Lizenzbedingung lässt sich nur selten in einen klar abgegrenzten Abschnitt pressen.

Vielmehr können sich Bedingungen aus verschiedenen Sätzen der Lizenz ergeben,

oder ein Satz kann gleich mehrere Bedingungen enthalten.

String

hasLicen

Paragraph

seName

isParagraphOf

hasParagraph

isLicenseOf

Work

hasLicense

License

hasLicen

i

s

s

eC

Lic

on

en

d

s

i

eC

tion

on

ked

ditionOf

License

isTrademar

Condition

Trademark

Abbildung 5: Zentrale Klasse Lizenz, jeweils verknüpft durch eine Property, welche die Beziehungen zu

anderen Klassen verdeutlicht.

Abbildung 5 zeigt die Beziehungen zwischen den eben aufgeführten Klassen. Sie zeigt

außerdem den Lizenznamen als eine Beziehung zwischen License und einer

Zeichenkette. Im Gegensatz zu

ObjectProperties

, die Instanzen von Klassen verbinden,

werden bei

DatatypeProperties

Relationen zwischen Instanzen von Klassen und

Datentypen ausgedrückt. Eine Eigenschaft oder

Property

lässt sich optional durch eine

Domain

, welche die Grundmenge darstellt und eine

Range

, die den Wertebereich

verkörpert, einschränken. Im Fall des Lizenznamens handelt es sich um eine

46

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Eigenschaft mit der Grundmenge License und dem Wertebereich

String

. Namen sind

einfache Zeichenketten, die Lizenzen benennen.

Die

Property

hasLicenseCondition hat als Grundmenge License und als Wertebereich die

Klasse LicenseCondition. Nur Instanzen der Klasse License können Lizenzbedingungen

haben und Lizenzbedingungen kommen ausschließlich in der Klasse LicenseCondition vor.

Die redundante Beziehung zu dieser Eigenschaft ist isLicenseConditionOf, die folglich die

Grundmenge LicenseCondition und den Wertebereich License haben muss. Obwohl die

Bedingungen verschiedener Lizenzen möglicherweise das gleiche aussagen, ist eine

Bedingung selbst einzigartig. Sie kann nur in einer Lizenz vorkommen und ist daher

functional

:

<owl:ObjectProperty rdf:ID="isLicenseConditionOf">

<rdf:type rdf:resource="&owl;FunctionalProperty" />

<rdfs:domain rdf:resource="#LicenseCondition"/>

<rdfs:range rdf:resource="#License"/>

<owl:inverseOf rdf:resource="#hasLicenseCondition" />

</owl:ObjectProperty>

Bezüglich der

Property

hasLicenseParagraph wird festgelegt, dass sie als Grundmenge die

Klasse License und als Wertebereich LicenseParagraph erhalten soll. Damit müssen alle

Lizenzen, die es geben kann, der Grundmenge License entstammen und jeder Satz, der

ihr zugeordnet werden soll, in der Klasse LicenseParagraph zu finden sein. Hier ergibt

sich ebenfalls die redundante

Property

isLicenseParagraphOf, weil jeder Satz genauso gut

einer Lizenz zugeordnet werden kann. Die

Property

ist

functional

, da Sätze nur genau

einer Lizenz angehören können, während hasLicenseParagraph als

inverse functional

deklariert wird. Zum einen muss

inverse functional

das Gegenteil einer

functional

-

Property

sein, zum anderen besteht die Möglichkeit, dass eine Lizenz eine

Menge von Sätzen haben kann.

<owl:ObjectProperty rdf:ID="hasLicenseParagraph">

<rdf:type rdf:resource="&owl;InverseFunctionalProperty" />

<rdfs:domain rdf:resource="#License"/>

<rdfs:range rdf:resource="#LicenseParagraph"/>

<owl:inverseOf rdf:resource="#isLicenseParagraphOf" />

</owl:ObjectProperty>

Die

Property

hasLicense lässt sich der Wertebereich License zuordnen, da Lizenzen auch

für Dinge gegeben werden können, die keine Werke sind, erfolgt keine Angabe des

Wertebereichs. Analog zu den oben genannten Eigenschaften besteht ebenfalls eine

47

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

redundante Beziehung in Form von isLicenseOf und der Domain License.

<owl:ObjectProperty rdf:ID="isLicenseOf">

<rdfs:domain rdf:resource="#License"/>

<owl:inverseOf rdf:resource="#hasLicense" />

</owl:ObjectProperty>

Unter Trademark sind Warenzeichen zu verstehen. Da Lizenzen unter Umständen durch

Organisationen zertifiziert werden, sind durch ein Wahrenzeichen Rückschlüsse auf

den Lizenztyp möglich. Die OSI beispielsweise zertifiziert OSS-Lizenzen mithilfe der

bereits in Kapitel 2.1.1 beschriebenen

Open Source

-Defininition.

<owl:ObjectProperty rdf:ID="isTrademarked">

<rdfs:range rdf:resource="#Trademark"/>

</owl:ObjectProperty>

Die

Property

selbst kann bestimmte Ausprägungen haben. So tragen fast alle bisher

genannten Eigenschaften das Attribut

inverseOf

und zeigen damit redundante

Beziehungen an. Zwei Eigenschaften wurde bisher als

functional

definiert und auf

diese Weise angezeigt, dass eine Instanz einer Klasse sich lediglich auf genau eine

Instanz einer anderen Klasse beziehen kann, sofern sie existiert. Dagegen können die

Instanzen von License mehreren Werken angehören und auch ein einziges Werk lässt

sich unter verschiedenen Lizenzen verbreiten. (Jaeger/Metzger 2006: 71)

Die bisherigen Betrachtungen zeigen, in welcher Beziehung Werke, Lizenzen, Sätze

und Lizenzbedingungen nach diesem Formalisierungsansatz zueinander stehen. Nun

soll das für die meisten Schlussfolgerungen entscheidende Element und seine

Beziehungen formalisiert werden - die Lizenzbedingung. Zu diesem Zweck wird eine

Klasse Namens LicenseCondition angelegt. Die Klasse wird später noch spezifische

Einschränkungen des Wertebereichs für bestimmte Eigenschaften durch so genannte

Restrictions

erhalten. Im Moment wird sie jedoch als einfache Klasse definiert:

<owl:Class rdf:ID="LicenseCondition"/>

Mit der Beziehung zwischen License und LicenseCondition wurde bereits festgelegt, dass

sich Lizenzbedingungen auf Lizenzen beziehen. Ähnlich verhält es sich mit Ziffern

und Sätzen. Lizenzbedingungen stützen sich auf Ziffern und Sätze von Lizenzen, da in

diesen Lizenzbedingungen definiert werden. Eine Anwendung, die später die

Ontologie nutzt, kann dem Anwender auf diese Weise Rückschlüsse auf den zu der

48

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Bedingung gehörenden Satz liefern.

<owl:ObjectProperty rdf:ID="emergesOfLicenseParagraph">

<rdfs:range rdf:resource="#LicenseParagraph"/>

</owl:ObjectProperty>

License

License

License

Duty

Right

hasL

is

ic

L

en

icen

se

s

C

e

on

ight

Con

dit

seDuty

d

ion

seR

ition

Licen

O

has

f

Licen

has

License

Option

hasLicenseOption

License

Part

isValidToPartOfWork

Condition

of

distributed

work

em

Work

orm

erges

odeF

OfL

fDistributed

icens

FormO

idToC

eParagrap

isValidTo

h

isVal

Form

of

Code

distributed

form

License

work

Paragraph

Abbildung 6: Lizenzbedingung mit zugehörigen Klassen.

Links unten: Anwendungsfall, für den eine Bestimmung gilt.

Rechts oben: Bestimmung, die bezüglich des Anwendungsfalls zu beachten ist.

Die Analyse der Lizenztexte hat gezeigt, dass in Lizenzbedingungen Rechte

formuliert werden. Beispielsweise besagt der Text der GPL in Ziffer 1, dass auf

beliebigen Medien unveränderte Kopien des Quelltextest eines Programms verbreitet

werden dürfen, dafür aber gewisse Voraussetzungen erfüllt werden müssen: ,,You may

copy and distribute verbatim copies of the Program′s source code as you receive it, in

any medium, provided that [...]". Tatsächlich formulieren alle untersuchten

Lizenzbedingungen Rechte. Diese Beziehung wird in Abbildung 6 mit der

Property

hasLicenseRight dargestellt. Die Rechte werden in der neu anzulegenden Klasse

LicenseRight erfasst. Die Beziehung zwischen LicenseCondition und LicenseRight soll den

49

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Wertebereich LicenseRight erhalten. Alle Lizenzrechte sind in der Klasse LicenseRight zu

finden. Lizenzrechte beziehen sich z.B. auf den Umgang mit dem Programm, etwa das

Recht, dass Programm ablaufen zu lassen, es in unveränderter Form weiterzugeben

oder es zu modifizieren und anschließend weiterzugeben.

<owl:Class rdf:ID="LicenseRight"/>

<owl:ObjectProperty rdf:ID="hasLicenseRight">

<rdfs:range rdf:resource="#LicenseRight"/>

</owl:ObjectProperty>

Aus diesem kurzen Abschnitt der GPL kristallisieren sich noch weitere Dinge heraus,

die bei der Formalisierung zu beachten sind. Zum einen bezieht sich die Bedingung

auf ein Programm, dass im Quellcode vorliegt: ,,[...] the Program′s source code [...]".

Eine andere denkbare Möglichkeit wäre ein Programm im Maschinencode. Es wird die

Klasse CodeForm benötigt, die über die

Property

isValidToCodeForm mit dem Wertebereich

CodeForm zu definieren ist. Die Klasse kann durch die Aufzählung ihrer Mitglieder

spezifiziert werden. Als mögliche Varianten des vorliegenden Codes kommen nur

Binary und Source in Frage. Die

Property

ist

functional

. Ein Programm kann nur eine

einzige Form des Codes besitzen:

<owl:Class rdf:ID="CodeForm">

<owl:oneOf rdf:parseType="Collection">

<owl:Thing rdf:about="#Binary"/>

<owl:Thing rdf:about="#Source"/>

</owl:oneOf>

</owl:Class>

<owl:ObjectProperty rdf:ID="isValidToCodeForm">

<rdf:type rdf:resource="&owl;FunctionalProperty" />

<rdfs:range rdf:resource="#CodeForm"/>

</owl:ObjectProperty>

Das Programm darf im betrachteten Fall nur als unveränderte Kopie weitergegeben

werden: ,,[...] distribute verbatim copies of the Program [...]". Eine andere Möglichkeit

wäre ein Programm, welches von dem Werk abgeleitet wurde, das Werk nutzt, es linkt

oder eine von dem Werk unabhängige selbstständige Einheit darstellt. Noch weitere

Arten von weiterzugebenden Werken sind denkbar. Die Klasse FormOfDistributedWork

wird angelegt und mithilfe der

Property

isValidToFormOfDistributedWork verknüpft.

<owl:Class rdf:ID="FormOfDistributedWork"/>

<owl:ObjectProperty rdf:ID="isValidToFormOfDistributedWork">

<rdfs:range rdf:resource="#FormOfDistributedWork"/>

</owl:ObjectProperty>

50

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Da ein Programm unverändert weitergegeben werden soll, ist das ganze Werk von der

Bedingung betroffen. Allerdings formulieren Lizenztexte an verschiedenen Stellen

Bedingungen, die sich nur auf Teile von Werken beziehen. Zum Beispiel stellt Ziffer 2

Satz 2 der LGPL klar: ,,If identifiable sections of that work are not derived from the

Library, and can be reasonably considered independent and separate works in

themselves, then this License, and its terms, do not apply to those sections." Es ist also

denkbar, dass sich bestimmte Bedingungen nur auf neu hinzugekommene oder

veränderte Bereiche des Gesamtwerkes beziehen. Die Klasse PartOfWork soll diesem

Problem gerecht werden. Es wird definiert:

<owl:Class rdf:ID="PartOfDistributedWork"/>

<owl:ObjectProperty rdf:ID="isValidToPartOfDistributedWork">

<rdfs:range rdf:resource="#PartOfDistributedWork"/>

</owl:ObjectProperty>

Ein wesentlicher Bestandteil der Lizenzbedingung, sind die in Abbildung 6 als

LicenseDuty bezeichneten Pflichten, die der Benutzter bei der Wahrnehmung seiner

Rechte beachten muss. Erweitert man das oben genannte Zitat aus Ziffer 1 der GPL,

so finden sich Pflichten, die beim Weitergeben unveränderter Kopien beachtet werden

müssen. So sind beispielsweise

Copyright

-Vermerk und Haftungsausschluss zu

veröffentlichen: ,,You may copy and distribute verbatim copies of the Program′s source

code as you receive it, in any medium, provided that you conspicuously and

appropriately publish on each copy an appropriate copyright notice and disclaimer of

warranty." Die

Property

hasLicenseDuty wird erstellt und mit ihrem Wertebereich die

Klasse LicenseDuty einschränken:

<owl:Class rdf:ID="LicenseDuty"/>

<owl:ObjectProperty rdf:ID="hasLicenseDuty">

<rdfs:range rdf:resource="#LicenseDuty"/>

</owl:ObjectProperty>

Die letzte noch fehlende Beziehung zur Lizenzbedingung ist die LicenseOption. GPL

Ziffer 1 Satz 2 definiert diesbezüglich zwei Möglichkeiten. Der Distributor kann sich

vom Lizenznehmer die Kopierkosten erstatten lassen und Gegen eine Gebühr eine

Garantie für das Programm anbieten: ,,You may charge a fee for the physical act of

transferring a copy, and you may at your option offer warranty protection in exchange

for a fee." Diese Möglichkeiten sind nicht zwingend und fallen damit nicht unter die

51

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Pflichten. Sie ist in gewisser Weise ein Recht, aber eins, welches mit unter das Recht,

unveränderte Kopien weiterzugeben, fällt. Daher wurde es bei der Formalisierung als

Option oder Möglichkeit definiert. Die Codierung in OWL erfolgt auf die gleiche Art

und Weise, wie die

Property

hasLicenseDuty. In diesem Fall wird als Klasse LicenseOption

definiert, die zugehörige

Property

ist hasLicenseOption.

Nun soll noch der Satz selbst betrachtet werden. Sätze bestehen aus Wortfolgen, die

ihren Inhalt ausdrücken. Diese werden als Zeichenkette erfasst und als

DatatypeProperty

dargestellt. Diese Eigenschaft ist functional. Ein Satz kann nur genau

einen Wortlaut haben.

<owl:FunctionalProperty rdf:about="#ParagraphWording">

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>

</owl:FunctionalProperty>

Außerdem weisen Sätze, wie in Abbildung 7 gezeigt, die schon bekannte redundante

Beziehung zu einer Lizenz auf.

isParagraphOf

hasParagraphWording

License

String

Paragraph

hasParagraph

License

Abbildung 7: Satz (LicenseParagraph) mit Eigenschaften

Wie bereits weiter oben angekündigt, soll die Klasse LicenseCondition noch einige

Einschränkungen erhalten. Ein solcher

Workaround

wird notwendig, wenn eine

Property

nur in einem spezifischen Kontext eine besondere Ausprägung erhalten soll,

anstatt global deklariert zu werden. Beispielsweise können Lizenzen eine nicht näher

definierte Menge von Lizenzrechten oder -pflichten aufweisen, während

Lizenzbedingungen, so soll es hier festgelegt werden, mit nur genau einem

Lizenzrecht in Verbindung stehen. Die Kardinalität von hasLicenseRight wird daher im

Kontext der LicenseCondition auf 1 limitiert. Nur so ist gewährleistet, dass später jedem

Recht die entsprechenden Pflichten zugeordnet werden können. Man spricht in diesem

52

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Zusammenhang von einer notwendigen Bedingung, da ohne sie die Lizenzbedingung

nicht richtig definiert werden kann. Klassen, die ausschließlich notwendige

Bedingungen enthalten, werden in OWL als primitive Klassen bezeichnet.

Das Prinzip entspricht der Formulierung verschiedener Sätze in Lizenzen, die in der

Regel ein Recht sowie eine dazugehörige Menge von Pflichten und Möglichkeiten

definieren:

<owl:Class rdf:ID="LicenseCondition">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty>

<owl:ObjectProperty rdf:ID="hasLicenseRight"/>

</owl:onProperty>

<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:cardinality>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

Die Eingenschaften emergesOfLicenseParagraph, hasLicenseOption, isValidToAffectedCodeForm,

isValidToFormOfDistributedWork, isValidToPartOfDistributedWork und hasLicenseDuty kennen noch

keine Grundmenge. Es ist nicht bekannt, dass sie im Kontext von LicenseCondition

auftauchen können. Daher muss definiert werden, dass die eben genannten

Property

-Werte als Grundmenge die Klasse Lizenzbedingung haben können. Dies

geschieht mithilfe von

allValuesFrom

. Hier wird zwar auf den Wertebereich verwiesen,

dadurch, dass diese Definition in der Klasse LicenseCondition vorgenommen wird aber

auch klar gestellt, dass die Grundmenge eine Lizenzbedingung ist. Exemplarisch wird

hier nur eine dieser Einschränkungen vorgestellt:

[...]

<owl:Restriction>

<owl:allValuesFrom>

<owl:Class rdf:ID="LicenseOption"/>

</owl:allValuesFrom>

<owl:onProperty>

<owl:ObjectProperty rdf:ID="hasLicenseOption"/>

</owl:onProperty>

</owl:Restriction>

[...]

Die Lizenzbedingung ist damit vollständig definiert. Jede Bedingung kann genau ein

Recht innerhalb eines bestimmten Anwendungsfalls aufweisen. Der Anwendungsfall

setzt sich aus den Eigenschaften zusammen, die isValidFor im Namen tragen, also Form

des Codes, Teil des weiterzugebenden Werkes und Art des weiterzugebenden Werkes.

Auch diese Eigenschaften dürfen nur einen Wert erhalten, da später über Regeln

53

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

weitere Pflichten zu einer Lizenzbedingung hinzugefügt werden können, die sich

möglicherweise nur für eine ganz bestimmte Kombination der genannten drei

Elemente, oder anders formuliert, für einen bestimmten Anwendungsfall, der sich aus

diesen Elementen zusammensetzt, gültig sind. Ist ein Recht bezüglich eines

bestimmten Anwendungsfalls definiert, kann eine beliebig lange Liste von Pflichten

und oder Optionen folgen. Außerdem gehört die Lizenzbedingung zu genau einer

Lizenz, während sie sich auf eine nicht festgelegte Menge von Sätzen aus der Lizenz

beziehen kann.

Zusammenfassung:

Ziel des Kapitels

· Aufbau einer Basisstruktur aus Klassen und Klassenbeziehungen

in OWL, mit deren Hilfe sich Lizenzwissen beschreiben lässt.

Vorgehensweise

· Definition von Klassen als eine Sammlung von Eigenschaften in

Form einer Ontologie über Lizenzwissen, die eine Menge von

Instanzen beschreiben.

· Erstellung von Eigenschaften (Properties), zur Darstellung

allgemein gültiger Fakten über Klassenmitglieder durch binäre

Relationen zwischen Instanzen von Klassen oder Instanzen und

RDF-Literalen sowie XML-Schema Datentypen.

Ergebnisse

· Die Zusammenhänge zwischen der Lizenz, ihrem zugehörigen

Werk, ihrem Namen, den Sätzen aus dem Lizenztext und den

daraus hervorgehenden Lizenzbedingungen wurden dargestellt.

· Die Lizenzbedingung als eine Kombination aus Lizenzbestimmung

(Rechte, Pflichten, Möglichkeiten) und dem zugehörigen Fall,

für den die Bestimmung gilt (Form des weiterzugebenden

Werkes, Teil des weiterzugebenden Werkes, Form des

weiterzugebenden Codes) wurde beschrieben.

3.3.2 Werke, Lizenzen, Bedingungen - Instanzen der

Ontologie

Im vorangegangenen Abschnitt wurde bereits darauf hingewiesen, dass die Lizenzen

selbst als Instanzen aufgefasst werden sollen, da sie als kleinste Einheiten nicht weiter

zerlegt werden können. Die Instanzen der Klasse Lizenz zu finden ist relativ einfach.

Es handelt sich um die Lizenzen, die formalisiert werden sollen. Im Fall dieser

Ontologie die GPL in der Version 2, die LGPL 2.1 und die neuere Variante der

BSD-Lizenz. Instanzen werden im einfachsten Fall durch ihre Mitgliedschaft in einer

Klasse deklariert:

54

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

<License rdf:ID="GPLv2.0" />

Instanzen können über Eigenschaften, die sie durch die Mitgliedschaft in einer der

oben beschriebenen Klassen erben, in Verbindung gebracht werden. Ein Beispiel wäre

der Zusammenhang zwischen der GPL als Lizenz und der in ihr auftretenden Sätzen:

<LicenseParagraph rdf:ID="GPLv2.0-Section10">

<isLicenseParagraphOf rdf:resource="#GPLv2.0"/>

[...]

</LicenseParagraph>

Im weiteren Verlauf wird sich dieser Text darauf beschränken, einige wichtige

Instanzen der verschiedenen Klassen zu benennen und ihre Relevanz für das

Expertensystem zu erläutern. Instanzen, wie beispielsweise Sätze von Lizenzen

werden nicht einzeln aufgeführt, sondern lediglich die Mitgliedschaft in einer Klasse

erwähnt.

License right

Part of distributed work

·

·

Distribute verbatim copies

Modified part of software

of the program

·

Selfmade part of software

·

Distribute modified copies

·

Unmodified part of software

of the program

·

Software as whole

·

Use the program

·

(...)

·

(...)

License duty

·

add revision mark

Form of distributed work

·

accept license terms

·

Derivative work

License

·

give notice that a other

·

Work as verbatim copy

Condition

work is used

·

Work combines two works

·

make source code available

·

(...)

·

take no license fee

·

(...)

License option

·

Offer warranty protection

Codeform

for a fee

·

Binary

·

Perform the physical act

·

Source

of transferring a copy for a fee

·

(...)

Abbildung 8: Lizenzbedingung mit Klassenbeziehungen und beispielhaft aufgeführten Eigenschaften in

Form von Instanzen.

Links: Anwendungsfall, für den eine Bestimmung gilt.

Rechts: Bestimmung, die bezüglich des Anwendungsfalls zu beachten ist.

55

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Als Eigenschaft der Lizenzen enthält die Klasse Work verschiedene

Software-Programme in Form von Werken, in LicenseParagraph finden sich die einzelnen

Sätze der Lizenzen wieder, LicenseConditionen beinhaltet eine formalisierte Menge von

Lizenzbedingungen, Trademark enthält die Instanz OpenSourceInitiativeApproved, welches

ein Gütesiegel der

Open Source

-Initiative für

Open Source

-Lizenzen verkörpert.

Die Instanzen der Klassen aus Abbildung 8, welche mit der zentralen Klasse

Lizenzbedingung in Verbindung stehen, sind eine genauere Betrachtung wert.

Zunächst sollen Lizenzrechte ausgemacht werden. Ausführliche Regelungen bezüglich

der Weitergabe eines Programms in unveränderter bzw. modifizierter Form sind

typisch für die hier untersuchten

Open Source

-Lizenzen. Manchmal wird auch das

Recht, ein Programm ablaufen zu lassen, näher betrachtet und daher ebenfalls der

Liste der Lizenzrechte hinzugefügt. Insgesamt formulieren die Lizenztexte

hauptsächlich die folgenden 3 Rechte, die je nach Anwendungsfall eine bestimmte

Anzahl an Pflichten und Möglichkeiten nach sich ziehen.

<LicenseRight rdf:ID="useTheProgram" />

<LicenseRight rdf:ID="distributeVerbatimCopiesOfTheProgram" />

<LicenseRight rdf:ID="distributeModifiedCopiesOfTheProgram" />

[...]

Lizenzen enthalten eine Menge von Vorschriften, wie die Pflicht, einen

Änderungsvermerks bei modifizierten Kopien eines Programms zu anzubringen, den

Copyright

-Vermerk zu veröffentlichen, die Liste der Lizenzbedingungen unverändert

zu lassen, dem Lizenznehmer keine über die original Lizenzbestimmungen hinaus

gehenden Pflichten aufzuerlegen, alle abgeleiteten Werke wieder unter der

ursprünglichen Lizenz zu veröffentlichen oder den

Source Code

zur Verfügung zu

stellen. An dieser Stelle soll es bei diesen Beispielen belassen und das Augenmerk noch

auf einige besondere Pflichten gelegt werden, die bei der Analyse der Lizenztexte

aufgefallen sind. Die Ziffer 6a der LGPL besagt, dass alle Pflichten, die für die

veränderte und unveränderte Weitergabe eines Programms gelten, u.a. auch für die

eben genannte Ziffer zu beachten sind. Das würde heißen, dass bei der Formalisierung

der Lizenzbedingungen im hier beschriebenen Kontext alle diese Pflichten noch

einmal hinzugefügt werden müssten. Es soll jedoch an dieser Stelle bei einer

gewöhnlichen Instanz mit dem Namen AttendConditionsForModifiedCopies belassen werden.

56

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Das folgende Kapitel über Regeln wird zeigen, dass sich mithilfe einer solchen Instanz

Regeln erstellen lassen, die dieses Problem automatisch beheben:

<LicenseDuty rdf:ID="doNothingUnlessItsExplicitlyAllowed" />

<LicenseDuty rdf:ID="addRevisionMark" />

<LicenseDuty rdf:ID="publishCopyrightNotice" />

<LicenseDuty rdf:ID="leaveUntouchedLicenseTerms" />

<LicenseDuty rdf:ID="makeSourceCodeAvailable" />

<LicenseDuty rdf:ID="notImposeAnyFurtherRestrictionsToLicenseTerms" />

<LicenseDuty rdf:ID="distributeModifiedCopiesOfTheProgram" />

<LicenseDuty rdf:ID="AttendConditionsForModifiedCopies" />

<LicenseDuty rdf:ID="licenseTheWorkUnderTheTermsOfTheOriginalLicense" />

[...]

Die LPGL definiert als besondere Option die Möglichkeit, jede gegebene Kopie eines

Programms unter der GPL zu lizensieren, sofern alle Bedingungen der

Ursprungslizenz entsprechend angepasst werden. Außerdem erlaubt sie dem

Lizenzgeber unter Umständen, Teile des weiterzugebenden Programms unter selbst

gewählten Bedingungen zu veröffentlichen, sowie Garantie und den physischen

Kopiervorgang gegen Gebühr anzubieten.

<LicenseOption rdf:ID="mayDistributeThatWorkUnderTermsOfYourChoice" />

<LicenseOption rdf:ID="mayOfferWarrantyProtectionForAFee" />

<LicenseOption rdf:ID="mayPerformThePhysicalActOfTransferringACopyForAFee" />

<LicenseOption rdf:ID="maySwitchToGPL" />

[...]

Nun sollen Instanzen, welche die verschiedenen Anwendungsfälle bezüglich der

Lizenzbedingungen verkörpern, dargestellt werden. Hierbei geht es weder um Rechte

noch Möglichkeiten oder Pflichten, zu denen bereits einiges gesagt wurde, sondern um

die Frage unter welchen Umständen Pflichten und Möglichkeiten bezüglich eines

Rechtes gelten. Diese den Anwendungsfall darstellenden Instanzen, finden sich in den

Klassen PartOfDistributedWork, FormOfDistributedWork und CodeForm. Die Instanzen der ersten

Klasse beschreiben den Teil des weiterzugebenden Werkes, bei dem bestimmte

Pflichten und Möglichkeiten zu beachten sind. Aus den Lizenzen geht hervor, dass es

bei der Weitergabe lizenzrechtlich relevante Teile von Werken geben kann, die

unverändert gelassen, verändert oder neu erstellt wurden. Außerdem ist es denkbar,

Bedingungen zu definieren, die für das Werk als Ganzes und damit unabhängig von

den eben beschriebenen Teilwerken gelten.

<PartOfDistributedWork rdf:ID="ModifiedPartOfSoftware" />

<PartOfDistributedWork rdf:ID="SelfMadePartOfSoftware" />

<PartOfDistributedWork rdf:ID="UnmodifiedPartOfSoftware" />

57

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

<PartOfDistributedWork rdf:ID="WorkAsWhole" />

Die Form des Codes wird vor allem dann relevant, wenn ein Programm als

Binary

weitergegeben werden soll. Ein Großteil der hier formalisierten Bedingungen fordert

an dieser Stelle eine Offenlegung des Quellcodes, in einigen Fällen ist dies jedoch nicht

erforderlich.

<CodeForm rdf:ID="Binary" />

<CodeForm rdf:ID="Source" />

Ein wichtiger Ansatzpunkt für die Anwendung der richtigen Lizenzbedingung ist die

Form des weiterzugebenden Werkes. Diese ergibt sich aus der Art und Weise, auf die

ein Programm verändert wurde, oder dem Umstand, dass überhaupt keine

Modifikation vorliegt. Von dem Urspungsprogramm abgeleitete Werke, hier als

DerivativeWork

bezeichnet, ziehen bei GPL und LGPL sehr strenge Pflichten nach

sich, während beispielsweise für in sich unabhängige und eigenständige Werke

überhaupt keine Pflichten zu beachten sind ­ sofern die Programmteile nicht von

irgendeinem Teil des ursprünglichen Programms abgeleitet wurden.

Abbildung 9: Formalisierte Lizenzbedingung aus Ziffer 1 der GPL in

Protégé

.

Links: Lizenz aus der die Bedingung stammt, sowie Ziffer und Satz der Bedingung.

Mitte: Lizenzrecht mit zugehörigen Pflichten und Möglichkeiten (Optionen).

Rechts: Anwendungsfall für den die Bedingung gültig ist.

Eine Definition, was unter den verschiedenen Formen weiterzugebender Werke zu

verstehen ist, finden sich in den Lizenzen selbst. So definiert die LGPL in Ziffer 5 ein

58

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Werk, dass darauf ausgelegt ist, mit einer LGPL-Bibliothek zusammenzuarbeiten,

aber nichts von ihr Abgeleitetes enthält und separat ausgeliefert wird, als ein Werk,

das die Bibliothek nutzt. Unterschiedliche Pflichten ergeben sich in diesem

Zusammenhang schon bei Werken, die Bibliotheken nutzen, durch die Art und Weise

ihrer Verbindung. Ist ein Werk in diesem Zusammenhang mit der Bibliothek gelinkt,

kommt Ziffer 6a zum tragen: ,,Use a suitable shared library mechanism for linking

with the Library." Wird ein solches Werk mit der Bibliothek auf eine andere Art und

Weise kombiniert, entstehen deutlich weitreichendere Pflichten. Auch für den Fall,

dass ein Programm, welches nicht nur darauf ausgelegt ist, Funktionseinheiten einer

Bibilothek zu nutzen, aber mit einer Bibliothek kombiniert wird, kennt die LGPL in

Ziffer 7 gesonderte Pflichten. Insgesamt wurden sieben verschiedene Formen von

weiterzugebenden Werken identifiziert. Unter anderem auch Werke, die unverändert

weitergegeben werden sollen.

<FormOfDistributedWork rdf:ID="DerivativeWork" />

<FormOfDistributedWork rdf:ID="IndependetWorksDeliveredSeparatelyButCanWorkTogether" />

<FormOfDistributedWork rdf:ID="pIndependetWorksDeliveredSeparatelyOneWorkIsMade..." />

<FormOfDistributedWork rdf:ID="WorkAsVerbatimCopy" />

<FormOfDistributedWork rdf:ID="WorkCombinesTwoWorks" />

<FormOfDistributedWork rdf:ID="WorkUsesAOtherWorkAndIsCombined" />

<FormOfDistributedWork rdf:ID="WorkUsesAOtherWorkAndIsLinked" />

Zusammenfassung:

Ziel des Kapitels

· Beschreibung von Instanzen zur Abbildung spezieller

Open Source-Lizenzen in der bereits erstellten

Klassenstruktur.

Vorgehensweise

· Instanzen werden definiert.

· Instanzen werden durch ihrer Klassenmitgliedschaft

deklariert.

Ergebnisse

· Regelmäßig in Lizenztexten auftretender Elemente, die

geeignet sind, den Inhalt eines Lizenztextes zu beschreiben

wurden in formalisierte OWL-Instanzen überführt.

· Lizenzbedingungen, die sich aus Lizenztexten ergeben, wurden

beispielhaft dargestellt.

3.3.3 Vervollständigung der Bedingungen durch Regeln

Das vorangegangene Kapitel hat gezeigt, dass Bedingungen in den Lizenztexten sehr

abstrakt formuliert sein können. Manchmal wird in ihnen ausgedrückt, dass bestimmte

59

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Pflichten, die bereits in einem anderen Zusammenhang formuliert wurden, für einen

weiteren Anwendungsfall erneut gelten. Wer beispielsweise modifizierte Kopien von

GPL-Programmen verbreitet, soll neben den in Ziffer 2 aufgeführten Pflichten auch

die Pflichten, die sich bei der Weitergabe unveränderter Kopien in Ziffer 1 ergeben,

beachten. Nun wäre eine Anwendung, die später Lizenzbedingungen darstellen soll,

für den Benutzer wenig hilfreich, wenn er, genau wie in den Lizenztexten, ständig

Querverweisen folgen müsste, um sich über alle zu beachtenden Pflichten zu

informieren. Hier sollen Regeln Abhilfe schaffen, mit deren Hilfe zu jeder einzelnen

Bedingung eine vollständige Liste aller Pflichten und Möglichkeiten generiert werden

kann. Derartige Regeln können nicht mit OWL erzeugt werden. Es wird eine

Regelsprache, wie SWRL, zu ihrer Integration in die Wissensbasis nötig. Auf diese

Weise können logische Regeln über OWL-Atomen definiert werden. Konkret nutzt

SWRL eine Horn-artige Syntax, mit der sie sich auf OWL-Klassen, -Eigenschaften

und -Instanzen mithilfe von Variablen bezieht. Zur Auswertung der Regeln wird

später ein Regelinterpreter nötig, der im hier dargestellten Fall ein Teil der

Inference Engine

ist. Die Regeln werden auf das schon vorhandene Wissen angewendet

und somit neues Wissen generiert.

Die erste hier vorgestellte Regel greift in dem eben genannten Beispiel von Ziffer 2

der GPL. Allen Bedingungen, die zur GPL V2 gehören und darüber hinaus die

abstrakt kodierte Pflicht AttendConditionsForVerbatimCopies enthalten, sollen ebenfalls die

Möglichkeiten und Pflichten der in Abbildung 9 dargestellten Bedingung für die

Weitergabe unveränderter Kopien erhalten. In dieser speziellen Bedingung mit dem

Namen GPLv2.0-Condition_01 findet sich alles, was bei der Verbreitung unveränderter

Kopien zu beachten ist und aufgrund verschiedener Regelungen im Lizenztext zu den

Ziffern 2 und 3 hinzugefügt werden muss.

hasLicenseCondition(GPLv2.0, ?y)

hasLicenseDuty(?y, AttendConditionsForVerbatimCopies)

hasLicenseDuty(GPLv2.0-Condition_01, ?a)

hasLicenseOption(GPLv2.0-Condition_01, ?b)

hasLicenseDuty(?y, ?a)

hasLicenseOption(?y, ?b)

Eine weitere Regel beschäftigt sich mit Abschnitten der Lizenz, bei denen alle

Bedingungen für die Weitergabe modifizierter Kopien des Programms beachtet

60

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

werden müssen. Hier tritt eine Besonderheit auf, da nicht alle Möglichkeiten und

Pflichten für modifizierte Kopien in einer einzigen Lizenzbedingung kodiert sind.

Vielmehr existieren zwei Bedingungen für zwei verschiedene Anwendungsfälle. Diese

enthalten auf der einen Seite Möglichkeiten und Pflichten, die bei der

Weiterverbreitung für das gesamte Programm zu beachten sind und auf der anderen

Seite eine Pflicht, die nur für den geänderten Teil des Programms relevant ist, nämlich

die Pflicht, Änderungsvermerke anzubringen. Daraus folgt, dass, wenn der Lizenztext

diesbezüglich an anderer Stelle auf diese Pflichten und Möglichkeiten verweist, für

unveränderte und modifizierte Teile des Programms jeweils verschiedene Regeln

angewandt werden müssen. Diese beziehen sich für unveränderte Teile des

Programms auf die Bedingung GPLv2.0-Condition_02 und für geänderte Bereiche auf die

GPLv2.0-Condition_0201:

hasLicenseCondition(GPLv2.0, ?y)

hasLicenseDuty(?y, AttendConditionsForModifiedCopies)

hasLicenseDuty(GPLv2.0-Condition_02, ?a)

hasLicenseOption(GPLv2.0-Condition_02, ?b)

hasLicenseDuty(?y, ?a)

hasLicenseOption(?y, ?b)

hasLicenseCondition(GPLv2.0, ?y)

hasLicenseDuty(?y, AttendConditionsForModifiedCopies-ModifiedPart)

hasLicenseDuty(GPLv2.0-Condition_0201, ?a)

hasLicenseOption(GPLv2.0-Condition_0201, ?b)

hasLicenseDuty(?y, ?a)

hasLicenseOption(?y, ?b)

Abbildung 10: Regel aus den Ziffern 4 und 5 der GPL im

Protégé

SWRL-Editor

61

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Neben Regeln, die einfache Querverweise auflösen, enthalten verschiedene Lizenzen

auch Ziffern und Sätze, die komplett als Regeln definiert werden. Die GPL z.B. fordert

von dem Lizenznehmer in Ziffer 4, keine Handlungen zu vollziehen, die nicht explizit

erlaubt wurden, sofern ein Werk vervielfältigt, verändert oder weiterlizensiert werden

soll und das weitergegebene Werk den Vertrag berührt. Der Absatz regelt, was im

Fall einer Vertragsverletzung geschieht. In diesem Fall verliert der Lizenznehmer

automatisch alle erworbenen Nutzungsrechte aus der Lizenz (Jaeger/Koglin/Kreutzer

2005: 86). Ziffer 5 definiert, auf welche Weise ein Vertragsabschluss zustande kommt.

Durch den Akt der Lizenzierung eines Programms unter der GPL richtet der

Lizenzgeber ein Angebot an jedermann, dessen Annahme Ziffer 5 regelt. Diesem

Punkt zufolge ist der Lizenznehmer zur Annahme der Lizenz verpflichtet, sofern er

die Rechte aus der GPL wahrnehmen möchte (Jaeger/Koglin/Kreutzer 2005: 97). Die

eben genannten Bestimmung ergeben sich für alle Bedingungen des Vertrages, die

Pflichten enthalten. Das einfache Ausführen von Programmen, sowie die Verbreitung

unabhängiger eigenständiger Werke ziehen laut GPL keine Pflichten nach sich. In

diesen Fällen ist der Lizenznehmer weder zur Annahme noch zur Erfüllung des

Vertrages verpflichtet. Die folgende Regel fügt die beiden Pflichten aus Ziffer 4 und 5

allen Bedingungen hinzu, die bereits Pflichten enthalten:

p2:hasLicenseCondition(p2:GPLv2.0, ?y)

p2:hasLicenseDuty(?y, ?z)

p2:hasLicenseDuty(?y, p2:doNothingUnlessItsExplicitlyAllowed)

p2:emergesOfLicenseParagraph(?y, p2:GPLv2.0-Section04)

p2:hasLicenseDuty(?y, p2:acceptLicenseTerms)

p2:emergesOfLicenseParagraph(?y, p2:GPLv2.0-Section05)

Wer GPL-Programme vertreibt, darf seinen Abnehmern keine über die Pflichten der

GPL hinausgehenden Beschränkungen auferlegen, es sei denn, die entsprechende

Bedingung erlaubt Abweichungen ausdrücklich, wie beispielsweise in Ziffer 1 Satz 2.

Hier wird dem Lizenzgeber optional gegen Gebühr gewährt, eine Garantie für das

Programm anzubieten Daraus folgt, dass sich für Ziffer 11 und 12 abweichende

Haftungs- und Gewährleistungsbestimmungen vereinbaren lassen (Jaeger/Metzger

2006: 29). Diese Regel ergibt sich aus Ziffer 6. Sie kann nur für Bedingungen gültig

sein, die eine Weiterverbreitung der Original-Lizenzbestimmungen fordern und nicht

explizit Abweichungen erlauben. Eine solche explizit erlaubte Abweichung stellt die

62

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Möglichkeit der Weiterverbreitung bestimmter Programmteile unter selbstgewählten

Bestimmungen dar, der Umstand, dass überhaupt keine Pflichten zu beachten sind

oder die Möglichkeit, abweichende Garantiebestimmungen einzuräumen. Aufgrund

der Pflicht in Ziffer 1, die Lizenzbestimmungen mit zuliefern und der Regeln für

unveränderte sowie modifizierte Kopien, die dafür sogen, dass jede Bestimmung, die

keine Abweichungen von den Lizenzbestimmungen zulässt, automatisch die Pflicht

DeliverOriginalLicenseTerms erhält, kann eine Regel definiert werden, die in diesem Fall

eine neue Pflicht zu jeder betroffenen Bedingung hinzufügt, die Pflicht, dem

Lizenznehmer keine über die GPL hinausgehenden Beschränkungen aufzuerlegen.

Natürlich wird auch die entsprechende Ziffer 6 der Lizenz hinzugefügt:

p2:hasLicenseCondition(GPLv2.0, ?y)

p2:hasLicenseDuty(?y, deliverOriginallyLicenseTerms)

p2:hasLicenseDuty(?y, notImposeAnyFurtherRestrictionsToLicenseTerms)

p2:emergesOfLicenseParagraph(?y, GPLv2.0-Section06)

Die fünf hier vorgestellten Regeln gelten in leicht angepasster Form auch für die

LGPL 2.1. Etwas anders gestaltet sich bei der LGPL eine Bedingung, welche sich aus

Ziffer 3 ergibt. Diese besagt, dass sich der Anwender eines Programms auch für die

Verwendung der GPL für eine gegebene Kopie des LGPL-Programms entscheiden

kann: ,,You may opt to apply the terms of the ordinary GNU General Public License

instead of this License to a given copy of the Library." Für die Bedingungen der

LGPL bedeutet dies, dass jede Bedingung, die sich in irgendeiner Weise auf ein

weiterzugebendes Werk bezieht, automatisch die Option SwitchToGPL enthalten muss.

Der zugehörige Satz der Lizenz muss ebenfalls kopiert werden:

hasLicenseCondition(LGPLv2.1, ?y)

isValidToFormOfDistributedWork(?y, ?z)

hasLicenseOption(?y, maySwitchToGPL)

emergesOfLicenseParagraph(?y, p2:LGPLv2.1-Section03)

Es zeigt sich, dass man sich bei der Formalisierung einiger Lizenzbedingungen mit

Hilfe einer Regelsprache viel Arbeit ersparen kann, da Lizenzen selbst Regeln

enthalten, die sie über schon bestehende Bestimmungen definieren.

63

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

Zusammenfassung:

Ziel des Kapitels

· Ergänzung der Ontologie mit Lizenzbedingungen, die in Form

von Regeln in den Lizenztexten auftauchen.

Vorgehensweise

· Formalisierung verschiedener Lizenzbedingungen in SWRL, indem

logische Regeln über OWL-Atomen definiert werden, die sich

auf Klassen, Properties und Instanzen mithilfe von Variablen

beziehen.

Ergebnisse

· Es wurden Möglichkeiten gezeigt, wie sich Teile von

Lizenztexten, die als Regeln definiert wurden und sich daher

nur mit großem Aufwand in OWL formalisieren lassen, in die

Wissensbasis übertragen werden können.

· Verschiedene Lizenzbedingungen, wie die Regelung der LGPL,

dass ein Programm bei der Weitergabe bezüglich verschiedener

Anwendungsfälle auch unter der GPL stehen darf, wurden durch

die Möglichkeiten von SWRL formalisiert.

3.3.4 Wissenszuwachs durch definierte Klassen

Hat eine Instanz bestimmte Eigenschaften, kann es infolge eines

Reasoning

-Prozesses

als Mitglied einer neuen Klasse auftauchen. Hier wird über die Beschreibungslogik aus

vorhandenem Wissen neues Wissen gewonnen (Sack 2006: 20). Dazu müssen

Eigenschaften als notwendige und hinreichende Bedingungen für ein Konzept

formuliert werden. Man spricht in diesem Zusammenhang von definierten Klassen.

Definierte Klassen sind ein mächtiges Mittel, um einzelne Ontologien

zusammenzusetzen, sie eigenen sich aber auch, um Instanzen aufgrund ihrer

Eigenschaften zu klassifizieren (Smith/Welty/McGuinness 2004: Ontology Mapping).

Für eine Anwendung bezüglich der OSS-Lizenzontologie sind möglicherweise

Informationen zu der Frage interessant, warum die Lizenz als OSS-Lizenz gilt. Auch

Hinweise über die Stärke des

Copyleft

-Effekts und auf welche Weise es zustande

kommt, könnten von Interesse sein. In diesem Kapitel werden Möglichkeiten

vorgestellt, zu einer Lizenz das zugehörige Lizenzmodell, sowie ihren Charakter für

eine spätere Kompatibilitätsuntersuchung zu bestimmen. Zu diesem Zweck müssen die

bereits gespeicherten Informationen aufbereitet, d.h neue definierte Klassen

geschrieben werden.

Die erste hier aufgeworfene Frage lässt sich relativ einfach beantworten. Zwar soll

kein Versuch unternommen werden, Lizenzen aufgrund ihrer Bedingungen als

Open Source

-Lizenzen zu klassifizieren, wie es beispielsweise die

Open Source Initiative

in

64

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

einer Art Zertifizierungsverfahren tut, allerdings kann der Umstand, dass

Open Source

-Lizenzen das Warenzeichen

Open Source Initiative Approved

der

Open Source Initiative

tragen, als Hinweis auf ihre Zugehörigkeit zur Klasse der

Open Source

-Lizenzen verstanden werden. Dabei gilt: Alles was mit dem Warenzeichen

Open Source Initiative Approved

ausgestattet ist und eine Lizenz ist, ist darüber hinaus

eine

Open Source

-Lizenz.

<owl:Class rdf:about="#OSSLicense">

<owl:equivalentClass>

<owl:Class>

<owl:Restriction>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#isTrademarked"/>

</owl:onProperty>

<owl:hasValue rdf:resource="#OpenSourceInitiativeApproved"/>

</owl:Restriction>

<owl:Class rdf:about="#License"/>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

Weitaus schwieriger gestaltet sich die Bestimmung des

Copyleft

-Effekts der Lizenz, da

in diesem Zusammenhang auf keine bereits vorgenommene Klassifizierung

zurückgegriffen werden soll. Der

Copyleft

-Effekt und die Lizenzbedingungen, die zu

seiner Ausprägung führen, sollen innerhalb einer Anwendung, die dieses Wissen

nutzt, Rückschlüsse auf die Kompatibilität zwischen

Open Source

-Lizenzen liefern. Zu

Beginn muss geklärt werden, ob eine Bedingung für die Untersuchung des

Copyleft

-Effekts überhaupt relevant ist. Hier ist der Anwendungsfall dahingehend zu

prüfen, ob er sich in irgendeiner Form auf ein lizenzrechtlich relevantes kombiniertes

Werk bezieht. Dabei sollen Lizenzbedingungen ausgeschlossen werden, die sich mit

Aussagen zu unabhängigen, in sich eigenständigen Werken befassen und für die Frage

nicht entscheidend sind. Die Weitergabe unveränderter Kopien von Programmen oder

Programmteilen soll ebenfalls nicht betrachtet werden, da sich das

Copyleft

mit der

Weitergabe von Werken auseinander setzt, die darüber hinaus verändert wurden. Zwei

Zwischenschritte werden nötig, bevor eine Lizenzbedingung der Untersuchung

zugänglich gemacht werden kann. Zunächst müssen aus der Menge aller Formen von

weiterzugebenden Werken die Elemente gefiltert werden, die lizenzrechtlich relevant

werden können. Zu diesem Zweck wird die definierte Klasse

FormOfCombinedDistributedWork angelegt, da es sich bei den relevanten Werken um

65

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

kombinierte weiterzugebende Werke handelt. In einem zweiten Schritt sind Teile von

den weiterzugebenden Werken dahingehend zu analysieren, ob sie verändert wurden.

Ist dies der Fall, sollen sie im Ergebnis Elemente der definierten Klasse

PartOfDistributedWorkTouched sein:

<owl:Class rdf:about="#FormOfCombinedDistributedWork">

<owl:equivalentClass>

<owl:Class>

<owl:Class>

<owl:oneOf rdf:parseType="Collection">

<FormOfDistributedWork rdf:about="#DerivativeWork"/>

<FormOfDistributedWork rdf:about="#WorkCombinesTwoWorks"/>

<FormOfDistributedWork rdf:about="#WorkUsesAOtherWorkAndIsCombined"/>

<FormOfDistributedWork rdf:about="#WorkUsesAOtherWorkAndIsLinked"/>

</owl:oneOf>

</owl:Class>

<owl:Class rdf:about="#FormOfDistributedWork"/>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

<owl:Class rdf:about="#PartOfDistributedWorkTouched">

<owl:equivalentClass>

<owl:Class>

<owl:Class>

<owl:oneOf rdf:parseType="Collection">

<PartOfDistributedWork rdf:about="#SelfMadePartOfSoftware"/>

<PartOfDistributedWork rdf:about="#ModifiedPartOfSoftware"/>

<PartOfDistributedWork rdf:about="#SoftwareAsWhole"/>

</owl:oneOf>

</owl:Class>

<owl:Class rdf:about="#PartOfDistributedWork"/>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

Nachdem diese beiden Klassen erstellt wurden, kann eine weitere Klasse definiert

werden. In der Klasse sollen alle Lizenzbedingungen auftauchen, die für eine

Untersuchung des

Copyleft

-Effekts relevant sind. Es handelt sich dabei um eine

Unterklasse von LicenseCondition. Ihre Elemente stellen Instanzen dar, bei denen

mindestens eine isValidToFormOfDistributedWork-

Property

auf eine Instanz der Klasse

FormOfCombinedDistributedWork

verweist

und

ebenfalls

eine

isValidToPartOfDistributedWork-

Property

auf

eine

Instanz

der Klasse

PartOfDistributedWorkTouched. Auf diese Weise wird sichergestellt, dass alle Elemente

dieser Klasse für den

Copyleft

-Effekt der Lizenz relevant sind:

<owl:Class rdf:about="#OSSLicenseConditionRelevantTo

Copyleft

Character">

[...]

<owl:Restriction>

<owl:someValuesFrom>

<owl:Class rdf:ID="FormOfCombinedDistributedWork"/>

</owl:someValuesFrom>

66

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

<owl:onProperty>

<owl:ObjectProperty rdf:about="#isValidToFormOfDistributedWork"/>

</owl:onProperty>

</owl:Restriction>

<owl:Restriction>

<owl:someValuesFrom>

<owl:Class rdf:ID="PartOfDistributedWorkTouched"/>

</owl:someValuesFrom>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#isValidToPartOfDistributedWork"/>

</owl:onProperty>

</owl:Restriction>

[...]

</owl:Class>

Die für die Analyse entscheidenden Lizenzbedingungen können zu diesem Zeitpunkt

identifiziert werden, da sie Mitglieder der eben definierten Klasse sind. Der nächste

Schritt wird diese Instanzen erneut untersuchen und in drei Gruppen aufteilen, die

wiederum Unterklassen von

OSSLicenseConditionRelevantTo

Copyleft

Character

sind:

Lizenzbedingungen, die für einen starken, einen schwachen oder gar keinen

Copyleft-Effekt sprechen.

Hinter Lizenzen mit starkem

Copyleft

-Effekt, insbesondere der GPL, steht das

Konzept, dass jede Weiterentwicklung und auch jede Form eines abgeleiteten

kombinierten Werkes mit all seinen Bestandteilen wieder unter der Ursprungslizenz

stehen muss (Jaeger/Koglin/Kreutzer 2005: 20). Dies trifft nur für den Fall zu, dass

die Software auch weitergeben werden soll. Wenn eine Lizenz diesen

Copyleft

-Effekt

hat, muss eine jede Bedingung zunächst einmal in der Klasse der Bedingungen

auftauchen, die für die Untersuchung des

Copyleft

-Effekts relevant ist. Als weiteres

Kriterium muss jede Lizenzbedingung die Pflicht enthalten, ein kombiniertes Werk

wieder unter den ursprünglichen Lizenzbedingungen zu veröffentlichen, wie es die

Ziffer 2b der GPL fordert und damit den entscheidenden Hinweis auf den starken

Copyleft-Effekt liefert (Jaeger/Koglin/Kreutzer 2005: 59). Dieser Rückschluss kann

aufgrund des Auftretens der Pflicht, abgeleitete Werke nur unter den

Original-Lizenzbestimmungen zu veröffentlichen, dargestellt durch die Instanz

licenseTheWorkUnderTheTermsOfTheOriginalLicense, in der Lizenzbedingung erfolgen.

<owl:Class rdf:ID="Strict

Copyleft

Condition">

<owl:equivalentClass>

<owl:Class>

<owl:intersectionOf rdf:parseType="Collection">

<owl:Class rdf:about="#OSSLicenseConditionRelevantTo

Copyleft

Character"/>

<owl:Restriction>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#hasLicenseDuty"/>

67

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

</owl:onProperty>

<owl:hasValue rdf:resource="#licenseTheWorkUnderTheTermsOfTheOriginalLicense"/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

Lizenzbedingungen, die für einen schwachen

Copyleft

-Effekt sprechen, geben dem

Lizenzgeber die Möglichkeit, ein weiterzugebendes Programm oder einen Teil davon

unter von der Ursprungslizenz abweichende Bedingungen zu stellen (Abbildung 11).

Dieses Prinzip kommt z.B. in der LGPL zum Ausdruck. Ziel der Gestalter solcher

Lizenzen war es, mit einer beschränkten

Copyleft

-Clausel eine einfachere Kombination

mit Softwaremodulen unter abweichenden Lizenzbedingungen, insbesondere

proprietären Komponenten zu ermöglichen (Jaeger/Metzger 2006: 51). Dabei ist die

Anwendung eigener Lizenzbedingungen erlaubt, sofern eine festgelegte Liste von

Pflichten erfüllt wird.

Abbildung 11: Definierte Klasse in

Protégé

für eine Lizenzbedingung, die für einen schwachen

Copyleft

-Effekt spricht.

Mit diesem Prinzip geht diese Art von Lizenzen nicht soweit, eine Weiterverbreitung

abgeleiteter Werke nur unter den Original-Bestimmungen zu erlauben, stellt aber

68

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

trotzdem einige Forderungen an die neuen Bedingungen. Es müssen also Pflichten

existieren, unter deren Beachtung der Lizenzgeber bestimmte Programmteile unter

eigenen Bedingungen veröffentlichen darf, da sonst das

Copyleft

völlig fehlen würde.

Für die definierte Klasse wird hier festgelegt, dass jede Lizenzbedingung aufgrund

ihres Anwendungsfalls für die Analyse des

Copyleft

-Effekts relevant sein muss, darüber

hinaus die Möglichkeit, etwas unter eigenen Bedingungen zu veröffentlichen, gegeben

sein muss und das dieser Möglichkeit mindestens eine Pflicht folgt.

Eine OSS-Lizenz ohne

Copyleft

-Effekt erlaubt dem Lizenzgeber ebenfalls die

Lizenzierung von abgeleiteten Programmen oder Programmteilen unter von der

Originallizenz abweichenden Bedingungen. Im Gegensatz zu den Lizenzen mit

schwachem

Copyleft-

Effekt fordert sie dafür aber keine Gegenleistung

(Jaeger/Metzger 2006: 61). Es ergeben sich also keine Pflichten in den

Lizenzbedingungen. Die definierte Klasse gestaltet sich genauso, wie die in

Abbildung 12 gezeigte, mit dem Unterschied, dass die Forderung nach mindestens

einer Lizenzpflicht fehlt.

Abbildung 12: Lizenz mit schwachem

Copyleft

-Effekt als definierte Klasse

Es sollen nun drei definierte Klassen von OSS-Lizenzen kreiert werden. Die erste wird

alle Lizenzen aufnehmen, die mindestens eine Bedingung mit starkem

Copyleft

-Effekt

enthalten, die zweite alle Lizenzen mit mindestens einer Bedingung, die für einen

schwachen

Copyleft

-Effekt spricht, der dritten gehören alle Lizenzen mit wenigstens

69

---

Ein Expertensystem für OSS-Lizenzen

3.3 Modellierung der Wissensbasis

einer Bedingungen ohne

Copyleft

-Effekt an.

Die Stärke des hier definierten Systems liegt nicht nur darin, dass es eine spätere

Anwendung in die Lage versetzt, eine Lizenz zu klassifizieren, sie kann darüber hinaus

alle relevanten Bedingungen, die zu diesem Ergebnis geführt haben, filtern und

anzeigen. Da sich alle Bedingungen auf Textstellen ihrer zugehörigen Lizenzen

beziehen, können darüber hinaus alle wichtigen Ziffern und Sätze der Lizenz gefunden

werden, die letztlich zu der formalisierten Lizenzbedingungen geführt haben. Diese

Fähigkeit wird vor allem für die Weiterentwicklung und Verbesserung des

Gesamtsystems interessant.

Zusammenfassung:

Ziel des Kapitels

· Neues Lizenzwissens soll durch definierte Klassen gewonnen

werden.

Vorgehensweise

· Erstellung von Klassen mithilfe von Bescheibungslogik, in

denen Instanzen aufgrund ihrer Eigenschaften auftauchen

können, weil sie die dazu erforderlichen notwendigen und

hinreichenden Bedingungen erfüllen.

Ergebnisse

· Es konnten Klassen erstellt werden, in denen verschiedene

Instanzen infolge eines Reasoning-Prozesses auftauchen.

· Neues Wissen über Lizenzen und Lizenzbedingungen wurde

generiert, so dass sich der Copyleft-Effekt einer Lizenz

aufgrund von Eigenschaften diverser Lizenzbedingung bestimmen

lässt.

70

---

Validierung der Formalisierung

4 Validierung der Formalisierung

4 Validierung der Formalisierung

Um das formalisierte Lizenzwissen in der Wissensbasis einer Prüfung zu unterziehen,

soll in einem kurzen Testszenario die Charakterisierung von OSS-Lizenzen

vorgenommen werden. Ziel ist die Bestimmung des

Copyleft

-Effekts der drei im System

vorhandenen Lizenzen. Dieser wird unterschieden in starkes

Copyleft

­ die Lizenz lässt

keine kombinierten Werke unter selbstgewählten Bestimmungen zu, die verändert und

weitergegeben werden sollen, schwaches

Copyleft

­ die Lizenz lässt weitergegebene

Werke unter selbstgewählten Lizenzbestimmungen mit Einschränkungen zu und kein

Copyleft

­ die Lizenz lässt weitergegebene Werke unter selbst gewählten

Lizenzbestimmungen ohne Einschränkungen zu.

Untersuchungsgegenstand ist also der Lizenzcharakter, das Ziel des Tests seine

Bestimmung. Für den Testlauf wird die auf http://www.qiq.de zur Verfügung

gestellte Wissensbasis in Verbindung mit folgendem Testsystem genutzt.

4.1 Verwendetes System

Für den Test wird ein PC mit einer Pentium 4 CPU und 1,6 GHz Taktfrequenz

herangezogen. Der Rechner verfügt über 1 GB Arbeitsspeicher.

Softwareseitig wird das JAVA

Runtime Environment

1.6 für den Betrieb der folgenden

Programme verwendet:

Protégé

3.4 bildet das

User Interface

und den Ontologie-Editor.

Als OWL DL

Reasoner

ist

Pellet

1.5.1 in das

Protégé

-

Framework

integriert. Zusätzlich

wird kommt die

Jess Rule Engine

7.1 zum Einsatz.

4.2 Ergebnisse des Regel- und
Reasoning-Prozesses

Im ersten Schritt wurden die in der Wissensbasis vorhanden Regeln angewendet. Zu

diesem Zweck wurde der komplette OWL-Code einschließlich der vorhandenen

Regeln zur

Rule Engine

gesendet und die Ergebnisse wieder in die Ontologie

zurückgeschrieben. Dieser Vorgang dauerte weniger als eine Sekunde und liefert 545

gefolgerte Axiome. In einem ähnlichen Verfahren wurde mithilfe von

Pellet

ein

Reasoning

durchgeführt. Die Ergebnisse wurden ebenfalls in die Ontologie

71

---

Validierung der Formalisierung

4.2 Ergebnisse des Regel- und Reasoning-Prozesses

zurückgeschrieben und waren dank der zuvor angelegten definierten Klassen in

Protégé

für den Betrachter sichtbar. Der komplette Prozesse dauerte knapp eine

Minute und lieferte die folgenden Ergebnisse:

26 Lizenzbedingungen wurden identifiziert, die für die Analyse des

Copyleft

-Effekts

bedeutsam erscheinen und zwar weil sie sich einerseits auf ein kombiniertes Werk

beziehen und andererseits auf den Teil eines Werkes, was weitergegeben werden soll

und darüber hinaus verändert wurde. Von diesen 26 Bedingungen sprechen sechs für

eine Lizenz ohne

Copyleft

-Effekt, zwölf für einen Lizenz mit strengem

Copyleft

-Effekt

und acht für eine Lizenz mit schwachem

Copyleft

-Effekt. Die sechs Bedingungen, die

für keinen

Copyleft

-Effekt sprechen, enthalten allesamt einen Passus, der die

Weitergabe veränderter Kopien der Software unter selbstgewählten Bestimmungen

erlaubt, bzw. geht geht dieses Ansinnen aus dem Lizenztext hervor. Zwölf der

relevante Bedingungen sprechen für einen starken

Copyleft

-Effekt, weil sie nur

Bestimmungen enthalten, die eine Weitergabe kombinierter Teile unter den original

Lizenzbestimmungen vorschreibt. Dies mag nach den ersten Blick auf die Lizenztexte

anders erscheinen, da aber die formalisierten Lizenzbedingungen so aufgebaut sind,

dass sie alle Querverweise auf andere Ziffern und Sätze im Lizenztext auflösen, führt

dies dazu, dass beispielsweise die GPL bei allen für den

Copyleft

-Effekt relevanten

Bedingungen eine Weitergabe unter den Original-Lizenzbestimmungen vorschreibt.

Schließlich ergab der Test acht relevante Bedingungen, die für einen schwachen

Copyleft-

Effekt sprechen, weil sie die Option, die Software unter selbstgewählten

Lizenzbestimmungen zu verbreiten, enthalten, im Gegensatz zu den Lizenzen ohne

Copyleft-

Effekt, diesbezüglich aber gesonderte Pflichten definieren. Diese gehen

allerdings nicht soweit, dass nur die Original-Lizenzbestimmungen verwendet werden

können.

Im Ergebnis wurde eine Lizenz der Gruppe mit Lizenzen ohne

Copyleft

-Effekt

zugeordnet. Dabei handelte es sich um die BSD-Lizenz. Eine Lizenz tauchte in der

Gruppe Lizenzen mit schwachem

Copyleft

-Effekt auf, die LGPL (Abbildung 13). Bei

Lizenzen mit starkem

Copyleft

-Effekt war das Ergebnis nicht eindeutig. Die GPL wie

auch die LGPL fanden sich in dieser Gruppe wieder. Der Grund dieser Klassifizierung

ist darin zu suchen, dass die LGPL sowohl Merkmale einer Lizenz mit starkem

72

---

Validierung der Formalisierung

4.2 Ergebnisse des Regel- und Reasoning-Prozesses

Copyleft

-Effect aufweist, andere Teile der Lizenz aber für einen schwachen

Copyleft

-Effekt sprechen.

Abbildung 13: Gefolgerte Instanzen nach Beendigung des Testlaufts

4.3 Bewertung der Ergebnisse

Für die Anwendungsentwicklung ist das zweideutige Ergebnis bei der Klassifizierung

von Lizenzen mit starkem

Copyleft

-Effekt weniger dramatisch, da eine nachgelagerte

Bedingung alle Lizenzen, die beide Charaktermerkmale aufweisen, automatisch zu

Lizenzen mit schwachem

Copyleft

-Effekt erklären könnte. Vor allem aber spricht das

Ergebnis für die korrekte Funktionsweise des Systems, da die LGPL sich zeitweise

tatsächlich wie eine Lizenz mit starkem

Copyleft

-Effekt verhält.

Das System kommt damit zu den gleichen Schlüssen, die auch in der gängigen

Fachliteratur gezogen werden. Der Test kann als Erfolg betrachtet werden. Der

Formalisierungsansatz hat sich damit zumindest im Rahmen der drei hier

formalisierten Lizenzen und bezüglich der Ausgangsfrage nach dem

Copyleft

-Effekt als

brauchbar erwiesen.

73

---

Die Lizenzkompatibilitätssuche

5 Die Lizenzkompatibilitätssuche

5 Die Lizenzkompatibilitätssuche

Mit der bereits vorhandenen und getesteten Wissensbasis ist das System zwar in der

Lage, Schlüsse zu ziehen, es existiert jedoch noch keine Anwendung, die daraus

hervorgehende Informationen nutzt. Daher wird in diesem Abschnitt eine

Beispielanwendung in Form einer Lizenzkompatibilitätssuche vorgestellt. Diese stellt

eine

Erweiterung

der

Softwaresuche

einer

kollaborativen

Open Source

-Entwicklungsplattform und damit einen neuen Teil einer bestehenden

Anwendung dar. Das Expertensystem soll in diesem Zusammenhang Informationen

zu den Lizenzen über Links im Suchergebnis der Softwaresuche bereitstellen. Diese

Informationen können z.B. die Klassifikation von Lizenzen betreffen. Das System soll

aber auch Empfehlungen geben, auf welche Weise ein Softwareentwickler eigens

erstellte Entwicklungen mit bestehender Software kombinieren kann. Realisiert wird

dies durch eine JAVA-Anwendung, die bestimmte Klassen von KAON2 für das

Reasoning

und verschiedene Abfragen nutzt.

Dabei spielt die Abfrage der definierten Klassen nach dem

Reasoning

-Prozess eine

wichtige Rolle. Diese Klassen wurden weiter oben mithilfe von Beschreibungslogik

erstellt und können innerhalb der Anwendung für alle im System formalisierten

Lizenzen zur Wissensgewinnung herangezogen werden.

Im weiteren Verlauf wird definiert, was genau untersucht werden soll, also der

Untersuchungsgegenstand exakt bestimmt. Es folgt eine Beschreibung des zu

entwickelnden Systems. Dazu wird das zu Beginn des Konzeptes beschriebene

Expertensystem in eine Anwendung integriert. Zunächst erfolgt eine grobe

Darstellung mit Hilfe des

Domain Models

. Es werden Systeme Komponenten und

Datenflüsse gezeigt. Anschließend werden die

Use Case

s, die eine Systemsicht aus dem

Blickwinkel des Anwenders zeigen, erstellt. Die folgende Spezifikation definiert die

nichtfunktionalen Anforderungen an das System und legt die Grenzen des Entwurfes

fest.

5.1 Untersuchungsgegenstand

Gegenstand der Untersuchung sind zum einen Informationen über

Open Source

-Lizenzen, die Rückschlüsse auf Kompatibilität zwischen verschiedenen

74

---

Die Lizenzkompatibilitätssuche

5.1 Untersuchungsgegenstand

Lizenzmodellen zulassen. Dazu wird eine Lizenz bzw. der darin enthaltene Text unter

Zuhilfenahme des Expertensystems analysiert. Ergebnis der Betrachtung soll zum

einen der

Copyleft-

Effekt der Lizenz sein und zum anderen eine Aussage über die

Kombinationsmöglichkeiten mit Softwarebestandteilen unter anderen Lizenzen. Dieses

Ergebnis wird im Rahmen einer erweiterten Softwaresuche als Suchergebnis

dargestellt. Im Gegensatz zu einer herkömmlichen Softwaresuche im Bereich

kollaborativer

Open Source

-Entwicklungsplattformen werden daher nicht nur die

eingegebenen Stichworte für das Suchergebnis relevant, sondern auch die vom

Entwickler gewünschte Ziellizenz. Aufgabe des Expertensystems wird es sein, zu

dieser Ziellizenz andere kompatible Lizenzen zu finden und diese bei der Suche nach

OSS zu berücksichtigen.

5.2 Domain Model

Das

Domain Model

zeigt eine grobe Struktur der Lizenzkompatibilitätssuche und wird

die Objekte der Anwendung zueinander in Beziehung setzten. Diese Objekte sind

Akteure, Komponenten, Systeme und die zugehörigen Daten, die nun identifiziert

werden. Ziel ist es, die Objekte und ihre Interaktion zu beschreiben und ein grafisches

Modell auf Grundlage der Beschreibung zu entwerfen. Entscheidend ist vor allem der

Informationsfluss. Informationsspeicher wie

Forge Database

und

License Knowledge Base

sowie Informationen, die übertragen werden, sind in Abbildung 14 grün dargestellt.

Der

Knowledge Expert

ist für die Erstellung und Wartung der

License Knowledge Base

verantwortlich. Er nimmt die Einträge in der Ontologie vor, indem er Klassen und

Instanzen erstellt, ihnen Eigenschaften zuordnet, sie in Beziehung zueinander setzt

und Regeln erstellt. Aufgabe des

Admins

ist es, die Daten der

License Knowledge Base

aktuell zu halten. Er ist insbesondere für die ordnungsgemäße Ausführung von

Reasoning

-Prozessen und die Anwendung der innerhalb der Wissensbasis festgelegten

Regeln zuständig. Dies wird bei jeder Veränderung der

License Knowledge Base

notwendig. Damit versetzt der Systemverwalter die Wissensbasis in die Bereitschaft,

Anfragen entgegen zu nehmen.

75

---

Die Lizenzkompatibilitätssuche

5.2 Domain Model

User

OUT:

OUT:

Search result

License overview

IN:

Keywords

IN:

Traget license

Selected search result

User Interface

Search Engine

License

OSS Compatibility Search

Information

Search

OUT:

OUT:

OUT:

OUT:

Set of OSS

Set of licenses

Set of

Set of license

compatible to

available

informations

target license

licenses

IN:

IN:

Target License

License

IN:

Compatible

license

IN:

Keywords

License Expert System

Inference Engine

Forge Database

Admin

Disjunctive

OS-Software

Ontology

Theorem

Datalog

Clausification

Prover

Engine

OSS 1
OSS 2
OSS 2

TBox axioms

ABox assertions

License Knowledge Base

Knowledge

Expert

Ontology (OWL)

Rules (SWRL)

Individuals

Rule 1

Classes

Rule 2

Properties

Rule 3

Abbildung 14: Lizenzkompatibilitätssuche

76

---

Die Lizenzkompatibilitätssuche

5.2 Domain Model

Der

User

ist Nutzer der Lizenzkompatibilitätssuche. Er kann Softwaresuche und

Kompatibilitätscheck mithilfe der

Search

Engine

über das

User Interface

durchführen

oder Informationen über Lizenzen bezüglich des Suchergebnisses abfragen.

Im Fall der Softwaresuche soll nun der Anwendungsfall beschrieben werden, bei dem

der

User

die Suche nach Software für eine gewünschte Ziellizenz durchführt. Im

diesem Fall nutzt der User die Komponente

OSS Compatibility Search

. Er wählt aus

einer vom

License Expert System

zur Verfügung gestellten Liste (

Set of available licenses

)

seine gewünschte Ziellizenz aus und startet nach der Eingabe seiner Suchbegriffe eine

Anfrage. Die Suchfunktion übergibt in Form der

Target license

dem

License Expert

System

die vom

User

gewünschte Ziellizenz. Jetzt wird nach kompatiblen Lizenzen

gesucht. Dazu findet ein Vergleich statt, bei dem einzelne Lizenzen anhand ihres

Copyleft

-Effekts auf Kompatibilität zur Ziellizenz geprüft werden. Dies erfolgt durch

einen Anfrage an die Wissensbasis. Nach erfolgter Prüfung gibt das

License Expert

System

eine Liste kompatibler Lizenzen (

Set of licenses compatible to target licenses

) an die

Search

Engine

zurück, welche diese als einschränkendes Kriterium für die Suche nach

OSS nutzt. Die Suche nach OSS erfolgt im letzten Schritt, indem die kompatiblen

Lizenzen mit den

Keywords

als Suchkriterien für die Abfrage der

Forge Database

genutzt werden. Ergebnis ist das

Search result

, eine Menge von Programmen mit eine

Verweis auf die URI, sowie die zugehörige Lizenz.

An dieser Stelle kann der User erneut eine Auswahl treffen, indem er einen Treffer der

Suche für die weitere Verwendung festlegt. Anschließend bietet die Anwendung

mithilfe der Komponente

License Information Search

den Nutzer die Möglichkeit,

genaueres über die Lizenzbedingungen und die Gründe für eine mögliche

Kompatibilität zur

Target license

zu erfahren. Dieser Überblick wird durch das

License

Expert System

erstellt und über die Suchmaschine als

License overview

an den

User

zurück gegeben.

Zusammenfassung:

System

Beschreibung

Search Engine

Suchmaschine, die sowohl zur Ziellizenz kompatible Software, wie

auch Informationen zu den Lizenzen suchen soll.

License Expert System

Expertensystem für die Lizenzanalyse.

77

---

Die Lizenzkompatibilitätssuche

5.2 Domain Model

System

Beschreibung

Inference Engine

Wendet die Regeln an und führt ein Reasoning durch.

Akteur

Beschreibung

Knowledge Expert

Ist für die Erstellung und Veränderung der Wissensbasis zuständig.

User

Anwender der Suche.

Admin

Verwaltet die Wissensbasis, startet Reasoning-Prozesse und den

Regelinterpretierer

Komponente

Beschreibung

OSS Compatibility Search

Diese Komponente ermöglicht die Suche von OSS und bietet die

Möglichkeit, die Software-Suche bezüglich der gewünschten

Ziellizenz einzuschränken.

License Information Search

Sucht nach Informationen zu einer Lizenz.

Ontology Clausification Component

Realisiert die Übersetzung einer SHIQ Knowledge Base in

Prädikatenlogik erster Ordnung.

Theorem Prover

Implementiert den den Superposition Calculus.

Disjunctive Datalog Engine

Beantwortet Anfragen.

Informationsset

Beschreibung

License Knowledge Base

Enthält Wissen über Lizenzen und Regeln für den

Kompatibilitäts-Check.

Ontologie

Lizenzontologie auf OWL-Basis.

Rules

Regelsammlung, mit denen sich Schlüsse aufgrund der in der

Ontologie festgehaltenen Zusammenhänge ziehen lassen.

Set of available licenses

Alle Lizenzen, die in der Wissensbasis gespeichert wurden.

Keywords

Stichworte, die der Benutzer bei der Suche nach OSS eingibt.

Target license

Einzellizenz, die zur Suche kompatibler Lizenzen als Ziellizenz an

das License Expert System übergeben wird.

Set of licenses compatible to

Zur Ziellizenz kompatible Lizenzen, die das License Expert System

target licenses

nach Abfrage der License Knowledge Base an die ,,Search Engine"

zurück liefert.

Set of OSS

In der Forge Database gefundene OSS.

License

Eine Lizenz, über die Informationen zusammengestellt werden

sollen.

Set of license informations

Informationen zu einer Lizenz

License overview

Zusammenstellung von Informationen zu einer Lizenz in einer

Übersicht.

Search result

Menge von gefundenen Programmen mit einem Verweis auf die URI,

sowie die zugehörige Lizenz.

Selected search result

Suchergebnis, welches für einen detaillierten Lizenzüberblick

ausgewählt wurde.

Forge Database

Datenbank, die Informationen über die von der Forge zur Verfügung

gestellte OSS enthält

78

---

Die Lizenzkompatibilitätssuche

5.3 Use Case-Entwicklung

5.3 Use Case-Entwicklung

Nach einem ganzheitlichen Blick auf das System sollen nun Interaktionen betrachtet

werden. Ein

Use Case

ist ein zeitlich in sich geschlossener Vorgang. Er hat einen

Akteur und ein Ergebnis. Der Akteur initiiert den

Use Case

, der

Use Case

wiederum

liefert ein Ergebnis an den gleichen oder einen anderen Akteur (Rupp/Hahn/Zengler

2005: 240ff). Im eigentlichen Sinne ist der

Use Case

ein dem Nutzer zur Verfügung

gestelltes Verhalten einer Systemkomponente. Während das

Domain Model

vor allem

den Datenfluss innerhalb des Systems veranschaulicht hat, zeigt der Use Case nun, wie

die Benutzer mit dem System agieren.

Im weiteren Verlauf sollen

Use Case

-Diagramme eine optische Darstellung der

Use Case

s zeigen. Die genaue Beschreibung der

Use Case

s ist in Anhang A hinterlegt.

Abbildung 15: User bei der Suche nach kompatibler Software, sowie Lizenzinformationen

Die Suche

Search for OSS compatible to selected license

(Abbildung 15) ermöglicht dem

Benutzer Software zu finden, die zu einer bestimmten Ziellizenz kompatibel ist. Um

die Funktion nutzen zu können, gibt der

User

Stichworte der zu suchenden Software

ein. Anschließend wählt er eine Ziellizenz aus, zu der die OSS kompatibel sein soll.

Nach dem die Suchkriterien spezifiziert wurden, drückt der

User

den OK-

Button

und

erhält im Anschluss eine Auswahl gefundener Software zurück.

Nun hat der

User

die Wahl den Vorgang zu beenden oder optional ­ daher handelt es

sich um eine

Extension

­ weitere Informationen bezüglich der verwendeten Lizenz

79

---

Die Lizenzkompatibilitätssuche

5.3 Use Case-Entwicklung

anzufordern. Entscheidet er sich, Informationen zu der Lizenz abzufragen, wählt er

durch

Select search result

aus der Liste der Suchergebnisse eines aus und bestätigt die

Auswahl. Jetzt werden mit

Search for informations about licenses of search result

Informationen zu den damit im Zusammenhang stehenden Lizenzen angefordert und

dem Benutzer ein Lizenzüberblick angezeigt. Dieser enthält Informationen über den

Copyleft

-Effekt der Lizenz und die Bedingungen, die zu diesem Charakter geführt

haben.

Abbildung 16:

Wartung und Update der Wissensbasis

Rechts: Lizenzexperte beim editieren der Wissensbasis

Links: Update der Wissensbasis durch den Systemverwalter

Den Kern des Systems bildet

License Knowledge Base

. Hier ist das Wissen über

Lizenzen und die Zusammenhänge zwischen ihnen gespeichert. Der

License Expert

editiert diese Wissensbasis, wie in Abbildung 16 dargestellt. Dazu legt er beim ersten

Mal mit

Create kowledge base

eine Wissensbasis an, die Wissen über OSS-Lizenzen in

Form einer OWL-Ontologie und zugehörige Regeln enthält. Existiert die

Wissensbasis bereits, sind im Zusammenhang mit dem Editieren lediglich die

eingebundenen

Use Cases

Open Knowledge Base

und

Save Knowledge Base

erforderlich.

Um die Wissensbasis in Bereitschaft zur Abfrage zu versetzen, muss durch den

Systemverwalter ein Update des darin enthaltenen Wissens durchgeführt werden.

Konkret geht es darum, die Regeln anzuwenden und ein

Reasoning

durchzuführen.

Dies erfolgt bei jedem Update.

80

---

Die Lizenzkompatibilitätssuche

5.4 Spezifikation

5.4 Spezifikation

Nach Kenntnis der

Use Cases

werden nun die Anforderungen an das System definiert

und die Grenzen des Entwurfes bestimmt. Konkret werden Standards,

Programmiersprachen und Datenquellen festgelegt, sowie nicht-funktionale

Anforderungen an das System definiert.

5.4.1 Standards, Programmiersprachen und Datenquellen

In diesem Abschnitt soll definiert werden, welche Standards, Programmiersprachen

und Datenquellen im System Verwendung finden. Nachdem einige dieser Elemente in

Kapitel 2.2 vorgestellt wurden, wird nun ein Rahmen festgelegt, der Möglichkeiten

und Beschränkungen für das System aufzeigen soll.

Aufgrund der bereits vorgenommenen Erstellung der Wissensbasis, wird die auf

XML und RDF basierende

Web Ontology Language

herangezogen. Sie eignet sich für

die Modellierung semantischer Zusammenhänge, stellt eine W3C-

Recommendation

dar

und garantiert in der Variante OWL DL vollständige Verarbeitbarkeit und

Entscheidbarkeit. Die Regelerweiterungen werden in der

Semantic Web Rule Language

erstellt, die logische Regeln über OWL-Atomen definiert. Die Sprache bietet den

Vorteil, dass sie von den im System genutzten Bestandteilen unterstützt wird und sich

somit für die Anwendungsentwicklung eignet.

Als Programmiersprache wird im wesentlichen JAVA15 eingesetzt. Die Sprache hat den

großen Vorteil der plattformunabhängigen Einsetzbarkeit und kann daher in jeder

Betriebssystemumgebung genutzt werden. Sie verfügt über eine automatische

Speicher- und

Heap

-Verwaltung und kommt damit der systemübergreifenden

Programmierung entgegen. Vor allem aber ist die

Inference Engine

KAON2 wie auch

die meisten anderen Entwicklungen in diesem Bereich in Java implementiert und daher

besser integrierbar.

Für die

Interface

-Entwicklung wird PHP16 verwendet. Diese Sprache beinhaltet schon

in ihrer grundlegenden Form eine große Zahl verschiedener Bibliotheken und

vorgefertigter Funktionseinheiten im Bereich des Netzwerks, der Protokolle, und

15 Vergl. <http://www.java.com/de/about/>.

16 Weitere Informationen auf <http://www.php.net/>.

81

---

Die Lizenzkompatibilitätssuche

5.4 Spezifikation

Datenbankanbindungen. Zudem es ist eine

Open Source

-Entwicklung, die im

Webumfeld sehr häufig eingesetzt wird. Für den Einsatz spricht auch der

Open Source-

Mediator

BerliOS

, der später zu Testzwecken genutzt werden soll und auf

PHP-Basis umgesetzt ist, was die nahtlose Integration erheblich erleichtert.

Als Mittler zwischen PHP und JAVA dient die sogenannte PHP/JAVA Bridge17. Mit

dieser Brücke besteht die Möglichkeit, eine Verbindung zwischen JAVA und PHP

herzustellen. Sie wird im Projekt für die Koppelung von Interface und der

Hauptanwendung herangezogen.

Als Datenquellen kommen auf der einen Seite die weiter oben vorgestellte

Wissensbasis und auf der anderen Seite die Datenbank der anzubindenden Forge zum

Einsatz.

5.4.2 Nicht-Funktionale Anforderungen

Über die eben beschriebenen Erfordernisse hinaus kann jedes System mehrere

nicht-funktionale Anforderungen haben. Die Tatsache, dass ein System den

funktionalen Anforderungen entspricht, sagt nicht zwangsläufig etwas über seine

Verwendbarkeit im Alltagsbetrieb aus. Ausfallsicherheit, Verfügbarkeit, Datenschutz,

Wartbarkeit und Performance können entscheidenden Einfluss auf die

Praxistauglichkeit seiner Komponenten haben.

Im Fall der Lizenzkompatibilitätssuche spielt, wie bei anderen Suchmaschinen, die

Performance ein wichtige Rolle. Anfragen sollten innerhalb eines Zeitraums bearbeitet

werden, der zwar größer als bei einer normalen Suchmaschine sein kann, jedoch 30

Sekunden nicht überschreiten sollte. Dies muss bei der Planung der Systemressourcen

Berücksichtigung finden. Die Planung der Systemresourcen ist allerdings kein

Bestandteil dieser Arbeit, da in diesem frühen Stadium des Entwurfs noch keine

ausreichenden Test erfolgen können.

Ausfallsicherheit und Verfügbarkeit werden in diesem Fall nicht als sonderlich kritisch

eingestuft, da keine anderen Dienste von diesem System abhängen und die Nutzung

des Dienstes nicht innerhalb wichtiger Geschäftsprozesse erfolgt.

Datenschutz ist insofern wichtig, dass der Zugang zu den Datenquellen mit

Benutzernamen und Passwort geschützt werden sollte, um eine Manipulation der

17 Projektinformationen auf <http://php-java-bridge.sourceforge.net/pjb/index.php>.

82

---

Die Lizenzkompatibilitätssuche

5.4 Spezifikation

Daten zu vermeiden. Da diese Zugangsdaten auch vom System selbst benutzt werden,

sollten sie an einer sicheren Stelle außerhalb des

Webroots

abgelegt werden. Eine

verschlüsselte Datenübertragung wird nicht als notwendig erachtet.

Da an dem System selbst keine regelmäßigen Änderungen vorgenommen werden

müssen und sich die Wartung im Wesentlichen auf das Starten und Stoppen von

Diensten beschränkt, wird auch der Punkt Wartung als weniger wichtig erachtet.

Lediglich die Wissensbasis muss von Zeit zu Zeit verändert werden. Dies wird jedoch

nicht mit Bestandteilen des hier entworfenen Systems geschehen.

83

---

Zusammenfassung

6 Zusammenfassung

6 Zusammenfassung

Die vorliegende Arbeit gibt auf der Basis von

Semantic Web

-Technologien einen

Einblick in die Möglichkeiten der maschinengestützten Darstellung und Verarbeitung

von Wissen und zeigt anhand einer problemorientierten Fragestellung sowohl eine

auf der Grundlage dieser Technologien durchgeführte Formalisierung von

Open Source

-Lizenzen als auch die situationsabhängige Auswertung des so gewonnen

Wissens mithilfe eines Expertensystems. Dieses Expertensystem wird beim

nachfolgenden Entwurf einer erweiterten Softwaresuche für kollaborative

Open Source

-Entwicklungsplattformen in eine praxisorientierte Anwendung integriert.

Dabei wird gezeigt, dass sich Lizenztexte als vertraglich festgelegte Nutzungssrechte

im

Open Source

-Bereich nicht nur auf eine bestimmte Art und Weise in einer Ontologie

formalisieren lassen, sondern dass die so vorgenommene Formalisierung als

Wissensbasis in ein Expertensystem integriert, auch einen praktischen Nutzen

innerhalb einer Anwendung bieten kann.

6.1 Ergebnisse

Nachdem in Kapitel 2 der schriftlichen Darlegung der allgemeine Wissensstand zur

Bearbeitung des Themas wiedergegeben wurde, setzt sich die Arbeit zunächst mit dem

Aufbau eines Expertensystems mithilfe von

Semantic Web-

Technologien auseinander.

Es wird gezeigt, wie eine spezielle Implementierungsvariante eines Expertensystems

auf der Basis einer

Inference Engine

, sowie einer Wissensbasis, codiert in OWL DL und

der Regelsprache SWRL, aussehen kann.

Der folgende Teil definiert kompatible Software-Lizenzen als Lizenzen, deren

zugehörige Programme in rechtlich vertretbarer Form miteinander kombiniert

werden können. Da in diesem Zusammenhang von einem komplizierten Wechselspiel

zwischen den Lizenztexten und deren Auslegung im nationalen Recht ausgegangen

werden muss, wird der

Copyleft-

Effekt der Lizenz als Ansatzpunkt für eine

vereinfachte Kompatibilitätsbetrachtung herangezogen. Zudem werden Indizien, die

zur Bestimmung des

Copyleft-

Effektes notwendig erscheinen, registriert.

Auf Basis der Erkenntnisse einer Untersuchung von drei

Open Source

-Lizenzen, sowie

84

---

Zusammenfassung

6.1 Ergebnisse

den Elementen, die zur Bestimmung des

Copyleft-

Effekts als wichtig erachtet werden,

wird im weiteren Verlauf eine Wissensbasis mit Wissen über

Open Source

-Lizenzen in

OWL DL modelliert. Die Lizenzen werden mithilfe eines dabei entworfenen Ansatzes

für die Formalisierung von

Open Source

-Lizenzen in die Wissensbasis übertragen.

Wesentliche Elemente der Formalisierung werden innerhalb der schriftlichen

Darlegung erläutert, die vollständige Wissensbasis ist auf http://www.qiq.de

f

verfügbar.

C

D

Als wichtige Elemente der Wissensbasis haben sich die einzelnen Ziffern und Sätze

des Lizenztextes, die mit der Lizenz im Zusammenhang stehenden Werke und die

Lizenzbedingungen erwiesen. Die Lizenzbedingungen stellen zudem die wesentlichen

Elemente für die Untersuchung des Lizenz-Charakters dar, welcher auf dem

Copyleft-

Effekt beruht. Diesbezüglich spiegelt die Lizenzbedingung den

Anwendungsfall wieder, unter dem eine Bestimmung gilt und verweist auf Rechte und

Möglichkeiten, die dem Lizenznehmer bei der Beachtung bestimmter Pflichten

gewährt werden.

Manche Lizenzbedingungen oder Querverweise im Lizenztext sind in Form von

Regeln in den Lizenztexten festgehalten und damit für eine Formalisierung mit OWL

DL Mechanismen ungeeignet. An dieser Stelle kommt die Regelsprache SWRL zum

Einsatz. Die Arbeit zeigt einen Ansatz, der es ermöglicht, solche Elemente zu

formalisieren. Es werden logische Regeln über OWL-Atomen definiert, die sich auf

Klassen, Eigenschaften und Instanzen mithilfe von Variablen beziehen und damit zur

Vervollständigung des Wissens in der Wissensbasis geeignet sind.

Ein ähnlicher Effekt wird mit definierten Klassen innerhalb der Ontologie erzielt.

Durch die Formulierung von Eigenschaften mit notwendigen und hinreichenden

Bedingungen als Konzepte, wird mit Beschreibungslogik neues Wissen aus

vorhandenem Wissen gewonnen. Der in diesem Zusammenhang entworfene Ansatz

identifiziert Bedingungen, die sich auf relevante kombinierte Werke beziehen. Diese

Bedingungen werden auf Pflichten untersucht, die für einen starken, einen schwachen

oder gar keinen

Copyleft-

Effekt sprechen. Ergebnis der Untersuchung sind

entsprechend dem

Copyleft-

Effekt klassifizierte Lizenzen, welche infolge des

Reasoning

-

Prozesses definierten Klassen zugeordnet werden.

85

---

Zusammenfassung

6.1 Ergebnisse

Die Tauglichkeit der eben beschriebenen Ansätze wird mit der Validierung der

Formalisierung auf Basis der drei beispielhaft formalisierten Lizenzen untersucht. Bei

einem Testlauf werden die durch das Expertensystem gezogenen Schlussfolgerungen

mit den Erkenntnissen der gängigen Fachliteratur verglichen. Ergebnis sind 26

identifizierte Lizenzbedingungen, die für die Untersuchung des

Copyleft-

Effekts

bedeutsam erscheinen, von denen sechs für Lizenzen ohne

Copyleft-

Effekt, zwölf für

Lizenzen mit strengem

Copyleft-

Effekt und acht für Lizenzen mit schwachem

Copyleft-

Effekt sprechen. Diese Ergebnisse führen innerhalb des Systems zu dem

Schluss, dass von den drei formalisierten Lizenzen die neue BSD-Lizenz keinen

Copyleft-

Effekt aufweist, die LGPL einen schwachen

Copyleft-

Effekt hat und GPL wie

auch LGPL als Lizenzen mit starkem

Copyleft-

Effekt zu sehen sind. Die LGPL taucht

bei der Klassifizierung zweimal auf. Wie auch in der Fachliteratur werden innerhalb

dieser Lizenz Charaktermerkmale identifiziert, die sowohl für einen starken, wie auch

für einen schwachen

Copyleft-

Effekt sprechen. Das System hat sich damit im Rahmen

dieses Testszenarios als tauglich erwiesen.

Den Abschluss bildet der Entwurf einer Anwendung, die eine Suchfunktion für

Software im Bereich von kollaborativen

Open Source

-Entwicklungsplattformen

erweitern soll und das zuvor getestete Expertensystem zur Lizenzanalyse nutzt.

Informationen zu den Lizenzen sollen dabei über Links im Suchergebnis der

Softwaresuche verfügbar werden. Diese Informationen betreffen die Klassifikation von

Lizenzen und geben Empfehlungen, auf welche Weise ein Softwareentwickler eigens

erstellte Entwicklungen mit bestehender Software kombinieren kann. Dazu werden im

Domain Model

die relevanten Systeme, Akteure und Komponenten der Anwendung

zueinander in Beziehung gesetzt, der Informationsfluss grafisch dargestellt,

Use Cases

entwickelt und eine Spezifikation für das System erstellt. Ergebnis ist der Entwurf

einer Anwendung, deren Kernbestandteil das zuvor beschriebene Expertensystem ist,

welches seine Schlüsse aufgrund der dafür entwickelten Wissensbasis mit Wissen über

Open Source

-Lizenzen zieht.

6.2 Probleme und offene Fragen

Die Formalisierung von

Open Source

-Lizenzen erwies sich als komplexes Unterfangen,

86

---

Zusammenfassung

6.2 Probleme und offene Fragen

da die Vertragstexte weder mit dem Anspruch der maschinellen Verarbeitbarkeit

entworfen, noch die verwendeten Ontologiesprachen speziell für die Formalisierung

von Rechtstexten entwickelt wurden.

Die Lizenzen enthalten viele Querverweise, die bei der Formalisierung nach dem

weiter oben beschriebenen System zur besseren Verarbeitung aufgelöst werden

müssen. Solche Passage beinhalten Aussagen wie in Ziffer 2 der LGPL: ,,You may

modify your copy or copies of the Program or any portion of it, thus forming a work

based on the Program, and copy and distribute such modifications or work under the

terms of Section 1 above." Einige Bedingungen in den Lizenzen ergeben sich erst aus

unterschiedlichen Aussagen, die nicht aus zusammenhängenden Abschnitten im

Lizenztext geschlussfolgert werden können, sondern über den ganzen Vertragstext

verteilt liegen. Andererseits fehlt den verwendeten Ontologie- und Regelsprachen bei

logischen Verknüpfungen die Negation, die bei der Formalisierung gewisser

Lizenzpassagen hilfreich gewesen wäre. Zum Beispiel existiert eine Passage in Ziffer 0

der GPL, die besagt, dass ein reines Ausführen des Programms nicht von der Lizenz

berührt wird. Das Fehlen von Pflichten ist ein Faktum, das anhand von Inferenzregeln

in OWL DL nicht hergeleitet werden kann. Es handelt sich um eine nicht beweisbare

Aussage, die weder wahr noch falsch ist. Eine

Inference Engine

wird immer annehmen,

dass noch nicht bekannt ist, ob Pflichten existieren, nicht aber davon ausgehen, dass es

keine Pflichten gibt.

Bei der vorgenommenen Formalisierung von Rechten, Möglichkeiten und Pflichten

ergibt sich das Problem, dass die so formalisierten Elemente immer als eine Art

Annäherung an den Lizenztext begriffen werden müssen, um überhaupt eine

Vergleichbarkeit verschiedener Lizenztexte zu ermöglichen. So wurden beispielsweise

die komplexen Bestimmungen, die sich mit der Bereitstellung des

Source Codes

bei

verschiedenen Lizenzen befassen in der Eigenschaft makeSourceCodeAvailable

zusammengefasst ­ ohne dabei auf Details einzugehen, die sich mit Art und Weise der

Veröffentlichung beschäftigen. Dies ist einer der Gründe, warum die Ergebnisse, die

das Expertensystem liefert, lediglich als Empfehlungen gesehen werden können.

Die Betrachtung von Kompatibilität stellt eine interessante Anwendungsmöglichkeit

für das Expertensystem dar. Lizenzkompatibilität kann in diesem Zusammenhang

87

---

Zusammenfassung

6.2 Probleme und offene Fragen

allerdings nur eingeschränkt analysiert werden, da zum Zeitpunkt der Formalisierung

keine Unterstützung durch einen Experten in Rechtsfragen gegeben war, die eben

beschriebene Formalisierung lediglich als Annäherung zu begreifen ist und sich die

verwendete Regelsprache im juristische Kontext nicht als optimale Lösung erwiesen

hat. Das hängt damit zusammen, dass sich in SWRL einige Eigenheiten bei

rechtlichen Fragestellungen nur ungenügend abbilden lassen. Die Regelsprache

besitzt z.B. keinen Mechanismus, um mit konfligierenden Regeln umzugehen oder

Prioritäten bei der Anwendung von Regeln festzulegen. Zudem kennt sie keine

Negation.

Zu den genannten Problemen kommt hinzu, dass innerhalb der Arbeit auf keine

früheren Erkenntnisse bei der Formalisierung von Lizenztexten zurückgegriffen

werden konnte, da auf diesem Feld entweder kaum verwertbare Ansätze existieren,

innerhalb der Recherche nicht gefunden werden konnten, oder nicht zugänglich waren.

Dies hatte zur Folge, dass eine Vielzahl von Ansätzen getestet werden musste, bis sich

eine Lösung als brauchbar erwies. Darüber hinaus ist der Verfasser kein

Rechtsexperte, weshalb der Formalisierungsansatz im Nachgang einer Rechtsprüfung

unterzogen werden müsste.

Im Verlauf der schriftlichen Darlegung ist bereits etwas zur Auslegung von

Lizenzbedingungen im Kontext nationalen Rechts gesagt worden und auch, dass

dieser Punkt nicht betrachtet wird. Im Zweifel und bei Rechtsverletzungen wird aber

genau diese Betrachtung entscheidend sein. Es stellt sich die Frage, ob es eventuell

mit neuen Ansätzen oder anderen Regelsprachen möglich ist, diesen Punkt zu

berücksichtigen.

Da in dieser Arbeit nur drei

Open Source

-Lizenzen untersucht und formalisiert werden,

ist offen, ob sich zumindest die auf der Seite der

Open Source

-Initiative gelisteten 72

Lizenzen mit den zugrunde liegenden Ansätzen formalisieren lassen. Die

identifizierten Rechten, Pflichten und Möglichkeiten, die innerhalb der Lizenztexte

beschrieben werden, könnten sich als derart vielschichtig erweisen, dass eine

Vergleichbarkeit von Lizenzen nicht, oder nur in Form eines geringen

Annäherungsgrades der formalisierten Elemente an den Inhalt der

Lizenzbedingungen, gegeben ist.

88

---

Zusammenfassung

6.3 Ausblick

6.3 Ausblick

Die vorangegangenen Abschnitte zu Problemen und offenen Fragen haben gezeigt,

dass nicht alle Ungewissheiten abschließend beantwortet werden konnten und sich die

Entwicklung wissensbasierter Systeme als eine sehr komplexe Thematik erweist. Der

folgende Text wird sich daher mit der Frage beschäftigen, in welcher Weise die bisher

gewonnenen Erkenntnisse genutzt und ausgebaut werden können.

Zunächst sind die in der Arbeit vorgestellten Ansätze mithilfe einer

vertrauenswürdige Beurteilung zu überprüfen. Ein solches Gutachten kann durch

einen Sachverständigen in Rechtsfragen erfolgen. Ziel ist es, eine externe

Stellungnahme zu dem besagten Sachverhalt einzuholen und die Tauglichkeit der

Formalisierung von

Open Source

-Lizenzen einer Prüfung zu unterziehen.

Erweist sich die Formalisierung als praxistauglich kann die Erweiterung der

Wissensbasis vorangetrieben und über neue Anwendungsmöglichkeiten nachgedacht

werden. Ontologien sind darauf ausgelegt zusammengesetzt bzw. erweitert zu

werden. Auf diese Weise lassen sich Wissensgebiete zusammenführen, was die

Möglichkeit späterer Schlussfolgerungen vervielfacht. Bei den Lizenzen wurde bereits

darauf hingewiesen, dass Werke Lizenzen haben können oder bestimmte

Organisationen Lizenzen zertifizieren. An dieser Stelle bestünde die Möglichkeit eine

Ontologie über Werke oder Organisationen einzubinden. Auch eine Urheberontologie,

in der Schöpfer von Werken geführt werden, ist denkbar. Eine Ontologie über Urheber

kann im Zusammenhang mit der Lizenzontologie beispielsweise Hinweise darüber

liefern, ob jemand Urheber von

Open Source Software

ist. Eine Ontologie über Werke

wäre in der Lage

Open Source Software

erkennen. Die Organisation OSI und ihr

Zertifizierungsprozess für OSS-Lizenzen kann in einer weiteren Ontologie dargestellt

werden, der sich wiederum auf die Lizenzontologie beziehen könnte und damit

herleiten, aus welchem Grund bestimmte Lizenzen ihr

Trademark

erhalten.

Wie bereits angedeutet, hat sich SWRL bei der Formalisierung der Lizenztexte nicht

als optimale Sprache erwiesen, da beispielsweise für die Entwicklung von Regeln keine

Negation zur Verfügung steht. Daher sollte die Verwendung einer anderen

Regelsprache in Betracht gezogen werden. In diesem Zusammenhang erscheint eine

nähere Untersuchung des

Legal Knowledge Interchange Format

(LKIF), was aus dem

89

---

Zusammenfassung

6.3 Ausblick

Estrella Projekt18 hervorgegangen ist, für eine Weiterentwicklung des

Expertensystems interessant. Es handelt sich dabei um ein Format für eine

Regelsprache zur Analyse juristischer Fragestellungen, welche mit Blick auf die

besonderen Eigenschaften von Regeln im Bereich des Rechts entwickelt wird.

Eigenschaften solcher Regeln sind beispielsweise, dass sie zueinander in Konflikt

stehen können, das Setzen von Prioritäten verlangen, in bestimmten Kontexten

ungültig sein können oder nur angenommen wird, dass sie wahr sind (Gordon 2008:

4). LKIF unterstützt im Gegensatz zu SWRL die Negation, ist in der Lage ein

anfechtbares

Reasoning

durchzuführen und damit möglicherweise besser für die

Betrachtung von Kompatibilitätsfragen im Bereich der

Open Source

-Lizenzen geeignet

als SWRL.

18 Vergleiche dazu <http://www.estrellaproject.org/?page_id=5>

90

---

Anhang A

Use Case Diagramme

Uses Case Name

Search for OSS compatible to selected license

Kurze Beschreibung

Es soll eine Suche nach OSS durchgeführt werden, die zu einer bestimmten

Ziellizenz kompatibel ist.

Akteure

User, License Expert System

Vorbedingung

Der User befindet sich im Suchbereich der Forge. Die Suchmaske wird

angezeigt. Ein Auswahlfeld mit möglichen Ziellizenzen steht zur Verfügung

Nachbedingung

Der User bekommt als Ergebnis seiner Suche OSS, die zur gewählten Liztenz

kompatibel ist, angezeigt.

Gewöhnlicher Ablauf

Der User drückt nach Eingabe der Suchkriterien auf den Suchbutton der

Suchmaske. Die Suchkriterien werden an das License Expert System

übergeben.

Alternativer Ablauf

-

Includes

Enter keywords, Select target license

Extends

Search for informations about licenses of search result

Uses Case Name

Enter keywords

Kurze Beschreibung

Stichworte für die Suche sollen eingegeben werden.

Akteure

User

Vorbedingung

Der User befindet sich im Suchbereich der Forge und bekommt ein

Suchformular angezeigt.

Nachbedingung

Die Stichworte wurden eingegeben.

Gewöhnlicher Ablauf

Der User gibt Stichworte in das Suchformular ein.

Alternativer Ablauf

-

Includes

-

Extends

-

Uses Case Name

Select target license

Kurze Beschreibung

Der User soll sich für eine Lizenz entscheiden, zu der er kompatible OSS

suchen möchte.

Akteure

User, License Expert System

Vorbedingung

Eine Liste verfügbarer Lizenzen wird im Browser angezeigt.

Nachbedingung

Eine Ziellizenz wurde ausgewählt.

Gewöhnlicher Ablauf

Der User wählt aus einem Drop-Down-Menü im Browser eine Lizenz aus einer

Liste, die ihm vom License Expert System zur Verfügung gestellt wird,

aus.

Alternativer Ablauf

-

Includes

-

Extends

-

Uses Case Name

Search for informations about licenses of search result

Kurze Beschreibung

Der User möchte weitere Informationen über das Suchergebnis erhalten.

---

Speziell soll ein Überblick zu der zur Software gehörenden Lizenz gegeben

werden.

Akteure

User

Vorbedingung

Ein Suchergebnis wurde ausgewählt

Nachbedingung

Ein Lizenzüberblick wird dem Benutzer präsentiert. Insbesondere

Bedingungen, die zu einem bestimmten Copyleft-Effekt geführt haben,

werden dargestellt.

Gewöhnlicher Ablauf

Der User bestätigt die Auswahl des Suchergebnisses.

Alternativer Ablauf

-

Includes

Select search result

Extends

-

Uses Case Name

Select search result

Kurze Beschreibung

Der User wählt ein Suchergebniss der vorangegangenen Suche aus.

Akteure

User

Vorbedingung

Das Suchergebnis wird angezeigt

Nachbedingung

Ein Suchergebnis wurde spezifiziert.

Gewöhnlicher Ablauf

Der User markiert ein Suchergebniss.

Alternativer Ablauf

-

Includes

-

Extends

-

Uses Case Name

Update Knowledge Kase

kurze Beschreibung

Nach Änderungen an der Wissensbasis sollen die Ergebnisse des Regel- und

Reasoning-Prozesses dem License Expert System zur Verfügung gestellt

werden.

Akteure

Admin

Vorbedingung

Die Wissensbasis wurde erstellt oder verändert.

Nachbedingung

Es können Anfragen an die Wissensbasis gestellt werden.

gewöhnlicher Ablauf

Der Admin setzt eine Sequenz in Gang, die eine Anwendung der Regeln

realisiert und den Reasoning-Prozess initiiert. Mit den Ergebnissen wird

die Wissensbasis aktualisiert.

Alternativer Ablauf

-

Includes

-

Extends

-

Uses Case Name

Edit Knowledge Base

Kurze Beschreibung

Eine Wissensbasis soll verändert oder erweitert werden.

Akteure

Knowledge Expert

Vorbedingung

Nachbedingung

Die Wissensbasis wurde verändert und die Änderungen gespeichert

Gewöhnlicher Ablauf

Die Wissensbasis wird geöffnet, verändert und wieder gespeichert.

Alternativer Ablauf

Die Wissensbasis wird angelegt, geöffnet, verändert und wieder

gespeichert.

Includes

Open Knowledge Base, Save Knowledge Base

Extends

Create kowledge base

---

Uses Case Name

Create kowledge base

Kurze Beschreibung

Eine Wissensbasis soll erstellt werden.

Akteure

Knowledge Expert

Vorbedingung

-

Nachbedingung

Die Wissensbasis wurde erstellt.

Gewöhnlicher Ablauf

Es wird eine Datei erstellt, in der Zusammenhänge zwischen OSS Lizenzen

und Regeln für deren Kompatibilität zueinander aufzeigt.

Alternativer Ablauf

-

Includes

-

Extends

-

Uses Case Name

Open Knowledge Base

kurze Beschreibung

Eine bestehende Wissensbasis wird geöffnet

Akteure

Knowledge Expert

Vorbedingung

Die Wissensbasis existiert.

Nachbedingung

Die Wissensbasis ist zum schreiben geöffnet.

gewöhnlicher Ablauf

Mit Hilfe eines Editors oder anderen Tools wird eine OWL-Datei geöffnet.

Alternativer Ablauf

-

Includes

-

Extends

-

Uses Case Name

Save Knowledge Base

kurze Beschreibung

Eine Wissensbasis wird gespeichert

Akteure

Knowledge Expert

Vorbedingung

Die Wissensbasis wurde verändert.

Nachbedingung

Die Änderungen an der Wissensbasis wurden gespeichert.

gewöhnlicher Ablauf

Mit Hilfe eines Editors oder anderen Tools wird die Wissensbasis

gespeichert.

Alternativer Ablauf

-

Includes

-

Extends

-

---

Literaturverzeichnis

BERNERS-LEE, Tim (2005): Uniform Resource Identifier (URI). Generic Syntax.

URI: http://www.ietf.org/rfc/rfc3986.txt. Stand: 13.09.2007.

BERNERS-LEE, Tim (1998): Semantic Web Road map. URI:

http://www.w3.org/DesignIssues/Semantic.html. Stand: 03.09.2007.

BERNERS-LEE, Tim / Hendler, James / Lassila, Ora (2001): The Semantic Web.

URI: http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-

84A9809EC588EF21&catID=2. Stand: 04.09.2007.

BOLEY, Harold / Kifer, Michael (2007): RIF Core Design. URI:

http://www.w3.org/TR/rif-core/. Stand: 10.09.2007.

BROCKHAUS (1986): Wissen, 19. Auflage Mannheim.

COAR, Ken (2007): The Open Source Definition. URI:

http://www.opensource.org/docs/osd. Stand: 20.03.2007.

DIGEL, Werner / Kwiatkowski, Gerhard (1980): Ontologie in: Meyers Neues

Lexikon, Band 6. Mannheim.

DUERST, Martin / Suignard, Michael (2005): Internationalized Resource Identifiers

(IRIs). URI: http://www.ietf.org/rfc/rfc3987.txt. Stand: 13.09.2007.

FOGEL, Karl / Barkhau, Manuel (2005): Produktion von Open Source Software. Wie

man ein erfolgreiches freies Software Projekt führt. URI:

http://producingoss.com/de/. Stand: 07.07.2008.

Free Software Foundation (2007): Categories of Free and Non-Free Software. URI:

http://www.gnu.org/philosophy/categories.html. Stand: 01.06.2008.

Free Software Foundation (2005): What is Copyleft?. URI:

http://www.fsf.org/licensing/essays/copyleft.html. Stand: 05.01.2008.

---

GHOSH, Rishab Aiyer (2006): Study on the: Economic impact of open source software

on innovation and the competitiveness of the Information and Communication

Technologies(ICT) sector in the EU. URI:

http://ec.europa.eu/enterprise/ict/policy/doc/2006-11-20-flossimpact.pdf.

Stand: 16.04.2008.

GORDON, T.F. (2008): Hybrid reasoning with argumentation schemes. URI:

http://www.tfgordon.de/publications/Gordon2008a.pdf. Stand: 12.08.2008.

GRASSMUCK, Volker (2004): Freie Software. Zwischen Privat-und Gemeineigentum,

2. Auflage Bonn.

GRUBER, Thomas R. (1993): A Translation Approach to Portable Ontology

Specifications. URI:

ftp://ftp.ksl.stanford.edu/pub/KSL_Reports/KSL-92-71.ps.gz. Stand:

06.09.2007.

HORROCKS, Ian / Patel-Schneider, Peter F. / Boley, Harold / u.a. (2004): SWRL. A

Semantic Web Rule LanguageCombining OWL and RuleML. URI:

http://www.w3.org/Submission/SWRL/. Stand: 10.09.2007.

JACOBS, Ian (2003): World Wide Web Consortium Process Document. URI:

http://www.w3.org/2003/06/Process-20030618/cover.html. Stand: 12.09.2007.

JAEGER, Till / Metzger, Axel (2006): Open Source Software. Rechtliche

Rahmenbedingungen der Freien Software 2. Auflage München.

JÄGER, Till / Koglin, Olaf / Kreutzer, Till u.a (2005): GPL kommentiert und erklärt,

1. Auflage Köln.

KLYNE, Graham / Carroll, Jeremy J. / McBride, Brian (2004): Resource Description

Framework. Concepts and Abstract Syntax. URI:

http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Stand:

04.09.2007.

Kreutzer, Till (2004): Gründe für GPL-Urteil veröffentlicht. URI:

http://www.ifross.de/ifross_html/home2_2004.html#ARTIKEL31. Stand:

27.03.2008.

---

MCBRIDE, Brian (2004): Resource Description Framework (RDF. Concepts and

Abstract Syntax. URI: http://www.w3.org/TR/rdf-concepts/. Stand:

23.08.2007.

MCGUINNESS, Deborah L. /Van Harmelen, Frank (2004): OWL Web Ontology

Language Overview. URI:

http://www.w3.org/TR/2004/REC-owl-features-20040210/. Stand:

03.09.2007.

MOTIC, Boris (2006): Reasoning in Description Logics using Resolution and

Deductive Databases. URI:

http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1437. Stand:

03.03.2008.

NELSON (2007): Certification Mark. URI:

http://www.opensource.org/docs/certification_mark.html. Stand: 01.05.2008.

O′Connor, Martin (2007): SWRL Language FAQ. URI: http://protege.cim3.net/cgi-

bin/wiki.pl?SWRLLanguageFAQ. Stand: 12.09.2007.

PELLEGRINI, Tassilo / Blumauer, Andreas (2006): Semantic Web. Wege zur

vernetzten Wissensgesellschaft, 1. Auflage Berlin.

PRUD′HOMMEAUX, Eric / Seaborne, Andy (2007): SPARQL Query Language for

RDF. URI: http://www.w3.org/TR/rdf-sparql-query/. Stand: 09.09.2007.

RUPP, Chris / Hahn, Jürgen / Queins, Stefan / Jeckle, Mario / Zengler, Barbara

(2005): UML 2 glasklar. Praxiswissen für die UML-Modellierung und

-Zertifizierung, 2. Auflage München Wien.

SACK, Harald (2006): Ontologien - "...was sind und zu welchem Ende studieren wir

Ontologien". URI:

http://www.informatik.uni-jena.de/%7Esack/Material/Ontologien.pdf. Stand:

03.06.2008.

SCHNEIDER, Hans-Jochen (1991): Lexikon der Informatik, 3. Auflage München.

SCHÖNING, Uwe (1995): Logik für Informatiker, 4. Auflage Heidelberg.

---

SMITH, Michael K. / Welty, Chris / McGuinness, Deborah L. (2004): OWL Web

Ontology Language Guide. URI: http://www.w3.org/TR/owl-guide/. Stand:

01.09.2007.

TIEMANN, Michael (2006): History of the OSI. URI: http://opensource.org/history.

Stand: 22.05.2008.

ZEITZ, Philip / Mahr, Bernd (2001): Aussagenlogik. In: Ehrig, Hartmut:

Mathematisch-strukturelle Grundlagen der Informatik, 2. Auflage Berlin.

ZEITZ, Philip / Mahr, Bernd / Robering, Klaus (2001): Prädikatenlogik. In: Ehrig,

Hartmut: Mathematisch-strukturelle Grundlagen der Informatik, 2. Auflage

Berlin.

---