Arrgh. The same issue in principle, but not in practice. "All the developers" of OpenZFS are Oracle Corporation, plus a few dozen other folks we can grep from the commit log. And if they don't consent and Oracle does, surely the community can duplicate the effort quickly. In practice (that word again) all the meaningful copyright to ZFS sits inside Oracle headquarters. It's just not the same.
(Also, as another poster points out, it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge)
No need to "Arrgh.". I'm asking serious questions that seem relevant, in which I'm interesting in getting actual opinions.
And if they don't consent and Oracle does, surely the community can duplicate the effort quickly.
it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge
As a reference, the AUTHORS[0] file from the 'zfs on linux' project that was imported into ubuntu lists 73 authors not including the Oracle developers, which appear to be both individuals (gmail accounts, etc) and multiple individual businesses (nexenta, ovh, etc)
This still seems to fall in to the category of "It's must be easy for you, because I could totally do it in 2 hours" that developers (such as myself) sometimes fall into where a task is deemed 'easy' because the complexity is hidden. It really seems like neither could easily relicense, so there is no magic wand.
I wondered the same thing: if say the Linux kernel was to be re-licensed, how long would it take to get a hold of all the developers that ever contributed something to it? I'm sure some of them have by now passed away, so they'd have to get a hold of their next of kin?
Also, how does duplicating someone's patches work? If I contributed some really basic piece of code, say a very specific hash map implementation where there aren't really two useful ways of doing it, does another developer get to copy/paste bits of it into their code? What if they name the variables the same and structure the code similarly? What exactly distinguishes the original code and the new replacement if they look similar? The fact that someone else typed it in?
I wondered the same thing: if say the Linux kernel was to be re-licensed, how long would it take to get a hold of all the developers that ever contributed something to it? I'm sure some of them have by now passed away, so they'd have to get a hold of their next of kin?
This came up back when the GPLv3 was first being discussed. At the time, as best as I can recall, the consensus was that it would be effectively impossible. I'm pretty sure that it is, indeed, the case that some of the copyright holders have passed away, and I believe there are some that nobody knows how to contact, etc.
All this is, IIRC, a separate issue aside from Linus not wanting to re-license anyway.
If anyone is really especially interested in this particular point, dig around in the /. archives or maybe Groklaw from that era. That and the lkml, of course. There was a decent amount of discussion and gnashing of teeth over this whole issue back then.
IANAL, but as far as I understand it, the theory is that you commit copyright infringement if you copy, that is, you don't come up with the code by yourself (whether you type it or use a copying tool is irrelevant).
How the courts go about deciding whether you actually copied is tricky; it involves actual evidence (emails, testimonial, etc) and common sense, often in the form of expert opinions (you probably didn't just happen to write a 30 kLOC library that implements everything the same way, with just different variable names).
Now, there is a threshold of originality, that is, if there's only obvious way to write something, it shouldn't be infringing. But considering that rangeCheck() was considered to be infringing (see Oracle v. Google), I'm not sure we can depend on that. Then again, the guy did testify he actually copied it.
There's actually some ambiguity over what it would take to relicense Linux. This came up at the time of GPLv3. Torvalds didn't want to relicense it so the question was moot but there was some discussion.
Look, ZFS on linux is a comparatively small community project with a comparatively small number of developers as such things go. To argue that this requires significant hassle to relicense is... probably correct. If Oracle were to relicense ZFS under GPLv2, the community would have to do some work (in the worst case asymptote: they'd have to duplicate the work that's already been done).
To argue that this is somehow of equivalent complexity to relicensing the entire Linux kernel is... I dunno, I've used up my "arrgh" for this post.
Seriously, I don't understand what you're arguing here.
Seriously, I don't understand what you're arguing here.
I'll try to be a little clearer, but it's basically what I started with and ended with (which you actually appear to agree with)
1.) SFC says 'in this context, Oracle could make everyone's life easier by waving their magic relicensing wand'
2.) I say 'That's not much of an argument.'
3.) I say 'lists 73 authors not including the Oracle developers, which appear to be both individuals (gmail accounts, etc) and multiple individual businesses (nexenta, ovh, etc)'
4.) I say 'It really seems like neither could easily relicense, so there is no magic wand.'
In other words, there is no 'magic wand' because even if Oracle magically did there thing it would not fix the issue that FSC has with Canonical because the actual 'ZFS on Linux' code would still be licensed as CDDL. So it's 'not much of an argument' because it would be hard (if even possible) to get every ZoL contributor to relicense, and thus doesn't solve the problem.
To argue that this is somehow of equivalent complexity
You seem to be getting stuck on some issue of relicensing being equivalent. From a mathematical point of view, I'm sure you could assign some probability to both events (with Linux relicensing having a smaller chance), but it seems like for all intents and purposes, it's zero (even if Oracle relicensed). Do two events have to have equivalent complexity in order to be basically irrelevant as FSC argument? Seems to me like it's just FSC finger-pointing as rhetorical trick (and thus my pointing out it's lack of merit)
VLC re-licensed their project and they had 300 authors.
When people talked about the feasibility of re-license linux to gplv3 (as a thought experiment), people talked about several thousands of authors under the time period of almost 30 years. Several of them are dead.
But the discussion here also lack a significant detail; the target license for which ZFS would switch to. Commenters here on HN has said (unsourced) that the original developers has expressed an opinion that it all would be better if ZFS would be Apache licensed. That way it would be compatible with both GPLv2 and CDDL licensed contributions, and everyone would stop bugging ZFS about it.
In the CDDL, like the MPL that it was modeled after, forward compatibility is not opt-in—unlike the GPL, where you explicitly have to state that it's under any later version if you want to allow for that. (The CDDL does allow you restrict the code to a specific version, but you have to explicitly opt out.)
The CDDL is at 1.0. Sun (Oracle) is the license steward. If they publish CDDL 1.1 tomorrow, and it says you can use the software under the terms of the MIT License, then every CDDL project in existence that didn't explicitly opt out will be available under very permissive terms.
That's a whole lot easier than relicensing the kernel.
> because it would be hard (if even possible) to get every ZoL contributor to relicense
I think this is the fundamental point that 'ajross disagrees with.
First, they could dump the code and rewrite it. That solves the actual problem (getting a ZFS under GPL) without actually relicensing. If the code from non-Oracle owners is small, that's reasonable.
Second, they could ignore their copyrights. I believe this is legal in many jurisdictions where you have many of the copyright holders on board; in particular, for many small patches, they are too small to be copyrightable. (The FSF, for instance, doesn't require copyright assignment if your patch is under 15 lines or otherwise not "legally significant", like a mechanical find/replace.) That's why Conservancy can't file lawsuits with anyone in the entire `git log` of Linux who's contributed one or two patches once, but needs someone who wrote something at least somewhat substantial.
See also this VLC blog post and its discussion of French law:
Third, per that VLC blog post, it is empirically possible to get every contributor to a large project to relicense. And VLC's ownership is almost certainly more varied than ZFS's.
> Arrgh. The same issue in principle, but not in practice. "All the developers" of OpenZFS are Oracle Corporation, plus a few dozen other folks we can grep from the commit log.
That's just patently not true. All of the BSD and Illumos guys all are the main source of ZFS talent.
> (Also, as another poster points out, it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge)
No, that was how it worked before the OpenSolaris proprietarisation fiasco. Now, everyone retains the copyrights IIRC.
That part doesn't matter. Ownership of work done by SUN employees would have been transferred to SUN, then transferred to Oracle. Ownership of work done by Oracle employees would have been transferred to Oracle. It's only the non-SUN/Oracle bits that matter.
(Also, as another poster points out, it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge)