Hallo zusammen,
aktuell entwickle ich mein Script [1] unter der GNU GPL Version 2, dies ist in einer "Serversprache" geschrieben, das Script laeuft also zum groessten Teil als PHP-Script auf dem Server, es gibt aber auch JavaScript-Teile [2].
Diverse Verzeichnisse, wo es keinen Sinn macht, diese unter GNU GPL zu stellen (z.B. 'templates', diese sollten nicht runterladbar sein), habe ich bereits per Ausschlussklausel aus der GNU-Lizenz rausgenommen [3].
Nun bleiben aber noch ein paar Dinge uebrig:
1.) Ich habe gelesen, dass die GNU Affero GPL fuer "Webanwendungen" optimaler ist, ist dies auch so? Die Infos [4] habe ich bereits gelesen. Ich wollte eigentlich nicht jeden Webmaster zwingen, alle Scripte downloafaehig zu machen, da dies z.B. gerade bei sicherheitsrelevanten Dingen ein enormes Risiko darstellt (z.B. wird der Datenbankzugang in einer "config-Datei" gespeichert).
2.) Ein Teil des Scriptes (GNU GPL 2) - dies ist gerade fuer so genannte Paidmailer von hohem Interesse - bindet sich an externe APIs an, die auf einem fremden Server laufen und zu 99,9999% non-free sind (z.B. kommt das Script von nickeyMEDIA sehr oft vor). Dennoch soll (und bleibt auch) die Anbindung an die APIs in meinem Script drinne.
3.) Es gibt bei meinem Script die Moeglichkeit, nach Updates zu suchen. Es werden dann von einem Script Daten abgefragt, das auf meinem Script installiert ist und aktuell nicht releast ist (soll nur vielleicht erfolgen).
Und schnelle, fachkundige Antworten waere ich sehr dankbar, da ich mir das Wort "GNU-Projekt" auf die Fahne geschrieben habe und dies auch gerne einhalten moechte.
Mit freundlichen Gruessen, Roland Haeder
[1]: http://mxchange.org/repos/mailer/branches/0.2.1-FINAL/ [2]: http://mxchange.org/repos/mailer/branches/0.2.1-FINAL/js/ [3]: http://mxchange.org/repos/mailer/branches/0.2.1-FINAL/DOCS/README [4]: http://www.gnu.org/licenses/why-affero-gpl.html
Hallo,
On Monday 19 September 2011 18:34:13 Roland Häder wrote:
aktuell entwickle ich mein Script [1] unter der GNU GPL Version 2, dies ist in einer "Serversprache" geschrieben, das Script laeuft also zum groessten Teil als PHP-Script auf dem Server, es gibt aber auch JavaScript-Teile [2].
Diverse Verzeichnisse, wo es keinen Sinn macht, diese unter GNU GPL zu stellen (z.B. 'templates', diese sollten nicht runterladbar sein), habe ich bereits per Ausschlussklausel aus der GNU-Lizenz rausgenommen [3].
Du lizensierst keine Verzeichnisse, sondern Dateien. Idealerweise hat jede Datei im Header einen Vermerk zum Urheberrechtsinhaber und zur verwendeten Lizenz.
Ist der Grund, dass du templates nicht unter die GPL stellst, dass sie nicht "runterladbar" sein sollen? Was meinst du mit runterladbar, in welchem Kontext?
1.) Ich habe gelesen, dass die GNU Affero GPL fuer "Webanwendungen" optimaler ist, ist dies auch so? Die Infos [4] habe ich bereits gelesen. Ich wollte eigentlich nicht jeden Webmaster zwingen, alle Scripte downloafaehig zu machen, da dies z.B. gerade bei sicherheitsrelevanten Dingen ein enormes Risiko darstellt (z.B. wird der Datenbankzugang in einer "config-Datei" gespeichert).
Es geht nicht darum, dass man die tatsaechlich ausgefuehrten Scripte zum Download anbietet, sondern die Quelltexte des Programmes unter der AGPL. Das kann auch eine Kopie ohne Passwoerter in einem Archive sein.
Wenn du trotzdem noch ein Sicherheitsrisiko siehst, solltest du dein Programm vielleicht besser nicht auf einem oeffentlichen Webserver betreiben.
Die AGPL ist deshalb für Webanwendungen sinnvoll, weil niemand kommen kann, der dein Programm substantiell erweitert und es selbst einsetzt, aber niemandem den Quellcode gibt. Er konnte dann auf deiner Arbeit aufbauen, gibt dir und seinen Nutzerinnen aber nichts zurueck. Du musst dich fragen, ob du das willst.
2.) Ein Teil des Scriptes (GNU GPL 2) - dies ist gerade fuer so genannte Paidmailer von hohem Interesse - bindet sich an externe APIs an, die auf einem fremden Server laufen und zu 99,9999% non-free sind (z.B. kommt das Script von nickeyMEDIA sehr oft vor). Dennoch soll (und bleibt auch) die Anbindung an die APIs in meinem Script drinne.
Eine API ist in der Regel weder frei noch unfrei. Das ist ja nur eine Schnittstelle, hinter der sich Funktionalitaet verbirgt. Die will/soll niemand aendern.
Was ist hier genau deine Frage?
3.) Es gibt bei meinem Script die Moeglichkeit, nach Updates zu suchen. Es werden dann von einem Script Daten abgefragt, das auf meinem Script installiert ist und aktuell nicht releast ist (soll nur vielleicht erfolgen).
Was ist hier deine Frage?
Und schnelle, fachkundige Antworten waere ich sehr dankbar, da ich mir das Wort "GNU-Projekt" auf die Fahne geschrieben habe und dies auch gerne einhalten moechte.
Was meinst du damit, dass du dir das Wort "GNU-Projekt" auf die Fahne geschrieben hast?
MfG, Torsten
Hallo Torsten,
On Mon, 2011-09-19 at 21:57 +0200, Torsten Grote wrote:
Hallo,
Du lizensierst keine Verzeichnisse, sondern Dateien. Idealerweise hat jede Datei im Header einen Vermerk zum Urheberrechtsinhaber und zur verwendeten Lizenz.
Damit meinte ich, dass dann (hoffentlich doch?) alle Dateien im Verzeichnis 'templates' (die anderen auch) aus der GNU GPL rausgetrennt sind. Natuerlich sollen sie runterlbar (von meinem Server/Repository) sein. Wenn aber z.B. Person A seine Templates anpasst, oder die CSS-Dateien anpasst, dann moechte ich, dass er nicht zur Offenlegung gezwungen ist.
Ist der Grund, dass du templates nicht unter die GPL stellst, dass sie nicht "runterladbar" sein sollen? Was meinst du mit runterladbar, in welchem Kontext?
Damit meinte ich, dass der Quellcode nicht von Person A's Server herunterladbar sein soll (was die GNU GPL sonst doch vorschreiben wuerde?).
Es geht nicht darum, dass man die tatsaechlich ausgefuehrten Scripte zum Download anbietet, sondern die Quelltexte des Programmes unter der AGPL. Das kann auch eine Kopie ohne Passwoerter in einem Archive sein.
Okay, das verstehe ich nun besser.
Wenn du trotzdem noch ein Sicherheitsrisiko siehst, solltest du dein Programm vielleicht besser nicht auf einem oeffentlichen Webserver betreiben.
Nein, alle sicherheitsrelevanten Dinge (wie "privaten Schluessel" usw.) werden auf dem Server von Person A erzeugt und sind per "svn:ignore" nie in der Repository eingecheckt, inklusive Template-Cache natuerlich... ;-)
Die AGPL ist deshalb für Webanwendungen sinnvoll, weil niemand kommen kann, der dein Programm substantiell erweitert und es selbst einsetzt, aber niemandem den Quellcode gibt. Er konnte dann auf deiner Arbeit aufbauen, gibt dir und seinen Nutzerinnen aber nichts zurueck. Du musst dich fragen, ob du das willst.
Achso, bei der GNU GPL (ohne Affero) duerfte man seine Aenderungen behalten, wenn sie nicht rausgegeben werden. Bei der Affero muessen diese zurueckgegeben werden. Hmmm, das laesst sich nicht so einfach entscheiden.
Eine API ist in der Regel weder frei noch unfrei. Das ist ja nur eine Schnittstelle, hinter der sich Funktionalitaet verbirgt. Die will/soll niemand aendern.
Ich meine auch nicht die API ansich (die eh' per "Interface-Kennwort" gesichert ist), sondern das darunterliegende Script/Programm.
Was ist hier genau deine Frage?
Ist es mit der GNU Affero GPL vereinbar, dass ein freies Script per HTTP-Anfrage (GET/POST) auf eine API zugreift, die ihrerselbst ein prorpritaeres Script ist? Und wie sieht das bei der GPL aus?
3.) Es gibt bei meinem Script die Moeglichkeit, nach Updates zu suchen. Es werden dann von einem Script Daten abgefragt, das auf meinem Script installiert ist und aktuell nicht releast ist (soll nur vielleicht erfolgen).
Was ist hier deine Frage?
Prinzipiell s.o., da (in diesem Fall) mein Script non-free derzeit ist. Ich habe aber kaum Probleme damit, es auch offen zu legen, um mal "reinschauen zu lassen".
Was meinst du damit, dass du dir das Wort "GNU-Projekt" auf die Fahne geschrieben hast?
Dass mein Projekt halt GNU ist, also offen ist (bis auf sicherheitsrelevante Dinge, klar). Ich dokumentiere bereits auch derzeit sehr viel an meinem Script. Es sollte nicht so radikal klingen. :)
MfG, Roland
Roland Häder schrieb:
Achso, bei der GNU GPL (ohne Affero) duerfte man seine Aenderungen behalten, wenn sie nicht rausgegeben werden. Bei der Affero muessen diese zurueckgegeben werden. Hmmm, das laesst sich nicht so einfach entscheiden.
Bei Freier Software geht es um die Rechte der Anwender. Die Frage ist, wen man als Anwender sieht.
Klassischerweise ist der Anwender derjenige, auf dessen Rechner die Software läuft. Das ist die Idee, die der GPL zugrunde liegt.
Bei Web-Anwendungen bedeutet dies aber, dass nur der Serverbetreiber als "Anwender" betrachtet wird, und entsprechende Rechte zugesprochen kriegt. Aber die eigentlichen Anwender, die das Ding über den Browser bedienen, erhalten durch die GPL keine Rechte. [1]
Das heißt, die Grundidee der GPL wird bei Web-Anwendungen ausgehölt. Die AGPL schließt diese Lücke.
Daher würde ich bei Web-Anwendungen _immer_ zur AGPL statt GPL raten.
Vielleicht sollte man sogar _alle_ GPL-Software lieber unter AGPL stellen, wenn das nicht so unpraktisch wäre. Denn dann würde man von jedem Server-Betreiber verlangen, dass er den Quellcode von sämtlichen Diensten zum Download anbietet, die auf dem Server laufen. Mailserver, Webserver, Python/Ruby/PHP-Interpreter, womöglich bis hin zum Kernel (jenachdem wie man es auslegt). Daher ist für die meiste Software immer noch die GPL besser. Aber bei allem, was primär über das Netzwerk bedient wird, sei es ein MUD via Telnet oder eine Web-Applikation via Browser, all das sollte meiner Ansicht nach lieber AGPL statt GPL sein.
Was meinst du damit, dass du dir das Wort "GNU-Projekt" auf die Fahne geschrieben hast?
Dass mein Projekt halt GNU ist, also offen ist (bis auf sicherheitsrelevante Dinge, klar). Ich dokumentiere bereits auch derzeit sehr viel an meinem Script. Es sollte nicht so radikal klingen. :)
Du möchtest also, dass dein Projekt Freie Software ist.
Mit dem GNU-Projekt hat das erstmal nichts zu tun. Wenn Du wirklich möchtest, dass dein Projekt offiziell Teil des GNU-Projektes wird, dann hast du einiges mehr zu tun als es unter eine Freie Lizenz zu stellen. ;-)
Gruß Volker
[1] Außer bei JavaScript-Code, weil der clientseitig im Browser des Anwenders läuft. Aber das ist nochmal ein Thema für sich...
Hallo Volker,
On Mon, 2011-09-19 at 22:57 +0200, Volker Grabsch wrote:
Bei Freier Software geht es um die Rechte der Anwender. Die Frage ist, wen man als Anwender sieht.
Klassischerweise ist der Anwender derjenige, auf dessen Rechner die Software läuft. Das ist die Idee, die der GPL zugrunde liegt.
Bei Web-Anwendungen bedeutet dies aber, dass nur der Serverbetreiber als "Anwender" betrachtet wird, und entsprechende Rechte zugesprochen kriegt. Aber die eigentlichen Anwender, die das Ding über den Browser bedienen, erhalten durch die GPL keine Rechte. [1]
Das heißt, die Grundidee der GPL wird bei Web-Anwendungen ausgehölt. Die AGPL schließt diese Lücke.
Okay. Das verstehe ich nun. Danke dir fuer die Ausfuehrungen.
Daher würde ich bei Web-Anwendungen _immer_ zur AGPL statt GPL raten.
Dann sollte ich das mal in's .... Entwicklerteam geben. Ich glaube, aber dass die Aenderungen anderer Autoren [2] mittlerweile irrelevant sind, da die beigesteuerten Scripte nicht mehr in der Form im Quellcode sind - ich habe sie schon zu Hauf ueberarbeitet.
Vielleicht sollte man sogar _alle_ GPL-Software lieber unter AGPL stellen, wenn das nicht so unpraktisch wäre. Denn dann würde man von jedem Server-Betreiber verlangen, dass er den Quellcode von sämtlichen Diensten zum Download anbietet, die auf dem Server laufen. Mailserver, Webserver, Python/Ruby/PHP-Interpreter, womöglich bis hin zum Kernel (jenachdem wie man es auslegt). Daher ist für die meiste Software immer noch die GPL besser. Aber bei allem, was primär über das Netzwerk bedient wird, sei es ein MUD via Telnet oder eine Web-Applikation via Browser, all das sollte meiner Ansicht nach lieber AGPL statt GPL sein.
Lieber nicht. Nicht jeder hat "Unlimited" Traffic im Monat frei, der AGPL-lizensierte (Web-)Programme/Scripte einsetzt. ;-) Denn das kann schnell in die Gigabytes gehen, wenn ueberall der Kernel-Tar-Batzen runterladbar ist...
Du möchtest also, dass dein Projekt Freie Software ist.
Jo.
Mit dem GNU-Projekt hat das erstmal nichts zu tun. Wenn Du wirklich möchtest, dass dein Projekt offiziell Teil des GNU-Projektes wird, dann hast du einiges mehr zu tun als es unter eine Freie Lizenz zu stellen. ;-)
So war das auch nicht gemeint. Mein Projekt soll einfach gesagt offen und frei werden, also nicht nur einfach freie Software zum Download, sondern noch mehr (Dokumentation ist aktuell in der Mache [3]).
[1] Außer bei JavaScript-Code, weil der clientseitig im Browser des Anwenders läuft. Aber das ist nochmal ein Thema für sich...
Sehe ich auch so.
VG, Roland
[2]: http://mxchange.org/repos/mailer/branches/0.2.1-FINAL/DOCS/de/AUTHORS.txt
On Mon, Sep 19, 2011 at 10:57:44PM +0200, Volker Grabsch wrote:
Vielleicht sollte man sogar _alle_ GPL-Software lieber unter AGPL stellen, wenn das nicht so unpraktisch wäre. Denn dann würde man von jedem Server-Betreiber verlangen, dass er den Quellcode von sämtlichen Diensten zum Download anbietet, die auf dem Server laufen.
Ich überlege auch gerade, ob die Zeit nicht gekommen ist, alle Software auf die AGPL umzustellen. Allerdings mit einem anderen Hintergrund: Mein Projekt AKFAvatar basiert zur Zeit auf der SDL. Ein Bekannter fragte dann mal, ob das auch über's Web abrufbar sei. Zunächst hielt ich den Gedanken für ziemlich absurd. Es ist in C geschrieben und hat eine grafische Ausgabe...
Aber dann hörte ich von emscripten[1], das LLVM-Code und somit auch C-Code nach JavaScript konvertieren kann. Später hörte ich, dass Google LLVM direkt in den Browser Chrome integriert als "Native Client"[2]. Zu guter letzt habe ich gelesen, dass GTK+ jetzt auch ein HTML5-Backend hat[3] (also das Programm läuft wohl auf dem Server).
Damit verschwimmen jetzt doch die Rubriken Desktop und Web jetzt völlig. Oder wie seht ihr das?
[1] https://github.com/kripken/emscripten/wiki [2] http://code.google.com/intl/de/chrome/nativeclient/ [3] http://www.heise.de/open/meldung/Gtk-3-2-mit-Unterstuetzung-fuer-Wayland-und...
2011/9/26 Andreas K. Foerster list@akfoerster.de:
Ich überlege auch gerade, ob die Zeit nicht gekommen ist, alle Software auf die AGPL umzustellen. Allerdings mit einem anderen Hintergrund: Mein Projekt AKFAvatar basiert zur Zeit auf der SDL. Ein Bekannter fragte dann mal, ob das auch über's Web abrufbar sei. Zunächst hielt ich den Gedanken für ziemlich absurd. Es ist in C geschrieben und hat eine grafische Ausgabe...
Aber dann hörte ich von emscripten[1], das LLVM-Code und somit auch C-Code nach JavaScript konvertieren kann. Später hörte ich, dass Google LLVM direkt in den Browser Chrome integriert als "Native Client"[2]. Zu guter letzt habe ich gelesen, dass GTK+ jetzt auch ein HTML5-Backend hat[3] (also das Programm läuft wohl auf dem Server).
Damit verschwimmen jetzt doch die Rubriken Desktop und Web jetzt völlig. Oder wie seht ihr das?
Ich habe den Eindruck, dass du glaubst, die normale GPL-Bedingungen würden nicht gelten wenn der Code (oder eine in Javascript umgewandelte Version davon) zum Webbrowser geschickt würde. Wie immer braucht man dann die Möglichkeit zu haben, den Code zu bekommen.
Das Besondere an AGPL ist, dass man den Code auch bekommen kann, wenn er nicht auf dem eigenen Rechner kopiert wird bzw. läuft. Nämlich, wenn man die Anwendung entfernt mittels einer Web- oder (seit AGPL v3?) Netzwerk-Schnittstelle benutzt.
Nicolas
On Mon, Sep 26, 2011 at 09:45:03PM +0200, Nicolas Barbier wrote:
2011/9/26 Andreas K. Foerster list@akfoerster.de:
Ich überlege auch gerade, ob die Zeit nicht gekommen ist, alle Software auf die AGPL umzustellen. Allerdings mit einem anderen Hintergrund: Mein Projekt AKFAvatar basiert zur Zeit auf der SDL. Ein Bekannter fragte dann mal, ob das auch über's Web abrufbar sei. Zunächst hielt ich den Gedanken für ziemlich absurd. Es ist in C geschrieben und hat eine grafische Ausgabe...
Aber dann hörte ich von emscripten[1], das LLVM-Code und somit auch C-Code nach JavaScript konvertieren kann. Später hörte ich, dass Google LLVM direkt in den Browser Chrome integriert als "Native Client"[2]. Zu guter letzt habe ich gelesen, dass GTK+ jetzt auch ein HTML5-Backend hat[3] (also das Programm läuft wohl auf dem Server).
Damit verschwimmen jetzt doch die Rubriken Desktop und Web jetzt völlig. Oder wie seht ihr das?
Ich habe den Eindruck, dass du glaubst, die normale GPL-Bedingungen würden nicht gelten wenn der Code (oder eine in Javascript umgewandelte Version davon) zum Webbrowser geschickt würde. Wie immer braucht man dann die Möglichkeit zu haben, den Code zu bekommen.
Das Besondere an AGPL ist, dass man den Code auch bekommen kann, wenn er nicht auf dem eigenen Rechner kopiert wird bzw. läuft. Nämlich, wenn man die Anwendung entfernt mittels einer Web- oder (seit AGPL v3?) Netzwerk-Schnittstelle benutzt.
Okay, stimmt, du hast Recht was emscripten und Native Client anbelangt. Da scheint die normale GPL zu greifen und auszureichen.
Aber GTK+-Anwendungen laufen meines Wissens nach auf dem Server - und diese Anwendungen scheinen da sogar ohne Änderungen zu funktionieren...
On Mon, Sep 26, 2011 at 09:58:35PM +0200, Andreas K. Foerster wrote:
On Mon, Sep 26, 2011 at 09:45:03PM +0200, Nicolas Barbier wrote:
2011/9/26 Andreas K. Foerster list@akfoerster.de:
Ich überlege auch gerade, ob die Zeit nicht gekommen ist, alle Software auf die AGPL umzustellen. Allerdings mit einem anderen Hintergrund: Mein Projekt AKFAvatar basiert zur Zeit auf der SDL. Ein Bekannter fragte dann mal, ob das auch über's Web abrufbar sei. Zunächst hielt ich den Gedanken für ziemlich absurd. Es ist in C geschrieben und hat eine grafische Ausgabe...
Aber dann hörte ich von emscripten[1], das LLVM-Code und somit auch C-Code nach JavaScript konvertieren kann. Später hörte ich, dass Google LLVM direkt in den Browser Chrome integriert als "Native Client"[2]. Zu guter letzt habe ich gelesen, dass GTK+ jetzt auch ein HTML5-Backend hat[3] (also das Programm läuft wohl auf dem Server).
Damit verschwimmen jetzt doch die Rubriken Desktop und Web jetzt völlig. Oder wie seht ihr das?
Ich habe den Eindruck, dass du glaubst, die normale GPL-Bedingungen würden nicht gelten wenn der Code (oder eine in Javascript umgewandelte Version davon) zum Webbrowser geschickt würde. Wie immer braucht man dann die Möglichkeit zu haben, den Code zu bekommen.
Okay, stimmt, du hast Recht was emscripten und Native Client anbelangt. Da scheint die normale GPL zu greifen und auszureichen.
Vielleicht bin ich jetzt zu früh eingecknickt. Zwar bin ich selber da deiner Meinung, dass die normale GPL da greift, ich könnte mir aber auch eine Gegenargumentation vorstellen: Das Programm geht ja nicht in den Besitz des Anwenders über, es wird nicht auf die Festplatte kopiert, sondern es wird nur flüchtig (temporär) vorgehalten...
Das Besondere an AGPL ist, dass man den Code auch bekommen kann, wenn er nicht auf dem eigenen Rechner kopiert wird bzw. läuft. Nämlich, wenn man die Anwendung entfernt mittels einer Web- oder (seit AGPL v3?) Netzwerk-Schnittstelle benutzt.
Aber GTK+-Anwendungen laufen meines Wissens nach auf dem Server - und diese Anwendungen scheinen da sogar ohne Änderungen zu funktionieren...
Mittlerweile ist mir ein weiteres Beispiel eingefallen: Man könnte eine Anwendung per VNC anbieten. Dabei wird das Programm selber auch nicht übertragen. Es funktioniert aber mit jeder Desktop-Anwendung. (Randnotiz: SDL scheint mit VNC Probleme zu haben. Weiß da jemand genaueres?)
Technisch ist das Problem sicher nichts neues. Schon mit Telnet war sowas ähnliches möglich. Neu hingegen ist, dass "Software as a Service" (SaaS) als mögliches Geschäftsmodell wahrgenommen wird.
Wie gesagt, mir geht es hier aber eher um die Abwehr eines solchen potentiellen Problemes. Die AGPL für alles zu verwenden, wäre da ein Ansatz.
2011/9/27 Andreas K. Foerster list@akfoerster.de:
On Mon, Sep 26, 2011 at 09:58:35PM +0200, Andreas K. Foerster wrote:
On Mon, Sep 26, 2011 at 09:45:03PM +0200, Nicolas Barbier wrote:
Ich habe den Eindruck, dass du glaubst, die normale GPL-Bedingungen würden nicht gelten wenn der Code (oder eine in Javascript umgewandelte Version davon) zum Webbrowser geschickt würde. Wie immer braucht man dann die Möglichkeit zu haben, den Code zu bekommen.
Okay, stimmt, du hast Recht was emscripten und Native Client anbelangt. Da scheint die normale GPL zu greifen und auszureichen.
Vielleicht bin ich jetzt zu früh eingecknickt. Zwar bin ich selber da deiner Meinung, dass die normale GPL da greift, ich könnte mir aber auch eine Gegenargumentation vorstellen: Das Programm geht ja nicht in den Besitz des Anwenders über, es wird nicht auf die Festplatte kopiert, sondern es wird nur flüchtig (temporär) vorgehalten...
Ich glaube, der Server-Betreiber habe nicht das Recht, es an den Benutzer zu schicken, ohne den Code auch anzubieten. GPLv3:
----8<---- To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
[..]
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: ---->8----
Der erste Absatz scheint mir zu sagen, dass „conveying“ das Schicken einer Kopie einschließt (ob diese nun gespeichert wird oder nicht). Der zweite Absatz sagt, dass die Bedingungen bezüglich des Bereitstellens des Source Codes eingehalten werden müssen.
(Es gibt bestimmte Ausnahmen bezüglich „make modifications exclusively for you“ und „provide you with facilities for running“ (siehe „2. Basic Permissions“), wovon ich aber glaube, dass sie hier nicht zutreffen.)
[..]
Mittlerweile ist mir ein weiteres Beispiel eingefallen: Man könnte eine Anwendung per VNC anbieten. Dabei wird das Programm selber auch nicht übertragen. Es funktioniert aber mit jeder Desktop-Anwendung. (Randnotiz: SDL scheint mit VNC Probleme zu haben. Weiß da jemand genaueres?)
Technisch ist das Problem sicher nichts neues. Schon mit Telnet war sowas ähnliches möglich. Neu hingegen ist, dass "Software as a Service" (SaaS) als mögliches Geschäftsmodell wahrgenommen wird.
Wie gesagt, mir geht es hier aber eher um die Abwehr eines solchen potentiellen Problemes. Die AGPL für alles zu verwenden, wäre da ein Ansatz.
Das könnte vielleicht funktionieren, vor allem weil seit (A)GPL v3, AGPL Anwendungen GPL Code einbinden dürfen. Es würde nicht lange dauern, bevor alle einst-GPL Software AGPL ist.
Die frage, die ich mir stelle ist: Will man eine Situation schaffen, wo man keinerlei private Änderungen an jegliche Netzwerk-Anwendungen (die nur auf dem eigenen Rechner laufen) machen darf, ohne sie den Benutzern zwangsmäßig zeigen zu müssen? Vielleicht ist da das Mittel schlimmer als die (für „normale“ Anwendungen noch ziemlich hypothetische) Qual.
Nicolas
Hallo,
On Tue, Sep 27, 2011 at 10:16:37AM +0200, Andreas K. Foerster wrote:
Mittlerweile ist mir ein weiteres Beispiel eingefallen: Man könnte eine Anwendung per VNC anbieten. Dabei wird das Programm selber auch nicht übertragen. Es funktioniert aber mit jeder Desktop-Anwendung.
Genau das ist der Grund, wieso bei GPLv3 mit der Affero-Klausel geliebäugelt wurde.
Da jedoch solche Szenarien bisher keine nennenswerte Verbreitung gefunden haben, wurde am Ende der Kompromiss gewählt, diese Klausel in Form von AGPLv3 optional zu machen. Wenn Du aber trotzdem besorgt bist wegen solcher Szenarien, ist es völlig angemessen, Deine Programme vorsorglich alle unter die AGPL zu stellen.
-antrik-
Hallo,
On Mon, Sep 19, 2011 at 10:57:44PM +0200, Volker Grabsch wrote:
Vielleicht sollte man sogar _alle_ GPL-Software lieber unter AGPL stellen, wenn das nicht so unpraktisch wäre. Denn dann würde man von jedem Server-Betreiber verlangen, dass er den Quellcode von sämtlichen Diensten zum Download anbietet, die auf dem Server laufen. Mailserver, Webserver, Python/Ruby/PHP-Interpreter, womöglich bis hin zum Kernel (jenachdem wie man es auslegt).
Eine solche Auslegung scheint mir unwahrscheinlich. Der Anwender interagiert ja nicht unmittelbar mit dem Interpreter oder dem Kernel.
(Es sei denn der Service stellt eine Remote-Konsole für den Interpreter zur Verfügung -- aber das wäre schon ein sehr spezieller Fall :-) )
(Bei Mailserver oder Webserver bin ich etwas unschlüssig...)
-antrik-
On Monday 19 September 2011 22:14:39 Roland Häder wrote:
Ist es mit der GNU Affero GPL vereinbar, dass ein freies Script per HTTP-Anfrage (GET/POST) auf eine API zugreift, die ihrerselbst ein prorpritaeres Script ist? Und wie sieht das bei der GPL aus?
Ich bin kein Anwalt, aber ich denke, das ist in beiden Faellen kein Problem.
3.) Es gibt bei meinem Script die Moeglichkeit, nach Updates zu suchen. Es werden dann von einem Script Daten abgefragt, das auf meinem Script installiert ist und aktuell nicht releast ist (soll nur vielleicht erfolgen).
Prinzipiell s.o., da (in diesem Fall) mein Script non-free derzeit ist. Ich habe aber kaum Probleme damit, es auch offen zu legen, um mal "reinschauen zu lassen".
Wenn du es unter eine freie Lizenz stellst, haben alle die vier Freiheiten, die mehr beinhalten als "nur mal reinschauen" zu duerfen.
Danke auch an Volker fuer die Beantwortung der anderen Fragen!
Torsten
Torsten Grote schrieb:
On Monday 19 September 2011 22:14:39 Roland Häder wrote:
Ist es mit der GNU Affero GPL vereinbar, dass ein freies Script per HTTP-Anfrage (GET/POST) auf eine API zugreift, die ihrerselbst ein prorpritaeres Script ist? Und wie sieht das bei der GPL aus?
Ich verstehe nicht ganz, wieso der Client (das "freie Script") unter AGPL stehen sollte. Da reicht auch die GPL. Die AGPL wäre eher für die serverseitige Software interessant, aber die wurde hier ja als proprietär beschrieben.
Wie auch immer, das ganze ist eine reine GPL-Frage, die AGPL ist in diesem Punkt identisch mit der GPL. Für die Entscheidung GPL vs. AGPL spielt das somit keine Rolle.
Ich bin kein Anwalt, aber ich denke, das ist in beiden Faellen kein Problem.
Vorsicht! Das hängt sehr stark von den Umständen ab.
Positiv-Beispiel: Auf dem Server läuft eine proprietäre Web-Applikation, und der Client ist ein Browser, der eine GPL-Library verwendet. Dann muss der Browser selbstverständlich unter GPL stehen, aber die Web-Applikation ist davon nicht betroffen.
Negativ-Beispiel: Der Client ist eine Software, die eine GPL-Library verwendet, aber zugleich auch aus proprietärem Code bestehen soll. Die GPL verbietet das natürlich, genau sowas will sie ja verhindern! Also versucht man das zu umgehen, indem man den proprietären Code hinter einem Netzwerkdienst "versteckt". Dessen API ist in keiner Weise standardisiert, und dient lediglich zur "Legalisierung" des proprietäeren Bestandteils. In diesem Fall sollten wir hoffen, dass ein Richter diesen plumpen Versuch durchschaut und entsprechend zugunsten der GPL-Software urteilt.
Anders gesagt: Diese Frage kann man nicht technisch beantworten. Es geht nicht darum, ob der proprietäre Code als Library, Kommandozeilentool oder Netzwerkdienst angesprochen wird. Es geht nur darum, ob Client und Server zusammen eine Einheit bilden oder nicht. Muss man sie als eine Software betrachten? Oder gibt es eine klare Trennung zwischen beiden? Ist die Trennung nur technisch, oder auch inhaltlich vorhanden?
Falls du wirklich auf solch einen solchen Grenzfall stößt, würde ich dir empfehlen, dich an die FTF (Freedom Task Force) der FSFE zu wenden. Ich hatte vor einiger Zeit ein ganz ähnliches Problem und habe dort eine sehr nützliche und gut verständliche Antwort erhalten. [1]
Gruß Volker
[1] Wichtiger Hinweis: Du solltest die Leute auf jeden Fall in englischer Sprache anschreiben! Das erhöht sowohl die Geschwindigkeit als auch die Qualität der Antwort.
Webseite: http://fsfe.org/projects/ftf/ftf.de.html E-Mail: legal@fsfeurope.org
Hallo,
On Tue, Sep 20, 2011 at 02:22:45AM +0200, Volker Grabsch wrote:
On Monday 19 September 2011 22:14:39 Roland Häder wrote:
Ist es mit der GNU Affero GPL vereinbar, dass ein freies Script per HTTP-Anfrage (GET/POST) auf eine API zugreift, die ihrerselbst ein prorpritaeres Script ist? Und wie sieht das bei der GPL aus?
Ich verstehe nicht ganz, wieso der Client (das "freie Script") unter AGPL stehen sollte. Da reicht auch die GPL. Die AGPL wäre eher für die serverseitige Software interessant, aber die wurde hier ja als proprietär beschrieben.
Es ging um den Fall, dass eine (freie) Server-Software ihrerseits wiederum auch als Client für (proprietäre) Services auftritt -- was ja durchaus nicht unüblich ist.
-antrik-