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.