Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03435.jsonl.gz/1547

Fr, 11. März 2022, Ralf Hersel
Kurz nach dem Kriegsbeginn in der Ukraine, haben viele Tech-Firmen begonnen, ihre Aktivitäten in der Russischen Förderation zu beschränken oder ganz einzustellen. Dazu gehören Apple, Samsung, Microsoft, Meta, Oracle und viele andere. Das sind privatwirtschaftlich organisierte Unternehmen, die proprietäre Software und Services anbieten; das geht in Ordnung und obliegt deren unternehmerischen Entscheidung.
Eine andere Sache ist es, wenn sich Organisationen aus der Open-Source-Szene zu solchen Schritten entscheiden. Am 2. März hat das Analyse-Gateway Scarf begonnen, den Zugang zu Open-Source-Paketen für russische Regierungs- und Militäreinrichtungen über sein Gateway zu beschränken. In einer Ankündigung des Unternehmens schreibt der CEO von Scarf, Avi Press, dass:
"Scarf bis auf Weiteres alle Downloads von Paketen und Containern, die von russischen Regierungsquellen stammen, blockieren wird."
Dies ist bemerkenswert, da sich die Beschränkung hier auf Freie Software und nicht auf proprietäre Software bezieht.
Die Definition der OSI dazu ist eindeutig: Es darf "keine Diskriminierung von Personen oder Gruppen" und "keine Diskriminierung von Arbeitsgebieten" geben. Jedes dieser Kriterien gilt für die Lizenz der besagten Open-Source-Software. Auch die vier Freiheiten sprechen eine klare Sprache; insbesondere diese:
Verwenden:
"Freie Software darf für jeden Zweck genutzt werden und ist frei von Einschränkungen wie dem Ablauf einer Lizenz oder willkürlichen geografischen Beschränkungen."
Dies betrifft die Lizenzbedingungen Freier Software, sagt jedoch nichts über die Verteilung derselben Software aus, argumentiert Avi Press:
"Es gibt einen Unterschied zwischen dem Code und den Repositories, in denen wir gemeinsam an dem Code arbeiten, und den Vertriebskanälen, über die der Code verbreitet wird. Nur weil man die freie Erlaubnis hat, den Quellcode selbst herunterzuladen, heisst das noch lange nicht, dass man eine Docker-Anwendung herunterlädt, so dass man ein ganzes Infrastruktur-Ökosystem innerhalb einer Firewall aufsetzen kann, und alles funktioniert auf Knopfdruck - das sind zwei völlig verschiedene Dinge. Mehr Kontrolle über den Vertriebskanal zu haben, hat keinen wirklichen Einfluss auf das, worum es bei diesen Lizenzen geht."
In seinem Blogbeitrag fordert er andere Unternehmen im Open-Source-Bereich auf, diesem Beispiel zu folgen, und merkt an, dass "jede Paket- und Container-Registrierungsstelle auch eine bessere Beobachtbarkeit der Verteilung bieten muss, damit wir diese Bemühungen im gesamten OSS-Ökosystem wirksam machen können."
Mindestens zwei Unternehmen (GitHub und GitLab) haben es abgelehnt, den Zugang für Nutzer in Russland zu beschränken, wohl auch, weil die Forderungen weiter gefasst waren als die Beschränkung des Zugangs auf die russische Regierung und militärische Organisationen.
Zwischenzeitlich gab es einige Anfragen an die Free Software Foundation (FSF) im Sinne von:
"Sollen und können wir Massnahmen ergreifen, um den Zugang Russlands zu unserer Software zu verhindern/einzuschränken?"
Dazu gab es gegensätzliche Kommentare, welche aber überwiegend die vier Freiheiten unterstützten. So äusserte sich Thomas Lord (Arch) wie folgt:
"Ich denke, wir wollen, dass freie Software in Russland und in jeder Gesellschaft gedeiht, weil das den Nutzern mehr Freiheit gibt, das zu tun, was sie für das Beste halten."
Zu dieser Haltung gab es auch Widerspruch:
"Wir können nicht gleichzeitig die wachsende Akzeptanz von freien und Open-Source-Technologien durch Regierungen und Militärs auf der ganzen Welt feiern und uns von jeglicher Verantwortung freisprechen, wenn unsere Arbeit verwendet oder missbraucht wird, um Schaden in noch nie dagewesenem Ausmass zu verursachen."
Die OSI hat eine differenzierte Haltung:
"Pauschale Beschränkungen für Russland schaden den russischen Bürgern weit mehr als dem russischen Militär und den mächtigen Eliten, die sicherlich über die Mittel zur Entwicklung von Umgehungslösungen verfügen. Allerdings ist die Beschränkung des Zugangs zu Open-Source-Distributionen ein wirksames Mittel des Protests."
Und auch:
"Die Lizenzen besagen nicht, dass Einzelpersonen und Unternehmen weiterhin mit einem Tyrannen Geschäfte machen müssen. Die Einschränkung der Verbreitung und nicht die Änderung der Lizenzierung ist ein feiner Unterschied."
Am Anfang der Lieferkette für Freie Software sind die Dinge klar und einfach. Software wird unter einer freien Lizenz geschrieben und steht damit jedem für jeden Zweck zur Verfügung. Das gilt sowohl für Copyleft-Lizenzen (z.B. GPL), als auch für Non-Copyleft-Lizenzen (z.B. BSD-Lizenz). Der Quelltext des Werkes muss bereitgestellt werden. Damit ist die Verwendung theoretisch für jeden und jede möglich. «Theoretisch» deshalb, weil kaum jemand das Programm aus dem Quellcode kompiliert.
Die normale Verwendung von Freier Software erfolgt über die weiteren Schritte der Lieferkette. Die Software wird zum Paket in einem definierten Format (deb, rpm, Flatpak, usw.) gebunden, wodurch sie - unter Berücksichtigung ihrer Abhängigkeiten - installiert werden kann. Dieser Schritt ist keine Pflicht, die durch die Lizenz erzwungen wird, sondern liegt im Ermessen der Entwickler. Hierbei sehe ich keinen Ansatz für Blockaden, da der Schritt in der Regel der Entwicklerin obliegt und in deren Interesse ist. Wer Freie Software schreibt, um sie zu verbreiten, wird sich nicht gegen deren Paketierung sperren.
Nun könnte ein Entwickler von Freier Software auf die Idee kommen, sein Werk nicht den Tyrannen dieser Welt bereitstellen zu wollen. In diesem Fall müsste die Lizenz gewechselt werden. Eine freie Lizenz erlaubt diese Einschränkung nicht, weil sie ihren eigenen Grundsätzen widersprechen würde.
Der dritte Schritt (es könnte auch der zweite sein) ist die Publikation von Code und Paket auf einer Versionierungs-Plattform, wie Github, Gitlab, Codeberg, eigene Git-Instanz oder auch nur auf einer Homepage. Damit gelangt die Anwendung endgültig in die Öffentlichkeit, da sie durch eine Internetsuche gefunden werden kann. An dieser Stelle entscheidet die Entwicklerin nicht mehr darüber, wer die Software nutzen kann, bzw. wem sie verwehrt bleibt. Falls Microsoft entscheidet, dass Github in Russland nicht mehr zur Verfügung steht, ist das eben so. Ausgenommen sind selbstverständlich selbst gehostete Git-Instanzen.
Der nächste übliche Schritt in der Lieferkette ist die Bereitstellung des Paketes in einem Repository oder auf Verteil-Plattformen, wie z.B. Flathub, Snap-Store, F-Droid, sowie die anderen bekannten App-Stores für Smartphones. Dadurch gelangt die Software in den direkten und einfachen Zugriff von Endanwendern. Auch hier gilt dasselbe, was ich beim vorherigen Schritt beschrieben habe: falls F-Droid in Russland verboten wird, gibt es keinen bequemen Zugriff auf die App.
Quellen: