|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
|
|
|
|
Ich habe es nicht in der GPL nachgelesen, aber wenn ich mich recht erinnere, geht es doch um den Passus, dass Programme, die an ein GPL-Programm gelinkt werden müssen, damit sie lauffähig sind, auch GPL (oder sonstwie lizenzkompatibel) sein müssen, sonst wäre es nicht erlaubt.
Das dürfen die natürlich so bestimmen und ein Hersteller darf auch nicht ein proprietäres Kernelmodul mit einem Linux-Kernel direkt lauffähig vertreiben.
Aber, und da hat Linus völlig recht, wenn der Benutzer diese beiden Teile zusammenfügt, ist das völlig in Ordnung. Der Benutzer darf das, der Programmierer nicht.
Ich bin etwas perplex, dass es nicht mehr Stimmen gibt, die der FSF vorwerfen, in diesen Fällen ein Verhalten an den Tag zu legen, dass verdammt dem der proprietären Softwarehersteller ähnelt.
Wegen der GPL, beziehungsweise ihrer Auslegung durch den heiligen Sankt Ignucius, müssen unterdessen für gewisse Module diesselben Klimmzüge gemacht werden, wie wenn ich auf meinem Rechner proprietäre Video-Codecs benutzen will.
Es mag ja sein, dass die FSF für die Freiheit kämpft. Aber ich bin mir nicht so sicher, für wessen Freiheit.
|
|
|
|
|
|
|
|
|
|
|
|
|
Linus Torvalds zum "Linking = derived work"-Mythos: http://article.gmane.org/gmane.linux.kernel/476807
Ist es nicht eine wahre Freude den pointierten Äusserungen von LT zu folgen...!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Genau genommen steht in der GPL nichts Konkretes. In der Regel werden zwei Argumente angebracht, die beide umstritten sind:
- Um die Module zu kompilieren, benötigt man die Kernel Header, welche als Teil des Kernels unter GPL stehen. Somit ist das Modul von den Headern abgeleitet, und muss ebenfalls unter GPL stehen.
- Das Modul ist keine eigenständige Software, sondern benötigt den Kernel zur Funktion. Somit ist es vom Kernel abgeleitet.
Gegenargument zu 1: Die Header sind keine Software, sondern lediglich eine technische Beschreibung. Als solche unterstehen sie nicht dem Urheberrecht, auch wenn sie Teil eines urheberrechtlich geschützten Werkes sind, und folglich kann auch nichts von ihnen im urheberrechtlichen Sinn abgeleitet sein.
Gegenargument zu 2: Das Modul ist sehr wohl eine eigenständige Software, die auch auf andere Betriebssysteme portiert werden kann. Nur die Schnittstelle zum Kernel ist spezifisch. Allgemein wird aber davon ausgegangen, dass eine Schnittstelle per se kein abgeleitetes Werk darstellt.
Ich halte die Gegenargumente für durchaus stichhaltig. Aber da es nie einen Gerichtsprozess darüber gab, gibt es auch kein entgültiges Urteil.
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 19. December 2006, 15:30 MEW (#5)
|
|
|
|
|
Das ist doch Lötzinn. Gerade bei C++ kann der eigentliche Hirnschmalz komplett in den Header-Dateien stecken. Ich sag nur "Templates". Ähnliches ist aber auch bei C möglich. Der Compiler kann nur das optimieren, was er auch sieht, daher kann es durchaus sinnvoll sein, Code komplett in Header-Dateien zu packen, d.h. für "static inline" Funktionen und Macros. Zudem steckt eine Menge Hirnschmalz in einem guten Interface. Die Implementierung desselben ist dann oft reine Routine. Im Übrigen scheint mir das Gefasel der GPL bezüglich "Linken" doch sehr auf C zugeschnitten, von gewissen Implementierungsdetails auszugehen und trotzdem eher schwammig bleibt. Ansonsten gäbe es jawohl auch keine unterschiedlichen Ansichten dazu, was konform ist und was nicht.
|
|
|
|
|
|
|
|
|
|
|
|
|
daher kann es durchaus sinnvoll sein, Code komplett in Header-Dateien zu packen, d.h. für "static inline" Funktionen und Macros.
Durchaus, aber auf die Kernel Header trifft das meines Wissens nicht zu. Selbst wenn, kann man einfach eine eigene Header Datei schreiben, die nur die "external" Deklarationen enthält. Bei dynamischen Libraries hat man sogar die Möglichkeit, komplett darauf zu verzichten, und nur mit dlopen() zu arbeiten.
Zudem steckt eine Menge Hirnschmalz in einem guten Interface.
Mag sein, aber das macht es nicht zu einer Software. Nur Software ist durch das Urheberrecht geschützt.
Im Übrigen scheint mir das Gefasel der GPL bezüglich "Linken" doch sehr auf C zugeschnitten
Kein Einwand.
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 19. December 2006, 19:44 MEW (#9)
|
|
|
|
|
>> Zudem steckt eine Menge Hirnschmalz in einem
>> guten Interface.
> Mag sein, aber das macht es nicht zu einer
> Software.
Bitte? Meine SupaDupahHaiLävel-Bibliothek mit polymorphen Macros und schlagmichtot ist also Public-Domain, "int main(void) { use_library(); return 0; }" aber nicht? Meines Wissens besteht Boost hauptsächlich aus Templates bzw. Header-Dateien.
Das kann jawohl nicht ganz sein, da es sich hierbei lediglich um technische Details handelt. In den USA gibt es zudem Software-Patente und ein Interface sollte eigentlich eine hervorragende Vorlage für ein solches darstellen. Wenn dies nun nicht schützenswert sein soll, dann beißt sich die Katze ja nun selbst in den Schwanz. In Europa gelten da sicherlich andere Regeln, aber die GPL ist nunmal deutlich US-lastig.
> Nur Software ist durch das Urheberrecht
> geschützt.
Ich gehe mal schwer davon aus, dass das jetzt nicht ganz wortwörtlich gemeint war, nicht wahr? Es ist völlig schnurz was ein schriftliches Werk darstellt, sobald eine gewisse Schöpfungshöhe gegeben ist, greift zumindest in Deutschland das Urheberrecht vollautomatisch und zwar unwiderruflich.
|
|
|
|
|
|
|
|
|
|
|
|
|
Schau mal weiter unten. Deine Makros sind
nicht Interface-Definition, sondern Code,
auch wenn die Datei *.h statt *.c heißt.
Schöpfungshöhe ist hingegen nur eine der
notwendigen Bedingungen zum urheberrechtli-
chen Schutz und keinesfalls hinreichend;
das Werk muß auch in einer schützenswerten
Kategorie sein.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
|
|
Bitte? Meine SupaDupahHaiLävel-Bibliothek mit polymorphen Macros und schlagmichtot ist also Public-Domain,
Ein Interface hat Definitionsgemäss keine Funktionalität. Sprich: Es tut nichts, sondern sagt aus, wie man fragen muss, damit etwas getan wird. Im Umkehrschluss: Eine Header Datei mit eigenständiger Funktionalität ist kein reines Interface, sondern hat Softwarecharakter.
Ich gehe mal schwer davon aus, dass das jetzt nicht ganz wortwörtlich gemeint war, nicht wahr? Es ist völlig schnurz was ein schriftliches Werk darstellt, sobald eine gewisse Schöpfungshöhe gegeben ist, greift zumindest in Deutschland das Urheberrecht vollautomatisch und zwar unwiderruflich.
Das ist in der Schweiz anders. In der Schweiz muss ein Werk eine "geistige Schöpfungen der Literatur und Kunst" oder eben Software sein, damit es unter das Urheberrecht fällt. Allerdings wurde in Deutschland mal, wenn ich mich recht entsinne, den reinen Interfaces die nötige Schöpfungshöhe abgesprochen.
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Das ist in der Schweiz anders. In der Schweiz muss ein Werk eine "geistige Schöpfungen der Literatur und Kunst" oder eben Software sein, damit es unter das Urheberrecht fällt.
Wieso werden denn auch Computerprogramme explizit im deutschen UrhG, genau wie auch im Schweizer URG, erwähnt?
Computerprogramme sind eben nicht geistige Schöpfungen der Literatur und Kunst, die individuellen Charakter haben(URG) oder Werke der Literatur, Wissenschaft und Kunst(UrhG) - so sieht es zumindestens der Gesetzgeber - deshalb mussten sie explizit in die Gesetze aufgenommen werden. Witzigerweise betrachtet das deutsche Gesetz Computerprogramme als Sprachwerke, während das Schweizer Gesetz sie nicht mit den anderen Werken in einen Topf werfen will und lapidar in einem Unterabschnitt erwähnen (Als Werke gelten auch Computerprogramme.)
Allerdings wurde in Deutschland mal, wenn ich mich recht entsinne, den reinen Interfaces die nötige Schöpfungshöhe abgesprochen.
Das steht so schon fast im deutschen Gesetz.
UrhG Paragraph 69a 3: … Ideen und Grundsätze, die einem Element eines Computerprogramms zugrunde liegen, einschließlich der den Schnittstellen zugrundeliegenden Ideen und Grundsätze, sind nicht geschützt.
Ein reines Interface ist nun aber nichts anderes als ein Grundsatz, nämlich wie man auf gewisse Teile eines Programmes standardisiert zugreifen kann.
|
|
|
|
|
|
|
|
|
|
|
|
|
Noch ein weiteres Gegenargument ist ja wohl, dass der User das Kernel-Interface ja selber kompiliert und so mit dem Kernel zusammensetzt
Und der User darf ja eigentlich alles, auch seinen proprietären Code in den Kernel direkt tun, solange er es nicht weiter gibt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>Noch ein weiteres Gegenargument ist ja wohl, dass der User das
>Kernel-Interface ja selber kompiliert und so mit dem Kernel
>zusammensetzt
Fehlinformation (FUD-Streuung sogar). Zusammen-
gesetzt wird erst beim insmod. Ein Derivat wird
es jedoch auch, wenn es Kernelcode (z.B. die be-
reits erwähnten Makros) verwendet.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
|
|
http://groups.google.com/group/comp.lang.python/msg/29c7588fbecd8289
Wenn ich Werk A (hier: GPL Kernel) und Werk B (hier, nehmen wir
ein konkretes Beispiel, einen binären Graphikkartentreiber) habe,
wo Werk A nicht von Werk B abstammt und umgekehrt (die Treiber,
die ich im Sinn habe, sind nicht für Linux geschrieben worden,
sondern nur später so angepaßt, daß sie _auch_ dort tun, aber
ohne Nutzung von Kernelcode), und diese zusammenlinke - zu einem
neuen Werk verbinde - darf ich dieses nur *verbreiten*, wenn
das Gesamtwerk GPL ist. So weit, so gut. Aber wenn ich es nicht
*verbreite*, sondern nur *nutze*, gilt diese Regel nicht, und
das weiß die FSF nur zu gut, weswegen sie versuchen, den Leuten
vorzumachen, daß es "natürlich immer" verbreitet wird.
Ein Kernelmodul (.o, .ko, was auch immer) wird allerdings erst
dann mit dem Kernel verbunden, wenn man insmod (modprobe, etc.)
aufruft. [Wir haben ja oben bereits gesagt, daß es keinen Ker-
nelcode verwendet, also wird das .o/.ko unabhängig vom Kernel
erzeugt.]
P2501 schrieb:
>Strikte nach GPL gelten Kernelmodule als vom Kernel abgeleitete Werke.
Das ist falsch. Das gilt nur, wenn sie tatsächlich vom Ker-
nelcode abgeleitet sind, also nicht für zum Beispiel die
obengenannten Graphikkartentreiber, oder die durch einen
ndiswrapper geladenen ODI/NDIS Netzwerkkartentreiber für NT.
bhaak schrieb:
>Ich habe es nicht in der GPL nachgelesen, aber wenn ich mich recht
>erinnere, geht es doch um den Passus, dass Programme, die an ein
>GPL-Programm gelinkt werden müssen, damit sie lauffähig sind, auch GPL
>(oder sonstwie lizenzkompatibel) sein müssen
Das ist eben der FUD, den die FSF streut. In der GPL steht das
nicht. Was hingegen in der GPLv2 steht, ist folgendes:
|Activities other than copying, distribution and modification are not
|covered by this License; they are outside its scope. The act of
|running the Program is not restricted, and the output from the Program
|is covered only if its contents constitute a work based on the
|Program (independent of having been made by running the Program).
(Quelle: GNU GPL Version 2, Sektion 0)
Selbst nicht lizenzkompatible Software (zum Beispiel die unter der
GPL stehende GNU libreadline, und die bekanntermaßen problematische
libcrypto/libssl (OpenSSL)) kann zusammengelinkt werden (zum Bei-
spiel in einem Programm, welches beide benutzt), solange das Ergeb-
nis des Zusammenlinkens nicht verbreitet wird. Hierzu sagt GPLv2,
Sektion 2, im übrigen folgendes:
|In addition, mere aggregation of another work not based on the Program
|with the Program (or with a work based on the Program) on a volume of
|a storage or distribution medium does not bring the other work under
|the scope of this License.
Sprich: sogar wenn ich als OS-Entwickler eine CD herausgebe, wo
OpenSSL drauf ist, und wo etwas drauf ist, was gegen GNU libreadline
linkt (also "a work based on the Program") _und_ gegen OpenSSL
dynamisch(!) linkt, geht's. Hierbei ist der Terminus "mere aggre-
gation" wichtig - sie dürfen nicht miteinander verbunden sein.
Die FSF-Hardliner werden jetzt sagen: "Ja aber es ist doch egal,
ob Du statisch oder dynamisch linkst, das ist doch nur eine tech-
nische Banalität". Ich hingegen sage Euch: Es ist ebenso egal, ob
Du dynamisch linkst (mit ld.so) oder dlopen(3) und Co. verwendest;
ich hoffe, hier könnt ihr mir folgen. Was nun aber, wenn ich eine
Bibliothek habe, die mit dlopen() geladen werden kann und genau
die gleiche ABI wie z.B. GNU libreadline exportiert? (Zufällig
gibt es so eine, das ist nämlich libedit, die bei den BSDs auch
mit dabei ist und _extra_ etwas libreadline-Kompatibilität hat.)
Deshalb kann nicht gelten, daß wenn ich libreadline dlopen()e,
daß es dann "automatisch GPLd wird". Und wegen der oben beschrie-
benen legalen Äquivalenz von dlopen() und dynamischen Linkens
kann das dann auch nicht gelten, wenn ich gegen libreadline
linke. (Statisches Linken hingegen ist *wohl* etwas anderes,
aber _nur_, weil beim statischen Linken ein neues Werk erzeugt
wird und dieses eben auch verbreitet - was bei dynamischem Lin-
ken erst im Arbeitsspeicher passiert. Also keine Coredumps rum-
mailen, wenn ihr nicht wollt, daß Euer Werk GPLt wird oder ihr
einer Lizenzverletzung schuldig sein wollt.)
>Aber, und da hat Linus völlig recht, wenn der Benutzer diese beiden
>Teile zusammenfügt, ist das völlig in Ordnung. Der Benutzer darf das,
>der Programmierer nicht.
Exakt dies habe ich auch geschrieben, als die Diskussion um
die Koroaa(sp?) Live-CD aufkam. Die Verbindung von Kernel und
Kernelmodul geschieht erst im Arbeitsspeicher des Systems, wo
sie gebootet wurde. Leider haben sie doch aufgehört.
Eigentlich paradox, daß es eines nicht nur GPL-Gegners, sondern
auch BLOB-Gegners (die BSDs halten nicht so viel von Binärmüll
im Kernel, siehe Theo de Raadt) bedarf, um die GNU- und Linux-
Gemeinde über solche Lizenzdetails aufzuklären. Naja, ich habe,
obschon ich eigentlich Programmierer bin, mich halt viel mit
Lizensierung beschäftigt, und entsprechend auch die GPL (nicht
nur im Sinne von "kenne Deinen Feind", sondern auch, weil wir
durchaus GNU Binutils und GCC verwenden).
>Ich bin etwas perplex, dass es nicht mehr Stimmen gibt, die der FSF
>vorwerfen, in diesen Fällen ein Verhalten an den Tag zu legen, dass
>verdammt dem der proprietären Softwarehersteller ähnelt.
Naja, die BSDler wollen halt auch keine BLOBs und haben mit
ihrem eigenen Kram genug zu tun, und auf Patrick Maupin (den
Autor des eingangs erwähnten Usenetpostings) hört wohl auch
kaum jemand - wer ist das überhaupt?
Aber es gibt _noch_ jemanden, der dazu Stellung bezogen hat:
* http://www.rosenlaw.com/html/GL18.pdf
* http://www.rosenlaw.com/html/GPL.PDF
Ganz richtig, der Rechtsprofessor Lawrence Rosen unterstützt
den oben dargelegten Standpunkt.
flyingfischer weist auf eine Mail von Linus Torvalds hin:
>>[...] The kernel COPYING
>>makes it clear that user space is not a derived work of the kernel
Das ist nur eine Klarstellung, denn eine reine Schnittstellen-
beschreibung wie die syscall-API es ist unterliegt keinem ur-
heberrechtlichen Schutz. (Deswegen gilt auch "headers (*.h files
are not copyrightable, unless they contain non-trivial amounts
of actual code, such as inline functions, macros, etc." - frei
aus dem Gedächtnis zitiert, dürfte vor einigen Jahren auf der
LKML gepostet worden sein, ich lese da schon seit 2.4.8 nicht
mehr mit, sorry.)
>>There really wassn't much need for the LGPL, I think.
Deshalb verwenden sehr viele Projekte nun auch die GPL mit
Library Exception (z.B. GNU classpath).
>>> Some claim that, in the case of static linking, since there part of
>>> the library copied to the binary, it is definitely a case of derived
>>> work.
>>
>>No, the sane way to think about it is that linking just creates an
>>"aggregate" work.
Hier stimme ich nicht ganz überein - sie werden miteinander
verbunden und es gibt keine Möglichkeit, z.B. ein statisch
gegen GNU libreadline gelinktes Programm stattdessen die
Funktionen von libedit nutzen zu lassen. Allerdings verlasse
ich mich hier nicht drauf, sondern würde einfach, wenn das
akut wäre, einen Anwalt zum Thema "mere aggregation" (s.o.)
befragen.
Aber ich mag die Analogie zum Buchbinden.
>>So to get back to the example of glibc: if a program _could_ have been
>>linked against some other library, then that pretty clearly shows that
>>it's really independent of glibc, and the linking is "mere aggregation"
>>exactly the same way "mkisofs" is generally considered "mere aggregation".
Ah, ja, hätte ich fast vergessen. Den Fall "Nicht-GPL Werk
linkt (direkt oder indirekt) mit GPL-Werk" hätten wir ja
für GNU libreadline abgehandelt: wenn ich dlopen()e, kann
ich libedit unterschieben und alles tut noch. Das Gleiche
gilt entsprechnd für dynamisches Linken, aber das lassen
wir hier mal außen vor. Ich bitte den geneigten Leser,
sich im folgenden auf den leichter nachzuvollziehenden
dlopen()-Fall zu beschränken:
Wenn ich in meinem Nicht-GPL-Programm ein dlopen() von
(GPL) libreadline mache, kann ich (BSD) libedit unter-
schieben. Was ist, wenn ich eine (GPL) libfoobar dlopen()e,
zu der es (noch) kein Nicht-GPL-Äquivalent gibt? Was,
wenn jemand (ich?) eine libbsdfoobar schreibe, ändert
sich dann plötzlich die Lizenz von dem Programm, das
libfoobar dlopen()t? Sicherlich nicht.
Somit ist die Argumentation "ich nutze dlopen(), um
über eine (wie auch immer geartete) ABI - eine Schnitt-
stelle - auf eine Bibliothek zuzugreifen" und "die
Bibliothek ist zwar GPL, aber ich kombiniere sie erst
im Arbeitsspeicher mit meinem Werk" unabhängig davon,
ob es zu der Bibliothek auch eine Nicht-GPL-Implemen-
tation gibt oder nicht.
Die GPL erwähnt in Sektion 3:
| [...] However, as a
|special exception, the source code distributed need not include
|anything that is normally distributed (in either source or binary
|form) with the major components (compiler, kernel, and so on) of the
|operating system on which the executable runs, unless that component
|itself accompanies the executable.
Diese Ausnahme ist somit eigentlich überflüssig. Vielleicht
hat Eben Moglen sich dabei was gedacht - vielleicht ist das
ein Teil des FUDs, den die FSF absichtlich streut, um von
der Problematik "was ist, wenn ich kombiniere, aber nicht
distribuïere" abzulenken. "accompanies the executable" KANN
sich ja nicht auf "mere aggregation" beziehen, denn die wurde
ja in Sektion 0 bereits ausgeschlossen - also kann das eigent-
lich nur statisches Linken meinen.
Wie immer, IANAL, TINLA.
P2501 erwiderte:
>Genau genommen steht in der GPL nichts Konkretes.
Doch, siehe oben. Nur ist die Frage, wie RMS (und Eben Moglen)
es gerne hätte, wie jemand anders es auslegt, und besonders,
wie der Richter das auslegt.
>Gegenargument zu 1: Die Header sind keine Software, sondern lediglich
>eine technische Beschreibung. Als solche unterstehen sie nicht dem
>Urheberrecht, auch wenn sie Teil eines urheberrechtlich geschützten
>Werkes sind, und folglich kann auch nichts von ihnen im
>urheberrechtlichen Sinn abgeleitet sein.
Genau was ich weiter oben erwähnte. Die Linuxer sind allerdings
nicht doof - dieser Punkt kam wie gesagt vor Jahren schon mal
vor, und daraufhin haben sie festgestellt "ah ja, wir haben da
ja ein paar Header, die Inline-Funktionen mitbringen... machen
wir dadraus doch einen Trend". (Daß OpenBSD durch das *Entfer-
nen* von 'inline' im Kernel einen GeschwindigkeitsVORTEIL er-
halten hat, da nun mehr Code in den Instruktionscache der CPU
paßt, sollte man denen vielleicht auch mal stecken.)
Man kann sich jedoch seine eigenen Header aus der mitgeliefer-
ten Schnittstellenbeschreibung basteln und diese dann zum Kom-
pilieren des proprietären Kernelmoduls verwenden. Ich denke,
dies ist auch, was die Hersteller tun. (Viel Spaß dann beim
Mergen der Änderungen von Kernelversion zu Kernelversion.)
Hier ist ironischerweise sogar copy'n'paste von den Kernel-
headern erlaubt, solange es um reine Interfacedefinitionen
(struct foo; extern void bar(void); etc.) geht.
>Gegenargument zu 2: Das Modul ist sehr wohl eine eigenständige
>Software, die auch auf andere Betriebssysteme portiert werden kann. Nur
>die Schnittstelle zum Kernel ist spezifisch.
Stimmt. Und wie ndiswrapper (Linux und FreeBSD), oder die
Binärkompatibilität der BSDs zu BSD/OS, FreeBSD, Linux,
SCO, IRIX (nur in NetBSD), iBCS2 (übrigens auch in Linux),
und einem Haufen anderer Betriebssysteme zeigt, ist diese
Schnittstelle nicht urheberrechtlich relevant. (Wird auch
durch Linus' COPYING-Erweiterung unterstrichen.) Eine Ab-
bildung der Schnittstellen unterläuft zwar den "Spirit"
der GPL, aber ist zumindest nicht illegal.
Ein anonymer Feigling fügte hinzu:
>Das ist doch Lötzinn. Gerade bei C++ kann der eigentliche Hirnschmalz
>komplett in den Header-Dateien stecken. Ich sag nur "Templates".
Das hat dann aber nichts damit zu tun, daß das in den
.h-Dateien steht, sondern daß da tatsächlich urheber-
rechtlich relevantes Material, das die nötige Schöp-
fungshöhe erreicht, drinsteht, und daß es keine reine
Schnittstellenbeschreibung mehr ist.
Deswegen gibt es die GPL mit library exception clause.
>Zudem steckt eine Menge Hirnschmalz in einem
>guten Interface.
Das stimmt zwar, aber erstens nicht in dem von Linux ;)
(frag Tonnerre Lombard, wenn Du's nicht glaubst), und
zweitens ist es nunmal so, daß Schnittstellenbeschrei-
bungen vom urheberrechtlichen Schutz ausgenommen sind,
hierbei hat sich der Gesetzgeber sicher auch etwas ge-
dacht. Stichwort Interoperabilität zum Beispiel. Und
wie viele Linuxer sind froh über die "analoge Lücke",
mit der sich DRM bei vielen Playern noch umgehen läßt,
weswegen es jetzt digitale verschlüsselte und DMCA-
geschützte Steckverbindungen zwischen Player und An-
zeigegerät gibt... weswegen man überhaupt erst den
DMCA erfinden mußte.
PS: Ich bitte doch sehr, die in diesem Posting darge-
legten Argumente als weitere Diskussionsbasis zu ver-
wenden und gerne auch an die beteiligten Personen in
den GNU-, FSF- und Linux-Lagern weiterzuleiten. Über
eine Nennung meines Namens dabei würde ich mich schon
freuen. Und ich glaube auch nicht an "dieses Posting
steht unter Lizenz X". Wenn jemand eine braucht...
soller halt schreien, ich hab 'ne passende. "Go down
to the copycenter and make as many copies as you want",
wie Marshall Kirk McKusick es mal ausdrückte. Oder,
in legalesischer Form: http://mirbsd.de/MirOS-Licence
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Noch ein netter:
From: Theodore Tso <tytso <at> mit.edu>
>It's not a question of "honoring the license"; it's a matter of what
>is the reach of the license, as it relates to derivitive works. It's
>a complicated subject, and very dependent on the local law; certainly
>in the U.S., when I asked a Law Professor from the MIT Sloan School of
>Management, who specialized in IP issues about the FSF theory of GPL
>contamination by dynamic linking, after I explained all the details of
>how dynamic linking work, she told me that it would be "laughed out of
>the courtroom".
Und nochmal Linus Torvalds:
>If a module owner can argue successfully in a court of law that a binary
>driver isn't a derived work, then the GPL simply DOES NOT COVER IT!
und
>And no, including one header file in order to compile against something
>does not automatically make something a "derived work". It may, or it may
>not.
Was mir auch besonders gefällt ist der Patch von ./kernel/module.c
in diesem Diff (gesehen in einer Mail von Martin J. Bligh):
>ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch
Ich würde sogar noch weiter gehen, wenn ich ein Linux distribuïeren
würde, und diese ganze Taint-Scheiße raushauen. Laß dem Nutzer die
Freiheit zu laden, was er will, und nerv ihn nicht. "Shut up and
hack." (Und die GPL erlaubt mir ironischerweise, solche Änderungen
zu machen.)
Ich bin ja sonst kein Ubuntu-Fan, wie XTaran Euch sicher
bezeugen kann, aber Ben Collins hat nen Punkt:
>Let the licenses and lawyers fight to protect the code. The code doesn't
>need to do that itself. It's got better things to do.
Zum Grinsen hat mich gebracht, wie er drüber rantet, daß
Lizenzen den Code schützen sollen, aber nicht der Code dafür
sorgen soll, daß die Lizenz ihn prüft. Oder wer will schon
in Zukunft beim Booten von GNU/Linux erst die Source-CD ein-
legen müssen, bevor der Kernel den Computer freigibt?
Wo ich hingegen nur drüber lachen kann ist Linus Torvalds,
wo er EXPORT_SYMBOL_GPL beschreibt:
> [...] we give clear hints to people that "we
>think this is such an internal Linux thing that you simply cannot use this
>without being considered a derived work".
Ah ja. Und was, wenn ich einfach ein proprietäres Modul schreibe,
das nicht "für Linux", sondern "für Linux x.y.z" gedacht ist, und
mir meine eigene .h für diese *SCHNITTSTELLE* bastle?
Ich würde eh nicht für Linux entwickeln wollen. Deren API ist ein
Witz und ändert sich viel zu oft. Zu viel #ifdef schon allein zu
der Zeit, wo ich noch aktiv dabei war (2.0.33-38).
Und schließlich nochmal Greg K-H:
>GPL covers distribution, not usage, no matter how much the people
>working on v3 want to change that :)
Point taken. ;)
Dann doch lieber wie Eric W. Biederman:
>Kernel modules without source, or that don't have a GPL compatible
>license are inconsiderate and rude.
>
>Please don't be rude.
Und Rik van Riel:
>Maybe we should just educate users and teach them to
>avoid crazy unsupportable configurations and simply buy
>the hardware that has open drivers available?
So macht's auch OpenBSD. (Nur daß sie auch versuchen, die
Hersteller zu erziehen. Und ironischerweise besseren WLAN-
Support als Linux haben... ganz ohne BLOBs - von Firmware,
die ja nicht im OS selber läuft, und somit unproblematisch
ist, solange man sie unmodifiziert weiterverbreiten darf,
was allerdings Intel nicht schafft, mal abgesehen.)
Linus Torvalds:
>We're "open source", and we're not a religion.
Das sollte mal jemand RMS sagen...
Ty Ts'o zum "ich schreib mir meine eigenen .h Dateien":
> [...] recall that there have been
>those who have claimed that Linux is a derived work of Unix because we
>used things like #define's for errno codes and structure definitions
>of ELF binaries. You really sure you want to go there?
So, jetzt hab ich keinen Bock mehr, weiterzulesen,
hab schließlich noch mehr zu tun. War aber wieder
mal lustig zu sehen , was die Leute von "the other
OS" so tun.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, hab ich dann auch gelesen. Hab die ersten
4 Kommentare hier einfach nach dem Artikel
sequentiell abgearbeitet und meinen Reply
in nem anderen Screen geschrieben.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
