Close-Source-Module statisch gelinkt?

[hermann72pb]

ich kann dir schon jetzt in etwa sagen was da kommt:

1. Standardantwort des AVM-E-Mailbeantworters
2. Ein Erbsenzähler aus der Supportabteilung der AVM meldet sich bei dir und wird dir mit allen möglichen Mitteln beweisen, dass AVM Recht hat
3. Nach 10-ter Re-Re-Aw-Re-Re-Mail vergeht dir dein Geduld mit ihm zu streiten, weil er überhaupt nicht kompromissbereit ist. Woher auch, er ist sowieso nur das 5-te Rad da in der Abteilung und wird weder dir irgendwelche Aussagen machen noch deine meinung weiter in die Chefetage leiten. Seine Aufgabe ist: Puffer zu spielen.
4. Alles verläuft entweder im Sande und bleibt weiter so...


Wenn du wirklich gegen AVM vergehen willst, musst du die Kernel-Entwickler an Board ziehen. Nur sie haben da was zu sagen. Mit dir alleine wird AVM gar nicht handeln. Der von dir zitierte Herr Welte befasst sich eher mit der iptables-Thematik, was AVM schlauerweise nicht einsetzt (wenn ich es richtig verstanden habe). Du brauchst schon busybox-Entwickler und kernel-Entwickler. Dass es grundsätzlich geht, bezweifele ich nicht, aber es kostet viel Zeit, Geduld und erfordert gewisse Kenne im deutschen und europäischen Recht (also, wenn du Jura nicht studiert hast, vergiss es).

Wenn du wirklich nicht aufgeben willst und dir die Sache annehmen willst, dann gründe erstmal eine Community der richtig engagierter Leute, so ähnlich wie dieser Herr Welte, oder lass uns mal bei seiner Community (wenn die überhaupt gibts) eine AVM-GPL-Unterabteilung (sozusagen) gründen.

Als Gegenaktion kann man z.B. bei der nächsten CEBIT auf dem AVM-Stand mit PRO-GPL-T-Shirts auflaufen und so Aufmerksamkeit auf sich lenken. Über die Legalität solcher Aktionen sollte man sich vorher informieren lassen.

Wie es bereits im anderen Thread (querpostings!!!) angesprochen wurde, dass AVM komplett auf closed-source umschwenkt, das glaube ich kurzfristig eher nicht. Aber der langfristige Trend geht dahin, ohne Zweifel. Nur das Problem ist, dass der Weg dahin auf Kosten der Open-Source-Community getragen wird. Und auf auf Kosten von Freetz. Schaut euch mal nur die letzten Features von AVM-Firmware an: https, vpn, statische Leases... Erinnert es euch nicht an die Ideen von hier, wie überhaupt ds-mod entstanden ist?

MfG

 

[MReimer]

Bisher haben bei mir noch immer die Support-Mitarbeiter aufgegeben

Wie groß ist denn die Chance das sich Kernel-Entwickler mit solchen Thematiken befassen?

Der von dir zitierte Herr Welte befasst sich eher mit der iptables-Thematik, was AVM schlauerweise nicht einsetzt (wenn ich es richtig verstanden habe).

Einen Versuch ist es dennoch wert. Dort hat man wohl Erfahrung mit Lizenzverstößen.

Wie es bereits im anderen Thread (querpostings!!!) angesprochen wurde, dass AVM komplett auf closed-source umschwenkt, das glaube ich kurzfristig eher nicht. Aber der langfristige Trend geht dahin, ohne Zweifel. Nur das Problem ist, dass der Weg dahin auf Kosten der Open-Source-Community getragen wird. Und auf auf Kosten von Freetz. Schaut euch mal nur die letzten Features von AVM-Firmware an: https, vpn, statische Leases... Erinnert es euch nicht an die Ideen von hier, wie überhaupt ds-mod entstanden ist?

Eben das ist das Thema. AVM profitiert auf ganzer Linie von der GPL. Freie Lösungen werden aufgegriffen und es wird sich an der Arbeit anderer bedient. Gegen all das spricht nichts, denn dafür ist freie Software da. Allerdings kann man nicht nur die Vorteile der Lizenz auskosten sondern muss auch mit den Nachteilen leben.

 

[ao]

Alleine mit harten Fakten ist denen beizukommen. Und diesbzgl. dürfte sich Harald Welte (der auch schon für diese Sache bzw. hier erfolgreich aktiv war) in der Tat gut auskennen und ggf. auch Kontakte zu Kernel-Entwicklern haben.

 

[abraXxl]

Hi !

Nach Herrn Torvalds sind Treiber die explizit fuer Linux entwickeltwurden derived work.
Das AVM die UBIK2/UR8 Parts scheinbar vornehmlich unter Linux einsetzt, würde ich schon sagen: "Der Treiber ist zuerst fuer Linux geschrieben worden".

Dazu kommt, dass der Capi-HW-Treiber das struct skbuff nutzt (Das ist das was Iptables und mehr auf einigen Boxen mit falschen Kernel-Konfig explodieren lässt). Und genau dieser Teil ist definitiv unter GPL. Also ist alles was daruf aufsetzt IMO derived work. Also auch kdsldmod, capi_codecs, isdn_fbox_*, tiatm. Nun gut der Treiber fuer tiatm ist mittlerweile verfügbar, aber nicht frei im Sinne der GPL.

just my 2cents

 

[gfuer]

Ob die Treiber eine Bearbeitung/Umgestaltung ("derived work") des Kernels darstellen oder nicht, hat m.E. weder Hr. Torwalds noch die GPL zu bestimmern, sondern das ist Sache des jeweiligen nationalen Urheberrechts und muss im Zweifelsfall von einem Gericht entschieden werden (und wenn in mehreren Staaten geklagt wird, dann kann die Enscheidung des Gerichts natürlich in jedem Staat anders ausfallen).

Erst wenn ein Gericht entschieden hat, dass es sich tatsächlich um eine Bearbeitung/Umgestaltung des Kernels handelt, kommt die GPL ins Spiel, denn erst dann wird eine Erlaubnis der Urheber des Kernels für die Verbreitung der Treiber benötigt (die GPL stellt so eine Erlaubnis dar, diese ist allerdings an bestimmte Bedingungen gebunden). Sollte das Gericht entscheiden, dass die Treiber keine Bearbeitung/Umgestaltung des Kernels darstellen, sondern komplett selbständige Werke sind, dann können die Treiber binär verbreitet werden, ohne eine Erlaubnis von den Urhebern des Kernels zu benötigen.

Das deutsche Urheberrecht schützt bei Computerprogrammen eigentlich nur das Programm an sich (in jeglicher Ausdrucksform wie Quellcode, Binärcode). Allerdings sind "Ideen und Grundsätze, die einem Element eines Computerprogramms zugrunde liegen, einschließlich der den Schnittstellen zugrundeliegenden Ideen und Grundsätze, nicht geschützt." (§ 69a (2))

Ob daher die ledigliche Benutzung einer Schnittstellendeklaration wie struct skbuf etc. ausreicht, um eine Bearbeitung/Umgestaltung zu begründen ist m.E fraglich. Das würde ich durhaus noch als "freie Benutzung" nach §24 auslegen ("Ein selbständiges Werk, das in freier Benutzung des Werkes eines anderen geschaffen worden ist, darf ohne Zustimmung des Urhebers des benutzten Werkes veröffentlicht und verwertet werden.")

Ein potentieller Ansatzpunkt könnten die vielen Inline-Funktionen in den Kernel-Header-Dateien sein. Im Gegensatz zu reinen Deklarationen, die zwar der Compiler bei der Übersetzung einliest, die aber letzendlich doch nicht im erzeugten Binärcode landen (-> freie Benutzung?), ist es unvermeidbar, dass im erzeugten Binärmodul die vom Treiber benutzen Inline-Funktion aus den Kernel-Header-Dateien in compilierter, binärer Form enthalten sind, womit man eventuell ein "derived work" der Kernel-Header-Dateien begründen könnte.

Aber wie schon gesagt, letztendlich muss das wohl ein Gericht im Einzelfall entscheiden.

Disclaimer: Ich bin kein Jurist, und dies stellt nur meine Meinung und meine persönliche Interpretation des UrhG dar.

 

[MReimer]

Ob die Treiber eine Bearbeitung/Umgestaltung ("derived work") des Kernels darstellen oder nicht, hat m.E. weder Hr. Torwalds noch die GPL zu bestimmern, sondern das ist Sache des jeweiligen nationalen Urheberrechts und muss im Zweifelsfall von einem Gericht entschieden werden (und wenn in mehreren Staaten geklagt wird, dann kann die Enscheidung des Gerichts natürlich in jedem Staat anders ausfallen).

Das die GPL/LGPL auch in Deutschland gültig sind wurde schon mehrfach bestätigt. Die GPL erlaubt aber nicht das Linken mit Code der später selbst nicht unter GPL steht. Dafür wurde die LGPL geschaffen, die dies erlaubt. Demnach liegt wohl ein Lizenzverstoß vor.

Ich hab das ganze mal an gpl-violations.org gemailt. Wurde auch aufgenommen und ich hab eine Ticket-Nummer erhalten. Wenn jemand anderes auch schon bei gpl-violations.org angemailt hat, dann bitte PN mit der Ticket-Nummer. Ich würde gerne vergleichen ob die das alles unter einem Ticket sammeln. Was daraus wird: Keine Ahnung. Das Ticket steht jetzt schon über zwei Wochen und ich bekomme keine weiteren Rückmeldungen. In, sagen wir zwei weiteren Wochen, frage ich dann mal in der Mailingliste nach.

Man hätte nicht diesen illegalen Weg gehen müssen. Kernel-Module unter GPL aber Daemons als Closed Source wäre legal gewesen. Letzten "Geheimen Code" dann einfach in die Daemons auslagern.

 

[McNetic]

Das Einzige, was bezüglich der GPL in Deutschland relativ sicher ist, ist daß sie als gültige Lizenzvereinbarung gilt. Das bedeutet aber weder, daß alle Punkte der GPL vor dem deutschen Recht und der Gerichtsbarkeit bestand haben (es kann auch Klauseln geben, die gegen das Recht verstoßen und somit ungültig sind), noch welche exakte Bedeutung die einzelnen Punkte der GPL haben - das ist eben letztendlich von der Rechtsprechung abhängig.

Es könnte also theoretisch sein, daß jegliches Kernel-Modul oder evtl. nur Kernel-Module, die inline-Funktionen verwenden, als 'derived work' anzusehen sind, genauso gut könnte es aber sein, daß die Gerichte sich dieser Auffassung nicht anschliessen. Insbesondere im Hinblick auf das technische Verständnis, was mancher Richter an den Tag legt, dürfte der Ausgang eines solchen Verfahrens wohl mehr als zweifelhaft sein.

Mir persönlich sind zwar mehrere Verfahren auf Basis der GPL in Deutschland bekannt, allerdings wurden die a) soweit ich weiss immer außergerichtlich beigelegt, und b) ging es dabei imho niemals um die Thematik 'binary kernel modules', sondern immer darum, daß die Kernelquellen/Busyboxquellen selbst nicht entsprechend der GPL mit angeboten wurden.