Verständnis der GPL

[MacFlieger]

Ich hab da einige Fragen, ob ich die GPL richtig verstehe.

1. Wenn man Software entwickelt, die eine Software unter GPL-Lizenz mitbringt, dann muß die auch unter GPL stehen, richtig?
Z.B. wenn man eine GUI für rsync macht und rsync in dem GUI-Programm mitliefert, damit nicht jeder zur Installation ins Terminal muß.
2. GPL bedeutet, daß man den Source-Code zur Verfügung stellen muß, richtig?
3. GPL bedeutet, daß man das Programm nur kostenfrei zur Verfügung stellen darf, richtig?

4. Was ist der Unterschied zu Apple Public Source Licence?
5. Welche Lizenz gilt, wenn zwei Lizenzen kollidieren, z.B. rsync von OS X nehmen und einen Patch von jemand anderem?

Fragen über Fragen, aber das Feld ist neu für mich.

[warlord]

Zuerst mal natürlich: IANAL.  Aber ich hatte mich auch anlässlich der Formulierung von eigenen Lizenzbedingungen etwas mit der Materie beschäftigt und auch die GPL etwas näher unter die Lupe genommen.

Zuerst mal die einfacher zu beantwortenden Fragen 1 - 3:

1) Ja, richtig. GPL ist diesbezüglich in etwa die strengste Lizenz, die es gibt.

2) Richtig.

3) Nein. In der Preambel wird ausdrücklich darauf hingewiesen, dass sich das "free" nicht auf den "Preis", sondern einzig auf die freie Verfügbarkeit bezieht.  Es ist durchaus erlaubt, für die Verteilung von unter GPL laufender Software eine Gebühr zu verlangen.

[warlord]

Zu Frage 4: Eine vollumfängliche und vor allem abschliessende Beantwortung dieser Frage ist wohl ein Ding der Unmöglichkeit.    Aber der massgeblichste und interessanteste Unterschied ist wohl der, dass die Apple Public Source License, wie die meisten Open Source Lizenzen ausser eben GPL, sogenannte "Larger Works" erlaubt, die nicht der gleichen Lizenz unterstellt werden müssen (also z.B. Dein Beispiel mit der GUI über einem Tool wie rsync).

[warlord]

Und zu Frage 5: Lizenzen sind schon für sich alleine ein recht komplexes Gebiet. Gänzlich schlimm wird es natürlich wenn es dann eben ums Kombinieren und Cross-Licensing geht. Generell beantworten lässt sich somit Deine Frage kaum. Man müsste schon wissen, um welche Lizenzen es genau geht. Und auch dann liessen sich mit einer umfassenden Antwort wohl Bücher füllen.

Da sich Deine Fragen aber sonst um GPL drehen, gehe ich mal davon aus, dass diese in der Kombination beteiligt wäre. Und da wird es dann natürlich sehr schnell sehr schwierig. GPL ist IMO praktisch unmöglich mit anderen Lizenzen zu kombinieren. Sie ist da einfach zu restriktiv.

[mbs]

Genau, IANAL... 

1. Wenn man Software entwickelt, die eine Software unter GPL-Lizenz mitbringt, dann muß die auch unter GPL stehen, richtig?
Z.B. wenn man eine GUI für rsync macht und rsync in dem GUI-Programm mitliefert, damit nicht jeder zur Installation ins Terminal muß.

Nicht unbedingt: Es hängt davon ab, wie Dein GUI-Programm das unter GPL stehende Programm nutzt. Wenn das GUI-Programm ein eigenständiges Programm ist, das das andere nur aufruft, gilt die GPL nicht für Deinen eigenen Code. "Aufruft" würde konkret in Mac OS X fork() und exec() oder darauf basierende Mechanismen wie z.B. "NSTask" in Cocoa bedeuten.

Mac OS X enthält ja auch viele GNU-Tools, steht aber nicht unter GPL.

Nur wenn Du direkt den Source-Code des GPL-Programms verwendest, oder Teile des GPL-Programms durch statisches oder dynamisches Linken mit Deinem Programm verbindest oder wenn die beiden Programme so eng miteinander kommunizieren, dass sie unmittelbar auf der gleichen Datenstruktur arbeiten, dann würde die GPL auch für Dein Programm gelten.

GPL bedeutet, daß man den Source-Code zur Verfügung stellen muß, richtig?

Ja, wobei er nicht unbedingt mitgeliefert werden muss. Du musst den Source-Code nur für mindestens 3 Jahre maschinenlesbar "anbieten".

GPL bedeutet, daß man das Programm nur kostenfrei zur Verfügung stellen darf, richtig?

Nein. Für Programme unter GPL dürfen Gebühren in beliebiger Höhe verlangt werden. Sonst wäre es nicht "free".

Was ist der Unterschied zu Apple Public Source Licence?

Neben kleinen Detailunterschieden ist der Hauptunterschied, dass Apple sich das Recht vorbehält, jemanden sofort von der Nutzung von APSL-geschütztem Code auszuschließen, wenn dieser patentrechtliche Schritte gegen Apple einleitet, auch im Nachhinein.

Welche Lizenz gilt, wenn zwei Lizenzen kollidieren, z.B. rsync von OS X nehmen und einen Patch von jemand anderem?

Sie dürfen nicht kollidieren. Wenn Du GPL-Code mit einem Programm linkst, das sich nicht an die GPL hält, dann verstößt das Produkt gegen die GPL und darf nicht genutzt werden.

[warlord]

Nicht unbedingt: Es hängt davon ab, wie Dein GUI-Programm das unter GPL stehende Programm nutzt. Wenn das GUI-Programm ein eigenständiges Programm ist, das das andere nur aufruft, gilt die GPL nicht für Deinen eigenen Code. "Aufruft" würde konkret in Mac OS X fork() und exec() oder darauf basierende Mechanismen wie z.B. "NSTask" in Cocoa bedeuten.

Das halte ich nun doch für eine etwas gewagte Auslegung.

These requirements apply to the modified work as a whole.  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.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.

Für mich ganz klar unmöglich ist damit ein Mitverteilen des Tools mit dem eigenen GUI-Programm, wenn jenes nicht unter GPL veröffentlich wird.
Aber in meinen Augen kann eine GUI über einem Tool nicht "reasonably be considered independent", so dass IMO selbst eine Veröffentlichung ohne das Tool heikel ist.

Edit: Den letzten Satz nehm ich zurück. Eine Verteilung ohne das Tool müsste kein Problem sein.

[mbs]

Für mich ganz klar unmöglich ist damit ein Mitverteilen des Tools mit dem eigenen GUI-Programm, wenn jenes nicht unter GPL veröffentlich wird.

Nein, der zitierte Absatz bezieht sich nur auf ein "modified work", oder "work based on the program" und ist deshalb für diese Fragestellung nicht anwendbar.

Du hast schon Recht: Die Frage, was denn nun ein "derived work" ist und was nicht, ist der kritischste Punkt in der GPL. Die offizielle GPL-FAQ interpretiert dies aber so, wie ich geschrieben habe:

Can I release a non-free program that's designed to load a GPL-covered plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

Die GPL-Interpretation unterscheidet zwischen "Aggregation" und "Kombination" von Programmen. Die GPL erstreckt sich nur auf kombinierte, nicht aber aggregierte Teile. Allerdings wird darauf hingewiesen, dass der Übergang in Spezialfällen fließend sein kann und die Auslegung nur vor Gericht eindeutig klärbar ist:

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Ein prominentes Beispiel für MacFliegers Fall wäre z.B. Xcode: Auch hier handelt es sich um eine GUI, um die unter GPL stehende Software "gcc" zu steuern.

[warlord]

OK. Wobei ich nach wie vor der Ansicht bin, dass es so nicht im Lizenztext steht. Eine speziell über ein Tool entwickelte GUI lediglich als "aggregation" von zwei unabhängigen Programmen zu bezeichnen, bleibt in meinen Augen gewagt, auch wenn die FSF das nun (in gewissen Fällen) so ausgelegt haben möchte, weil sie gemerkt hat, dass sie die Lizenz strenger formuliert hat, als sie das wohl eigentlich gewollt hat.

[MacFlieger]

Erst mal vielen Dank für Eure Antworten.

Klar, IANAL und selbst wenn, vor Gericht und auf hoher See...
Aber es geht mir ja auch nicht um eine juristisch wasserdichte Einschätzung, wenn es sowas überhaupt gibt, sondern nur um das Verständnis, damit ich keine groben Fehler mache.

Noch zum Verständnis: Meine Fragen bezogen sich zwar zum einen auf den konkreten Fall, was ich jetzt machen will, die Fragen hatte ich aber schon länger, weil mir schon öfters auffiel, was man programmieren könnte und dabei oft auch auf Software unter GPL zurückgegriffen wurde.

Zu den einzelnen Punkten, zu denen ich noch Fragen/Kommentare hätte:

1. Wenn man Software entwickelt, die eine Software unter GPL-Lizenz mitbringt, dann muß die auch unter GPL stehen, richtig?
Es ist also abhängig davon, wie stark das eingebunden ist und eine genaue Grenze gibt es nicht.
Nur mal, wie ich mir das im konkreten Beispiel beim Backup-Programm gedacht habe:
- Ich würde das rsync aus dem Quellode von Apple zusammen mit einem Patch neu compilieren und in dem Bundle des fertigen Programmes mitliefern, denn das Erstellen des gepatchten rsync kann man niemanden zumuten.
- rsync würde dann über Shell-Skripte gestartet werden.
- Evtl. würde rsync auch z.B. unter /usr/local/bin installiert werden und mit launchd gestartet werden, das ist mir noch nicht so klar.
So wie ich das sehe, wäre das schon eine sehr enge Verzahnung, die GPL erfordert, oder? Nicht, daß ich das schlimm finde, nur zur Klärung wollte ich das wissen.

2. GPL bedeutet, daß man den Source-Code zur Verfügung stellen muß, richtig?

OK, d.h. das Projektverzeichnis von Xcode zum Download anbieten oder mitliefern und gut?

3. GPL bedeutet, daß man das Programm nur kostenfrei zur Verfügung stellen darf, richtig?
Zur Klärung:
- Ich könnte also hingehen und ein Programm zum Kauf anbieten, dabei muß ich natürlich den Quellcode mitgeben oder anbieten. Und wer nicht zahlt, kriegt gar nichts von beiden.
- Oder ich muß den Quellcode immer kostenfrei anbieten, aber das compilierte Programm kann man nur gegen Bezahlung herausrücken.
- Oder man muß Quellcode und fertiges Programm immer kostenlos anbieten, nur für die Benutzung darf man Geld verlangen?
Nicht, daß ich für das aktuell konkrete Projekt Geld haben will, es geht mir nur ums Verständnis.

4. Was ist der Unterschied zu Apple Public Source Licence?

OK, kein Problem, ich habe keine Patente, mit denen ich Apple gefährlich werden könnte.

Noch eine neue Frage:
Ich schrieb ja oben, daß ich die Apple-rsync-version mit einem Patch neu compilieren will. Darf man die dann auch problemlos auf Nicht-Tiger-Systemen einsetzen. Ich denke schon, aber was meint ihr?

[warlord]

1. Das gepatchte rsync müsste wieder unter GPL laufen. Soweit sind sich mbs und ich schätzungsweise einig.  Was Du darum herum noch vor hast, habe ich jetzt noch nicht so genau verstanden.

2. Wenn Du mit "Verzeichnis" das computertechnische Verzeichnis, das auf dem Mac mal Ordner hiess, meinst und das somit die Quelldateien enthät, ja.

3.
- Ja. Er kriegt es nicht von Dir, wenn er nicht bezahlt. Er darf es sich aber von seinem Nachbarn kopieren (kostenlos oder auch gegen Entgelt, das ist dann nicht Deine Sache).
-  Das ist eine Möglichkeit, ja.
- Für die Benutzung darfst Du keine Gebühr verlangen. Dann wäre die Software nicht mehr "free".

Und zur letzten Frage: Sehe da auch nichts, das einem Einsatz auf Nicht-Tiger-Systemen (lizenztechnisch) im Wege stehen sollte.

[MacFlieger]

1. Das gepatchte rsync müsste wieder unter GPL laufen. Soweit sind sich mbs und ich schätzungsweise einig.  Was Du darum herum noch vor hast, habe ich jetzt noch nicht so genau verstanden.

Naja, die Bedienung von rsync ist ja nicht jedermanns Sache, RSyncX ist eigentlich nur eine GUI, bei der man die Optionen zwar kennen muß, aber die Syntax nicht. Schön wäre eine GUI, bei der man nur zu sichernde Ordner, Zielordner, wieviele rotierende Backups vorliegen sollen einstellen kann/muß und dann alles funktioniert. Weitergehende Funktionen wie Backup übers Netz, in eine DMG-Datei, automatischen Start des Backups per launchd oder ähnliches kann ja dann noch dazu kommen. Man hätte dann eine GUI, in der man nur das gewünschte einstellt und das Programm würde die Informationen so aufbereiten, daß dann der notwendige rsync-Befehl über ein Shellskript im Hintergrund abgesetzt wird.

3.
So langsam habe ich es. GPL bedeutet, daß sich jeder das Programm/den Quelltext kostenfrei kopieren darf, daß die Benutzung des Programmes kostenfrei ist und das man nur für die Lieferung des Programmes Geld verlangen darf.

[warlord]

Aha, Dein GUI Programm würde ja dann wohl letztlich mit fork() oder exec() zu Werke gehen. Das dürfte dann wohl gemäss GPL-FAQ anscheinend in Ordnung gehen sollen.  Aber wirklich auf die Äste hinaus lasse ich mich in dieser Frage nicht. 

3. Ja, oder z.B. auch dafür, dass Du für die von Dir gelieferte Software/Version gewisse Garantien übernimmst.

[MacFlieger]

Aha, Dein GUI Programm würde ja dann wohl letztlich mit fork() oder exec() zu Werke gehen. Das dürfte dann wohl gemäss GPL-FAQ anscheinend in Ordnung gehen sollen.  Aber wirklich auf die Äste hinaus lasse ich mich in dieser Frage nicht. 

OK.
Für das gepatchte rsync (läuft ja unter GPL) muß ich ja die Sourcen mitgeben. Reichen da die Sourcen, für rsync von Apple und die benutzten Patches? Darf ich einfach die Sourcen dann zum Download anbieten?

3. Ja, oder z.B. auch dafür, dass Du für die von Dir gelieferte Software/Version gewisse Garantien übernimmst.

Na, garantiert nicht.
Wenn ich bei so einem sensiblen Thema wie Backup und mit root-Rechten laufenden Skripten Garantien abgeben müßte, dann bräuchte ich aber eine gute Versicherung. Nene, das ist mir zu heikel.

[MacFlieger]

Hol ich den Thread nochmal nach oben.
Ich hatte es so verstanden, daß jeder, der z.B. rsync benutzt oder verändert, die Quelltexte liefern muß bzw. zur Verfügung stellen muß.

Auf den Downloadseiten von Apple ( http://www.opensource.apple.com/darwinsource/ ) finde ich auch die Sourcen für rsync und die Apple-Patches für die unterschiedlichsten Systemversionen. Soweit, so gut.
Bei den beiden letzten Sicherheitsupdates, die noch nach 10.4.5 kamen, wurde beidesmal eine neue Version von rsync mitgeliefert, die sehr wichtige Fehler behoben haben. Eigentlich müßte Apple doch die Sources für diese Versionen auch online stellen, oder? Ich finde die aber nicht. Suche ich an der falschen Stelle?

[warlord]

Bin mir nicht sicher. Aber ich glaube, Apple veröffentlich nicht nach jedem Patch gleich den angepassten Quellcode sondern spart sie zusammen und veröffentlich jährlich (oder so) eine neue Quellcodeversion. OpenSourcler haben sich meines Wissens wegen dieser Praxis schon über Apple beklagt.
Ist wohl schon nicht 100%-lizenzkonform, aber für eine grössere Firma wäre eine anderes Vorgehen wohl sehr aufwändig.