Wenn ich mich nicht irre geht es dabei mehr - oder neben anderem - um die Möglichkeit Bibliotheken mit Programmen zu verlinken die nicht unter GPL stehen, was ja nicht unbedingt closed-source heißen muss. Ich kann mich aber auch irren, ganz allgemein gesagtDie LGPL unterstützt doch aber auch nicht-freie Software. Das ist der einzige Punkt, an dem mir RMS inkosequent erscheint, evtl hab ich aber auch etwas nicht richtig verstanden.
Zum Thema LGPL interresiert dich vielleicht dieser Text: http://www.gnu.org/licenses/why-not-lgpl.htmlse8i hat geschrieben: Die LGPL unterstützt doch aber auch nicht-freie Software. Das ist der einzige Punkt, an dem mir RMS inkosequent erscheint, evtl hab ich aber auch etwas nicht richtig verstanden.
genau darum geht es bei der LGPL.DavidJ hat geschrieben: Wenn ich mich nicht irre geht es dabei mehr - oder neben anderem - um die Möglichkeit Bibliotheken mit Programmen zu verlinken die nicht unter GPL stehen, was ja nicht unbedingt closed-source heißen muss. Ich kann mich aber auch irren, ganz allgemein gesagt
Soweit ich weiß, hat Stallman die LGPL mal als den "größten Fehler seines Lebens" bezeichnet.se8i hat geschrieben: Die LGPL unterstützt doch aber auch nicht-freie Software. Das ist der einzige Punkt, an dem mir RMS inkosequent erscheint, evtl hab ich aber auch etwas nicht richtig verstanden.
Ja, genau das habe ich auch gehört. Was ist an der GNU FDL aus Debian-Sicht denn so unfrei? Ich selbst stelle eigentlich sämtliche von mir verfasste Dokumente unter die GNU FDL und würde gerne wissen, was es aus Debianprojektsicht daran ausszusetzen gibt.BeS hat geschrieben:Deswegen sollen z.B. GFDL lizensierte Dokumente nach der sarge release nach non-free verschoben werden.
So wie es momentan im Debian-Gesellschaftsvertrag ausgedrückt ist, finde ich es eigentlich ganz sinnvoll:BeS hat geschrieben:Hallo,
Aber dann sollte man so ehrlich zu sich und den usern sein und auch in den SC ganz klar schreiben das man ein GNU/Linux System mit freier und nicht-freier Software anbietet aber die beiden Teile strikt trennt so dass jeder die Wahl zwischen free und non-free hat.Hackmeck hat geschrieben: Stimmt schon. Aber es ist leider IMHO immer noch so, dass man bei einem Desktop-System dank Dingen wie JAVA und Shockwave einfach nicht ganz ohne non-free-Software auskommt. Und ob jemand wirklich nur freie Software einsetzt, sollte er immer noch selbst entscheiden - das Debian Projekt sollte hier IMHO nich jenen Steine in den Weg legen, die zwar größtenteils freie Software einsetzen möchten aber das eine oder andere aus non-free brauchen.
Quelle:http://www.debian.de/social_contract.de.htmlWir versprechen, dass die Debian-GNU/Linux-Distribution auch weiterhin vollständig aus Freier Software bestehen wird. Da es viele verschiedene Auslegungen des Begriffs »Freie Software« gibt, haben wir weiter unten die Richtlinien aufgeführt, nach denen wir Freie Software identifizieren. Trotzdem werden wir Anwender unterstützen, die nicht-freie Programme einsetzen oder entwickeln. Wir werden aber niemals das Gesamtsystem von nicht-freier Software abhängig machen.
Das problem sind die invariant-sections. Wenn du mal bei google.de/groups oder auf der debian-legal Mailingliste danach suchst wirst du viele Diskussionen darüber zwischen Debian-developer und RMS und anderen FSF Mitgliedern finden.Hackmeck hat geschrieben:Ja, genau das habe ich auch gehört. Was ist an der GNU FDL aus Debian-Sicht denn so unfrei? Ich selbst stelle eigentlich sämtliche von mir verfasste Dokumente unter die GNU FDL und würde gerne wissen, was es aus Debianprojektsicht daran ausszusetzen gibt.
aber damit besteht Debian GNU/Linux nicht mehr aus 100% freier Software. Debian bietet dir vielleicht eine saubere Trennung damit du ein 100% freies System installieren kannst. Debian bietet dir aber auch nicht-freie Software an und empfiehlt sie dir sogar bei Programmen die in main sind!Hackmeck hat geschrieben: Die Unterstützung von Anwendern, die nicht-freie Software benutzen möchten, sieht eben so aus, dass auch Server mit nicht-freier Software vom Debian-Projekt bereitgestellt werden, deren Software einfach ins System integriert werden kann.
Bisher bezogen sich die meisten Argumente die ich gehört habe auf diese invariant sections, was ja auch deine Aufzählung bestätigt, jetzt wo ich es lese fällt mir diese "inkompatibel zur GPL" Argument auch wieder ein.pdreker hat geschrieben:Die Behauptung, dass die Invariant Sections das alleinige Problem darstellen, und dass Debian Software und Text gleichstellen (oder behandeln) will, ist schlicht falsch.
Da stellt sich für mich die Frage in wie fern Software und Dokumenten Lizenzen kompatibel sein können. Das ist ungefähr so wie wenn man sagen würde mit einer Bohrmaschine kann ich keinen Nagel in die Wand hauen.Folgende Kritikpunkte hat Debian an der GNU FDL (In Klammer jeweils meine persönliche Meinung oder Anmerkungen von mir):
- Die FDL ist inkompatibel mit der GPL. Dies wirft interessante Fragen auf, wenn man z.B. Dokumentation per Doxygen aus dem Source eines GPL Programms generiert, und diesen unter die FDL stellt.
von den Fehlern beim labeln habe ich bisher noch nichts gehört. Aber das sind doch höchstens 'Schönheitsfehler' die man in einer neuen Version der GFDL beheben kann.[*]unklare Formulierung. Selbst die FSF macht Fehler beim Labeln von Invariant Sections. (evtl. mit Version 1.2 behoben/verbessert?)
invariant sections sind keine technischen Infos, wie können sie dann überhohlt werden?[*]invariant sections können von der Zeit überholt werden
Das verstehe ich nicht, hast du ein Beispiel. Aber theoretisch kann natürlich jede Lizenz durch ein bestimmtes Ereignis obsolet werden.[*]Die Lizenz kann durch Änderungen in der Technologie obsolet werden. (eher unwahrscheinlich)
Es ist Sinn der invariant-section das diese niemand ändern oder entfernen kann. Die 'technischen-Teil' des Dokumentes kann aber jeder ändern.[*]um invariant sections zu ändern, muss man die Zustimmung aller Personen einholen, die daran mit gearbeitet haben. Das ermöglicht es einzelnen die Modifikation von Dokumenten zu blockieren.
Wenn ich ein Dokument für etwas völlig anderes verwende, dann werde ich wohl kaum auf einem vorhandenen aufbauen, da ich dann 90% ändern müsste. Ich werde also höchstens in meinem neuen Dokument Teile eines anderen zitieren und das darf ich immer, egal welche Lizenz das Dokument hat. Stichwort: fair-use.[*]es ist potentiell nicht möglich, Teile eines Dokuments für einen anderen Zweck zu verwenden oder in Dokumenten zu verwenden, die sich mit etwas völlig anderem beschäftigen.
Wieder das gleiche, die invariant-section ist dafür da, dass sie niemand anderes als der ursprüngliche Autor verändern kann. Wenn du wirklich zwei Dokumente 1:1 kombinierst ist es daher nur richtig das du auch beide invariant-sections verwendest. Erstellst du aber ein neues Dokument auf Basis der beiden vorherigen spielt die Lizenz wieder keine Rolle (siehe einen Punkt weiter oben)[*]Wenn man 2 FDL Dokumente kombiniert, müssen die invarianten Sektionen beider Dokumente unverändert übernommen werden, auch wenn diese sich potentiell widersprechen (alte vs. neue Mailinglistenadresse z.B.)
Wenn sich dein Dokument nicht mit dem gleichen Thema/Problem beschäftigt wirst du wohl kaum das alte Dokument 1:1 übernehmen, höchstesn Abschnitte zitieren -> wie die letzten zwei Punkte: Lizenz spielt keine Rolle.[*] Man kann invariante Sektionen aus Dokumenten nicht verwenden, wenn diese invariante Sektion sich mit dem Hauptthema des neuen Dokumentes beschäftigt.[/list]
stimmt.Man sollte aber auch im Auge behalten, dass die GPL auch schon in der Version 2.0 vorliegt, "nobody is perfect"... Ausserdem wird der Konflikt nicht so kritisch gesehen, dass man jetzt auf biegen und brechen FDL Dokumente aus main entfernt. Nach dem Sarge Release könnte das allerdings durchaus geschehen. Aber wie schon gesagt: das liegt nicht daran, dass man die FDL für "echt unfrei" halten würde, sondern daran, dass die Interpretation nicht eindeutig ist, und die Auslegung sich im Zweifelsfall am "worst case"orientiert, der halt nach dem DSC "non-free" wäre...
"Weitere Informationen finden sie unter http://unsere.alte.webseite/infos.html"invariant sections können von der Zeit überholt werden
invariant sections sind keine technischen Infos, wie können sie dann überhohlt werden?
Insbesondere Trick2 (mit der Signatur) macht es möglich das Dokument trotzt offener Lizenz quasi zu monopolisieren, da alle folgenden Autoren es nicht korrekt signieren können und dürfen, weil die Lizenz es verbietet... Trick 3 zwingt alle weiteren Autoren, Werbung für meine Bankverbindung zu machen, ohne dass sie sich direkt daran anhängen können, was bei entsprechenden Beiträgen ja durchaus legitim wäre.
) und diese strikte Definition jetzt auch auf Dinge anwendet, für die sie eigentlich nicht vorgesehen war. Zusätzlich kommen noch ein paar Bedenken dazu, dass die FDL in einigen Punkte einfach nicht klar genug ist, und wenn man dan die Debian Regeln anwendet, muss man von schlimmsten Fall ausgehen, der dann halt non-free bedeutet. Ich bin damit auch nicht besonders glücklich, da ich es ehrlich gesagt für dumm und für Debian schädlich halten würde, GNU Dokumente nach non-free zu verschieben, aber das sind nun einmal die Regeln, wie sie momentan interpretiert werden. Der Link funktioniert leider nicht.pdreker hat geschrieben: "Weitere Informationen finden sie unter http://unsere.alte.webseite/infos.html"
Das ist der Sinn der invariant-section das sie kein dritter verändern kann.Nur so als Beispiel... Wenn man jetzt einen der alten Autoren nicht mehr auftreiben kann, kann man die IS nicht ändern. Schade...
Dazu kann ich aktuell nichts sagen, ich werde mir den Bereich aber mal genauer ansehen.Die Nummer mit den Covertexts in der FDL ist auch unklar.
In der GFDL klar formuliert was in der invaraint-section stehen darf:
- Invariant Section: BeS ist ein radikaler FSF Anhänger und niemand sollte auf Ihn hören. [1]
In der GFDL steht ganz eindeutig:[*]Invariant Section: Wenn die folgende GPG Signatur nicht intakt ist, enthält dieses Dokument evtl. Anweisungen und Hinweise, die Ihre Daten zerstören können.
--- BEGIN PGP SIGNATURE ---
...
[..]nsbesondere Trick2 (mit der Signatur) macht es möglich das Dokument trotzt offener Lizenz quasi zu monopolisieren, da alle folgenden Autoren es nicht korrekt signieren können und dürfen, weil die Lizenz es verbietet...
Das wiederspricht genauso der Definition der invariant-section.[*]Invariant Section: Wenn dieses Dokument hilfreich war, oder sie dem Autor (mir!!!) danken wollen, können sie Geld an folgende Bankverbindung überweisen....[/list]
[..]Trick 3 zwingt alle weiteren Autoren, Werbung für meine Bankverbindung zu machen, ohne dass sie sich direkt daran anhängen können, was bei entsprechenden Beiträgen ja durchaus legitim wäre.
Ja, aber dieser "nicht wohlwollender Autor" braucht dazu doch nicht die GFDL. Dann kann er gleich das normale Copyright/Urheberrecht nehmen oder eine andere Lizenz.Was mich im Prinzip stört, ist dass ein nicht wohlwollender Autor die Lizenz mit sowas genau zu Zwecken einsetzen kann, die eigentlich nicht so gedacht sind und wenn wir alle wohlwollend wären, dann bräuchten wir die Lizenz nicht...
Gibt es da noch aktive Diskussionen? Soviel ich mitbekommen habe wurden sie größtenteils abgebrochen und RMS hat auch gesagt das er sich erstmal um die Fertigstellung der GPL v3 kümmert und eine Mögliche Überarbeitung der GFDL eine geringe priorität hätte.Die FSF hat sich ja sogar mit debian-legal kurzgeschlossen, um in einer offenen Diskussion diese Lücken in einer neuen Version der FDL zu beheben.
Neben der überarbeitung des DSC sollte es vielleicht auch einen DFSG und einen DFDG (== Debian Free Dokcumentation Guide) geben. Vielleicht sollte man dann sogar überlegen einen eigenen Zweig für Dokumente aufzumachen. Einfach das der user weiß das bei Paketen aus dem doc-Zweig andere Regeln gelten als bei Paketen aus dem main-Zweig, da es sich um andere Werke als Software handelt.IM very personal O muss der DSC einfach 'mal wieder den äusseren Gegebenheiten angepasst werden, damit das Problem der Software Regeln, die auf Doku angewendet werden gelöst wird.
-> http://www.gnu.org/licenses/license-list.htmlHackmeck hat geschrieben:Gibt es eigentlich brauchbare alternative freie Lizenzmodelle für Dokumente?
Das mache ich mit der GPG Sig ja nicht. Man kann das Dokument ja problemlos weiterverbreiten und kopieren, man kann es sogar verändern. Man kann nur die Signatur nicht updaten oder entfernen. Die Interpretation der Lizenz wird den meisten Usern entgehen. Es geht nicht darum, das Dokument echt zu monopolisieren, die FDL schliesst ja DRM aus, sondern es geht darum bei den Usern diesen Eindruck zu erwecken, dass nur man selbst legitime Versionen erzeugen kann.In der GFDL steht ganz eindeutig:
"You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute."
Code: Alles auswählen
wintermute:~# apt-get source cdrecord
....
wintermute:~# cd cdrtools-2.0+a25/cdrecord
wintermute:~/cdrtools-2.0+a25/cdrecord# cat LICENSE
This software is under GPL with the following limitations:
- You may not modify certain copyright messages in cdrecord.c
See cdrecord.c for further information.
- You may (with a few exceptions) not modify the location of the
configuration file /etc/default/cdrecord.
See defaults.c for further information.
Ehrlich gesagt verstehe ich es nicht ganz. Warum will jemand einen Eindruck erwecken das man was nicht verändern kann, es aber letztlich doch erlauben? Sollte es eine Abschreckung sein, damit man es nicht verändert? Dann geh doch gleich auf Nummer sicher und verwende eine andere Lizenz bzw. das normale Copyright.pdreker hat geschrieben: Das mache ich mit der GPG Sig ja nicht. Man kann das Dokument ja problemlos weiterverbreiten und kopieren, man kann es sogar verändern. Man kann nur die Signatur nicht updaten oder entfernen. Die Interpretation der Lizenz wird den meisten Usern entgehen. Es geht nicht darum, das Dokument echt zu monopolisieren, die FDL schliesst ja DRM aus, sondern es geht darum bei den Usern diesen Eindruck zu erwecken, dass nur man selbst legitime Versionen erzeugen kann.
Da du dadurch auf die Idee gekommen bist, siehts du ja selber das es nicht wirklich ein problem der GFDL istWie ich auf diese seltsame Idee überhaupt gekommen bin? Ganz einfach:In meinen Augen ist das ein glasklare GPL Violation, aber trotzdem wird es gemacht, und auch noch befolgt. cdrecord hat eigentlich kein Lizenz (GPL is ungültig, durch die zusätzlichen Einschränkungen, und Debian hat durch das weitergeben IMO alle Rechte daran verwirkt.) Lustig? Finde ich gar nicht. In cdrecord.c wird dann noch ganz nonchalant darauf hingewiesen, dass dies keine zusätzliche Einschränkung darstellt, sondern nur eine "Interpretationshilfe" für die GPL. Lizenzen werden verbogen und gequält...Code: Alles auswählen
wintermute:~# apt-get source cdrecord .... wintermute:~# cd cdrtools-2.0+a25/cdrecord wintermute:~/cdrtools-2.0+a25/cdrecord# cat LICENSE This software is under GPL with the following limitations: - You may not modify certain copyright messages in cdrecord.c See cdrecord.c for further information. - You may (with a few exceptions) not modify the location of the configuration file /etc/default/cdrecord. See defaults.c for further information.
Wenn du es nur der einen Person zum lesen gibst (es könnte ja sein das er nur word hat und dass das einzige Format ist das er lesen kann) gehört das zu imho Punkt2 der Lizenz:Noch ein Beispiel, worum es mir geht: Der oben zitierte Satz aus der FDL unterliegt einer sehr weitreichenden Interpretation: angenommen ich will ein Dokument, welches bereits unter der FDL steht, WinWord Usern zugänglich machen (warum auch immer...) und konvertiere es in ein Word Dokument. Nach strenger Auslegung habe ich damit im Prinzip eine technische Massnahme (Konvertierung in ein proprietäres Format) vorgenommen, die das Lesen des Dokumentes einschränkt bzw. behindert (obstruct): Man braucht plötzlich ein ziemlich teures Software Paket, um das Dokument zu lesen. Verstosse ich dann gegen die Lizenz?
Wenn du es in Massen kopierst, dann gibt es diese Auflagen (Punkt3):Muss ich immer das ASCII (oder ein anderes nicht proprietäres Format) dazu legen (Dazu steht IIRC was in der FDL)? Muss ich das ganze evtl. als eine Einheit (ZIP Archiv o.ä.) verteiben?
Aber es ist ein Format das jeder lesen und schreiben kann, da es ein offenes Format ist:Man braucht eigentlich gar nicht bis zu Word zu gehen: Konvertiere das Dokument einfach ins KWord Format, schon ist das Lesen eingeschränkt.
und in Englisch wäre es auch eine Einschränkung, da mann dann ein System braucht das lateinische Buchstaben anzeigen kann?Auch wäre es im Prinzip ein technische Einschränkung ein Dokument in japanischer Sprache zu veröffentlichen, da man dann ein System bräuchte, dass japanisch anzeigen kann, und man müsste es auch lesen können.
Kleiner OT-Einwurf am Rande:BeS hat geschrieben:Oder wenn man an Standards denkt. Wenn man mit einer Entwicklungsumgebung den C Sprachstandard mitliefert ist es auch nicht umbedingt sinnvoll das diesen dritte verändern können, da sich ein Standard dadurch auszeichnet das er für alle gleich ist.
Das verbietet die GPL. Es stehen zwar kein expliziten Angaben zum Medium dort aber dort steht:Dabei kommt mir eine Idee. Man muß bei Programmen unter der GPL den Zugang zum Quellcode garantieren. Ist da das Medium festgeschrieben? Könnte ich auch als Autor auf Anfrage den Quellcode ausdrucken und in einem Briefumschlag verschicken und hätte damit mein Soll erfüllt? Ich bin mir da gerade nicht sicher ob zum Medium was in der GPL steht.
Ausgedruckter Source Code trifft dier verschiedenen Bedingungen (preferred form of editing, medium customarily used for software interchage) nicht...GPLv2 Section 3 hat geschrieben:a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
[...]
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
