Lizenzkompatibilität GPLv2 und GPLv3 - konkretes Beispiel

Dirk L fsfe_dl at yahoo.de
Mo Nov 10 13:45:33 UTC 2014


Hallo Bernhard,

vielen Dank für deine Einschätzung.

Am 13.08.2014 um 17:42 schrieb Bernhard Reiter:
> [...]
> Alle unter GNU GPL v>=2 stehenden Teile, dÃŒrfen auch unter GNU GPL v>=3
> weitergenutzt werden. Egal, ob es sich da nun um abgeleitete Werke handelt 
> oder nicht, läߟt sich dann das Gesamtergebnis im Zweifel als GNU GPL v>=3 
> nutzen.

Gut. Dann kann ein Großteil des Projekts auch weiterverwendet werden.

> Linux (im engeren Sinne) ist GNU GPL v==2, aber da ist meinst klar, dass 
> Anwendungen darauf ablaufen können. Probleme gäbe es nur bei Kernel-Modulen.

Das stimmt. Hier werden jedoch keine Kernel-Module benötigt, also
sollte dies kein Problem sein.

> Pragmatisch gesehen würde ich alles genauer untersuchen, was unter
> einer Lizenz steht, welche nicht mit GNU GPL v>=3 kompatibel ist.
> 
> Ein Problem sind wohl Lizenzen GNU GPL v==2 und irgendwann auch GNU GPL v==3.
> Diese sollten mittelfristig wohl ersetzt werden.

Da wollte ich nochmal nachhaken und zwar habe ich folgendes Paket bzw.
Funktion, die unter GPLv2 entwickelt und im Jahr 2008 veröffentlicht wurde.

>> - Das Herzstück (in meinen Augen), die Synchronisation eines
>> vorher erstellten Speicherabbildes (Image) auf einem Server mit einem Client,
>> des Projekts steht unter GPLv2, beinhaltet jedoch Skripte unter GPLv3.
>> Mit daran gearbeitet hatten Software-Entwickler aus dem Knoppix-Umfeld.

Im Laufe der Zeit ist es jedoch um weitere Funktionen (unter GPLv3)
erweitert worden, darunter SCP-Wrapper durch rsync+ssh und mit Einfügen
einer Update-Funktion des Dateisystems (alle 2009);
Torrent-Unterstützung, Einfügen einer Schnittstelle zur
Administration, Remote-Unterstützung (alle 2010), Überarbeitung des
Multicast-Skripts und Wechsel auf GPLv3 durch explizite Angabe der
Lizenz (2011), Überarbeitung und Wechsel auf GPLv3 eines "Pre-Upload
script for rsync/$SoftwareName" (2013).

Läge dann nicht eine Lizenzinkompatibilität (bzw. Lizenzverletzung)
vor, da ja die debian\copyright-Datei GPLv2 vorgibt? Denn ich meine sie
steht an erster Stelle ähnlich zu dem /-Verzeichnis. Anders
ausgedrückt, sie vererbt die Lizenz an alle anderen Dateien, steht
jedoch mit den unter GPLv3 stehenden Skripte in Konflikt.

>> - Um Truecrypt in einen Linux-Client zu integrieren, wird ein
>> entsprechendes unlizenziertes (keine „debian/Copyright“-Datei) Paket
>> bereitgestellt.
> 
> Truecrypt ist unfrei und gilt mittlerweile auch als ungepflegt und deshalb 
> unsicher. Würde ich aus allen drei Gründen rauswerfen.

Nun gibt es jedoch die ein oder andere Kultusverwaltung, die eine
Verschlüsselung vorschreibt (z. B. Hessen [1], Niedersachsen [2] oder
Baden-Württemberg für USB-Sticks [3]) und/oder auch den Einsatz von TC
7.1a weiterempfiehlt [4].
Daneben ist es ein Komfortgewinn, wenn sich TC durch ein einfaches
"apt-get install *-truecrypt" auf den verwendeten Linux-Clients
installieren lässt.

> Deinen Quelltext kannst Du vermutlich unter jeder Lizenz beitragen, welche 
> kompatibel zur GNU GPL v>=2 ist, z.B. die X11-Lizenz, GNU LGPL v>=2 oder auch 
> die GNU GPL v>=2 selbst.

Danke für diesen Hinweis.

> Hilft Dir das weiter? ;)

Ja, das hilft mir bei meiner Entscheidung. Danke :)

Gruss

Dirk

Referenzen:
[1]
http://studienseminar-ghrf-wi.de/uploads/media/Verarbeitung-personenbezogener-Daten-am-haeuslichen-PC.pdf
[2]
http://nibis.ni.schule.de/~ref_404/dokumente/2011_12/20111017_Uebersendung_Jahresstatistik.pdf
[3]
http://kultusportal-bw.de/IT,Lde/Startseite/IT-Sicherheit/Verschluesselung+von+Speichermedien
[4]
http://kultusportal-bw.de/IT,Lde/Startseite/IT-Sicherheit/Information+zu+TrueCrypt



Mehr Informationen über die Mailingliste FSFE-de