guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#45692] [PATCH 0/3] Better Support for ZFS on Guix


From: Maxime Devos
Subject: [bug#45692] [PATCH 0/3] Better Support for ZFS on Guix
Date: Thu, 17 Mar 2022 18:22:04 +0100
User-agent: Evolution 3.38.3-1

Liliana Marie Prikler schreef op do 17-03-2022 om 09:24 [+0100]:
> In any case, I've added Maxime to CC so they can have a closer look at
> it.

I have been more-or-less ignoring the ZFS patches since some time after
<https://issues.guix.gnu.org/45692#44>.  If ZFS people(^), after a
disagreement about licensing concerns, directly jump to accusations of
gaslighting and sabogate, completely ignoring my previous arguments (*)
without trying to refute any of them or bringing new arguments, then I
don't want to be involved with ZFS.

(^) So far only Mason Loring Bliss, _not_ raid5atemyhomework! 

Also, the various ‘work-arounds’ around the GPL<->CDLL incompatibility
still seem super fishy to me even if they _might_ be technically
correct.  To me, this makes reviewing the code practically pointless --
why review the zfs service patches if they will have to be reverted
due to incompatibility concerns anyway?  Summarised:

  * The ‘Oracle does not care so no legal risk’ argument:

    - Oracle might not care, but there are other parties involved as
      well (e.g. the Linux people and contributors to OpenZFS).
    - Not getting caught doesn't mean things are above board.  It just
      means you haven't got caught, and you might get caught later.
    - Has anyone actually ever asked Oracle for some official ‘yes,
      go ahead’ / ‘no, here's a DMCA notice / see you at YYYY-MM-DD
      in court’ / ‘no, but you're too small fry to bother so you'll
      get away for it ... for now’ response?

      AFAICT, this has not been done.
    - Even if it would be very strange for Oracle to try to stop (the
      Linux part of(*)) OpenZFS, why would that stop Oracle and how
      would the odd behaviour actually legally matter?

  * The ‘zfs package is already in Guix’ argument
    (https://issues.guix.gnu.org/45692#47): then it should be
    reverted when the incompatibility is discovered.

    Also, the incompatibility issue has been noted before:

    https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00404.html

    though it appears to have been forgotten in

    https://lists.gnu.org/archive/html/guix-patches/2019-12/msg00543.html

    presumably because different people were involved?

  * The ‘Guix is not distributing the source code, it's only pointing
    to the source code’ argument:

    - We do distribute the source code, at https://ci.guix.gnu.org
    - probably also via our friends at SWH
    - and via the Wayback Machine fallback
    - possibly also to any Guix users on the local network, when using
      '--advertise' and '--discover'
    - and by delegating the distributing to the OpenZFS project
    - even if pointing to the tarball OpenZFS web would not count as
      distribution, assuming there's a license incompatibility (and
      hence, the Linux part of OpenZFS is illegal (*), wouldn't this
      pointing count as facilitation of a crime (or misdemeanor or
      contract breach or whatever's the local terminology), wouldn't
      this make Guix or individuals behind Guix accomplishes?
    - even if it's all legal, what about freedom 3 -- the freedom
      to distribute the program?
    - also, not being able to distribute the source code by ourselves
      seems rather inconvenient

  * The ‘we're not doing binary distribution’ argument:

    - That seems rather inconvenient, why not use BTRFS instead which
      seems quite capable and doesn't have this weird restriction?
    - Freedom 3 is:
      ‘The freedom to redistribute copies so you can help others
      (freedom 2).’  Guix redistributes copies is a convenient form,
      to help all users (‘others’).  To help the users, it not only
      redistributes in source form, but also in binary form
      (substitutes).  But the CDDL+GPL combination stops us from
      helping others by redistributing binary copies!

      Basically, if there's the freedom to redistribute copies,
      shouldn't this include _binary_ copies, especially when
      binaries are convenient?
   - We _are_ doing binary distribution:

     (here, ‘we’ includes all relevant users of Guix)

     An uninitiated user might do "guix system image ..." to
     produce an image (that happens to include a binary ZFS),
     dutifully uses "guix build --sources=transitive" and share
     the sources+binary with other people, and accidentally commit
     a violation.

     All the initrd, system image and "guix pack" would need to
     propagate unsubstitutability (and the top-level tools might need
     to error out) and this needs to be tested, AFAIK this has not
     been done.

  * The ‘we're not distributing _modified_ source code’ argument:

    Freedom 4!  We should be able to (legally) distribute modified
    source code as well.

  * Various ’technically, because of Section 1 (bis) alpha Z of this
    license, Paragraph 2 beta 3 of that license, this and that clause
    do not apply’ arguments:

    This seems to be missing the spirit, and the law is, to my limited
    knowledge, not a deterministic automaton with an exact mathematical
    formulation without any bit flips.

Greetings,
Maxime.

(*) The BSD modules are presumably fine though (unverified)!  But Guix
does _not_ (currently) support BSDs.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]