Login
Newsletter
Werbung

Thema: SFC hält Auslieferung von binären ZFS-Modulen für GPL-Verletzung

22 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von gol. am Fr, 26. Februar 2016 um 13:53 #

Es gibt schon einige Überschneidungen von GPL-Fans und SFC. Wundert mich nicht das deren bevorzugte Lizenz eine Kombination mit anderen nicht hergibt, schon aus Eigeninteresse.

  • 0
    Von brrrrrrr am Fr, 26. Februar 2016 um 16:19 #

    Die SFC hat Ihre Argumentation ja dargelegt. Der Kernel trägt nun einmal die GPL V2-Lizenz.

    IMO muss die ganze Sache vor Gericht geklärt werden. Je schneller, desto besser.

    • 0
      Von nico am Fr, 26. Februar 2016 um 17:59 #

      Die Frage, was man wie mit ausliefern darf gibt es seit es Distributionen gibt. Von den einen packt man so manchen Binärblob rein, die anderen werden verteufelt. Je nach Auslegung sind die ganzen Androiden legal oder eben GPL-Brecher. Ob ein fertiges Modul oder ein script zum compilieren und installieren bei gelegt wird sollte nicht den großen Unterschied machen.

      Bei ZFS ist man abhängig von Oracle und deren Juristen. Dass die nicht zimperlich sind ist bekannt. Genau das wird auch der Grund sein, warum bisher alle von offizieller Seite die Finger davon gelassen haben.

      • 0
        Von gol. am Sa, 27. Februar 2016 um 09:02 #

        Es ist dann "legal" wenn die akt. Maintainer des Subsystem das akzeptieren, das geschieht im Kernel ständig. Hier wird nur wieder die Antipathie zu Oracles herausgestellt, alles Nvidia, AMD, Broadcom und die ganzen ARM-Buden verletzen streng gesehen fortlaufend die GPL.

        • 0
          Von Sad am Sa, 27. Februar 2016 um 13:58 #

          Genau so ist es!

          0
          Von Clueless am Mo, 29. Februar 2016 um 09:37 #

          alles Nvidia, AMD, Broadcom und die ganzen ARM-Buden verletzen streng gesehen fortlaufend die GPL

          Nvidia & AMD umgehen sie, aber verletzen sie strenggenommen nicht. Unschön, aber keine Verletzung!

          Broadcom & die anderen ARM-Buden verletzen die GPL in jedem Fall, und nicht nur strenggenommen.

        0
        Von dumichauch am Di, 1. März 2016 um 07:45 #

        Das Problem kommt wohl eher von der GPL-Seite, da hier mehr Copyleft gefordert wird. So ist es ja auch die SFC die Oracle um eine Relizensierung bittet und nicht umgekehrt.

0
Von jb_ am Fr, 26. Februar 2016 um 17:05 #

Habe gerade gesehen, dass Oracle zum Teil auch Software unter GPL stellt. Also kann man davon ausgehen, dass sie nicht grundsätzlich was gegen dieses Lizenzmodell haben. Warum sie sich da bei zfs so quer stellen ist mir schleierhaft.

Als Anwender fände ich es super zfs fest integriert zu haben.

  • 0
    Von -.,-.,.-,-.,-.,-., am Fr, 26. Februar 2016 um 21:27 #

    Btrfs interessiert potentielle Zfs-Anwender offensichtlich nicht? Btrfs hat die "richtige" GPL-Lizenz, wird u.a. von Oracle selbst unterstützt und wenigstens ein kompetenter Linuxdistributor in Gestalt von Suse kümmert sich intensiv mit um Btrfs.

    • 0
      Von Sad am Sa, 27. Februar 2016 um 13:51 #

      Btrfs ist wie Hurd. Im nächste Jahr, da wird es bestimmt etwas werden. ;)

      0
      Von jb_ am So, 28. Februar 2016 um 21:26 #

      Doch, ich interessiere mich schon sehr dafür und beobachte seit längerem den Status. Vor ein paar Wochen hatte ich es dann im produktiv eingesetzt, hat sich aber nur ein paar Tage auf dem System halten können. Für Raidsysteme ist es noch nicht geeignet, zumindest wird es nicht empfohlen. Was mir bei btrfs bis jetzt noch negativ aufgefallen ist:

      - CoW ist problematisch bei großen Dateien, z.B. VM Images
      - autodefrag hat gleiches Problem
      - Kompression funktioniert nur wenn CoW aktiviert ist.
      - erstellen neuer Subvolumes finde ich umständlicher und man muss sie manuell einhängen, in zfs ist das schöner gelöst.

0
Von CptDark am Sa, 27. Februar 2016 um 08:38 #

... ist und bleibt Oracle.
Ich mag diesen Verein und seine Produkte nicht sonderlich (allem voran dieses unsägliche JAVA).

  • 0
    Von Sad am Sa, 27. Februar 2016 um 14:02 #

    Bevor Oracle Java und viele andere Produkte übernommen hatte, hattest du da auch etwas gegen SUN Microsystems? Klar kann man viel an Oracle kritisieren, aber das ist doch mit allen IT- Konzernen so. An erster Stelle steht nun einmal das Geld.

    • 0
      Von gol. am Sa, 27. Februar 2016 um 23:37 #

      Dann könnte man auch SAP, IBM, Facebook und andere Linuxunterstützer nennen die noch schlimmer sind aber mehr Geld an Linux-Lobbyisten zahlen. Sun hat den Bereich Java ganz schön schleifen lassen.

      • 0
        Von brrrrrrrrrr am So, 28. Februar 2016 um 16:25 #

        Das Problem hier geht doch viel weiter.

        Wann und wie wird etwas zu "derived work", nachdem es in irgendeiner Form mit dem Linuxkernel in "Kontakt" gebracht wurde?

        Wie kann so etwas überhaupt bei Zfs möglich sein, wenn es als Solaris-Produkt keine einzige Zeile Linuxkernelcode enthält?

        Was bedeutet das generell, wenn Nicht-GPL-Codefragmente in Kontakt mit dem GPL V2-Linuxkernel geraten?

        Wie ich schon sagte, eine Klage wäre das Beste, da diese Fragen dringend von unabhängiger Seite (nicht von der FSF und SFC alleine) geklärt werden müssen.

        • 0
          Von glasen am So, 28. Februar 2016 um 18:52 #

          Canonicals Anwälte sagen, dass ZFS4Linux kein "derivate work" ist, da das Dateisystem ursprünglich für ein anderes Betriebssystem entwickelt und später nur auf Linux portiert wurde. Dazu wurde extra das Modul "spl" (Solaris Porting Layer) entwickelt, welches unter der GPLv2 steht.

          Interessanterweise gibt es sogar einen Präzedenzfall, der Canonicals Position stützen könnte:

          Andrew File System

          Dieses wurde genau wie ZFS unabhängig von Linux entwickelt und erst später auf Linux portiert. Es verwendet eine Lizenz, die inkompatibel zur GPL ist:

          IBM Public License

          Trotzdem liefern verschiedene Distributionen schon seit Jahren vorkompilierte Module in ihren Kernel-Images aus bzw. ermöglichen die einfache Nachinstallation ohne Kompilierung des Quellcodes. Als Beispiel sei hier nur Debian aufgezeigt:

          https://packages.debian.org/search?searchon=contents&keywords=afs.ko&mode=path&suite=stable&arch=any

          Warum also gibt es Probleme mit ZFS, aber keinerlei Probleme mit AFS?

          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Feb 2016 um 21:53.
          • 0
            Von komsomolze am Mo, 29. Februar 2016 um 03:41 #

            [quote]
            Warum also gibt es Probleme mit ZFS, aber keinerlei Probleme mit AFS?
            [/quote]

            https://en.wikipedia.org/wiki/Andrew_File_System:

            There are three major implementations, Transarc (IBM), OpenAFS and Arla, although the Transarc software is losing support and is deprecated. AFS (version two) is also the predecessor of the Coda file system.

            A fourth implementation exists in the Linux kernel source code since at least version 2.6.10.[7] Committed by Red Hat, this is a fairly simple implementation still in its early stages of development and therefore incomplete as of January 2013[8]

          0
          Von irgendwer am Mo, 29. Februar 2016 um 08:55 #

          Ich glaube nicht, dass die Erschaffung eines getrennten Modules automatisch zu einem "derived work" führt.

          Jedoch ist mir das auch ziemlich egal. Es benötigt gar kein "derived work", um gegen die GPL zu verstoßen. Es ist dort insbesondere auch explizit die Rede davon, dass GPL-Software nicht mit anderer Software kombiniert vertrieben werden darf, sofern diese nicht ebenfalls den Rechten der GPL genügt. Das ist darin ziemlich eindeutig formuliert. Ich frag mich daher, weshalb sich so viele auf das "derived work" versteifen und eine Verletzung von dem Sachverhalt des "derived" abhängig machen wollen.

          Dann ist es halt eben kein "derived work". Na und!? Die Lizenzbestimmungen der GPLv2 besagen, dass entsprechend nach ihr lizenzierte Werke ihre Lizenz verlieren, wenn sie mit nicht unter den Bedingungen der GPLv2 vertreibbaren Werken kombiniert vertrieben werden.

          Kombiniert man zwei Werke (und darunter verstehen die Urheber der GPL recht offensichtlich selber schon etwas anderes als ein abgeleitetes gemeinsames Werk, wenn sie zwischen diesen beiden Umständen unterscheiden) und möchte diese zwei getrennten Werke gemeinsam vertreiben, dann müssen die jeweiligen Bedingungen der jeweiligen einzelnen Werke für sich betrachtet erfüllt werden - darin sind sich wohl alle einig. Erfüllt man nun eine der Bedingungen für eines der enthaltenen Werke nicht, begeht man einen Lizenzbruch - darin sind sich wohl ebenfalls alle einig. Dazu muss das eine Werk gar nicht bzgl. der Lizenz des anderen Werkes betrachtet werden - aka "derived work". Wenn man nun - im Falle der GPLv2 - die Lizenz nicht erfüllt, wenn man es mit einem nicht unter GPLv2 stehenden Werkes kombiniert vertreibt, dann ist für mich ziemlich eindeutig die Lizenz eines der enthaltenen Werke verletzt. Somit darf zwar meinetwegen der nicht betroffene - da nicht unter der GPLv2 stehende - Teil vertrieben werden, sofern es dessen Lizenz zulässt, nicht jedoch der unter der GPLv2 stehende Teil.

    0
    Von Clueless am Mo, 29. Februar 2016 um 09:47 #

    Mit was du so alles Probleme hast.

    Bei mir war zumindest Java nur Anfangs ein Problem, als es noch wirklich saulangsam war.

    Nur warum sollte man jetzt noch ein Problem mit Java haben:
    - steht unter der GPL
    - ist Open Source
    - die OS-Version ist DIE Referenz für Java
    - das "unsägliche" JRE-Plugin wurde "terminiert" :)

0
Von jb_ am Mo, 29. Februar 2016 um 19:41 #

Wer wäre eigentlich der Kläger, wenn das ganze gegen die GPL verstoßt? Oracle doch eigentlich nicht, weil deren zfs ja nicht unter GPL steht und ihre Lizenz nicht verletzt wird. Das Kernel Team hat sicher auch wenig Interesse hier zu klagen, weil sie ja kein Nachteil davon haben.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung