I am obviously glad that this happened, but afraid of an Oraclocalypse.
I am obviously glad that this happened, but afraid of an Oraclocalypse.
The CDDL doesn't have any problems being linked into GPL'ed code, it is the GPL that has a problem accepting CDDL code.
The problem would go away if you convinced oracle to change the license or give explicit permission to link ZFS with the linux kernel under the GPL conditions.
Or:
Convinced the linux kernel team to change their license or give explicit permission to link the linux kernel with ZFS under the CDDL conditions.
Or you can blame "GPL", because it obviously was created after CDDL...
It's the other way around.
/s
http://arstechnica.com/tech-policy/2016/05/round-2-of-oracle...
https://en.m.wikipedia.org/wiki/Oracle_America,_Inc._v._Goog....
"The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable."
That's a strange way to say relicensing CDDL code under GPL
> A license incompatibility happens when two licenses has each some conditions which are incompatible with each other,
I think it's a bit of a far stretch to say that both licenses are to blame when one license has a so far reaching condition that other code needs to be relicensable under that license.
Which license require that other code needs to be relicensable under its license? this license really means, this license. Modified code is required to be under, and I will repeat myself here, this license. If source code is not under this license, then it is infringing on this license condition and this license will no longer permit redistribution.
This license has a condition, and this license condition makes it incompatible with every other license that has an identical condition.
Here's another post about GPL violations related to combining ZFS and Linux: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
Quote from that:
"Is The Analysis Different With Source-Only Distribution?
We cannot close discussion without considering one final unique aspect to this situation. CDDLv1 does allow for free redistribution of ZFS source code. We can also therefore consider the requirements when distributing Linux and ZFS in source code form only.
Pure distribution of source with no binaries is undeniably different. When distributing source code and no binaries, requirements in those sections of GPLv2 and CDDLv1 that cover modification and/or binary (or “Executable”, as CDDLv1 calls it) distribution do not activate. Therefore, the analysis is simpler, and we find no specific clause in either license that prohibits source-only redistribution of Linux and ZFS, even on the same distribution media.
Nevertheless, there may be arguments for contributory and/or indirect copyright infringement in many jurisdictions. We present no specific analysis ourselves on the efficacy of a contributory infringement claim regarding source-only distributions of ZFS and Linux. However, in our GPL litigation experience, we have noticed that judges are savvy at sniffing out attempts to circumvent legal requirements, and they are skeptical about attempts to exploit loopholes. Furthermore, we cannot predict Oracle's view — given its past willingness to enforce copyleft licenses, and Oracle's recent attempts to adjudicate the limits of copyright in Court. Downstream users should consider carefully before engaging in even source-only distribution.
We note that Debian's decision to place source-only ZFS in a relegated area of their archive called contrib, is an innovative solution. Debian fortunately had a long-standing policy that contrib was specifically designed for source code that, while licensed under an acceptable license for Debian's Free Software Guidelines, also has a default use that can cause licensing problems for downstream Debian users. Therefore, Debian communicates clearly to their users that this code is problematic by keeping it out of their main archive. Furthermore, Debian does not distribute any binary form of zfs.ko.
(Full disclosure: Conservancy has a services agreement with Debian in which Conservancy occasionally gives its opinions, in a non-legal capacity, to Debian on topics of Free Software licensing, and gave Debian advice on this matter under that agreement. Conservancy is not Debian's legal counsel.)"
They would only bite a golden hand anyway.
> We are also concerned that it may infringe Oracle's copyrights in ZFS.
The Software Freedom Conservancy saying that is a bit scary. I am somewhat less afraid of Linux copyright holders suing.
Why would Free/open-source distros have to distribute ZFS source code? Couldn't they simply provide a method for downloading the source from the already existing ZFS repos and then compile the source? Wouldn't that be enough?
In the United States there are two kinds of indirect infringement: contributory infringement and vicarious infringement.
Contributory infringement can occur when you know that someone else is or will directly infringe, and you substantially aid that by inducing, causing, or materially aiding their direct infringement. That can include providing the tools and equipment they use to infringe.
Vicarious infringement can occur when someone who is a direct infringer is your agent or under your control.
A very important aspect of both of these types of indirect infringement is that they make you liable for the direct infringement of someone else. If there is no someone else who is a direct infringer, then you cannot possibly be a contributory or vicarious infringer.