In Debian wurde eine Bewegung generiert, um proprietäre Firmware in die Distribution aufzunehmen

Steve McIntyre, Leiter des Debian-Projekts für mehrere Jahre, ergriff die Initiative, Debians Haltung gegenüber dem Versand proprietärer Firmware zu überdenken, das derzeit nicht in den offiziellen Installationsabbildern enthalten ist und in einem separaten "nicht kostenlosen" Repository bereitgestellt wird.

Meinung von Steve, Der Versuch, das Ideal zu erreichen, nur Open-Source-Software anzubieten, bereitet Schwierigkeiten unnötig für Benutzer, die in vielen Fällen proprietäre Firmware installieren müssen, wenn sie möchten, dass ihre Hardware ordnungsgemäß funktioniert.

Proprietäre Firmware wird in einem separaten nicht freien Repository platziert, zusammen mit anderen Paketen, die unter offenen und unfreien Lizenzen vertrieben werden. Das non-free-Repository ist nicht offiziell Teil des Debian-Projekts und der darin enthaltenen Pakete Sie können nicht in die Installation oder Live-Builds aufgenommen werden.

Aus diesem Grund werden Installations-Images mit proprietärer Firmware separat erstellt und als inoffiziell eingestuft, obwohl sie offiziell vom Debian-Projekt entwickelt und gepflegt werden.

Damit ist in der Community ein gewisser Status quo erreicht, in dem sich der Wunsch, nur noch Open-Source-Software zu verteilen, und der Bedarf an Firmware für die Nutzer vereinen. Es gibt auch einen kleinen Satz kostenloser Firmware, die in den offiziellen Builds und im Haupt-Repository enthalten ist, aber es gibt nur sehr wenige solcher Firmwares und sie reichen in den meisten Fällen nicht aus.

Der Ansatz von Debian schafft viele Probleme, darunter Unannehmlichkeiten für Benutzer und verschwendete Ressourcen durch das Erstellen, Testen und Hosten inoffizieller Builds mit geschlossener Firmware. Das Projekt präsentiert offizielle Images als die wichtigsten empfohlenen Builds, aber es verwirrt diese Benutzer nur, wenn sie während des Installationsprozesses auf Probleme mit der Hardwareunterstützung stoßen.

Die Verwendung inoffizieller Builds führt unwissentlich zur Popularisierung unfreier Software, da der Benutzer zusammen mit der Firmware auch ein unfreies Repository erhält, das mit anderer unfreier Software verbunden ist, während dies der Fall wäre, wenn die Firmware separat angeboten würde möglich sein, ohne das Non-Free-Repository einzubeziehen.

In letzter Zeit greifen Hersteller zunehmend auf die Verwendung externer Firmware zurück, die vom Betriebssystem geladen wird, anstatt Firmware im permanenten Speicher der Geräte selbst bereitzustellen. Diese externe Firmware wird von vielen modernen Grafik-, Sound- und Netzwerkadaptern benötigt.

Zur gleichen Zeit die Frage, wie viel Firmware auf die Verpflichtung, nur freie Software zu liefern, zurückzuführen ist, ist zweideutig, da Firmware tatsächlich auf Hardwaregeräten und nicht auf dem System erstellt wird und sich auf Geräte bezieht. Mit dem gleichen Erfolg führen moderne Computer, die sogar mit völlig kostenlosen Distributionen ausgestattet sind, eine in das Gerät eingebettete Firmware aus. Der einzige Unterschied besteht darin, dass das Betriebssystem einen Teil der Firmware lädt, während andere bereits im ROM oder Flash-Speicher installiert sind.

Steve hat fünf Hauptoptionen vorgestellt für das Design der Firmware-Veröffentlichung in Debian, die zur allgemeinen Abstimmung durch die Entwickler vorgesehen ist:

1. Lassen Sie alles wie es ist, liefern Sie geschlossene Firmware nur in separaten inoffiziellen Baugruppen.
2. Hören Sie auf, inoffizielle Builds mit unfreier Firmware bereitzustellen, und richten Sie die Distribution an der Ideologie des Projekts aus, nur freie Software zu liefern.
3. Verschieben Sie inoffizielle Builds mit Firmware in die offizielle Kategorie und versenden Sie sie Seite an Seite und am selben Ort mit Builds, die nur Freeware enthalten, wodurch es für den Benutzer einfacher wird, die gewünschte Firmware zu finden.
4. Fügen Sie proprietäre Firmware in reguläre offizielle Builds ein und lehnen Sie es ab, einzelne inoffizielle Builds bereitzustellen. Der Nachteil dieses Ansatzes ist, dass das Non-Free-Repository standardmäßig aktiviert ist.
5. Trennen Sie die proprietäre Firmware aus dem Non-Free-Repository in eine separate Non-Free-Firmware-Komponente und verschieben Sie sie in ein anderes Repository, das keine Aktivierung des Non-Free-Repository erfordert. Fügen Sie eine Ausnahme zu den Projektregeln hinzu, die es erlaubt, eine nicht-freie Firmware-Komponente in reguläre Installations-Assemblys aufzunehmen. Somit wird es möglich sein, die Bildung separater inoffizieller Assemblys abzulehnen, Firmware in reguläre Assemblys aufzunehmen und das Non-Free-Repository für Benutzer nicht zu aktivieren.

Steve selbst befürwortet die Übernahme des fünften Punktes, was es dem Projekt ermöglicht, nicht zu sehr von der Förderung freier Software abzuweichen, aber gleichzeitig das Produkt für Benutzer bequem und nützlich macht.

Der Installer schlägt vor, freie und unfreie Firmware explizit zu trennen, was dem Benutzer die Möglichkeit gibt, eine informierte Entscheidung zu treffen und ihn darüber zu informieren, ob die verfügbare kostenlose Firmware mit aktueller Hardware kompatibel ist und ob es Projekte gibt, freie Firmware für bestehende Geräte zu erstellen. In der Download-Phase ist auch geplant, eine Einstellung hinzuzufügen, um das Paket mit unfreier Firmware zu deaktivieren.

Quelle: https://blog.einval.com/