ZFS/ZoL und Linux 5.0

[hikaru]

Eine Relizensierung des Quellcodes, die die GPL einfordert, bezieht sich nur auf das Gesamtwerk, welches durch die Verlinkung von Elementen von GPL lizensierten Code und einem anders lizensierten Code entsteht. Der "Fremdcode" darf alleine weiterhin unter der angegebenen Lizenz weitergegeben werden.

Natürlich! Das setzt aber trotzdem voraus, dass der Autor des CDDL-Codes damit einverstanden ist, dass sein Code unter GPL verbreitet wird. Was, wenn er zwar mit dem GPL-lizensierten Projekt (Linux) einverstanden ist, nicht aber mit der Lizenz an sich - wenn er z.B. nicht möchte, dass sein Code (als Teil des Kernels) infektiösen Charakter annimmt?
Ich halte das für ein valides anliegen. Ich sehe hingegen nur einen einzigen Punkt, der die unbedingte Forderung der GPL auf Unterwerfung von Fremdcode rechtfertigt, und das ist der Wunsch, das Gesamtwerk lizenzrechtlich einfach zu halten. Einfachheit in allen Ehren, aber ich finde es sollte auch andere Wege geben, die Aufgabe, ein Gesamtwerk zu erstellen, zu lösen.

Der Grund für diese Forderung ist die Befürchtung, dass bei einer Doppellizensierung, etwa GPL und BSD, zusammengesetzter Werke ein Einfallstor zur Umgehung des starken Copyleft gegeben sei.

Deshalb schrieb ich ja "hinreichend kompatibel". Es könnte z.B. eine Anforderung an unter Originallizenz eingebetteten Code sein, dass er selbst unter einer Copyleft-Lizenz steht.

Falls - wie Du sagst - die CDDL sich gegen diese Bedingungen wehrt (oder verwehrt), dann ist das selbstverständlich ein Grund von Seiten der FSF aus zu sagen: In dem Fall ist diese Lizenz nicht kompatibel zur GPL.

Natürlich. Aber es zäumt trotzdem das Pferd von hinten auf. Wenn ich dem Polizisten erzähle, dass ich dich nur geschlagen habe, weil du mir deine Brieftasche nicht freiwillig gegeben hast, dann mag das zwar stimmen, aber das Grundübel bleibt trotzdem, dass ich sie überhaupt von dir gefordert habe.

Die Bedingungen der GPL gelten nun mal in einem GPL-lizensierten Code. Da kann die FSF nicht einfach so tun als wäre das egal.

Aber sie diktiert die Bedingungen der GPL. Und wenn die GPL einseitig etwas fordert, kann man nicht andere Lizenzen dafür verantwortlich machen, wenn sie eine andere Auffassung vertreten.

Die Frage, die sich mir stellt, ist eher: Sind die Bedingungen der CDDL tatsächlich unbedingt inkompatibel zur GPL?

(Disclaimer: Laiengefasel) Ja, denn die GPL fordert eine Relizensierung von CDDL-Code und die CDDL lässt das nicht zu. Das ist aber nicht die Schuld der CDDL, so wie es nicht deine Schuld ist, dass du dich gegen meinen Versuch, deine Brieftasche zu kriegen wehrst.

Wenn es so sein sollte, dass die Inkompatibilität "in Wahrheit" gar nicht gegeben und lediglich eine unzutreffende Behauptung der "Taliban" sei, dann sehe ich keinen Grund, warum die Lizenzrechteinhaber eines CDDL-Codes nicht diese kleine Geste der expliziten Erlaubnis den Code so verwenden, wie es die GPL vorsieht, zu geben. Um des lieben Frieden willens.

Wenn das so drastisch wie du es formulierst zuträfe, dann relizensiert die CDDL schon deshalb nicht, weil man nicht mit "Terroristen" verhandelt.
Aber ich denke wir sind uns einig darüber, dass unser Argumentationsniveau in den Gänsefüßchen hier gerade die Wasserlinie unterschreitet. Und ich kann so schlecht plappern wenn ich die Luft anhalte.

Mir ist unter den Umständen einfach nicht wirklich verständlich, was diese Lizenz [Anm: CDDL] zusätzlich zu den schon vorhandenen freien Lizenzlösungen eigentlich leisten soll.

Sie stellt eine nicht-infektiöse Copyleft-Lizenz bereit. Ich halte das für einen lobenswerten Ansatz, der mir eigentlich sympathischer ist als die GPL. Im Endeffekt siegt aber auch bei mir hier Pragmatismus über Sympathie, so dass ich ein Werk im Zweifelsfall eher unter GPL als CDDL stellen würde, falls ich mich für eine einzige von beiden entscheiden müsste.

[wanne]

Sie stellt eine nicht-infektiöse Copyleft-Lizenz bereit.

Das ist falsch. Ganz im Gegenteil ist die CDDL ja nochmal eine Nummer härter. Sie verlangt sogar, dass du Patente auf kombinierte Werke nicht durchsetzen darfst. Und genau da kollidiert sie mit der GPL, die das erlaubt. (Im Sinne du darfst mit deinem Code machen was du willst.)

Der andere Fall wäre ja, dass die Vertreter der CDDL ebenfalls eine Inkompatibilität sehen bzw. eine explizite Konkurrenz zur GPL anstreben und dementsprechend auch einfach sagen könnten: Ja klar, sind die Lizenzen nicht miteinander vereinbar. War so gedacht.

Das ist so ein bisschen gespalten. Einige ehemalige Mitarbeiter von Sun sagen,man habe von Anfang an von der Problematik gewusst und die passende Patenklausel aber für wichtiger als die Kompatibilität zur GPL gefunden. Andere sagen die Lizenz wäre erst nach dem Gehen der vorherigen Mitarbeiter finalisiert worden und man hätte sich absichtlich mühe gegeben, kompatibel zur GPL zu sein. Offizielle Aussagen von Sun gab es nie.
Meine Verschwörungstheorie ist, dass SUN absichtlich die Gegenteiligen Behauptungen da gelassen hat. So hat man Komptibilität in der Grauzone zum Anfixen und wenn die Rechtsabtilungen meckern wäre man halt auf Solaris gewächselt.So wie MS mehr oder minder dabei erwischt wurde, Cracks für windows gebaut zu haben. Damit man chinesiche firmen erst mal anfixt und dann wenn sie genug Geld haben doch Geld verlangt.
Am Ende gehen die jetztihen ZoL-Entwickler offensichtlich davon aus, dass man nicht kompatibel zur GPL ist, sonst hätte man ja nicht so ein Problem damit gehabt, dass die passenden Funktionen jetzt explizit GPL gemarkt wurden.

Ich verstehe zwar, dass die FSF als Stallmeister der GPL diesen Standpunkt wählt, halte hier das Pferd aber trotzdem für von hinten aufgezäumt.

Im Prinzip hat die GPL mit der v3 ja gezeigt wie man es machen kann, dass man trotz Patentklausel (vermutlich) kompatibel zu v2 bleibt. Ursprünglich wollte SUN da ja mitmachen und hat dann aber den Rückzieher gemacht.

Die CDDL ist nicht inkompatibel zur GPL. Die GPL ist inkompatibel zur CDDL.

Inkompatibel ist eine symmetrische Relation. Und Fakt ist, die GPL war zuerst da. Die GPL konnte keine Rücksicht auf die CDDL nehmen. In die andere Richtung wäre das aber gegagnten. Wie schon angemerkt wurde hat ja sogar die FSF mehr oder minder zugegeben, dass die CDDL in mancherlei Hinsicht besser als die GPLv2 ist. Nur die nichtkompatibilität zur GPL ist halt doof.

[hikaru]

Sie stellt eine nicht-infektiöse Copyleft-Lizenz bereit.

Das ist falsch. Ganz im Gegenteil ist die CDDL ja nochmal eine Nummer härter. Sie verlangt sogar, dass du Patente auf kombinierte Werke nicht durchsetzen darfst. Und genau da kollidiert sie mit der GPL, die das erlaubt. (Im Sinne du darfst mit deinem Code machen was du willst.)

1. Hat die Frage nach Patenten nichts damit zu tun, ob eine Lizenz infektiös ist oder nicht. Die Aussage die du hier von mir zitierst ist also nicht falsch.

2. In welcher Weise stehen die Patentklauseln aus Punkt 6, der CDDL im Konflikt mit den Bestimmungen der GPL? Die CDDL sagt aus, dass deine Lizenzrechte dann verfallen, wenn du gegen Autoren des erhaltenen Codes patentrechtlich vorgehst.
GPL v3 verlangt in Punkt 11. Patents. sinngemäß, dass du Nutzungsrechte an Patenten mit der Software weitergibst. Die Situation, dass du nach CDDL deine Lizenz verlierst kann nie eintreten, da du nach GPL bereits der Nutzung deiner Patente zugestimmt hast.

Die CDDL ist nicht inkompatibel zur GPL. Die GPL ist inkompatibel zur CDDL.

Inkompatibel ist eine symmetrische Relation.

Nein. Du darfst CDDL-Code nicht in ein GPL-Projekt einbinden, weil die GPL die Forderung stellt, den CDDL-Code zu relizensieren. Du darfst aber GPL-Code in ein CDDL-Projekt einbinden, weil die CDDL keine vergleichbare Forderung aufstellt.

[wanne]

GPL v3 verlangt in Punkt 11

Der Kernel ist aber (in erster Linie) GPLv2

Du darfst aber GPL-Code in ein CDDL-Projekt einbinden, weil die CDDL keine vergleichbare Forderung aufstellt.

Die CDDL stellt die Forderung Auf, dass du Patente auch auf kombinierte werke nicht durchsetzen darfst. Natürlich ist das viral.
So wie btw. defakto jede üblichere Lizenz abgesehen von CC0. Und auch da ist strittig wie weit die international durchsetzbar ist. Am Ende passen andere Lizenzen üblichwerweise halt nicht mit dem Vorhandensein des Urheberrechts überhaupt zusammen. – Ganz abgesehen davon, dass sie bei 99%-Werkanteil mit viralen Lizenzen früher oder später defakto von so einer geschluckt werden.
Und nein. Die GPL verlangt keine Relizenzierung unter GPL. Sie verlangt lediglich eine Lizenz, dass du die Rechte des Nutzers nicht weiter einschränkst. Genau deswegen ist der obere Punkt relevant.

[hikaru]

Der Kernel ist aber (in erster Linie) GPLv2

Du hast GPL v2 in's Spiel gebracht. Darauf bezog ich mich. GPL v2 sagt gar nichts zu Patenten, abgesehen davon, dass die Lizenzbestimmungen nicht die Absicht haben, Patente zu verletzen.

Die CDDL stellt die Forderung Auf, dass du Patente auch auf kombinierte werke nicht durchsetzen darfst. Natürlich ist das infektiös.

Die CDDL fordert, dass du keine Patentansprüche auf "Covered Works", also unter der CDDL stehende Teile durchsetzt. "Larger Works", also kombinierte Werke, bestehen aus "Covered Works" und anderen Teilen. Über diese anderen Teile sagt die CDDL nichts. Eben deshalb ist sie nicht infektiös.

So wie btw. defakto jede üblichere Lizenz abgesehen von CC0.

Das stimmt nicht. Mir fällt auf Anhieb keine Freie Lizenz außer der GPL (und Abkömmlingen) ein, die infektiös ist. (Vielleicht übersehe ich aber gerade auch eine oder zwei.)
Insbesondere die ganzen Lizenzen ohne Copyleft sind nicht infektiös. Infektösisät geht überhaupt nur mit Copyleft, denn ohne Copyleft lässt sich Infektösität nicht durchsetzen. Copyleft impliziert aber nicht zwangsläufig Infektösität, je nachdem auf welche Teile eines Werks sich das Copyleft bezieht.

Und nein. Die GPL verlangt keine Relizenzierung unter GPL.

Doch. Wenn ein Gesamtwerk als solches verteilt wird, dann wirkt die GPL auf alle Teile:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

[nudgegoonies]

BTRFS wird davon sicher nicht 'profitieren' - da es ganz klar nie mit dem Maßstab "production safe" entwickelt wurde und mittlerweile sämtliche größeren Firmen die Unterstützung bzw Entwicklungsarbeiten eingestellt haben. BTRFS wird also weiterhin eine Totgeburt bleiben.

Nur weil RedHat es nicht supported soll BTRFS eine Totgeburt sein? RedHat supportet vieles aus der Open Source Welt nicht. Was auch völlig verständlich ist, weil sie vor allem in Anbetracht von LTS Zeiträumen sich auf möglichst wenig Software beschränken müssen. Denn sie müssen sie schließlich sehr lange selber pflegen. Ich hatte mir vor Jahren mal die RedHat Kernel Sourcen angesehen. Ihre Patches für den Kernel waren größer als die Sourcen des Vanilla-Kernel. Von daher werden sie auch innerhalb eines Linux-Kernels nicht alles supporten und backporten, sondern nur das, was sie auch pflegen wollen und können. SuSE dagegen propagiert BTRFS sogar und entwickelt es aktiv weiter. Ich nutze es jetzt schon länger und es läuft bei mir völlig stabil.

Wenn überhaupt jemand Profitiert, sind das FreeBSD und illumos - da beide noch mehr als bisher die de-facto Standard-Entwicklungplatformen für ZFS sein/bleiben werden und - sofern der CDDL-FUD und gezielte blockade von OpenZFS in Linux weiter betrieben wird - dürften auch einige Entwickler und Firmen (wieder) zu FreeBSD oder illumos abwandern (ich denke da z.B. speziell an Nexenta, die einen großen Teil an OpenZFS/ZoL-Entwicklern beschäftigen).

Erstens: Die Lizenzen sind so wie sie sind. Manche finden die GPL schlecht weil sie "viral" ist. Manche finden sie gut, weil sie dafür sorgt, dass auch alle Änderungen "frei bleiben" müssen und sich niemand bereichern kann. Manche finden die BSD schlecht weil sie eine "Schmarotzer-Lizenz" ist, wo sich Firmen bei der Community bedienen ohne etwas zurückzugeben. Manche finden die BSD gut, weil nur sie die Freiheit gewährt entsprechend lizenzierte Software komplett in "kommerzielle Anwendungen" zu übernehmen. Ich bin kein Anwalt. Die Vor- und/oder Nachteile der CDDL kenne ich nicht. Ich weiß nur, dass GPL und CDDL inkompatibel sein sollen. BSD und CDDL sollen kompatibel sein. Man kann unter Linux auch kommerzielle Software bauen und nutzen. Aber ein Dateisystem, was komplett im Kernel-Mode läuft und mit Kernel-Subsystemen und internen Kernel-Schnittstellen interagiert, die gar nicht nach "außen" exponiert werden, ist wohl doch eher Teil des Kernels. Es gibt aber wohl auch bei Treibern so eine Art interne API, die sich häufig ändert, und eine externe API, wo ja auch NVIDIA mit seinen nicht-freien Treibern andockt. Und ZFS hat ewig eine interne API benutzt die seit Ewigkeiten deprecated ist. Da ZFS wegen der Lizenz nicht Teil des offiziellen Kernels wird müssen die ZFS Entwickler halt immer nachfixen. Und es fehlen somit auch die Entwickler, die sich auch mit dem Dateisystem beschäftigt hätten, wenn es denn echter Teil des Linux Kernels wäre. DKMS Treiber fühlen sich häufig wie ein Fremdkörper an. Es gibt welche, die immer funktioniert haben. Und es gibt welche, wahrscheinlich die, die nicht schnell genug auf Änderungen an der internen API reagieren, wo jedes Kernel-Update ein Lotteriespiel ist.

Zweitens: Was Storage Server betrifft könntest Du bei der Betriebssystemwahl recht haben. Die werden ja hauptsächlich als Komplett-Systeme verkauft und werden dann auf unterschiedlichsten Art und Weisen per Netzwerk angebunden. Da ist das Betriebssystem und das darunterliegende Dateisystem egal. Hauptsache die API (DRDB, S3, etc.) ist stabil. Für normale Linux-Desktop-Anweder ist ZFS dagegen viel zu kompliziert aufzusetzen und für normale Compute Server, die eh nur kleine Platten und dafür aber immer einen Raid-Controller haben, bringt es auch keine Vorteile außer vielleicht Snapshots. Die hat BTRFS auch. XFS soll sie übrigens demnächst auch können.

[Colttt]

BTRFS wird davon sicher nicht 'profitieren' - da es ganz klar nie mit dem Maßstab "production safe" entwickelt wurde und mittlerweile sämtliche größeren Firmen die Unterstützung bzw Entwicklungsarbeiten eingestellt haben. BTRFS wird also weiterhin eine Totgeburt bleiben.

Für dich sind also Oracle, Synology, Fujitsu, SuSe, Facebook uvm nur kleine Klitschen?

Du hast recht BTRFS ist nicht das gelbe vom Ei und sie opfern machmal Ausfallsicherheit für usebility (Bsp: im RAOD10 darf insgesamt nur eine Platte ausfallen) aber ist nicht per se schlecht. Wir nutzen es oft als / -Dateisystem. Und wenn man sieht wie langsam und zäh die Entwicklung da geht ist das schon traurig, immerhin ist es schon über 10Jahre alt.

Wobei ich hoffe das bcachefs bald in den Kernel kommt.