Should we report AVM's GPL violations

[McNetic]

Wenn man jemand 'Offiziellen' findet, der das tut, hat vermutlich niemand was dagegen. Am vielversprechendsten wäre hier wohl wirklich gpl-violations.org, weil die wirklich was tun. Aber die können sich auch nicht um alles kümmern...

 

[GuruHacker]

*PUSH*

Frische ware von heise.de


Quelle: www.heise.de

Lizenzverstöße auf der Spur mit der GPL Compliance Engineering Guide


Armijn Hemel, die rechte Hand von Harald Welte bei gpl-violations.org, hat eine Anleitung veröffentlicht, die beschreibt, wie das Projekt GPL- oder LGPL-lizenzierte Software auf Embedded-Geräten ausfindig macht. Der GPL Compliance Engineering Guide (PDF) geht auf 26 Seiten auf die Analyse von Firmware ein, wobei der Bootloader, die Bootreihenfolge, das Dateisystem, Kompressionstechniken und ausführbare Dateien unter die Lupe genommen werden. Auch beschreibt das Dokument die Werkzeuge, die bei der Recherche zum Einsatz kommen, darunter die binutils, hexdump, file, strings. tar, gunzip/zcat, lzma, squashfs-tools und mtd-tools. Wenn der Bootloader nicht in einem Firmware-Update enthalten ist, bleibt nur die Möglichkeit, sich über eine serielle Konsole oder per JTAG mit dem untersuchten Gerät zu verbinden.

Im letzten Teil der Anleitung nennt Hemel Software (darunter Linux-Kernelmodule, C-Bibliotheken und die Tool-Sammlung BusyBox), die häufig in solchen Geräten anzutreffen ist. Auch wenn die meisten Verstöße gegen die GPL und die LGPL mit Linux-Geräten passieren, geht Hemel auch kurz auf das Thema Compliance Engineering für Windows ein. So wird das unter der GPL stehende Cygwin, mit dem sich POSIX-Programme auf Microsoft Windows portieren lassen, nach Hemel auf einigen teuren Routern eingesetzt. Mit einer Checkliste sowie einem Aktionsplan, wie man im Falle einer entdeckten Verletzung der (L)GPL vorgehen sollte, beschließt der Autor die Anleitung. Hemel ist angestellt bei der niederländischen Beratungsfirma Loohuis Consulting, die GPL-Compliance-Engineering als Dienstleistung anbietet.





Nach den Lizenzbestimmungen der GPL muss Software, die unter der GPL lizenzierte Open-Source-Software verwendet, selbst auch wieder unter die GPL gestellt werden und im Sourcecode zur Verfügung stehen. Das Projekt gpl-violations.org untersucht mögliche Verstöße und geht gerichtlich gegen Firmen vor, die die Lizenzbestimmungen der GPL und LGPL nicht korrekt einhalten. So hat im Juli vergangenen Jahres zum Beispiel das Landgericht München entschieden, dass der VoIP-Anbieter Skype mit dem Vertrieb eines Linux-basierten VoIP-Telefons von SMC Networks gegen die GPL verstößt, da das Gerät ohne Quelltexte geliefert wurde.

Da es zum diesen thema gehört, denke ich das das hier passt.

 

[olistudent]

Sehr schöner Artikel. Beim Durchlesen ist mir aufgefallen, dass AVM kein "mksquashfs", also keine Squashfs-Tools (mit dazu gehörigen Patches) anbietet.

MfG Oliver

 

[RalfFriedl]

Sie liefern auch kein mksquashfs Binary als Bestandteil der Firmware aus, daher sind sie nicht dazu verpflichtet, Quellen dafür zu liefern

 

[olistudent]

Also ich verstehe den Abschnitt anders:

Often a binary-only toolchain is shipped in a GPL archive, without sources. For other tools, like the ones to create an actual file system (mksquashfs with or without LZMA compression, mkfs.jffs2, genromfs, mkcramfs) the sources are missing quite often too.

Wo ist denn da die Logik? Wir liefern einfach kein mksquashfs mit aus, dann brauchen wir auch keinen Source mit rein packen? Dann ist die Toolchain nicht vollständig.

MfG Oliver​

 

[RalfFriedl]

Von wo stammt der Text?

Nach meinem Verständnis ist es eine Lücke in der GPL2, daß nicht alle Werkzeuge oder Keys bereitgestellt werden müssen, um aus den Quellen tatsächlich eine auf dem Gerät lauffähige Software zu machen, wie bei TIVO und ähnlichen Geräten.

Wenn die GPL auch die vollständige Toolchain verlangt (idealerweise mit Quellen), ist das aus meiner Sicht natürlich noch besser.

Für den Anfang wäre ich aber schon mit der gleichzeitigen Bereitstellung aller Quellen und Konfigurationen zufrieden.

 

[olistudent]

Aus dem von GuruHacker geposteten Compliance Engeneering Guide.

MfG Oliver

 

[RalfFriedl]

Kurz vor der Stelle steht auch:

It is an ongoing debate whether or not the toolchain itself should be shipped. Some people say it should be, since without it it is very difficult and sometimes even impossible to build a new executable for a device without having access to the exact cross compiler that was used for building the software on the device. Other people say that because only the result of the toolchain is distributed, the toolchain does not need to be distributed.

Es ist also nicht klar, ob die Toolchain mitgeliefert werden muß, auch wenn es wünschenswert ist.
Wenn aber eine Toolchain aus GPL-Programmen mitgeliefert wird, muß diese auch mit Quellen geliefert werden.

 

[MReimer]

Für den Anfang wäre ich aber schon mit der gleichzeitigen Bereitstellung aller Quellen und Konfigurationen zufrieden.

Wobei zu "alle Quellen" auch und besonders all das gehört um die Kernel-Module selber bauen zu können. Solange das nicht möglich ist bleibt im Moment nur eine Zweitbox, wenn man wirklich auf den Datenstrom von DSL nach LAN Einfluss nehmen will. Ich experimentiere da gerade mit der Fritz!Box SL. Auf der soll später mein Traffic-Manager inklusive Routing laufen, während ich die Fritz!Box Fon mittlerweile als abgeschlossene Blackbox betrachte.

 

[poruid]

Also very interesting is the statement issued by many of the kernel developers, see Position Statement on Linux Kernel Modules

 

[morpheus80]

Ganz meine Meinung.

Nur ob dieses Statement diverse "Globalplayer" wie u.a. Nvidia, dazu bewegt die Module bzw. die zugrundeliegenden Bibliotheken freizugeben, ist fraglich.

Habe vor Kurzem einen Speedport W721V von der TCOM erhalten. Hier mein Post:
http://www.ip-phone-forum.de/showthread.php?t=178644

Dieser Speeport W721V wird von AVM produziert. Diesem liegt ein DIN-A5 Blatt bei, auf welchem diverse Lizenzen abgedruckt sind. Unter anderem die GNU GPLv2, die Lesser GPL (LGPL), die BSD License und eine propritäre (AVM) Lizenz.

Jetzt sollte sich AVM halt auch noch dran halten.

Weiss ja nicht wie lange das schon so ist, dass die Lizenzen mitgeliefert werden, aber zumindest mal ein Schritt in die richtige Richtung.

morpheus80.

 

[MReimer]

Nur ob dieses Statement diverse "Globalplayer" wie u.a. Nvidia, dazu bewegt die Module bzw. die zugrundeliegenden Bibliotheken freizugeben, ist fraglich.

Was Nvidia macht ist maximal Grauzone, denn dort kann man sein Kernel-Modul ja selbst bauen. Für jede Kernel-Version die einem beliebt! Bei AVM dagegen liegen die Kernel-Module nur binär vor. Kernel-Tausch auf der Box: Fehlanzeige.

Weiss ja nicht wie lange das schon so ist, dass die Lizenzen mitgeliefert werden, aber zumindest mal ein Schritt in die richtige Richtung.

Nichtmal das. Ein Blatt Papier hilft niemandem. Taten würden helfen. Das absolute Minimum wäre das Veröffentlichen der Sourcen für die Kernel-Module.

 

[morpheus80]

Ich denke auch, es ist Zeit, dass AVM die Quellen offenlegt.

Die haben lange genug davon profitiert, dass andere die Arbeit für sie machen, jetz müssen sie auch mal was zurückgeben.

Oder auf Closed Source umsteigen. Irgendein Hersteller findet sich bestimmt, der in die Lücke springt. Bzw. gibt es ja auch noch andere Open Source Router (Linksys, D-Link, etc.).

Weiss allerdings nicht, wie man genau vorgehen sollte. AVM bei gpl-violations.org oder bei der FSF zu melden, wäre sicher eine Möglichkeit. Ob die dann allerdings etwas unternehmen, weiss ich nicht. Wobei die Busybox Entwickler (welche ja von AVM verwendet wird) recht Konsequent gegen GPL verstöße vorgehen, soviel ich weiss.

morpheus80.

 

[RalfFriedl]

Aber AVM verstößt nicht mit der Busybox gegen die GPL.

 

[morpheus80]

Ja, stimmt, sorry. Die Quellen der Busybox sind ja enthalten.

Ausserdem denke ich, dass bei den Modulen eventuell Texas Instruments u.a. noch ein Wörtchen mitzureden hat. Da AVM doch viele Boxen mit deren Chips ausstattet bzw. ausgestattet hat, weiss nicht ob das noch so ist.

Es sind doch hauptsächlich die Module für die Hardware (z.B. tiap, tiatm, ...), für welche die Quellen nicht enthalten sind, oder?

Entwickelt dann nicht der Hersteller der Hardware die Kernel-Module, oder macht das AVM selbst? Und ist dann nicht der jeweilige Hardware-Hersteller Ansprechpartner in Sachen GPL bzw. Quellcode?

 

[MReimer]

Was das mit TI und AR7 angeht:
http://lists.gpl-violations.org/pipermail/legal/2005-September/000494.html

Keine Ahnung was dran ist.

Ich habe das Thema bereits einmal an GPL-Violations.org gesendet. Man hat mir eine Ticket-Nummer für ein Ticket-System gegeben, welches ich mangels Berechtigung nicht einsehen kann. Wer auch eine Mail an GPL-Violations.org senden will, der möge das tun. Keine Ahnung wie die ihre Fälle wählen. Vielleicht wird ein Thema mit vielen Anfragen hochpriorisiert.

 

[RalfFriedl]

Was TI betrifft und den Link, so scheint mir das plausibel. Selbst wenn TI den Treiber ohne Quellen an die Hersteller liefern würde (unwahrscheinlich, weil dann müßten sie passende Binaries für alle Kernel erstellen, die von irgend einem Hersteller verwendet werden), würde das nur einen Anspruch der Hersteller auf die Quellen begründen, aber nicht von Dritten.

Andererseits, selbst angenommen TI wäre gegen die Weitergabe der Quellen durch AVM, dann wäre das keine Entschuldigung für AVM, keine Quellen zu liefern. Die GPL ist in idesem Punkt sehr deutlich: Wenn man nicht die Quellen mitliefern kann und gleichzeitig seine anderweitigen Verpflichtungen erfüllen kann, dann ist die einzige Lösung, das Programm überhaupt nicht zu weiterzugeben.

Ansprechpartner ist immer der, von dem man die Binärdateien bekommen hat, nicht der ursprünglich Author. Ob die einzelnen Moduls von AVM oder von TI sind, können wir letztlich nur vermuten, aber nicht sicher wissen.

Ansonsten ist auch die ganze Ansteuerung für ISDN und USB in binärmodulen enthalten, die vermutlich vollständig von AVM erstellt wurden.

 

[poruid]

FTF and gpl-violations release a guide to reporting and fixing licence violations

see http://www.fsfeurope.org/news/2008/news-20081208-01.en.html