Web lists-archives.com

Re: ZFS in Buster







I hope that we do not choose to open the zfs discussion at this time.

If it does get opened, I think my approach would be to try and educate
the community about the various different viewpoints, find text for GRs
that would allow key stakeholders to believe their positions were
respected and considered (and that we were setting global policy not
trying to unreasonably micromanage ftpmaster), and hold a vote.
I don't think we could come to a rough consensus on zfs as a project; we
have a position  that at least at the time was working for ftpmaster and
the zfs maintainers.


However please consider the following.
I think the Software Freedom Law Center (SFLC's) blog post on zfs
https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html is
the most pro-zfs legalish position that seems credible to me.
I understand that blog post is not legal advice,  but it's the kind of
nuanced and complex reasoning you're going to get from a lawyer if
you're working to find a legally defensible way to be permissive.
That position basically depends on arguing that by their actions the
kernel community has interpreted the boundary of derivative works
somewhat different than the FSF typically does.  I haven't read the blog
post recently, but it basically argues that the kernel community could
if they choose make the boundary even more clear.
But a key take away is that they are arguing that it's the intent of the
copyright holders that matters here.
Yeah, that sucks for people who want clear answers because the intent of
the kernel copyright holders is mixed.

Except now we're seeing a different intent expressed.  We're seeing the
kernel developers choose to close off some interfaces.
So, even under a very permissive (but IMHO still legally credible)
interpretation, the kernel developers are moving *away* rather than
*towards* zfs not being permitted to use the SIMD interfaces.

I have really high confidence that even if you reopen the discussion,
you're not going to convince the project of a legal position more
permissive than that advanced by the SFLC.

And if you take the Software Freedom Conservancy (SFC)'s position
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/-UUU:**--F1
*unsent wide reply to Aron Xu*   Bot L50    (Message SC:f MML Abbre
which is a fairly typical position from someone who values a strong GPL
over being permissive in what we allow users to do, well, the issue is
fairly cut & dry.

So if people really are uncomfortable with the position--if getting some
sort of real closure would be worth a month or so of putting together
educational material, rangling text for a GR, and having a vote, let's
do that.  I think it will be painful, but I do totally understand that
issues like this can be painful if you feel a position was not given
adequate consideration.
But no matter what we do I suspect we'll find that getting a project
level consensus to revert commits so zfs can use certain interfaces ends
up being very unlikely.
That's only my prediction.  As DPL, I'll run the discussion fairly if
that's what we need to do.
I'd rather spend time on other things unless this is something a
significant number of people in our community need.


Meanwhile I'd like to thank the zfs maintainers, the former DPL,
ftpmaster, and all the parties that contributed to the balance we have
today.

Attachment: signature.asc
Description: PGP signature