Freie Software einsetzen und jedermann anbieten, aber dennoch die Quellen zurückhalten – das geht ganz legal über das Schlupfloch Application Service Providing. Die Free Software Foundation ist hin- und hergerissen, will das Loch aber nicht schließen.

Application Service Providing, kurz ASP, und Software as a Service (SaaS) sind Buzzwords wie Web 2.0 auch. Während Hersteller proprietärer Software hier vor allem Einsparungsmöglichkeit für Vertrieb und Patch-Distribution sehen, nutzen findige Anbieter freie Software, um ASP-Lösungen zu entwickeln, brauchen aber den Quellcode nicht offenzulegen. Dürfen sie das?

Alles schon mal da gewesen

Application Service Providing bedeutet zwar – technisch betrachtet – eine Rückkehr in die gute alte Zeit der Zentralrechner, allerdings in deutlich größerem Rahmen. Ursprünglich hatte man dabei zunächst nur “im eigenen Haus” gearbeitet, auch wenn schon früh eine Fernverbindung möglich war, die Tty-Relikte in Linux erinnern daran. Heute bedeutet ASP vor allem Einsparung, nämlich auf der teuren Vertriebsschiene. Weil jeder Internet hat, ist es nicht länger nötig, Software umständlich auf Scheiben zu brennen, in bunte Kartons zu verpacken und in Regale zu schichten, es genügt ein Download-Link zur Produktbeschreibung auf der Homepage.

Das Prinzip bedeutet aber auch eine Abkehr vom traditionellen Verbreitungszyklus freier Software. Der Nutzer bekommt keinen Programmcode mehr, den er bearbeiten und weitergeben oder einfach nur weitergeben kann. Selbst wenn das Programm vollständig unter der GPL stünde, wäre der (Fern-)Benutzer genauso schlecht gestellt, als nutze er proprietäre Software. Er hat keinen Zugriff auf den Quellcode und nichts, das er erweitern oder kopieren könnte.

Nun ist es bei freier Software so, dass ein Benutzer – zumindest nach europäischer Rechtslage – in keinem Fall einen direkten Anspruch auf Herausgabe des Quellcode gegen denjenigen hat, von dem er das Programm erhält, wenn dies nicht besonders in einem Vertrag zwischen beiden vereinbart ist. Nur umständlich und auf Umwegen kann der Urheberrechtsinhaber, mit dem der Geber seinerseits den Lizenzvertrag geschlossen hat, dies durchsetzen. Wegen der inzwischen gefestigten Rechtsprechung zur GPL und der drohenden Kosten für den Verletzer bewirkt aber meist bereits die bloße Androhung, dass der den Quellcode zugänglich macht.

Quellen nur bei Weitergabe

Nicht so bei ASP-Programmen. Denn hier erhält der Kunde kein Programm, auch keine Kopie, selbst in seinen Arbeitsspeicher gelangt es nicht. Er benutzt es nur indirekt – genau so, wie er das Programm eines Geldautomaten benutzt, um sich Bargeld zu besorgen. Er gibt seine Daten ein und erhält das Ergebnis (oder auch nicht). Die GPL und andere freie Software setzen urheberrechtlich auf die Verbreitung, das ist die Weitergabe einer Kopie, oder auf das “öffentlich zugänglich machen”.

Bei ASP ist beides nicht der Fall, weil das betreffende Programm ausschließlich auf dem Rechner des Anbieters und in dessen Kontrollsphäre abläuft. Zwar automatisiert, aber nicht durch den Benutzer gesteuert, der nur die Daten eingibt, auf denen das Programm arbeitet. In der Regel wird SaaS ergänzt durch weitere Elemente wie Javascript-Code oder Programme wie den Webserver, die letztlich aber nur den Zugang zum eigentlichen ASP-Programm vermitteln oder unterstützen und urheberrechtlich individuell zu betrachten sind.

Aus GNU-Sicht hat SaaS einen schweren Nachteil: Die Software, also das datenverarbeitende Programm selbst, ist nicht mehr beim Benutzer. Weil viele, die auf Linux setzen, dies auch deshalb tun, um die Kontrolle über das, was auf ihrem Rechner passiert, zu behalten, wiegt der Nachteil schwer. Sie dürfen lediglich Daten an einen fremden Rechner schicken und darauf vertrauen, dass der schon richtig damit umgeht.

Die GPL verpflichtet den, der entsprechend lizenziert Software weitergibt, dazu, auch die Quellen zugänglich zu machen. Wird die Software aber wie beim ASP nicht weitergegeben, sondern lediglich eine Benutzerschnittstelle angeboten, entsteht auch keine Quellenöffnungspflicht. Das ist vergleichbar mit der Situation, in der ein Unternehmen nur intern freie Software einsetzt, ohne diese wieder an die Community zurückzugeben: Das ist legitim und liegt im Rahmen der GPL-Lizenzbedingungen.

Affero-Lizenz

Weil der ASP-Markt schon vor einigen Jahren zu boomen drohte, hat die FSF zusammen mit dem Affero-Projekt (Abbildung 1) noch zu GPL-v2-Zeiten eine Abwandlung der GPL entworfen, die genau diesen Fall berücksichtigt. Die Affero General Public License [1] ist nichts anderes als die um eine einzige Bestimmung erweiterte GPL. Nach der neuen Ziffer 2 d) muss, wer AGPL-lizenzierte Software im Rahmen eines ASP einsetzt, eine Funktion beibehalten, die es dem Benutzer zu jedem Zeitpunkt ermöglicht, sich den Quellcode der Anwendung über das HTTP-Protokoll übermitteln zu lassen, wenn diese Funktion bereits im Quellcode vorhanden war, den der Anbieter nutzt oder erweitert.

Abbildung 1: Die Affero-Webseite listet Informationen zur GPL-Variante, sieht aber nicht sehr lebendig aus.

Das Affero-Projekt scheint indes heute nicht bei bester Gesundheit. Die letzte News auf der Webseite datiert vom März 2003, der letzte Community-Newsletter ist kaum jünger [2]. Viele Programme, die auf die AGPL setzen, sind auch nicht bekannt. Die deutsche Wikipedia listet zwei: Cmsimple, ein Contentmanagement-System, und Civi CRM, ein Customer-Relationship-Management-Plugin für Joomla! & Co.

Die Gründe für die Zurückhaltung liegen auf der Hand: Wer freie Software verteilen will, bietet ohnehin die Quellen zum Download an – der User soll das Programm auf seiner eigenen Hardware laufen lassen und nicht die Ressourcen des Anbieters belasten. Aber wer mit dem SaaS-Dienst Geld verdienen will, hat vielleicht gar kein Interesse AGPL-Software zu benutzen, weil er damit den Konkurrenten sein Know-how öffnet.

Es gibt aber auch Gründe, die für den Einsatz von AGPL-Software sprechen: Zum einen kann es erwünscht sein, die selbst entwickelte Anwendung auf Daten operieren zu lassen, die fremde Benutzer übers Netz eingeben, weil sich deren Daten auf diese Weise sammeln und auswerten lassen. Das ist nicht nur für unredliche E-Mail-Adressen-Sammler oder wissenshungrige Marketingstrategen praktisch, sondern auch für die Weiterentwicklung des Supports und des eigenen Produkt- oder Dienstleistungssortiments.

Und außerdem ist es in der Zeit des Trustworthy Computing, in der sich niemand sicher sein kann, was mit den eigenen Daten passiert, ein Qualitätskriterium: Allein die Möglichkeit, anhand des Quellcode nachzuprüfen, ob Nutzerdaten integer verarbeitet werden, erhöht den Wert des Programms und bei SaaS den Wert der Dienstleistung.

Alte Programme und neue Nutzungsarten

Einige Juristen behaupten, alte GPL-Software sei nicht für den Einsatz im Rahmen einer SaaS-Anwendung lizenziert, weil es sich bei SaaS um eine Nutzungsart handelte, die vor 1990 nicht bekannt gewesen sei. Das Urheberrecht verbietet nämlich die pauschale Vorab-Einräumung von Nutzungsrechten für aktuell unbekannte Nutzungsarten [3]. Mit dieser Norm wollte der Gesetzgeber verhindern, dass Buchverlage später ohne weitere Vergütung an ihre Autoren deren Texte per Internet oder auf CD vermarkten, weil das noch nicht absehbar war, als der Verlagsvertrag unterschrieben wurde.

Diese Meinung ist zwar verbreitet, aber nicht haltbar. Denn nur jenen, die noch nie einen Akustikkoppler in Händen hielten und meinen, vernetzte Rechner gäbe es erst seit Beginn des World Wide Web, ist weiszumachen, dass ASP etwas Neues ist. Tatsächlich war die Terminalsitzung der klassische Vorläufer und selbst der Fernzugriff per Einwahlverbindung war bekannt, noch bevor in den 80ern der PC erschwinglich wurde. Das Prinzip mag nicht so vermarktet worden sein wie beim “Web 2.0”, doch bekannt war es allemal.

Zum Vergleich: Ein textbasierter E-Mail-Client müsste demnach auch als unbekannte Anwendung gelten, auch wenn Elm & Co. schon alte Kameraden sind. Dementsprechend ist auch der Einsatz älterer GPL-Programme im Rahmen eines ASP durch die Lizenz gedeckt.

FSF bewahrt Status quo

Während die FSF dieses Schlupfloch zunächst in der GPLv3 stopfen wollte, hat sie sich doch für den Status quo entschieden. Die FSF war dabei hin-und hergerissen zwischen politischer Einflussnahme auf die Entwicklung der Rechtsfrage “Geistiges Eigentum” und der Aufrechterhaltung der Freiheiten, die die GPLv2 garantiert und die sie zur dominierenden Lizenz für freie Software gemacht haben. Der in der GPLv3 benutzte Begriff “Convey”, der Verteilung, Weitergabe und Verbreitung im Sinne jeder Form der Übertragung umfasst, nimmt ausdrücklich die bloße Benutzung/Bedienung über das Netz aus.

Die Interaktion eines Programms mit einem Benutzer über ein Netz ohne Übertragung einer Programmkopie – auch nicht in binärer Form – ist nach Ziffer 0 der GPLv3 (Definitionen) keine solche Übertragung. Hierfür sorgt wiederum die AGPLv3, die derzeit noch erarbeitet wird [4]. Unter Ziffer 13 dieses Entwurfs findet sich eine Bestimmung die im Wesentlichen der Ziffer 2 d) in der aktuellen AGPL entspricht.

Hintertürchen offen

Solange nicht mehr Programme auf die AGPL setzen, insbesondere solche, die ASP-Anbieter effektiv einsetzen können und müssen um Geld zu sparen, reichen die bestehenden GPL-Programme völlig aus, um eigene SaaS-Angebote daraus zu stricken. Die FSF scheint das heiße Thema nur mit der Kohlenzange angehen zu wollen. Zu groß scheint die Gefahr, durch eine in der Open-Source-Gemeinschaft unübliche Veröffentlichungspflicht – denn nichts anderes ist ein solcher Quellenzugriff bei ASP – an Akzeptanz und Verbreitung und damit an Einflussnahme zu verlieren.

Dazu kommt noch das Problem der Kontrolle: Während selbst bei Embedded-Systemen noch durch Reverse-Engineering Rückschlüsse auf den Code möglich sind, scheint dies bei Webanwendungen schon allein wegen eines zwischengeschalteten Webservers deutlich schwieriger. Schwierig zu lösen ist auch, wie weit sich die Interaktion mit dem Benutzer erstreckt: Reagiert ein intelligenter Filter auf E-Mails, die ein Kunde – womöglich aus einem Webformular heraus – an ein Unternehmen schickt, ist das schon genug Interaktion, um eine Quellenöffnungspflicht zu begründen. Oder bezieht sich die Interaktion ausschließlich auf das Programm, das der Benutzer gerade steuert? Was ist, wenn es sich dabei nur um einen schlichten Eingaben-Sammler und -Weiterleiter handelt?

Abbildung 2: Wer Software übers Web anbietet, braucht auch bei GPL-Programmen keine Quellen zu liefern.

Unangetastetes Prinzip

Wer Webanwendungen entwickeln will, ob für Intranet oder SaaS, ist mit GPL-Software gut bedient. Zu den ursprünglichen Freiheiten, die die GPL schützen wollte, gehört auch die Freiheit, selbst entwickelten Code für sich zu behalten. Dieses Prinzip ist noch unangetastet.

Selbst wenn eines Tages die AGPL im Bereich der Webanwendungen die GPL verdrängt: Wer Code partout nicht veröffentlichen will, leitet die Daten aus der AGPL-Webanwendung in ein separates GPL-Programm und zurück. Was die so verborgene zweite Programmebene mit den Daten anstellt, bleibt unsichtbar. Das mag die Performance drosseln, hebelt aber die Veröffentlichungspflicht aus, zumindest solange diese sich durch die AGPL nicht auf “jegliche freie Software, die der Benutzer auf irgendeinem System dieser Welt laufen lässt”, erstreckt.

Freiheit oder Freiheit?

Auch weiterhin werden findige Unternehmer freie Software nutzen, anpassen und damit Dienstleistungen anbieten, ohne der Gemeinschaft etwas zurückzugeben. Das mag ethisch fragwürdig sein, ist aber durch die GPL erlaubt. Wenn die FSF daran rütteln will, muss sie sich entscheiden: Freiheit wie bisher oder freier Quellenzugang für alle. (uba)