Ich raffs nicht, was für unfreie versteckte komponenten sollen denn in den distries drin sein, außer treiber und codecs? Libs sinds ja nicht, das geht ja nicht mit der GPL...
> Libs sinds ja nicht, das geht ja nicht mit der GPL... Bibliotheken in denen CSS mit MIT- oder BSD-lizensiertem Code gebundelt sind wären ein Beispiel. Lizenzen gibt es ja wie Sand am Meer. Die GPL ist nicht die einzige Lizenz die von der FSF anerkannt und in sog. "freien Distributionen" enthalten ist.
Du hast Recht, das darf nicht sein. Passiert aber!
So war in Mesa seit jeher Code drin, der nicht Frei war. Bis es bemerkt wurde und SGI ihren Code dann Frei gegeben hat. Ich glaube Mesa steht nicht mal unter GPL. Auf die Lizenzen aller Dateien und ihren echten Ursprung gucken nicht immer alle.
Das Problem daran ist, dass wir Code, den wir nicht vertreiben dürfen, auch nicht vertreiben wollen. Und die Aufgabe ist, ihn zu finden. Sonst kann es z.B. ratz-fatz passieren, dass der Eigentümer es selbst rausfindet und z.B. Redhat mit einer einstweiligen Verfügung droht.
Insgesamt eine wichtige Sache, dass jemand, der es weiss, es nicht aus reiner Bequemlichkeit oder Desinteresse für sich behält. So ein GNU Buck kann genug Anreiz sein. Auf Ebay wird der schon was wert sein oder halt für die Wand.
Verstehe die Nachricht nicht. Woran erkennt man denn unfreie Software? Wie kann sich unfreie Software denn unbemerkt in einer Distribution verstecken? Wenn ich Opera installiere, weiß ich, dass er unfrei ist, Wenn ich Firefox installiere, weiß ich, dass er frei ist. Ich muss mir nur die Lizenzen angucken. Meint die Nachricht, dass in den Distributionen Pakete enthalten sind, deren Lizenz doch nicht frei ist? Wie sind die denn dann reingekommen? Liest sich etwa niemand die Lizenz durch, wenn ein neues Paket aufgenommen wird? Gibt es denn so viele Lizenzen? Mal konkret: Ich möchte helfen und unfreie Komponenten finden. Wie gehe ich vor?
Naja, einfaches Beispiel, ein Prog steht zwar unter einer freien Lizenz, meinetwegen BSD, aber im subdir foo befindet sich ein Plugin, welches auf unfreiem Code basiert. Der Distributions-Entwickler hat aber im copyright-file den kleinen Satz übersehen, dass es da ein subdir foo mit unfreiem Code gibt.
Sowas kommt öfter mal vor. Ein Beispiel wär 7-zip, das ist an sich frei, enthält aber für RAR-support unfreien Code von unrar.
Verstehe die Nachricht nicht. Woran erkennt man denn unfreie Software? Wie kann sich unfreie Software denn unbemerkt in einer Distribution verstecken? Wenn ich Opera installiere, weiß ich, dass er unfrei ist, Wenn ich Firefox installiere, weiß ich, dass er frei ist.
Die sind ja auch sehr bekannt. Distrubutionen haben aber tausende von Software-Paketen.
Ich muss mir nur die Lizenzen angucken.
Ja.
Meint die Nachricht, dass in den Distributionen Pakete enthalten sind, deren Lizenz doch nicht frei ist? Wie sind die denn dann reingekommen? Liest sich etwa niemand die Lizenz durch, wenn ein neues Paket aufgenommen wird?
FSF-Gesegnete-Distributionen wie gNewSense sind meist Abspaltungen von Distributionen, die auch Pakete mit nicht 100% ideologisch reinen Free-Software-Lizenzen beinhalten wie z.B. Ubuntu.
Lustig, dass du gerade Firefox nennst, der ja mit seinem Artwork (Logos, Icons) auch unfreie Teile enthält. Sonst würde er sich in Debian ja nicht Iceweasel nennen...
Von Anonymer Feigling am Di, 6. Oktober 2009 um 12:16 #
Warum sollten alle Logos unfrei sein? Das halte ich für ein Gerücht. Natürlich, einige sind es tatsächlich, wie etwa das Debian-Logo oder das Firefox-Logo, aber das bedeutet ja nicht dass sie generell unfrei sind.
Na weil man nicht einfach ein Logo übernehmem und z.B. einen anderen Namen druntersetzen kann.
>>Natürlich, einige sind es tatsächlich, wie etwa das Debian-Logo oder das Firefox-Logo,<< Oder Fedora, RedHat,Suse...
Man denke an die CentOS-Geschichte, als sich der Gründer, der alle Rechte an der Marke Centos inkl. Logo hatte,verschollen war. Da waren die Entwickler ganz schön am zucken.
Oder klau mal die Initialen FSF oder GNU, da wird sich schon einer melden;)
Natürlich kann man ein beliebiges Logo nehmen: Die Lizenz muss es nur erlauben. Die Frage kann höchstens sein, inwieweit ein Logo Teil eines Programms ist.
Interessanterweise nach deutschem Recht schon. Logos erreichen üblicherweise und überraschenderweise (für mich) regelmäßig nicht die Schöpfungshöhe (s. diverse Urteile), solange es nicht ums Markenrecht geht, sind sie somit nicht mal übers Urheberrecht geschützt.
Von Michael Stehmann am Mi, 7. Oktober 2009 um 10:10 #
Debian hat ein freies Logo, welches in Programmen verwendet wird, und ein unfreies Logo (nämlich das mit der Flasche), welches für das Projekt verwendet wird.
Das Logo, welches man meistens sieht, ist also inzwischen frei im Sinne der Debian Free Software Guidelines; man kann also beispielsweise die Farbe ändern, wenn einem Grün oder Blau lieber ist.
Du siehst ein Bild, dir fällt etwas auf, du fragst dich etwas. Doch anstatt den Text neben dem Bild zu lesen, bemühst du die Kommentierfunktion, um allen von deiner "Entdeckung" zu erzählen? Ein solches Verhalten kann man ja schon nicht mal mehr Dummheit nennen...
Vielleicht kann die FSF ja einmal einen solchen Buck z.B. an einen Grafikkartenhersteller wie z.B. AMD/ATI direkt auszahlen, wenn dieser, um z.B. das Problem unfreier Kernel-Firmware für seine Grafikkarten zu lösen, seine freien Treiber in Zukunft nur noch mit bloßer 2D-Funktionalität anbietet, d.h. seine Firmware "einfriert" bzw. "zurückzieht". Warum soll man sich die ganze Mühe machen, wenn man doch nur eine Ohrfeige für seine Engagement bekommt? Mit freien Nur-2D-Treibern passiert das erst gar nicht, siehe NVidia. Die Forderungen der FSF u.a. in punkto unfreier Firmware im Kernel können durchaus dazu geeignet sein, den Feature- und Source-Pool freier Software für alle Linuxdistributionen dauerhaft zu verkleinern.
So einen hirnlosen Schwachsinn gibt aber auch nur jemand von sich der nicht fähig ist langfristig zu denken!
Du hast weder Ahnung von Software-Entwicklung geschweige denn Hintergrundwissen über die Kernel-Entwicklung stimmts?
Was nützt es verdammt nochmal JETZT irgendwelche BLOBS zu haben die in 3 Jahren mit dem dann aktuellen kernel nicht mehr funktionieren und den Hersteller interessiert es einen Scheißdreck?
Siehe nvidia CS-Treiber den es verdammt nochmal auch gibt der aber keine alten Karten mehr unterstützt und der alte Treiber läuft nicht mit einem aktuellen Kernel - Ergo kannst du dir die Grafikkarte in den Arsch stcken weil der Hersteller meint du mögest dir doch eine neue kaufen
Wäre der Dreckstreiber offen würde sich diese Frage nicht stellen weil dessen Schnittstellen parallel zu denen des Kernels hepflegt werden können.
Und Nein verdammt nochmal "stabile" Schnittstellen bringen LANGFRISTIG auch nichts weil man keine alten Zöpfe mehr abschneiden kann und Dinge die heute OK und in 5 Jahren nicht mehr zeitgemäss sein könnten nie wieder los wird - Gratuliere: Einbahnstrasse
Aber Hauptsache DU hast ohne vom Thema auch nur das Geringste zu verstehen auch was gesagt
"Was nützt es verdammt nochmal JETZT irgendwelche BLOBS zu haben die in 3 Jahren mit dem dann aktuellen kernel nicht mehr funktionieren und den Hersteller interessiert es einen Scheißdreck?"
Es ist doch nur so, dass ihr "freien Software-Kämpfer" im allgemeinen mit 2D anscheinend ganz glücklich seid (anscheinend leistet ihr Euch lieber teure Intel-Boards mit extra schwachen 3D-Grafikchips). Warum sollte man Euch dann nicht entsprechend beglücken? Nicht erst in drei Jahren, jetzt. Und: Was interessieren mich die NVidia-Blobs, von denen habe ich nicht geredet, sondern von der unfreien Kernel-Firmware, die u.a. AMD/ATI für r128 und radeon zur Verfügung stellen.
Zudem könnt "ihr" nur entfernen. Xorg so zu modifizieren, damit die ATI-Karten von 1xx bis 5xx auch 3D ohne unfreie Kernel-Firmware nutzen können, ist eben nicht. Hauptsache entfernen. Nur weiter so. Feature-Kastration als oberstes Distributionsfeature.
Die Kritik an unfreier Firmware im Kernel stößt bei den Herstellern auf blankes Unverständnis. Warum, kannst Du Dir wohl selber denken. In Euren Augen sinkt ATI trotz seines Engagements in Sachen freier 2D-/3D-Treiber auf das nv-NVidia-Niveau herab. Das kommt sicherlich sehr gut an.
> Warum sollte man Euch dann nicht entsprechend beglücken? Nicht erst > in drei Jahren, jetzt.
Weil es verdqammt nochmal witzlo ist wenn der Hersteller entscheiden kann ab wann ich mir neue Hardware zu kaufen habe obwohl die alte noch funktioniert und ausreichend Leistung hat.
Wenn dir das egal ist nimm Windows! Niemand hindert dich daran!
Das ZIEL freier Software ist sowas zu verhindern, wenn dir daran nichts liegt bist du nicht die Zielgruppe -> Ergo: Schnauze halten
> Und: Was interessieren mich die NVidia-Blobs, von denen habe ich nicht > geredet, sondern von der unfreien Kernel-Firmware, die u.a. AMD/ATI für > r128 und radeon zur Verfügung stellen.
Und wo willst du eine Grenze ziehen du Gehirnakrobat? Entweder die Distribution ist frei oder nicht Niemand hindert dich verdammt nochmal daran irgendwelche BLOBS nachzuinstallieren, aber eine freie Distribution hat schon alleine aus rechtlichen Gründen keine unfreie Software mitzuleifern.
Benutzt Du denn keine unfreie Firmware mehr, die in Hardware-Chips "gegossen" ist? Du benutzt also keine unfreies BIOS mehr, keine unfreie Festplatten-Firmware?
Natürlich benutzt Du solche Firmware, ansonsten könntest du hier nicht posten.
Vor allen Dingen besteht ja keinerlei Unterschied in den "Auswirkungen" zwischen der unfreien Kernel-Firmware und der Firmware auf ROM-Chips, wenn sie denn beide zur Laufzeit geladen werden.
Somit ist Dein Rechnersystem nicht frei, Deine Distro im übrigen auch nicht. Sicher werkelt zur Laufzeit irgendeine proprietäre Firmware auf Deinem System.
Und, falls Du vielleicht noch das Argument möglicher juristischer Probleme bei der Verteilung unfreier Kernel-Firmware einwerfen solltest: Die r128- und radeon-Firmware darf natürlich verteilt werden, von jedermann ("any person"). Die Lizenzen sind da eindeutig: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git; a=blob_plain;f=firmware/WHENCE Einfach nach ganz unten scrollen.
Fazit: Hier geht es demzufolge um reine Politik, nicht um Logik.
"Wie dumm muss man sein um das nicht zu verstehen?" Wirklich sehr schlechter Stil. Das fällt primär auf Dich zurück.
> Vor allen Dingen besteht ja keinerlei Unterschied in den "Auswirkungen" zwischen der unfreien Kernel-Firmware und der Firmware auf ROM-Chips
Klar gibt es Unterschiede in der Auswirkung. Die hat "Verwundert" auch sehr ausführlich dargestellt. Hast du Probleme mit deinem Kurzzeitgedächnis oder wie sind deine Auswürfe zu verstehen?
> Somit ist Dein Rechnersystem nicht frei
Nun bring doch noch das Argument, daß Hardware ja auch Geld kostet und Software deswegen nicht frei sein kann. Junge, gehts noch?
> Und, falls Du vielleicht noch das Argument möglicher juristischer Probleme
Und jetzt schweifst du wieder ab...
Fazit: Du brauchst professionelle Hilfe. Hier kann dir nicht geholfen werden.
Immer dann, wenn man andere Poster grundlos beleidigt, zeigt das nur, das man selber argumentativ auf verlorenem Posten steht.
Ich habe oben erklärt, was es mit den beiden Firmware-Arten auf sich hat. Mit dem Entfernen des Firmware-Microcodes wird das proprietäre Firmware-Problem jedenfalls nicht beseitigt. Konsequent wäre es gar keine Firmware zu benutzen, das aber traut ihr Euch verständlicherweise nicht. Es ist hier halt wie in der Politik: Lieber eine Pseudolösung als gar keine.
> Immer dann, wenn man andere Poster grundlos beleidigt, zeigt das nur, > das man selber argumentativ auf verlorenem Posten steht.
Nö, dann ist die Gegenseite so grenzenlos dumm dass es einen aufregt
> Ich habe oben erklärt, was es mit den beiden Firmware-Arten auf sich hat. > Mit dem Entfernen des Firmware-Microcodes wird das proprietäre > Firmware-Problem jedenfalls nicht beseitigt..
Wenn man nur von 12 bis gegen Mittag denken kann mag das so sein Natürlich wird es langfrstig genau so erledigt Sobald eine Firma a) gute Hardware mit b) dreier Firmware im Portfolio hat kommen die anderen unter Zugzwang und mittlerweile kann es sich in die Zukunft gedacht kaum ein Unternehmen leisten Linux zu ignorieren.
Klar geht das nicht von heute auf Morgen Aber nur debile Vollidioten denken nicht weiter und setzen keine Schritte die nicht sofort was bringen weil "geht ja eh irgendwie" -> Schwachköpfe sind Leute die so denken und Gott sei Dank sind nicht alle so sonst würden wir heute noch in Höhlen sitzen und an den Wänden rumkratzen
Ich habe auf Ihren zutiefst asozialen und aüßerst beleidigenden "Hooligan-Schreibstil" keine Lust mehr. Was ein AMD-/ATI-Entwickler zur Problematik des Radeon Microcodes im Kernel zu sagen hatte, können Sie hier nachlesen: http://phoronix.com/forums/showthread.php?t=6585&page=63#628 Ich bin im übrigen mit "bridgman" einer Meinung. Falls Sie des Englischen einigermaßen mächtig sein sollten, so werden Sie seine Argumentation nachvollziehen können.
So, hier kommt jetzt ein hoffentlich nüchterner Kommentar, ganz ohne Fäkalsprache: :-)
Es gibt zwischen den beiden Firmwarearten (unfreier Microcode im Kernel, proprietäre Firmware z.B. in ROM-Chips) nach dem Laden zur Laufzeit keinen Unterschied. Nun ist es aber möglich, die unfreie Firmware im Kernel problemlos zu entfernen. Nur würde ich doch nicht deswegen meine ROM-Chips von der Hardware manuell herunterreißen wollen, "nur" weil darin proprietäre Firmware enthalten ist. Das wäre - ohne wirklichen funktionsfähigen Ersatz - Irrsinn.
Diese Entscheidung zur Entfernung von unfreier Firmware im Kernel ist politisch motiviert und sie ist willkürlich. Sie ist aber nicht "unlogisch", man möchte ein möglichst freies Betriebssystem benutzen, auch wenn das zur Zeit noch nicht zu 100% möglich ist. Diese Entscheidung beeinflusst Dich in keinster Weise, weil niemand durch die FSF dazu gezwungen wird, es genauso tun zu müssen. Alles ist freiwillig und alles geschieht aus freien Stücken.
Hinzu kommt ein Problem, das natürlich ernst genommen wird: "Chirurgische" Code-Entfernung kann auch Folgen haben, man denke nur an die unselige Openssl-Geschichte. Von daher muß man hier höllisch aufpassen. Nicht immer ist die Entfernung so einfach wie im Falle der mga-, r128- und radeon-Microcodes.
Ich habe gerade oben gelesen, dass Du anscheinend Angst davor hast, dass zu rüde "Anfragen" beim "Besitzer" des betreffenden unfreien Codes zur Entfernung von solchem Code und auch zur Entfernung von freiem "zukünftigen" Code des jeweiligen Kontributors führen könnten. ATI beispielsweise steuert ja beide "Codearten" bei.
Natürlich muß man nett sein und respektvoll anfragen bzw. ebenso respektvoll den "Codeinhaber" über das Problem (den "freedom bug") informieren. Hierauf wird auch geachtet. Siehe u.a.: http://lists.gnu.org/archive/html/gnewsense-users/2009-10/msg00013.html
> Was nützt es verdammt nochmal JETZT irgendwelche BLOBS zu haben die in 3 Jahren mit dem dann aktuellen kernel nicht mehr funktionieren und den Hersteller interessiert es einen Scheißdreck?
Es geht nicht um irgendwelche Kernelmodule, die auf Grund von API-Änderungen nicht mehr funktionieren, sondern um BLOBs, die Microcode für die GPU enthalten. Die sind unabhängig von kernelinternen APIs.
Bibliotheken in denen CSS mit MIT- oder BSD-lizensiertem Code gebundelt sind wären ein Beispiel. Lizenzen gibt es ja wie Sand am Meer. Die GPL ist nicht die einzige Lizenz die von der FSF anerkannt und in sog. "freien Distributionen" enthalten ist.
So war in Mesa seit jeher Code drin, der nicht Frei war. Bis es bemerkt wurde und SGI ihren Code dann Frei gegeben hat. Ich glaube Mesa steht nicht mal unter GPL. Auf die Lizenzen aller Dateien und ihren echten Ursprung gucken nicht immer alle.
Das Problem daran ist, dass wir Code, den wir nicht vertreiben dürfen, auch nicht vertreiben wollen. Und die Aufgabe ist, ihn zu finden. Sonst kann es z.B. ratz-fatz passieren, dass der Eigentümer es selbst rausfindet und z.B. Redhat mit einer einstweiligen Verfügung droht.
Insgesamt eine wichtige Sache, dass jemand, der es weiss, es nicht aus reiner Bequemlichkeit oder Desinteresse für sich behält. So ein GNU Buck kann genug Anreiz sein. Auf Ebay wird der schon was wert sein oder halt für die Wand.
Gruss,
Kay
Mal konkret: Ich möchte helfen und unfreie Komponenten finden. Wie gehe ich vor?
Sowas kommt öfter mal vor. Ein Beispiel wär 7-zip, das ist an sich frei, enthält aber für RAR-support unfreien Code von unrar.
Die sind ja auch sehr bekannt. Distrubutionen haben aber tausende von Software-Paketen.
Ich muss mir nur die Lizenzen angucken.
Ja.
Meint die Nachricht, dass in den Distributionen Pakete enthalten sind, deren Lizenz doch nicht frei ist? Wie sind die denn dann reingekommen? Liest sich etwa niemand die Lizenz durch, wenn ein neues Paket aufgenommen wird?
FSF-Gesegnete-Distributionen wie gNewSense sind meist Abspaltungen von Distributionen, die auch Pakete mit nicht 100% ideologisch reinen Free-Software-Lizenzen beinhalten wie z.B. Ubuntu.
Gibt es denn so viele Lizenzen?
Ja.
Bei der Iceweasel-Sache ging es wohl um von Debian vorgenommene Patches an "alten" Firefoxversionen.
>>Natürlich, einige sind es tatsächlich, wie etwa das Debian-Logo oder das Firefox-Logo,<<
Oder Fedora, RedHat,Suse...
Man denke an die CentOS-Geschichte, als sich der Gründer, der alle Rechte an der Marke Centos inkl. Logo hatte,verschollen war. Da waren die Entwickler ganz schön am zucken.
Oder klau mal die Initialen FSF oder GNU, da wird sich schon einer melden;)
Bei GNU sind die noch recht locker. Beispiel: Gnuplot oder Gnutella - das sind beides keine GNU-Projekte.
Dann gleich weg mit dem "unfreien" Debian Mist.
Sofort eine Meldung an RMS und die FSF absetzen...
Das Logo, welches man meistens sieht, ist also inzwischen frei im Sinne der Debian Free Software Guidelines; man kann also beispielsweise die Farbe ändern, wenn einem Grün oder Blau lieber ist.
[Merkel]Ich veruteile soetwas aufs schaerfste.[/Merkel]
Ein solches Verhalten kann man ja schon nicht mal mehr Dummheit nennen...
Scheiß auf die Ehre! Wo kann man denn die GNU Bucks einlösen?
;-)
Weltwaehrung werden.
Die Oelscheichs sind auch schon ganz heiss drauf. Endlich
richtiges Geld fuer Oel.
Der Omega13.
Warum soll man sich die ganze Mühe machen, wenn man doch nur eine Ohrfeige für seine Engagement bekommt? Mit freien Nur-2D-Treibern passiert das erst gar nicht, siehe NVidia.
Die Forderungen der FSF u.a. in punkto unfreier Firmware im Kernel können durchaus dazu geeignet sein, den Feature- und Source-Pool freier Software für alle Linuxdistributionen dauerhaft zu verkleinern.
Du hast weder Ahnung von Software-Entwicklung geschweige denn Hintergrundwissen über die Kernel-Entwicklung stimmts?
Was nützt es verdammt nochmal JETZT irgendwelche BLOBS zu haben die in 3 Jahren mit dem dann aktuellen kernel nicht mehr funktionieren und den Hersteller interessiert es einen Scheißdreck?
Siehe nvidia CS-Treiber den es verdammt nochmal auch gibt der aber keine alten Karten mehr unterstützt und der alte Treiber läuft nicht mit einem aktuellen Kernel - Ergo kannst du dir die Grafikkarte in den Arsch stcken weil der Hersteller meint du mögest dir doch eine neue kaufen
Wäre der Dreckstreiber offen würde sich diese Frage nicht stellen weil dessen Schnittstellen parallel zu denen des Kernels hepflegt werden können.
Und Nein verdammt nochmal "stabile" Schnittstellen bringen LANGFRISTIG auch nichts weil man keine alten Zöpfe mehr abschneiden kann und Dinge die heute OK und in 5 Jahren nicht mehr zeitgemäss sein könnten nie wieder los wird - Gratuliere: Einbahnstrasse
Aber Hauptsache DU hast ohne vom Thema auch nur das Geringste zu verstehen auch was gesagt
Es ist doch nur so, dass ihr "freien Software-Kämpfer" im allgemeinen mit 2D anscheinend ganz glücklich seid (anscheinend leistet ihr Euch lieber teure Intel-Boards mit extra schwachen 3D-Grafikchips). Warum sollte man Euch dann nicht entsprechend beglücken? Nicht erst in drei Jahren, jetzt.
Und: Was interessieren mich die NVidia-Blobs, von denen habe ich nicht geredet, sondern von der unfreien Kernel-Firmware, die u.a. AMD/ATI für r128 und radeon zur Verfügung stellen.
Zudem könnt "ihr" nur entfernen. Xorg so zu modifizieren, damit die ATI-Karten von 1xx bis 5xx auch 3D ohne unfreie Kernel-Firmware nutzen können, ist eben nicht. Hauptsache entfernen. Nur weiter so. Feature-Kastration als oberstes Distributionsfeature.
Die Kritik an unfreier Firmware im Kernel stößt bei den Herstellern auf blankes Unverständnis. Warum, kannst Du Dir wohl selber denken. In Euren Augen sinkt ATI trotz seines Engagements in Sachen freier 2D-/3D-Treiber auf das nv-NVidia-Niveau herab. Das kommt sicherlich sehr gut an.
> in drei Jahren, jetzt.
Weil es verdqammt nochmal witzlo ist wenn der Hersteller entscheiden kann ab wann ich mir neue Hardware zu kaufen habe obwohl die alte noch funktioniert und ausreichend Leistung hat.
Wenn dir das egal ist nimm Windows!
Niemand hindert dich daran!
Das ZIEL freier Software ist sowas zu verhindern, wenn dir daran nichts liegt bist du nicht die Zielgruppe -> Ergo: Schnauze halten
> Und: Was interessieren mich die NVidia-Blobs, von denen habe ich nicht
> geredet, sondern von der unfreien Kernel-Firmware, die u.a. AMD/ATI für
> r128 und radeon zur Verfügung stellen.
Und wo willst du eine Grenze ziehen du Gehirnakrobat?
Entweder die Distribution ist frei oder nicht
Niemand hindert dich verdammt nochmal daran irgendwelche BLOBS nachzuinstallieren, aber eine freie Distribution hat schon alleine aus rechtlichen Gründen keine unfreie Software mitzuleifern.
Wie dumm muss man sein um das nicht zu verstehen?
Benutzt Du denn keine unfreie Firmware mehr, die in Hardware-Chips "gegossen" ist?
Du benutzt also keine unfreies BIOS mehr, keine unfreie Festplatten-Firmware?
Natürlich benutzt Du solche Firmware, ansonsten könntest du hier nicht posten.
Vor allen Dingen besteht ja keinerlei Unterschied in den "Auswirkungen" zwischen der unfreien Kernel-Firmware und der Firmware auf ROM-Chips, wenn sie denn beide zur Laufzeit geladen werden.
Somit ist Dein Rechnersystem nicht frei, Deine Distro im übrigen auch nicht. Sicher werkelt zur Laufzeit irgendeine proprietäre Firmware auf Deinem System.
Und, falls Du vielleicht noch das Argument möglicher juristischer Probleme bei der Verteilung unfreier Kernel-Firmware einwerfen solltest:
Die r128- und radeon-Firmware darf natürlich verteilt werden, von jedermann ("any person"). Die Lizenzen sind da eindeutig:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
a=blob_plain;f=firmware/WHENCE
Einfach nach ganz unten scrollen.
Fazit:
Hier geht es demzufolge um reine Politik, nicht um Logik.
"Wie dumm muss man sein um das nicht zu verstehen?"
Wirklich sehr schlechter Stil.
Das fällt primär auf Dich zurück.
Klar gibt es Unterschiede in der Auswirkung. Die hat "Verwundert" auch sehr ausführlich dargestellt. Hast du Probleme mit deinem Kurzzeitgedächnis oder wie sind deine Auswürfe zu verstehen?
> Somit ist Dein Rechnersystem nicht frei
Nun bring doch noch das Argument, daß Hardware ja auch Geld kostet und Software deswegen nicht frei sein kann. Junge, gehts noch?
> Und, falls Du vielleicht noch das Argument möglicher juristischer Probleme
Und jetzt schweifst du wieder ab...
Fazit: Du brauchst professionelle Hilfe. Hier kann dir nicht geholfen werden.
Ich habe oben erklärt, was es mit den beiden Firmware-Arten auf sich hat. Mit dem Entfernen des Firmware-Microcodes wird das proprietäre Firmware-Problem jedenfalls nicht beseitigt.
Konsequent wäre es gar keine Firmware zu benutzen, das aber traut ihr Euch verständlicherweise nicht.
Es ist hier halt wie in der Politik: Lieber eine Pseudolösung als gar keine.
> das man selber argumentativ auf verlorenem Posten steht.
Nö, dann ist die Gegenseite so grenzenlos dumm dass es einen aufregt
> Ich habe oben erklärt, was es mit den beiden Firmware-Arten auf sich hat.
> Mit dem Entfernen des Firmware-Microcodes wird das proprietäre
> Firmware-Problem jedenfalls nicht beseitigt..
Wenn man nur von 12 bis gegen Mittag denken kann mag das so sein
Natürlich wird es langfrstig genau so erledigt
Sobald eine Firma a) gute Hardware mit b) dreier Firmware im Portfolio hat kommen die anderen unter Zugzwang und mittlerweile kann es sich in die Zukunft gedacht kaum ein Unternehmen leisten Linux zu ignorieren.
Klar geht das nicht von heute auf Morgen
Aber nur debile Vollidioten denken nicht weiter und setzen keine Schritte die nicht sofort was bringen weil "geht ja eh irgendwie" -> Schwachköpfe sind Leute die so denken und Gott sei Dank sind nicht alle so sonst würden wir heute noch in Höhlen sitzen und an den Wänden rumkratzen
Was ein AMD-/ATI-Entwickler zur Problematik des Radeon Microcodes im Kernel zu sagen hatte, können Sie hier nachlesen:
http://phoronix.com/forums/showthread.php?t=6585&page=63#628
Ich bin im übrigen mit "bridgman" einer Meinung. Falls Sie des Englischen einigermaßen mächtig sein sollten, so werden Sie seine Argumentation nachvollziehen können.
Es gibt zwischen den beiden Firmwarearten (unfreier Microcode im Kernel, proprietäre Firmware z.B. in ROM-Chips) nach dem Laden zur Laufzeit keinen Unterschied. Nun ist es aber möglich, die unfreie Firmware im Kernel problemlos zu entfernen. Nur würde ich doch nicht deswegen meine ROM-Chips von der Hardware manuell herunterreißen wollen, "nur" weil darin proprietäre Firmware enthalten ist. Das wäre - ohne wirklichen funktionsfähigen Ersatz - Irrsinn.
Diese Entscheidung zur Entfernung von unfreier Firmware im Kernel ist politisch motiviert und sie ist willkürlich. Sie ist aber nicht "unlogisch", man möchte ein möglichst freies Betriebssystem benutzen, auch wenn das zur Zeit noch nicht zu 100% möglich ist.
Diese Entscheidung beeinflusst Dich in keinster Weise, weil niemand durch die FSF dazu gezwungen wird, es genauso tun zu müssen. Alles ist freiwillig und alles geschieht aus freien Stücken.
Hinzu kommt ein Problem, das natürlich ernst genommen wird: "Chirurgische" Code-Entfernung kann auch Folgen haben, man denke nur an die unselige Openssl-Geschichte. Von daher muß man hier höllisch aufpassen. Nicht immer ist die Entfernung so einfach wie im Falle der mga-, r128- und radeon-Microcodes.
Wenn du vom Thema nichts verstehst solltest du dich dazu nicht äussern
Natürlich muß man nett sein und respektvoll anfragen bzw. ebenso respektvoll den "Codeinhaber" über das Problem (den "freedom bug") informieren.
Hierauf wird auch geachtet.
Siehe u.a.:
http://lists.gnu.org/archive/html/gnewsense-users/2009-10/msg00013.html
Es geht nicht um irgendwelche Kernelmodule, die auf Grund von API-Änderungen nicht mehr funktionieren, sondern um BLOBs, die Microcode für die GPU enthalten. Die sind unabhängig von kernelinternen APIs.