Ebbene, la mossa sembra che stia causando non poche perplessità (sono intervenuti addirittura Lennart Poettering, Matthew Garrett ed Alan Cox): dai possibili problemi di licenza tra la Common Development and Distribution License (CDDL) e la GNU General Public License (GNU GPL) - motivo storico della mancata inclusione di ZFS in Linux - al motivo per il quale Canonical non abbia scelto BTRFS come file system di riferimento, specie considerando la sua integrazione con machinectl (systemd).
Ma vediamo un po' più nel dettaglio qual è l'incompatibilità tra la GNU GPL e la CDDL e perché ZFS non può quindi essere integrato direttamente nel kernel Linux.
La CDDL è una licenza che deriva dalla Mozilla Public License (MPL) ed è simile alla GNU LGPL, salvo il fatto che ha un copyleft debole che si applica solo ai file rilasciati sotto tale licenza e non all'intero progetto.
Il che significa che è possibile espandere il prodotto rilasciato sotto licenza CDDL e rilasciarlo come closed source, limitandosi a rilasciare i sorgenti della sola parte CDDL.
Il rilascio di tale parte rimane naturalmente obbligatorio, così come il rispetto di tale licenza. Ma come ho scritto prima, si limita solo ai FILE già rilasciati.
Questo rende impossibile all'atto pratico un mix con la GNU GPL che invece impone che non ci siano "limitazioni" di questo tipo per evitare espansioni closed source di software open, mentre invece sarebbe stato possibile se il codice fosse stato rilasciato sotto BSD, in quanto quest'ultima permette la redistribuzione di tutto il codice sotto diversa licenza, cosa già avvenuta in passato e che - a dirla tutta - ha attirato non poche critiche dal mondo BSD, che si è visto impossibilitato nel prendere le migliorie apportate da Linux al codice originario.
Questo cosa vuol dire all'atto pratico? Beh, vuol dire che non potremo mai vedere ZFS nel trunk del kernel Linux.
Tuttavia non vuol dire che ZFS non possa essere portato da noi. Il porting infatti è stato fatto sia via FUSE (zfs-fuse, che se non ricordo male è defunto da tempo) e sia tramite modulo nativo nel progetto ZFSonLinux.
Tutto ciò che non si deve fare è unirli nel kernel e distribuire il tutto come un blocco unico. Tuttavia, non è affatto vietato pacchettizzare ZFS e distribuirlo nella propria distro come modulo a sé.
Ora, al di là della questione legale, che pare sia stata già affrontata dagli avvocati di Canonical:
sebbene in molti abbiano fatto notare che ZFS sia effettivamente nello stesso trunk del kernel Linux, e sebbene nella wiki di Ubuntu gli accenni al conflitto di licenza tra CDDL e GPL siano stati "misteriosamente" eliminati dallo stesso Kirkland.Dustin Kirkland ha scritto:Our lawyers have examined the licenses in detail and we see no problem. ZFS remains CDDL and the kernel GPL. zfs.ko ships add a kernel module.
(EDIT: A tal proposito sembra che la storia non sia destinata a finire tanto facilmente)
Quello che IMHO traspare da questa mossa è una manovra anti-Red Hat per cercare di catturare l'attenzione di sysadmin Solaris, notoriamente affezionati a ZFS e spesso avversi a BTRFS.
In sostanza è come se Canonical IMHO stesse cercando di dire: "ehi, gente: state scappando da Oracle e dai suoi contratti di licenza assurdi? Beh, non c'è più bisogno di disperarsi. Anche se Linux non è Solaris, noi vi offriamo un completo supporto a ZFS sui vostri container."
Questa sensazione è data dal modo in cui viene presentata la cosa
Dato che Ubuntu Server, sebbene sia uno dei big player per quanto riguarda OpenStack, non può facilmente scardinare il dominio di Red Hat Enterprise Linux, allora cerca di far breccia in coloro che stanno lasciando le lande Oracle.ZFS one of the most beloved features of Solaris, universally coveted by every Linux sysadmin with a Solaris background. To our delight, we're happy to make to OpenZFS available on every Ubuntu system.
Una mossa sicuramente astuta, ma che rischia di distruggere ancora di più la già precaria reputazione di BTRFS, che dopo 9 anni di sviluppo non è riuscito a guadagnarsi lo stesso rispetto che l'IT nutre per il suo rivale, specialmente a causa del suo diverso design che lo ha portato a diverse limitazioni, tra cui la mancanza di una gestione seria delle opzioni di montaggio dei subvolumi rispetto alle properties dei dataset ZFS, mancanza della gestione dei block device (ZVOL in ZFS) che permettono di eliminare completamente l'uso di LVM, deduplicazione on-line integrata, nessuna integrazione con NFS e CIFS, e specialmente col primo attraverso il supporto al mixed case, case insensitive e ACL NFSv4/Windows NT ed il non essere a 128-bit.
Senza contare che BTRFS si è visto privato del supporto da parte dell'azienda che l'ha creato, Oracle, che ha stipendiato Chris Mason (ideatore e team leader di BTRFS) fino a qualche anno fa, per poi vederlo lasciare la compagnia dopo l'acquisizione di SUN e l'offerta di soluzioni storage totalmente ottimizzate per ZFS.
Ora, naturalmente BTRFS ha molti altri partner, tra cui Red Hat, Fujitsu (che tra l'altro sviluppa i processori SPARC insieme ad Oracle su cui poi ci fanno girare Solaris 11 e ZFS ), Intel ecc., ma rimane comunque il fatto che questo file system stia venendo trattato come seconda scelta. E la mossa di Canonical potrebbe rischiare veramente di decretarne il fallimento, se la combinazione ZFS+LXD si dovesse rivelare un successo.