Auf der Suche nach dem Neuen im Alten
Artikel drucken

Webanwendungen und GPL

Es wurde schon viel geredet vom Trend zu immer mehr Webanwendungen, langsam – mit zunehmenden Breitbandanschlüssen – zeigt sich aber, dass etwas draus werden könnte. Ich möchte eine selten thematisierte Folge dieses Trends thematisieren: Die GPL wird ausgehebelt.

Der Sinn der GPL liegt darin, dass Software, die einmal frei war auch weiterhin frei bleibt, dass unterscheidet sie und andere copyleft-Lizenzen von anderer Freier Software. Die Regel ist ganz einfach: Die GPL erlaubt ausdrücklich das Modifizieren der Software, unter der Bedingung, dass bei einem Vertrieb der Sourcecode der modifizierten Software mit weitergegeben werden muss, so dass auch andere von den Modifikationen profitieren können.

Im Fall einer Anwendung, die blos übers Web im Browser abgewandelt wird, funktioniert das leider nicht mehr, weil gar kein Vertrieb mehr stattfindet. Ich kann also eine Serversoftware, die unter GPL steht verändern und auch im Zweifel Millionen von Leuten sie übers Web benutzen lassen, ohne den veränderten Sourcecode freigeben zu müssen. Je mehr nun aber Webanwendungen zunehmen umso drängender wird dieses Problem der GPL.

Zur Zeit wird in einem umfassenden Communityprozeß (selber eine Webanwendung) eine neue Version der GPL erarbeitet. Leider bietet auch diese neue Version keinen Schutz vor einem solchen Mißbrauch, es ist auch fraglich ob sich dass rechtlich überhaupt machen lässt. Was also tun?

Kategorien: Feindbeobachtung, Freie Software

Tags: ,

4. März 2007, 18:42 Uhr   17 Kommentare

1 Christian (04.03.2007, 22:41 Uhr)

Doch doch, die GPL 3 bietet da durchaus einen Ausweg, sie erlaubt der Software-Autor/in nämlich, eine Klausel hinzuzufügen, dass bei serverseitiger Anwendung den Nutzer/innen des Dienstes der Zugriff auf den Sourcecode ermöglicht werden muss:

Additional requirements are terms that further constrain use, modification or propagation of covered works. […] Only these kinds of additional requirements are allowed by this License: […]
4) terms that require, if a modified version of the material they cover is a work intended to interact with users through a computer network, that those users be able to obtain copies of the Corresponding Source of the work through the same network session […]

(Paragraph 7.b des aktuellen Entwurfs)

Die FSF überlässt also der Autor/in die Entscheidung darüber, ob solche serverseitige Verwendung weiterhin als privat gilt (keine Veröffentlichung des modifizierten Sourcecodes nötig) oder ob eine Offenlegung stattfinden muss. IMHO ein weiser Standpunkt.

Als Autor eines GPL’ten Spamfilteransatzes, der nun von einem der größten deutschen Webhoster genutzt wird, um serverseitig 15 Millionen Mails pro Tag zu filtern, ohne dass sie deswegen ihren eigenen Code offenlegen oder mich um Erlaubnis fragen müssten, finde ich die künftige GPL mit dieser Klausel jedenfalls eine gute Sache 😉

2 StefanMz (05.03.2007, 09:14 Uhr)

Ist das Problem nicht eher, dass es (noch) keine entsprechenden Freien Webanwendungen gibt, die mit den Hype-Anwendungen mithalten könnten? Alle (Freie) Welt schaut auf den Desktop und wartet dort auf den Durchbruch von GNU/Linux. Derweil werden wir bei den Web-Apps abgehängt.

Nimm nur den Google-Reader. Das ist an sich nicht wirklich keine komplizierte App, vielleicht aufwändig, weil da viel Ajax drin steckt. — Wo bleibt der Freie Web-Reader?

3 benni (05.03.2007, 10:33 Uhr)

@Christian: Ah super, dass wusste ich noch nicht. Danke für die Korrektur. Das freut mich ja sehr (auch als Autor eines GPL-Browserspiels). 🙂

@Stefan: Das Problem mit den Webapplikationen ist wohl auch, dass man da ja nicht unerhebliche Server- und Traffickapazitäten braucht. Es handelt sich halt auch um eine Re-Zentralisierung von Produktionsmitteln (und ist damit eine echte Bedrohung?) . Zu beheben wäre dass erst wieder mit sowas wie freien Rechen- und Trafficgrids, gibts natürlich auch noch nicht (oder?)…

4 StefanMz (05.03.2007, 11:33 Uhr)

@Benni: Re-Zentralisierung ist eine Gefahr, ja. Sie entsteht aber genau dadurch, dass die Web-Apps nicht Frei sind und es viel einfacher ist, zu Google zu gehen und den kostenlosen Dienst zu verwenden. Gäbe es z.B. einen Freien Webreader, dann könnten die Communities jeweils für sich einen Dienst aufsetzen, und dann wäre auch die PM-Seite nicht so ein Problem.

5 benni (05.03.2007, 11:59 Uhr)

@Stefan: Dann lass uns mal einen freien Webfeed(b)reader schreiben, damit wäre auch das Privacyproblem bei Google gleich mitgelöst 😉 es scheint zumindestens noch kein solches Projekt zu existieren (hab eben mal ein bisschen bei sourceforge und google geguckt), was wirklich verwundert angesichts der ja nicht gerade völlig ausufernden Komplexität der Aufgabe. „Feedbreader“ fänd ich übrigens nen netten Namen, war eben nur ein Verschreiber, aber das trifft es ja genau!

6 StefanMz (05.03.2007, 12:33 Uhr)

@Benni: Kein laufendes Projekt? Das kann ich mir irgendwie nicht vorstellen… Aber vielleicht denken das ja alle. — Also, meist du das echt ernst?

Ich habe noch einen Namen: We-Breader, the free webreader:-)

7 benni (05.03.2007, 13:14 Uhr)

@Stefan: So halb ernst… ich hab momentan ein bisschen Luft aber es ist noch unklar wie es demnächst aussehen wird. Zur Zeit bin ich recht euphorisiert bei dem Thema, aber ich kann nicht versprechen, dass das anhält.

Muß es eigentlich wirklich ein Web-Reader sein? Wichtig ist doch nur die Publishing-Funktionalität. Diese Webapplikationen sind halt immer so schnarchlangsam, wenn man nur so Uraltrechner hat, wie ich. So wie ich es sehe, gibt es drei wichtige Funktionen, die der Googlereader bietet und andere nur eingeschränkt oder schlecht:

  • Es ist ein wirklich ziemlich gut umgesetzter Webreader, dass heisst man hat den Vorteil auch an fremden Rechnern ganz normal feeden zu können.
  • Er cached alle feeds für alle Subscribenten, dadurch hat man auf die einzelnen Feeds ziemlich schnellen Zugriff (abhängig von der Serverleistung), da liegt ein Problem für ein Freies Projekt.
  • Er erlaubt das republishen und mischen von Feeds ohne dass man selber Server bräuchte. Das macht er auch zentral, das müsste ein freies Projekt dezentralisieren, dann bräuchte man aber natürlich wieder eigene Server.

Dem Gegenüber stehen vier Nachteile:

  • Langsam, weil Ajax.
  • Die Google-Privacy-krake hält viele von der Benutzung ab. Ich hab jetzt schon zwei Leute aus meinem Umfeld, die sich das nicht geben wollen. Verständlich.
  • Es ist immer noch nicht das full-flavoured-Vorurteilssystem, dass ich mir wünsche und natürlich …
  • Es ist keine Freie Software

Wenn wir einen Weg finden die Nachteile zu beseitigen (ok, der letzte Punkt ist simpel 😉 ) ohne die Vorteile zu verlieren würde meine Euphorie noch etwas steigen…

8 StefanMz (05.03.2007, 14:32 Uhr)

@Benni: Das nette an dem Reader ist die Nähe von zwei verschiedenen Tätigkeiten: Einträge durchsehen und ggf. taggen.

An sich sind aber Mix und Republish sind die entscheidenden Features. Also eher sowas wie Yahoo-Pipes: einmal definiert und läuft.

Vielleicht kann man das auch trennen: Ein Mix&Publish-Dienst allein auf der Basis von RSS/Atom. Und Tagging via del.icio.us oder Firefox-XY-Plugin oder in der lokalen App – je nach dem, was entwickelt wurde. Wenn man das als Dienst auslegt, der über XML-RPC oder JSON ansprechbar ist, dann wäre das nur ein Mashup-Baustein, der sogar komplett extern steuerbar wäre (Caching dann auf der Klientenseite). Sowas würde ich dann z.B. gerne in opentheory2.0 nutzen (argh, das liegt auch schon wieder ewig rum….)

Ich würde das gerne mal IRL diskutieren mit den Interessierten (Thomas?).

9 benni (05.03.2007, 16:18 Uhr)

@Stefan: IRL-Treffen: Vielleicht schaffe ich es nach Hiddinghausen, kanns aber noch nicht versprechen. Oder vielleicht in der Woche vorher nach Berlin, aber dass ist eher noch unsicherer. Ansonsten: Ab Donnerstag bin ich für 4 Tage in Hannover, dass ist doch von Dir nur ’nen Katzensprung 😉

10 StefanMz (05.03.2007, 18:45 Uhr)

@Benni: Ein Treffen in Hiddinghausen wäre prima. Ich wollte sowieso die Gelegenheit nutzen und eine „Session“ zu sozialen Werkzeugen anbieten. — Vielleicht steigen wr ab diesem Punkt aber besser auf die Mailingliste um.

11 ibu (05.03.2007, 21:44 Uhr)

Wäre mal spannend zu erfahren, wie diejenigen, die die Freie Software reflektieren, dich selber reflektieren, wenn sie an der Bewegung teilnehmen. Besonders hinsichtlich der These, dass die Bewegung meist nur das nachahmt, was die proprietäre Szene vormacht, und nichts wirklich Neues hervorbringt. 😉

12 benni (05.03.2007, 23:57 Uhr)

@Ibu: Du meinst sicher „sich“ selber reflektieren, oder?

War das kritisch gemeint, dass wir nicht einfach nur den Googlereader nachbauen sollen? Ich hab ja geschrieben, wo ich den schlecht finde und in meinem Beitrag unten zu Vorurteilssystemen steht ja auch dass die Idee ursprünglich aus einer Szene stammt, die als „proprietär“ zu bezeichnen eher gewagt ist 😉

Was die Reflektion angeht: Meine Beteiligung an der „Szene“ war immer eher eingeschränkt. Ich hab mal ein paar patches beigesteuert und ansonsten ein,zwei eigene Spielprojekte gemacht, wo ausser meinem direkten Freundeskreis niemand beteiligt war. Ich bin also sicherlich nicht repräsentativ.

So, jetzt sind wir aber endgültig vom Thema dieses Beitrags abgekommen, dass wäre vielleicht mal einen eigenen wert. In die Richtung ging ja schon letztens dieser Artikel.

13 Mischka (06.03.2007, 20:58 Uhr)

Wo ist das Problem? Wie ich es verstanden hab, muss der Sourcecode ja nicht dem Produkt beiliegen (also z.B. beim Lan-Router auf CD-Rom oder so), er muss nur zur Verfügung gestellt werden. D.h. wenn ich einen Sourcecode einer Webanwendung will, die auf einer GPL-Anwendung aufbaut, schreibe ich an den Betreiber der Webanwendung und er hat sie mir auszuhändigen. Oder habe ich das falsch verstanden?

14 StefanMz (06.03.2007, 21:59 Uhr)

@Mischka: Das Problem ist, dass die großen Webanwendungen von Google & Co nicht von GPL-Anwendungen abgeleitet sind („aufbauen“ z.B. im Sinne von „auf Linux laufen“ reicht nicht), also proprietär sind. — Kannst ja trotzdem mal versuchen, den Code von einer Google-App anzufordern:-)

15 Christian (06.03.2007, 22:10 Uhr)

@Stefan: Nein, dann gäb’s ja kein Problem — dass sich die Autor/innen neuer Software ihre Lizenz (if any) selbst aussuchen dürfen, darüber sind wir uns ja vermutlich einig 😉 Das Problem bei Webanwendungen ist vielmehr, dass die Konditionen der GPL — Recht auf Zugang zum Sourcecode — nur dann triggern, wenn ich die Software selbst (Binärcode) bereits habe. Das ist aber bei Webanwendungen nicht der Fall, denn dort läuft die Software ja auf dem Server — da ich als Nutzer der Software den Binärcode nicht habe, habe ich aber auch kein Recht auf Zugang zum Sourcecode, und die Konditionen der GPL sind ausgehebelt. Google o.a. können GPL-te Software nehmen, ihren Bedürfnissen anpassen (oder auch nicht) und Millionen von Nutzern damit beglücken — aber keiner dieser Nutzer hat ein Recht, an den Sourcecode rankommen (und der Originalautor ebensowenig), obwohl die Software unter GPL steht!

Aber die GPL v3 bietet, wie oben geschrieben, glücklicherweise einen Hebel, um das zu ändern 🙂 — dann, aber erst dann, könnte man es so machen wie Mischka beschreibt.

16 StefanMz (07.03.2007, 16:02 Uhr)

@Christian: Ich verstehe deinen Widerspruch nicht:

Nein, dann gäb’s ja kein Problem…

Anyway. Du hast recht, wenn GPL-V2 für die Serversoftware genommen würde, dann gäbe es das zusätzliche Problem, dass der Server-Code im engeren Sinne gar nicht verteilt wird, so dass die GPL nicht griffe. Ein großer Teil der Web-2.0 Anwendungen besteht jedoch aus Javascript, ist also „eigentlich“ verfügbar. Und da griffe die GPL-Vx sehr wohl. Aber das ist alles graue Theorie — praktisch steht wohl keine der „großen“ Web-2.0-Anwendungen unter einer Freien Lizenz, jedenfalls so weit ich weiß. Für gegenteilige Hinweise bin ich dankbar.

17 benni (10.07.2007, 20:17 Uhr)

Korrektur: Leider ist der oben von Christian genannte Passus jetzt doch nicht in der GPLv3 gelandet, statt dessen gibt es für diesen Fall eine eigene Lizenz.

und nochmal verspätet @Stefan: Mediawiki würde ich schon als eine „große“ Web-2.0-Anwendung beschreiben 😉

Schreibe einen Kommentar