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

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  NA  

  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 Vertragstyp 1 . Dieser ermöglicht es z.B. dem Rechteinhaber, einem Lizenznehmer zustimmungsbedürftige Handlungen, wie z.B. die Vervielfältigung eines Computerprogramms, zu erlauben.

1 Vergleiche dazu die Anmerkungen der Kanzlei „LÜBECK Steuerberater Rechtsanwälte“ zu

Lizenzverträgen .

­ 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 Free Software unter .

­ 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

.

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, Lesser General Public License, die und die New Berkeley Software Distribution License. Alle diese Lizenzen genügen den Richtlinien der OSI, unterscheiden sich jedoch mehr oder weniger stark. Dabei entsteht ein Problem, was die freie Weiterentwicklung von OSS nicht nur behindert, sondern rechtliche Unsicherheit schafft. OSS lässt sich nicht mehr beliebig kombinieren 8 ,

6 Eine Beschreibung des Projektes kann auf eingesehen

werden.

7 Eine alphabetisch geordnete Liste anerkannter Open Source-Lizenzen der OSI ist auf

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:

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:

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:

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 ( ∃ x L 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 Diagrams findet sich im Semantic Web-Bereich des W3C

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.

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

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.

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

.

12 Eine stabile Version von Kaon2 findet sich auf . ­ 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 .

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

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:

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.

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.

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:

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.

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.

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.

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:

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.

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.

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:

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.

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

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:

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.

Außerdem weisen Sätze, wie in Abbildung 7 gezeigt, die schon bekannte redundante Beziehung zu einer Lizenz auf.

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:

1

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:

[...]

[...]

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:

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

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:

[...]

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.

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

[...]

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:

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.

[...]

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.

­ 57 ­

Ein Expertensystem für OSS-Lizenzen 3.3 Modellierung der Wissensbasis

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.

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.

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.

Zusammenfassung:

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)

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:

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 Open Source Initiative Approved das Warenzeichen 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.

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:

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

verweist und ebenfalls eine

FormOfCombinedDistributedWork

auf eine Instanz der Klasse

isValidToPartOfDistributedWork-Property

PartOfDistributedWorkTouched. Auf diese Weise wird sichergestellt, dass alle Elemente

dieser Klasse für den Copyleft-Effekt der Lizenz relevant sind:

[...]

­ 66 ­

Ein Expertensystem für OSS-Lizenzen 3.3 Modellierung der Wissensbasis

[...]

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

­ 67 ­

Ein Expertensystem für OSS-Lizenzen 3.3 Modellierung der Wissensbasis

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.

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.

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:

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.

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

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

Die Lizenzkompatibilitätssuche 5.2 Domain Model

­ 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 Cases zeigen. Die genaue Beschreibung der Use Cases ist in Anhang A hinterlegt.

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.

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 JAVA 15 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 PHP 16 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. .

16 Weitere Informationen auf .

­ 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 Bridge 17 . 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 . ­ 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

verfügbar.

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 Projekt 18 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

­ 90 ­

Anhang A

Use Case Diagramme

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.