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.
signature.asc
Description: PGP signature
