Linked by ddc_ on Mon 29th Feb 2016 21:41 UTC
GNU, GPL, Open Source Ubuntu's announcement about inclusion of ZFS support in upcoming 16.04 LTS started an important discussion in opensource community: the license incompatibility between GPL and CDDL licenses may be an issue. Being a copyleft license, GPL requires that all works that are derived from GPL-licensed work are also distributed under terms of GPL. CDDL, the license of ZFS code, is also a copyleft license, and as such requires CDDL-licensed work be distributed "only under the terms of [CDDL]." Although Ubuntu's ZFS code comes from OpenZFS project, Oracle is still one of the major copyright holders of the code base, and it does not seem likely to relicense its assets under GPL any time soon.

Dustin Kirkland of Ubuntu, the author of the announcement, explained Canonical's position, albeit light on details:

The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module -- the kernel itself is quite obviously not a derivative work of this new file system. And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.

Software Freedom Conservancy (SFC), a non-profit with self-assigned mission of carrying on a crusade against GPL violations, quickly pointed out that the "obvious" conclusions of Canonical are not really all that obvious:

[I]f ZFS were statically linked with Linux and shipped as a single work, few would argue it was not a "work based on the Program" under GPLv2. And, if we believe there is no legal difference when we change that linking from static to dynamic, we conclude easily that binary distribution of ZFS plus Linux - even with ZFS in a .ko file - constitutes distribution of a combined work.

Another non-profit organization - Software Freedom Law Center (SFLC) - provides yet another opinion on the matter. Eben Moglen points out that CDDL permits distribution of binaries under other licenses, so in case of Linux module GPL's requirements in case of binary module may be fullfilled by distributing it under GPL. Admittedly, this does not solve the issue of the license incompatibility of the code bases. The proposed solution is basically to ignore the wording of GPL's viral clause:

In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the "equity of the license," or its "spirit." As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of "equity." This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders' intention which determines which mode of interpretation is to be employed.

The issue of GPL compatibility and kernel modules' licensing arised before. For example, Linus Torvalds already noted that kernel modules are in "gray area" when it comes to the issue of derived worked. Using an example of Andrew filesystem he stated that external code base that was designed on different system and only required minimal porting effort due to interface similarities, in his opinion, was not a derived work of Linux. Even more appropriate example is Nvidia's infamous proprietary Linux driver, which interfaces the kernel via specially-crafted module that abstracts away Linux kernel implementation details, so that Nvidia's binary blob may still considered to be a self-contained work targetting module's interface, not the interfaces of Linux. This driver is widely used and generally tolerated by distributions.

The differences in these two positions reveal the two conflicting opinions on Linux copyright situation. SFLC is more concerned about the ability of opensource ecosystem to survive in face of fanatic GPL enforcement: their statements goes into painful details about difficulties that projects with permissive licenses are facing when they need to maintain the ports of their code in GPLed projects. If stictly enforced, GPL could hinder such projects to the point when whole ecosystem comes to net loss. Such situation could be particularly painful in cases like this, when the goals of GPL are met, but the legal mechanism that was chosen by opensource Foundation prevents both Linux and OpenZFS from cross-polination.

But on the other hand, making such excuses would open gates for projects that don't really contribute to the opensource, but only use it to their own benefit. While proponents of permissive licenses (myself included) don't find anything wrong with such outcome, GPL was specifically designed to prevent it, and that is why it is one of the most popular opensource licenses out there. Obviously, every concession weakens the position of those seeking GPL enforcement, including SFC, whose mission right now is endangered by both SFLC's and Canonical's views on ZFS integration into Linux. Being a self-styled GPL crusader with several battles already fought, SFC knows that the ZFS inclusion in Ubuntu may come at a price of legal actions lost, and potentially tolanted hackers driven out of opensource by frustration and disappointment.

There is another interesting angle to this situation: by now it is common knowledge that Sun Microsystems specifically designed CDDL to be incompatible with GPL, so that ZFS, while being opensource, could not be included with Linux. Shipping ZFS with Ubuntu would defeat this tactics and potentially remove motivation for such unfortunate choice of license for companies like Sun or Oracle, to benefit of all involved sides.

And yet another thing to consider: some (most?) jurisdictions explicitly require sticking with literal meanings of laws and contracts. This means that even if SFLC's position is defendable in United States, it might be dismissed in other parts of the world, giving Linux copyright holders ability to sue Canonical over copyright infringement. Given that Oracle holds copyright in both Linux and OpenZFS, and that it already demonstrated willingness to take legal actions against opensource projects, Canonical might still be under significant risk.

At any rate, the outcome of this discussion, if any, have potential to settle a long-standing issue in opensource community, and to make legal implications of using GPL more transparent and clear.

Order by: Score:
Possible solutions/workarounds
by Lennie on Mon 29th Feb 2016 23:03 UTC
Lennie
Member since:
2007-09-22

1. The obvious: DKMS already exists, this means: build from source at installation time.

2. automatic download/install kernel module binary from an other source. Like the http://zfsonlinux.org/ project.

Edited 2016-02-29 23:03 UTC

Reply Score: 5

RE: Possible solutions/workarounds
by Alfman on Tue 1st Mar 2016 05:34 UTC in reply to "Possible solutions/workarounds"
Alfman Member since:
2011-01-28

Lennie,

1. The obvious: DKMS already exists, this means: build from source at installation time.


It would require both a build environment and up-to-date kernel headers on all machines where you want ZFS. I guess we can hide this complexity from the user. But for a live cd or linux install media it seems unreasonable to add hundreds of megabytes and several minutes of overhead just to be able to access one's ZFS file systems.


2. automatic download/install kernel module binary from an other source. Like the http://zfsonlinux.org/ project.


"You can't get ZFS from us, but I have a friend who can hook you up..." ;)

They would have to coordinate with Ubuntu to get the kernel sources and compile a compatible ZFS kernel module. As a derivative of both GPL and CDDL sources, the legal status of this module by itself wouldn't be clear to me.

Since they're not distributed together, great care would have to taken to provide assurances that users always have access to the correct ZFS kernel module, it would be very bad if they lost access to their own ZFS file systems on an upgrade, for example.


I think Ubunto should avoid voodoo engineering work done solely to workaround GPL license restrictions, especially when those changes would make the OS more fragile. ZFS should really just be distributed as a normal kernel module, but then I'm not the one who'll be answering when the legal brigade comes-a-knocking. ;)

Reply Score: 2

Lennie Member since:
2007-09-22

Lennie,

"1. The obvious: DKMS already exists, this means: build from source at installation time.


It would require both a build environment and up-to-date kernel headers on all machines where you want ZFS. I guess we can hide this complexity from the user. But for a live cd or linux install media it seems unreasonable to add hundreds of megabytes and several minutes of overhead just to be able to access one's ZFS file systems.
"

Never said it was a pretty solution. ;-)

"2. automatic download/install kernel module binary from an other source. Like the http://zfsonlinux.org/ project.


"You can't get ZFS from us, but I have a friend who can hook you up..." ;)

They would have to coordinate with Ubuntu to get the kernel sources and compile a compatible ZFS kernel module. As a derivative of both GPL and CDDL sources, the legal status of this module by itself wouldn't be clear to me.

Since they're not distributed together, great care would have to taken to provide assurances that users always have access to the correct ZFS kernel module, it would be very bad if they lost access to their own ZFS file systems on an upgrade, for example.


I think Ubunto should avoid voodoo engineering work done solely to workaround GPL license restrictions, especially when those changes would make the OS more fragile. ZFS should really just be distributed as a normal kernel module, but then I'm not the one who'll be answering when the legal brigade comes-a-knocking. ;)
"

Nvidia already applies both solutions if I understand correctly: They have a binary module they download. And a small kernel/wrapper module they build from source to be compatible with the current installed kernels and the GPL.

Reply Score: 4

Bill Shooter of Bul Member since:
2006-07-14

Any workaround to Oracle suing the ever living crap out of ubuntu?

I kind of wonder if this is the exit strategy that Mark Shuttleworth came up with.

Exit strategy by Mark

1) Incorperate ZFS into Ubuntu
2) Get sued by oracle
3) Protest, countersue for something...
4) Negotiate a oracle buyout of ubuntu as a resolution of the lawsuits.
5) Retire to the south pacific.

Reply Score: 3

dionicio Member since:
2006-07-12

;)

But no.

Reply Score: 1

dionicio Member since:
2006-07-12

:)

Not Oracle!

Reply Score: 1

darknexus Member since:
2008-07-15

5) Retire to the south pacific.

He's rich enough that he could already do this several times over. Wouldn't be any point bothering with the rest.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

Sure, then he doesn't have to live with a bunch of nerds upset that he just dropped the business. Plus just dissolving the company means he wouldn't recoup nearly as much as a straight sale.

Canonical has never been profitable and the failure of the tablet/phone couldn't have helped. With a lawsuit exit, he can avoid blaming his decisions and blame it on big bad oracle. Ubuntu would be remembered as a bold, noble experiment that was ultimately doomed by an evil 600 lb gorilla .

Reply Score: 2

Lennie Member since:
2007-09-22

Ubuntu is Mark Shuttleworth's hobby project, he already has the money to retire.

Reply Score: 2

darknexus Member since:
2008-07-15

Ubuntu is Mark Shuttleworth's hobby project, he already has the money to retire.

Unless he pissed it all away on Ubuntu. Now that I think about it, given how poorly it has done, this is quite possible.

Reply Score: 2

Lennie Member since:
2007-09-22

I believe Mark put a large amount of money in a fund which funds Canonical.

They are doing a lot better than a couple of years ago though.

Ubuntu is the most used Linux distribution being deployed as guest on cloud-environments. And it's also used to build cloud environments by companies like Deutsche Telekom. Especially that last category are paying customers. I don't know how many organisations deploy it as private clouds.

Edited 2016-03-02 21:02 UTC

Reply Score: 2

Valve too
by petete on Mon 29th Feb 2016 23:43 UTC
petete
Member since:
2011-07-15

Isn't this the same situation with Valve distributing Nvidia and Amd binary drivers with SteamOS?

Reply Score: 1

A bit nonsensical
by kwan_e on Tue 1st Mar 2016 00:32 UTC
kwan_e
Member since:
2007-02-18

Dynamic linking can't constitute a derived work. A binary executable, somewhere down the chain, will be dynamically linking to kernel code and no one will argue a binary executable is a derived work. This applies whether the kernel is opensource or proprietary, otherwise Microsoft can claim all programs running on Windows are derived works. And it looks like zfs.ko is self-contained enough that it is essentially a standalone executable.

Reply Score: 7

RE: A bit nonsensical
by Alfman on Tue 1st Mar 2016 03:33 UTC in reply to "A bit nonsensical"
Alfman Member since:
2011-01-28

kwan_e,

Dynamic linking can't constitute a derived work. A binary executable, somewhere down the chain, will be dynamically linking to kernel code and no one will argue a binary executable is a derived work. This applies whether the kernel is opensource or proprietary, otherwise Microsoft can claim all programs running on Windows are derived works.



But many do argue that even dynamic linking makes a derived work. That's the only reason there's any debate at all.

http://programmers.stackexchange.com/questions/158789/can-i-link-to...


The reason proprietary developers can link to GPL code like stdc are because they have explicit linking exceptions.

https://en.wikipedia.org/wiki/GPL_linking_exception

I'm not arguing it should be this way, or even that the law would uphold it this way(*), but I'm merely pointing out that there are many who do think this way, even GNU holds this position.
http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs

Clearly Linux users want ZFS, and I think it's a shame if an open source license impedes users from experiencing the best that all open source has to offer even if it's not GPL. I don't really care that ZFS is CDDL, relaxations would undoubtedly be better for end users in cases like this. However if the intention of kernel developers was to allow linking with non-GPL sources, they should be using LGPL instead.

The core motivation for GPL is to combat proprietary software, but I wonder if there's an unintentional side effect of "friendly fire" going on when it encounters other open source licenses?

* I'm already convinced that "the law" is all about getting the case heard before a favorable judge more than anything else. Intellectually sound reasoning and draconian rulings are totally irrelevant to inept judges as the Oracle-v-Google case proved.



And it looks like zfs.ko is self-contained enough that it is essentially a standalone executable.


The FUSE implementation of ZFS is a standalone executable and can be treated as such. But native kernel modules have to compile against and link into a specific kernel version. They are very tightly coupled with internal kernel structures. Note I wouldn't necessarily say it's "derivative" in GPL speak, but a lawyer could...

Edited 2016-03-01 03:51 UTC

Reply Score: 6

RE[2]: A bit nonsensical
by Lennie on Tue 1st Mar 2016 07:32 UTC in reply to "RE: A bit nonsensical"
Lennie Member since:
2007-09-22

There is also the VMware/GPL case that is currently in court:

http://laforge.gnumonks.org/blog/20160225-vmware-gpl/

Reply Score: 4

RE[3]: A bit nonsensical
by ddc_ on Tue 1st Mar 2016 10:43 UTC in reply to "RE[2]: A bit nonsensical"
ddc_ Member since:
2006-12-05

VMWare case is very different: it is all about direct code usage, which is much more straight-forward.

Reply Score: 2

RE[4]: A bit nonsensical
by Lennie on Tue 1st Mar 2016 11:06 UTC in reply to "RE[3]: A bit nonsensical"
Lennie Member since:
2007-09-22

One of the most important parts of the court case is:

"Are vmklinux + vmkernel one program/work or multiple programs/works?"

Reply Score: 2

RE[2]: A bit nonsensical
by kwan_e on Tue 1st Mar 2016 11:27 UTC in reply to "RE: A bit nonsensical"
kwan_e Member since:
2007-02-18

But many do argue that even dynamic linking makes a derived work.


Yes, and I'm disagreeing with them.

" And it looks like zfs.ko is self-contained enough that it is essentially a standalone executable.


The FUSE implementation of ZFS is a standalone executable and can be treated as such. But native kernel modules have to compile against and link into a specific kernel version. They are very tightly coupled with internal kernel structures. Note I wouldn't necessarily say it's "derivative" in GPL speak, but a lawyer could...
"

But that's not the argument of the SFC. They are claiming that there is no difference between static linking and dynamic linking. I would argue that static linking is almost as different from dynamic linking as it is from a standalone.

A statically linked module can no longer exist on its own. With dynamic linking, it is not unreasonable to posit a completely different kernel with the same symbols that the module needs to link with and thus they can be switched. So it is much closer to a standalone and not dependent enough to be considered derived.

Reply Score: 2

RE[3]: A bit nonsensical
by Alfman on Tue 1st Mar 2016 13:16 UTC in reply to "RE[2]: A bit nonsensical"
Alfman Member since:
2011-01-28

kwan_e,

But that's not the argument of the SFC. They are claiming that there is no difference between static linking and dynamic linking. I would argue that static linking is almost as different from dynamic linking as it is from a standalone.

A statically linked module can no longer exist on its own. With dynamic linking, it is not unreasonable to posit a completely different kernel with the same symbols that the module needs to link with and thus they can be switched. So it is much closer to a standalone and not dependent enough to be considered derived.


Well, as much as I favor a legal outcome where ZFS can be distributed without a license issue, I think there's very little technical difference with a dynamic link library. Does the fact that the linking takes place at a different step make a legal difference - I really don't know. Given that oracle won the case that APIs are copyrightable, then it seems that they could claim a conflicting license violation exists in the module itself even when linked separately.


Yes, and I'm disagreeing with them.




That's fine, just in case you didn't read far into my previous link, I'm placing this here for posterity and to advance the general discussion. I already understand you disagree with it, we just need to understand that from a legal standpoint any of us could end up being wrong.

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)

No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module? (#GPLModuleLicense)

The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.


Edited 2016-03-01 13:20 UTC

Reply Score: 2

RE[4]: A bit nonsensical
by mkone on Tue 1st Mar 2016 17:27 UTC in reply to "RE[3]: A bit nonsensical"
mkone Member since:
2006-03-14

I am probably quite uninformed about this, but couldn't one get around this with a legal trick (I am not a programmer, so excuse my probable lack of precision with the terminology):
- create a kernel module (perhaps even a filesystem one) that has the exact same interface as the zfs.ko module
- (possibly independently) create a wrapper that loads a module with this interface into the Linux kernel

And hey presto - you have something that can load the module into the kernel and you only require a component that is not technically a derivative of the zfs.ko module to load said module.

A bit over the top I agree, but it shows how the argument that any module that can interface with Linux becomes a derivative is flawed.

In any case, if you distribute them completely separately, it appears there is no non-compliance. Therefore this non-compliance seems to only arise when you distribute them in "close" proximity, which seems a nonsensical position.

Reply Score: 2

RE[5]: A bit nonsensical
by Alfman on Tue 1st Mar 2016 18:06 UTC in reply to "RE[4]: A bit nonsensical"
Alfman Member since:
2011-01-28

mkone,

I am probably quite uninformed about this, but couldn't one get around this with a legal trick (I am not a programmer, so excuse my probable lack of precision with the terminology):
- create a kernel module (perhaps even a filesystem one) that has the exact same interface as the zfs.ko module


Well, let me just point out that the logic is reversed. The ZFS.ko module is using the kernel interface, not the other way around.

You may be onto something though. Going with your idea, maybe you could create a new in-kernel FS module interface that's specifically dual licensed. I nominate the WTFPL, as it should be compatible with both GPL and CDDL ;) ( https://en.wikipedia.org/wiki/WTFPL ). Even if mainline linux didn't adopt it, Ubuntu should be able to incorporate it into the kernel and distribute with no GPL problems. The new ZFS module could be built directly to this new interface which has no GPL restricted dependencies.


A bit over the top I agree, but it shows how the argument that any module that can interface with Linux becomes a derivative is flawed.


I'm not going to make any predictions that this couldn't violate some provision of the DMCA, but just maybe this would do the trick!

Edited 2016-03-01 18:18 UTC

Reply Score: 2

RE[6]: A bit nonsensical
by kwan_e on Wed 2nd Mar 2016 05:00 UTC in reply to "RE[5]: A bit nonsensical"
kwan_e Member since:
2007-02-18

You may be onto something though. Going with your idea, maybe you could create a new in-kernel FS module interface that's specifically dual licensed. I nominate the WTFPL, as it should be compatible with both GPL and CDDL ;) ( https://en.wikipedia.org/wiki/WTFPL ). Even if mainline linux didn't adopt it, Ubuntu should be able to incorporate it into the kernel and distribute with no GPL problems. The new ZFS module could be built directly to this new interface which has no GPL restricted dependencies.


Which is precisely my point earlier about dynamic linking and positing the existence of some module that fulfills the linking criteria. The fact such a thing is reasonable to posit makes the argument that there is no difference between static and dynamic linking wrong - regardless of what those other people said about it.

Reply Score: 2

RE[7]: A bit nonsensical
by Alfman on Wed 2nd Mar 2016 06:55 UTC in reply to "RE[6]: A bit nonsensical"
Alfman Member since:
2011-01-28

kwan_e,

The fact such a thing is reasonable to posit makes the argument that there is no difference between static and dynamic linking wrong - regardless of what those other people said about it.


Whether it's in a dynamic or statically linked, we're still looking at the exact same executable code down to the byte, we've merely moved it into a different container. Can one avoid GPL compliance by shifting code around into different containers? I really don't know. Would a court really make a distinction between an ISO file containing a vmlinuz binary built with ZFS and an ISO file containing vmlinuz + the same code in a shared kernel object? I really don't know. Can someone introduce kernel wrappers just to circumvent the GPL license? I really don't know. Can GNU enforce a license that prohibits linking to non-GPL code? I really don't know.

If there's a common theme here, it's that I really don't know because to my knowledge these haven't been answered in court, which is why I'm perplexed that you state with such conviction that GNU is wrong about it's own license. What do you know that I (and they) don't?

Even though I don't have my own made up, I do think any ruling on the GPL will depend on what judge gets the case and how well lawyers can make their case.

Edited 2016-03-02 06:59 UTC

Reply Score: 2

RE[2]: A bit nonsensical
by darknexus on Tue 1st Mar 2016 15:29 UTC in reply to "RE: A bit nonsensical"
darknexus Member since:
2008-07-15

But many do argue that even dynamic linking makes a derived work. That's the only reason there's any debate at all.

Then either those who argue such are idiots, or else they have an agenda. If dynamic linking could create a derived work, there would be not a single original work beyond kernels in any modern computing environment. The idea that linking constitutes a derived work is one of the stupidest things I've heard in recent times. If anything, statically linking would be more of a cause for this argument than dynamic as you're actually including a copy of the library in your program. Ridiculous.

Reply Score: 2

RE[3]: A bit nonsensical
by Alfman on Tue 1st Mar 2016 16:54 UTC in reply to "RE[2]: A bit nonsensical"
Alfman Member since:
2011-01-28

darknexus,

Then either those who argue such are idiots, or else they have an agenda.


Did you look at those links? GNU does have an agenda, but they are no idiots...

If dynamic linking could create a derived work, there would be not a single original work beyond kernels in any modern computing environment. The idea that linking constitutes a derived work is one of the stupidest things I've heard in recent times.


Respectfully, it doesn't sound like you realize that most libraries have explicit linking exceptions for exactly that reason. I'm also not sure you understand the thinking that went into the GPL, which was created very carefully to limit the abuse by those who would exploit loopholes.

For example, one could bypass all GPL requirements just by building all said code as a DLL and then linking proprietary code in a separate executable. Voila, GPL completely circumvented even if it constitutes 99% of the code. Quite the opposite of being stupid, it took a lot of foresight to see this, which is exactly why linking to non-GPL code isn't allowed.

It's natural to ask just how much functionality needs to be brought in via linking to constitute a "derived" work, 50%? 10% 2%? But the intention behind the GPL was that any linking to GPL code, even if it's only 1%, would be prohibited unless the entire codebase to be made available via GPL.


This isn't always desirable, particularly with system libraries as you pointed out, so those are often licensed under LGPL or GPL with exceptions.

Reply Score: 3

RE[4]: A bit nonsensical
by malxau on Tue 1st Mar 2016 20:03 UTC in reply to "RE[3]: A bit nonsensical"
malxau Member since:
2005-12-04

...GNU does have an agenda, but they are no idiots...

For example, one could bypass all GPL requirements just by building all said code as a DLL and then linking proprietary code in a separate executable. Voila, GPL completely circumvented even if it constitutes 99% of the code. Quite the opposite of being stupid, it took a lot of foresight to see this, which is exactly why linking to non-GPL code isn't allowed.


Right, as a technical matter it's clear the FSF foresaw this and made a claim with the intention of preventing it. The FSF would very much like this claim to be substantiated, because the GPL would be seriously harmed if it wasn't. But notwithstanding the FSF making the claim in many forms, it's never been legally tested (AFAIK) and its basis is quite shaky.

Sticking with GNU Classpath, FSF's position is that if I write some source code that uses zero lines of code from Classpath, then I compile that code and give it to you but give you zero bytes of Classpath itself, that I have created a derivative work. Although the FSF would like this to be true, there's an inconvenient aspect which is that zero source code and zero binary code from Classpath were copied in the process, and yet that's the basis for a copyright claim.

The good part about what Canonical are doing here is picking a fight with a litigious company such that this question is likely to be resolved and we can stop speculating about what the situation here really is.

Reply Score: 2

RE[5]: A bit nonsensical
by Alfman on Tue 1st Mar 2016 20:34 UTC in reply to "RE[4]: A bit nonsensical"
Alfman Member since:
2011-01-28

malxau,

But notwithstanding the FSF making the claim in many forms, it's never been legally tested (AFAIK) and its basis is quite shaky.
...
The good part about what Canonical are doing here is picking a fight with a litigious company such that this question is likely to be resolved and we can stop speculating about what the situation here really is.


I very much agree. This is getting very much ahead of ourselves, but hypothetically speaking a case between Ubuntu and Oracle could be very helpful in clarifying the legal situation, assuming the court didn't use some technicality to sidestep the issue.

Reply Score: 2

RE[3]: A bit nonsensical
by malxau on Tue 1st Mar 2016 20:05 UTC in reply to "RE[2]: A bit nonsensical"
malxau Member since:
2005-12-04

If dynamic linking could create a derived work, there would be not a single original work beyond kernels in any modern computing environment.


I'd question whether a kernel is special in this respect. A usermode dynamic library is one where a process can marshal some parameters and call a function which does some processing. A kernel is a dynamic library where a process can marshal some parameters and call a function which happens to perform a ring transition. I can't imagine that copyright would really consider the mechanics of the function as relevant in determining the outcome.

Reply Score: 2

RE[4]: A bit nonsensical
by galvanash on Wed 2nd Mar 2016 07:34 UTC in reply to "RE[3]: A bit nonsensical"
galvanash Member since:
2006-01-25

I can't imagine that copyright would really consider the mechanics of the function as relevant in determining the outcome.


Copyright, in terms of this discussion, is simply the laws that make the license legally binding. Things like dynamic vs static linking have absolutely nothing to do with copyright law - they are only relevant because the license terms makes them relevant.

The terms of the license do not have to be logical or fair. It is perfectly legal to have illogical and/or unfair license restrictions, and they are still legally binding as long as they do not violate any other law.

I'm not weighing in either way, just pointing out that the clarity of the license terms are all that really matters in the end, not how logical or reasonable they are - i.e. they can be rather stupid and nonsensical as long as their meaning is clear.

Getting to the point, if the authors of the GPL intended for the mechanics to be relevant, then they are relevant. The question is whether the license really makes that intention clear...

Edited 2016-03-02 07:35 UTC

Reply Score: 3

RE[5]: A bit nonsensical
by whartung on Wed 2nd Mar 2016 18:22 UTC in reply to "RE[4]: A bit nonsensical"
whartung Member since:
2005-07-06


Getting to the point, if the authors of the GPL intended for the mechanics to be relevant, then they are relevant. The question is whether the license really makes that intention clear...


This is the crux of it. Historically linking (any kind of linking) has been key to the "viral" nature of the GPL, and it's pretty clear that this is the intended effect.

How well that manifests through the license text when blended with the appropriate copyright law is a different question, but the intent is clear enough from the creators that they created a completely separate license (the LGPL) to address this exact issue, as the LGPL does NOT have the "viral" nature of the GPL.

If this linking issue did not exist, then 99% of the teeth gnashing over the GPL simply would not exist, much like it doesn't exist with the bulk of most every other OSS license (as they're more like LGPL than not).

The binding by linking intent of the GPL is also made clear through the creation of the AGPL, which addresses the "network" loophole. This was created to fill the gap of those using GPL code, but not, technically, distributing it (and therefore not triggering the distribution requirement of the license). People "knew" they were using GPL code, but since it wasn't being "distributed", there was no release requirement -- and thus the code lived locked away behind a network server port. AGPL addresses that issue.

GPL's intent towards linking is also made clear by the simple fact that they not only have the LGPL, but also the Classpath exemptions and other releases designed specifically to counter the linking claim.

So, regardless of how the letter of the license reads, the intent behind it, as well as the COMMUNITY'S understanding of it (as manifested in how it's used by the community at large) make clear the linking dependency. All of those will have weight in court.

Finally, this is from an email thread (http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-i... ) with Stallman back in '92:



* the user isn't distributing anything,
* I am not responsible for the user's deeds,
* I am not distributing "one program", so GPL doesn't apply to me either.

The FSF position would be that this is still one program, which has
only been disguised as two. The reason it is still one program is
that the one part clearly shows the intention for incorporation of the
other part.


I say this based on discussions I had with our lawyer long ago. The
issue first arose when NeXT proposed to distribute a modified GCC in
two parts and let the user link them. Jobs asked me whether this was
lawful. It seemed to me at the time that it was, following reasoning
like what you are using; but since the result was very undesirable for
free software, I said I would have to ask the lawyer.

What the lawyer said surprised me; he said that judges would consider
such schemes to be "subterfuges" and would be very harsh toward
them. He said a judge would ask whether it is "really" one program,
rather than how it is labeled.

So I went back to Jobs and said we believed his plan was not allowed
by the GPL.

The direct result of this is that we now have an Objective C front
end. They had wanted to distribute the Objective C parser as a
separate proprietary package to link with the GCC back end, but since
I didn't agree this was allowed, they made it free.


So I don't think the GPL actually requires a correction for this.
But perhaps it would be a good idea to add a note explaining this.


So, there's the letter of the GPL, and the spirit of the GPL. The spirit, as manifested by many, including its authors, is "linking matters, regardless of how it's linked".

Reply Score: 2

RE[5]: A bit nonsensical
by malxau on Thu 3rd Mar 2016 01:50 UTC in reply to "RE[4]: A bit nonsensical"
malxau Member since:
2005-12-04

Copyright, in terms of this discussion, is simply the laws that make the license legally binding.


Right.

Things like dynamic vs static linking have absolutely nothing to do with copyright law - they are only relevant because the license terms makes them relevant.


Not quite.

If I want to do something, copyright decides whether or not I need a license to do it. If I do, then I need a license and the terms of that license don't need to be logical, fair, etc. But copyright decides whether I need a license.

I can write a license that says, "if you drink beer on Friday then you must pay me the price of the beer", but unless you're doing something that requires this license to be granted, you don't owe me anything for drinking beer.

The issue here is whether dynamic linking constitutes a derivative work, and if it does, a license would be needed, and that license can impose any obligations it chooses. But if it doesn't create a derivative work, no copying has occurred, no license is needed, and the whole issue is moot.

Although the FSF have had a position on this, that position isn't really shared elsewhere. If creating a Mac program that dynamically links to Mac OS constitutes a derivative work of the OS, you'd need a license from Apple allowing that derivative work or developing the app would be unlawful. But where in the license do you have that right granted? Apple actually expressly forbids it ("2C. Except as and only to the extent permitted in this License and by applicable law, you may not...create derivative works of the Apple Software or any part thereof.")

So if dynamic linking constitutes a derivative work requiring a license grant, all Mac OS users have a big problem. The GPL is much more permissive, because you're allowed to create derivative works if those are also GPL; Mac OS just says it can't be done, period. As you say, license terms don't need to be fair; but if a court decides dynamic linking is a derivative work, that will have big implications on commercial licenses; if they decide it's not a derivative work, that will have big implications on copyleft licenses.

Reply Score: 2

RE[6]: A bit nonsensical
by Alfman on Thu 3rd Mar 2016 03:59 UTC in reply to "RE[5]: A bit nonsensical"
Alfman Member since:
2011-01-28

malxau,

I can write a license that says, "if you drink beer on Friday then you must pay me the price of the beer", but unless you're doing something that requires this license to be granted, you don't owe me anything for drinking beer.


Nice example, I like it! Let's assume that it's enforceable exactly as you describe.

The issue here is whether dynamic linking constitutes a derivative work, and if it does, a license would be needed, and that license can impose any obligations it chooses. But if it doesn't create a derivative work, no copying has occurred, no license is needed, and the whole issue is moot.


We can explicitly acknowledge that something (aka the beer) does not constitute a derivation of the licensed work (aka the software), and we can explicitly acknowledge that the developers are not entitled to any royalties over the non-derived work (aka the beer). Yet the software license CAN nevertheless dictate terms under which one can and cannot use the licensed work (aka pay the price of the beer). The fact that the beer does not legally derive from any of the developer's work is not relevant to a developer's right to restrict the software using illogical/unfair terms. (so long as they don't break the law).


I hope I didn't overly abuse the metaphor ;)

Another way to put what galvanash said is this: maybe we can establish that ZFS.ko is not a derivation and is not subject to the GPL, but the same cannot be said about the linux kernel. We might liberate ZFS.ko from the GPL, but when it comes to the kernel itself, it still remains bound by the GPL's terms (no matter how illogical they might be). "Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License."

I won't make predictions about the GPL's enforcability, but I don't think the issue becomes moot if it turns out that ZFS is not considered a derived work by copyright law.

Reply Score: 2

RE[6]: A bit nonsensical
by galvanash on Thu 3rd Mar 2016 04:03 UTC in reply to "RE[5]: A bit nonsensical"
galvanash Member since:
2006-01-25

The issue here is whether dynamic linking constitutes a derivative work, and if it does, a license would be needed, and that license can impose any obligations it chooses. But if it doesn't create a derivative work, no copying has occurred, no license is needed, and the whole issue is moot.


That is a bit different than what I was addressing. I may have focused on the wrong part of your post - sorry.

I personally agree with Canonical's view of things, i.e. a derivative work is essentially self evident - it has nothing at all to do with the mechanics of how you link things.

The SFC argument hinges on how you interpret the GPL and all the static vs dynamic linking business, but I think they are missing the forest through the trees. As you pointed out, the GPL simply doesn't apply to zfs.ko at all if you can clearly demonstrate that it was not derived from Linux in the first place.

Personally I don't think how you link things has any bearing on determining derivation - it only comes into play once the question of derivation has been answered. Linking, whether static or dynamic, may constitute evidence of derivation, but it certainly is not inculpatory. In other words if you dynamically link to something, and something else with an identical signature exists that you can link to instead - what matters is which one you actually used during development.

I.e. the whole GPL static vs dynamic argument is meaningless without first establishing that the work is derivative in the first place, and thus that the GPL would actually apply to it. THEN how you linked it may matter a great deal (depending on the which GPL license it is)

If creating a Mac program that dynamically links to Mac OS constitutes a derivative work of the OS, you'd need a license from Apple allowing that derivative work or developing the app would be unlawful.


That license already exists. It is part of the SDK license agreement - much that same as for virtually all commercial software. Microsoft, Oracle, etc., do it pretty much the same way. To use the SDK you agree to the terms, and generally the terms are fairly liberal, letting you develop derivatives (i.e. applications) and do what you will with them for the most part (certain restrictions apply, yada yada).

Edited 2016-03-03 04:21 UTC

Reply Score: 2

In general agreeing with kwan_e...
by dionicio on Tue 1st Mar 2016 16:34 UTC in reply to "A bit nonsensical"
dionicio Member since:
2006-07-12

But the reins aren't -by far- at the community hands. The linking interface has to be totally protocollary. The dual licenses could not be so much at an international environment.

Would you bet long term projects on it?

Reply Score: 1

Just use FreeBSD
by pfgbsd on Tue 1st Mar 2016 01:39 UTC
pfgbsd
Member since:
2011-03-12

Yes, I am biased and I think the problem only exists on the eyes of extreme copy-leftists: mostly lawyers than make money without coding.

While they figure it out, just use FreeBSD.

Reply Score: 1

RE: Just use FreeBSD
by nicubunu on Tue 1st Mar 2016 07:20 UTC in reply to "Just use FreeBSD"
nicubunu Member since:
2014-01-08

is a situation which can create a precedent and start a slippery slope.

Reply Score: 3

RE: Just use FreeBSD
by moondevil on Wed 2nd Mar 2016 09:30 UTC in reply to "Just use FreeBSD"
moondevil Member since:
2005-07-08

How are you enjoying those Apple and Sony contributions?

Reply Score: 3

This is why we can't have nice things
by Jondice on Tue 1st Mar 2016 03:09 UTC
Jondice
Member since:
2006-09-20

I really feel copyleft seems too strong in general. LGPL seems more reasonable.

Reply Score: 3

Lennie Member since:
2007-09-22

I've been recommending using LGPL in many cases.

It adheres to the general ideas of GPL, but makes life easier to understand.

The Linux kernel also sort of does this: it's GPLv2 with a binary module exception.

Reply Score: 2

'may'
by nicubunu on Tue 1st Mar 2016 07:19 UTC
nicubunu
Member since:
2014-01-08

If we talk about what Ubuntu 'may ship', there is the possibility they will just ignore the controversy, ship the module and hope nobody will sue in the foreseeable future.

Reply Score: 3

RE: 'may'
by Lennie on Tue 1st Mar 2016 07:37 UTC in reply to "'may'"
Lennie Member since:
2007-09-22

euh... if they are confident about the legal status they will ship it in some form. But only if they are confident I assume, because they might end up in court against Oracle which has a lot of money and a big bad legal department.

Reply Score: 2

silviucc
Member since:
2009-12-05

While the summary is interesting the following shows me that the author does fully grok the problem.

"Given that Oracle holds copyright in both Linux and OpenZFS, and that it already demonstrated willingness to take legal actions against opensource projects, Canonical might still be under significant risk."

Oracle can't sue because the CDDL is not the license that SFC alleges Canonical would infringe upon by shipping the zfs kernel module. It's about the license that the Linux kernel uses, GPL v.2

Oracle does not hold copyright over the Linux kernel and furthermore they've already shipped "infringing" products like d-trace with their Unbreakable Linux product.

Reply Score: 4

anda_skoa Member since:
2005-07-07

Oracle can't sue because the CDDL is not the license that SFC alleges Canonical would infringe upon by shipping the zfs kernel module. It's about the license that the Linux kernel uses, GPL v.2


Sure, the SFC focuses on the GPL, but I would be surprised if the CDDL didn't matter at least as much.

We know that the CDDL was specifically crafted by SUN's IP lawyers to prohibit anyone from distributing ZFS with Linux, so they must have seen some legal leverage in case someone tried.

Reply Score: 3

ddc_ Member since:
2006-12-05

Sorry, but it is you who does not grok the problem.

Oracle does not hold copyright over the Linux kernel

No, they do. There is some Oracle code in Linux, and it is GPLed. So they are entitled to defending their copyright in Linux. Oracle's copyright on OpenZFS is not that important, but it allows them to demonstrate that they never authorized third parties to distribute it under different terms, particularily under terms that would satisfy GPL in their view. That is: they can establish all the relevant facts in court without summoning any third parties at all.

Edited 2016-03-01 11:02 UTC

Reply Score: 3

silviucc Member since:
2009-12-05

And the module is not distributed under a different license. The module is CDDL compliant as far as we know. Do you know otherwise? Got proof?

The issue is with GPL v2 compliance not with some imagined CDDL non-compliance.

Reply Score: 2

pepa Member since:
2005-07-08

ddc's point is --as you are saying-- that including the CDDL module as part of the GPL-2 Linux kernel infringes on the GPL-2. So, copyright holders that have contributed GPL code to the Linux kernel like Oracle are able to sue Canonical/Ubuntu for this.

Edited 2016-03-01 15:24 UTC

Reply Score: 2

Alfman Member since:
2011-01-28

silviucc,

Oracle can't sue because the CDDL is not the license that SFC alleges Canonical would infringe upon by shipping the zfs kernel module. It's about the license that the Linux kernel uses, GPL v.2


I agree with the emphasized part, it's a GPL violation. But that doesn't automatically make it safe.

Any of the linux contributors could theoretically sue over non-GPL usage of their code. It turns out that oracle contributes in the ballpark of 2% of linux changes (*), so if Oracle has a problem with Ubuntu violating the GPL, theoretically they might have a good case. I don't think it's relevant that Ubuntu would be violating the GPL with Oracle's ZFS because Oracle is not violating it themselves.


* http://go.linuxfoundation.org/who-writes-linux-2012

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

Oracle can't sue because the CDDL is not the license that SFC alleges Canonical would infringe upon by shipping the zfs kernel module.


That's rich. Oracle legal is going to consult with SFC to see who it can and can not sue?

This is very close to the whole Google Oracle lawsuit in spirit. Oracle has cool tech that is open source, but wants people to pay for. Company uses it in an unapproved manner .... without paying!!!!

Reply Score: 2

schrepfler
Member since:
2014-06-02

As per title, the owners of Linux can equally apply a linking exception to it and make it easier on everyone (although unlikely if it hasn't happened so far). At that point would CDDL be violated though?

Reply Score: 1

chithanh Member since:
2006-06-18

CDDL is not violated at all, only GPL is.

Reply Score: 2

pfgbsd Member since:
2011-03-12

As per title, the owners of Linux can equally apply a linking exception to it and make it easier on everyone (although unlikely if it hasn't happened so far). ... ?


That is, more or less, what GPLv3 does. It is rather absurd (and actually double-faced) that GPLv3 "magically" makes Apache and Mozilla licenses compatible, but neither of those are acceptable in GPLv2. And then, CDDL is very similar to MPL2.

I don't see why the FSF actively rejects a perfectly viable *copyleft* license like CDDL, other than to retain some control (which doesn't belong to them IMO).

Reply Score: 1

Maybe wrong...
by dionicio on Wed 2nd Mar 2016 16:50 UTC in reply to "RE: Equally Linux can apply a linking exception"
dionicio Member since:
2006-07-12

But, could it be preventing 'flush backs' of code rights?

**** happens.

Reply Score: 1

Fully open, protocollary interfaces...
by dionicio on Wed 2nd Mar 2016 16:59 UTC in reply to "Maybe wrong..."
dionicio Member since:
2006-07-12

Are the best 'valve' against 'flush backs' of rights.
I'm hardly a fan of mixing licenses.

Reply Score: 1

Nice writeup
by Shane on Tue 1st Mar 2016 13:46 UTC
Shane
Member since:
2005-07-06

OSNews usually reads like Daring Fireball, but this was a nice writeup. Good summary and analysis.

Reply Score: 2

RE: Nice writeup
by Alfman on Tue 1st Mar 2016 14:03 UTC in reply to "Nice writeup"
Alfman Member since:
2011-01-28

Shane,

OSNews usually reads like Daring Fireball, but this was a nice writeup. Good summary and analysis.


Yes, I forgot to mention it myself, but it's nice to have more detailed writeups!

Reply Score: 2

RE: Nice writeup
by pepa on Tue 1st Mar 2016 15:23 UTC in reply to "Nice writeup"
pepa Member since:
2005-07-08

I was going to say the exact same thing. Cudos to dcc for this. Wow, what a helpful article! I had to scroll back and check that I was indeed on OSNews..! No flamebait, but balanced analysis and overview. Please write more!

Reply Score: 2

Great article...
by dionicio on Tue 1st Mar 2016 15:10 UTC
dionicio
Member since:
2006-07-12

Thanks Thom and ddc_.

Lots of 'open' licenses are not adequately protected from 'sinking' decades of community work on the benefit of a few.

Many times those not so open projects -as found too late- nourish from all over the world commitment.

So discouraging. Those contributing communities -and not the interdicted lawyers- should be consulted about the spirit of the license, before any modification.

Reply Score: 1

A catalog of concrete scenarios...
by dionicio on Tue 1st Mar 2016 15:42 UTC in reply to "Great article..."
dionicio Member since:
2006-07-12

Could be the best language interface between Law Enforcers and Coders.

Reply Score: 1

Wise, the one task, one program philosophy...
by dionicio on Wed 2nd Mar 2016 17:22 UTC in reply to "Great article..."
dionicio Member since:
2006-07-12

On a big guardian falling- Small, fragmented, dispersed community unable to sustain big blocks of code.

:) Learning here.

Reply Score: 1

Tempest in a teapot
by jessesmith on Tue 1st Mar 2016 15:25 UTC
jessesmith
Member since:
2010-03-11

The whole issue seems overblown. Canonical's lawyers looked into the situation and confirmed there is no copyright issue. They can ship Ubuntu with the ZFS module. Seems pretty open and shut.

The arguments against shipping with ZFS rely on ZFS being a derative work of the Linux kernel, which it is not. Modules that are loaded into the kernel are not subject to the kernel's license,

Reply Score: 3

The solution is called BTRFS
by piotr.dobrogost on Tue 1st Mar 2016 17:12 UTC
piotr.dobrogost
Member since:
2011-10-04

Sorry, but couldn't resist.
Problem is simply solved by using BTRFS instead of ZFS ;)

Btw, why the heck kernel is not LGPL licensed which would prevent problems like this?

Reply Score: 0

RE: The solution is called BTRFS
by darknexus on Tue 1st Mar 2016 17:34 UTC in reply to "The solution is called BTRFS"
darknexus Member since:
2008-07-15

Sorry, but couldn't resist.
Problem is simply solved by using BTRFS instead of ZFS ;)

Sure, if you don't give two shits for stability.

Reply Score: 3

Flatland_Spider Member since:
2006-09-01

That's what he's saying. Canonical should throw some engineers at btrfs to bring it up to speed as a ZFS competitor instead of wasting time with this.

Except it's Canonical, and they don't have engineers. ;)

Edited 2016-03-01 20:58 UTC

Reply Score: 3

Johann Chua Member since:
2005-07-22

So they're trying to be like Apple in more ways than one? ^_^

Reply Score: 2

jessesmith Member since:
2010-03-11

That doesn't make any sense though. Why hire engineers to create a new solution when an existing, ready solution already exists? Polishing Btrfs would take a lot of resources, years of effort and a lot of money. Plus there are probably relatively few people who can improve the Btrfs code. ZFS is an already working, out of the box solution that has been stable and used in production for a decade. It can be deployed right away and it costs next to nothing to add it to Ubuntu.

Wasting resources on Btrfs gains Canonical very little and would take a lot more time and money to implement.

Reply Score: 3

darknexus Member since:
2008-07-15

Because licensing, since that's all anyone at the SFC care about?

Reply Score: 2