Hacker News Reader

Comment by CannisterFlux | Hacker News Reader

Here's the other side of the argument:

https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-lin...

"""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."""

This has been shipped in Ubuntu for a year now and nothing bad has happened, so it must be OK. Maybe.

View on HN

What "other side" of the argument.

If you read the GPL, it is clearly designed to prevent EXACTLY this thing. I'm sure as it was being written, Microsoft was envisioned as the evil entity that would steal free software and mix it with closed proprietary code. The license is clearly and deliberately designed to prevent this.

The "other side" may not see it this way. But the "other side" must abide by all involved licenses, including the GPL. Their own license, and the GPL license. The GPL is clear that if you cannot abide by all licenses, then don't do this.

http://yarchive.net/comp/linux/gpl_modules.html

----8<----

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

Basically:

- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.

- anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.

Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kernel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived.

		Linus

----8<----

The real issue is if anyone who can claim copyright to Linux kernel will sue Canonical. I don't think so.

The relevant question isn't whether a kernel module is a derived work of the kernel (which is what Linus is discussing there).

It's whether someone who distributes the kernel module and the kernel together is obliged to distribute the module under GPL terms as described in the "part of a whole" paragraph:

« If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. »

(It seems pretty clear to me that the answer is "yes".)

Intention of the copyright owners matters, see my other comment.

A Linux kernel module is a derived work of the kernel and under GPL. While ZFS may not be a derived work of Linux, you have to glue it to GPL code. And the GPL license is viral.

Is it possible to glue a kernel module shim to something else under License A, glued to another shim under License B, etc until you have license compatibility with ZFS?

At the very least, this would seem to violate the very spirit of what the GPL intends.

And yet most of us wanted Google not to be held liable for infringing Java copyrights when they implemented the same APIs for Android. Theoretically one could use that reasoning to make an OS that's API-compatible with Linux but under a different license. They could then write a .ko for that other OS under that other license, and yet it would be compatible with Linux and non-infringing.

I'm not sure where the legal line is going to get drawn, but clearly it's still fuzzy.

You're misunderstanding the difference between an implementation of an interface and merely being compatible with an interface.

We each write something that passes as 'English' the language. Yet each of our brains has a different implementation of that interface. We do not copy each other even though we happen to be able to interact.

Licenses, copyrights and trademarks have value only when there is actual change of someone getting sued. Who among the many Linux kernel copyright holders would oppose having ZFS module? Who would be willing to sue Canonical? Will Oracle object?

Eben Moglen from Software Freedom Law Center thinks its OK as long as the source is distributed and no proprietary changes is made.

https://www.softwarefreedom.org/resources/2016/linux-kernel-...

>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.

Linus is one central figure among kernel copyright holders. When he has stated his interpretation and it seems that most other maintainers are not objecting either, kernel copyright holders' intention seems to be closer to the "equity of the license".

Stupid question: can the glue code not be licensed under both GPL and CCDL?

Clearly ZFS is not a derivative work of Linux and Linux is not a derivative work of ZFS. Only the glue code is in violation (because it derives from both).

I'm not sure this is true. It's certainly possible to construct an API/ABI such that one could build the glue, or even dispense with it, without having to use any part of ZFS or the kernel to build the other or the glue. I'm not saying that's been done. But it could be done. Indeed, that's what FUSE is, for example, and that's what NDIS does, for another.

To determine whether there is glue here that violates the GPL would require looking at the particulars. Said glue might be licensed under the GPL, and might export the sorts of interfaces that Illumos does, thus allowing the ZFS module to link without reference to either the glue or the kernel! Then how could such glue be said to violate the GPL? It couldn't! Nor could ZFS be said to be violating the GPL in that case.

I don't think you can avoid an escape hatch for the GPL in the kernel without disallowing dynamic loading or modifying the GPL to have harsher terms. But recall that the GPL, and/or much software distributed under the GPL, is designed to have escape hatches: so you can run proprietary software using standard interfaces, for example (i.e., user-land code is not required to be GPLed just because it runs on a GPLed kernel, though a kernel could require it, it's just that _Linux_ doesn't).

It seems here you can't have your cake and eat it too.

The idea to use shims in order to evade the law seems extremely dubious to me. I just can't see a judge say "oh, nice trick there in evading the intention of the copyright authors. I will now rule in your favor".

> A Linux kernel module is a derived work of the kernel

I'd like to see more legal argument, with citation to applicable precedent, on this conclusion. It necessarily, for functional reasons, makes some use of copyrighted kernel interfaces, but whether this use of functional elements makes it a legal derivative work is a question I've seen many people present cobflicting conclusions on, but never with much argument supporting the conclusion.

Imagine a kernel module which provides a bridge between an external (possibly standard, for some value of standard) API/ABI on one side, and the Linux kernel's internal interfaces on the other. Such a module might derive from the kernel depending on whether those internal interfaces can be copyrighted (and, do we want it to be the case that all interfaces can be copyrighted and licensed restrictively?! probably not), in which case it would have to be distributed under the terms of the GPL. But other modules using that external API/ABI certainly could not be said to be derived from the kernel, full stop.

This then requires looking for a way in which the GPL prevents creating such adaptor modules. I don't see how it does. Perhaps it could if modified, but as it is I don't think it does. IANAL though.

Linux has a established rule for module license.

In the kernel, functions which might be used by any modules are exported using EXPORT_SYMBOL. But if a module wants to use functions exported via EXPORT_SYMBOL_GPL, then the module has to use GPL.

The thing is, it's actually not clear whether the intention here might actually harm the GPL. Effectively, programmers aren't lawyers so is marking something as EXPORT_SYMBOL_GPL considered to be a legal restriction? And does that actually imply that EXPORT_SYMBOL is not considered a derived work? The problem is that "derived work" is something that needs to be handled on a case-by-case basis -- if you had a module that scanned the kernel's address space to violate the EXPORT_SYMBOL_GPL restriction, would that module have to be under the GPL (the answer is yes IMO, even though it didn't use any EXPORT_SYMBOL_GPL APIs).

This was brought up in a (very long) ML thread on LKML[1].

[1]: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...

the problem with that point is that certain open source Mobile OSes have been doing exactly that with the closed source SOC drivers found in most mobile handsets

If the module has no code from the Linux kernel, then how can it be said to derive from it? Well, some would say that a distribution that includes both is deriving one or the other from.. the other, since in the end both will be loaded in one "process". I think that's too much of a stretch, though ultimately that would have to be decided by the courts, naturally. Or maybe it's a strawman -- I really don't understand the arguments that Canonical is violating the GPL here.

Does building zfs.ko not involve #include ing some linux header files? Or is it all done via ABI?

The linux kernel headers are specifically exempt from the "linking" GPL infection.

No they're not. The kernel is under pure GPLv2 with a clarification that using standard system calls does not create a derivative work of the kernel. There are no additional exemptions.

There is no such thing as a "licensing infection", licenses being inert documents...

Unless the document has a close saying everything it touches gets infected.

The GPL does not use the word "infect" in any of its versions or related licenses. You're just projecting your biases onto an inert legal document, based on a fundamental misunderstanding of copyleft.

Legal documents have real life implications, calling it inert is just project a fantasy of yours that they are papers with no consequences.

That's not what I was saying, I was responding to a statement about documents "infecting" one another which is clearly incorrect.

But even if I _had_ said that, you're still not correct. In a contractual agreement, the legal document _itself_ is not what has the "power" in the agreement -- the agreement is what matters. To whit, contract law applies in cases where legal documents are not actually written down (you can even have implicit contractual obligations) and due to the requirement for "meeting of the minds" there can be cases where a contract doesn't have the power that it may claim it has. Of course, a legal document is a much more formalised agreement (and obviously they are a very useful tool to make sure that the precise agreement is laid out) but just because it's more formal doesn't implicitly mean that the document itself is somehow imbued with some mystical force to effect consequences.

I'm not a lawyer, but I have discussed this topic with lawyers in the past.

Maybe more people would adopt it if they changed the license?

Who is "they"?

I guess only Oracle can change the license, since they own original ZFS now.

Oracle can't change the license alone. While Oracle is the majority copyright holder, some parts are copyrighted by other people and/or organisations. In fact, this was one of the building principles of the CDDL license.

This ZFS on Linux project mentioned in the article doesn't use the current Oracle ZFS code (which is proprietary), but rather the OpenZFS code which has had very significant changes that happened post-Oracle fork by parties other than Oracle.

Almost all of ZoL is under "CDDL 1.0 or later". Oracle could release a new version of CDDL that explicitly made the ZoL project GPL compatible.

I'm not sure you understand the situation, which is surprising with how much time you spend talking about it - is this willful? - Oracle (And Sun before them) do not hold all of the copyrights involved. Some of them are held by third parties.

The CDDL was written to be as permissive as possible within the boundaries they are held to by these third parties.

It is impossible for Oracle to release a version of the license that is GPL compatible without completely removing all of these third party components they do not hold the copyright to.

I would recommend reading section 4 of the CDDL (it's actually very similar to section 6 of the MPL 1.1 because that's what it was based on).

In particular, it has an or-any-later version clause that is opt-out. This means that if Oracle decided to release CDDL 2.0 tomorrow that was GPL-compatible, anyone with CDDL 1.0 licensed (without the opt-out) codebases could then use it in conjunction with GPL code (by exercising the upgrade path). From memory, the original ZFS codebase (and also OpenZFS) doesn't exercise the opt-out -- which means that they can be switched this way. [This is basically how you would take LGPLv2 code and put it into an AGPLv3 codebase (LGPLv2 -> GPLv2+ -> GPLv3+ -> AGPLv3+).]

I believe that's what they were trying to say. I'm not a lawyer (as usual) but that was the opinion of the community a few years ago. Canonical decided to just "go for it" and see whether Oracle will sue them. We'll see what happens in the future.

The basic misunderstanding is that Oracle does not own the the copyright to all of OpenZFS. A lot of code in the OpenZFS code base is not under any sort of copyright assignment to Oracle. To change the license on the whole, you would need Oracle and all the contributors who have not done copyright assignments to agree to re-license their code.

I'm going to repeat this again. It's got nothing to do with copyright assignment. The license that the code is under (CDDL), by default, allows Oracle to provide newer versions that anyone can update their copy of the code to.

It's effectively the same mechanism as MPL's update system, and also effectively the same as GPL's update mechanism. You can take a GPLv2-or-later codebase and redistribute it as GPLv3-or-later because the FSF has released GPLv3. Similarly, you can take a CDDL-1.0 codebase and redistribute it as CDDL-2.0 because the "or any later version" clause is implicit and opt-out.

If you agree that GPLv2-or-later code (regardless of who owns the copyright) can be redistributed or combined with GPLv3-or-later code, then you agree with the basic point of what I'm saying. Obviously the specifics are different but the basic idea is the same.

Seriously. Read section 4 of the CDDL[1]. It's only three short paragraphs.

[1]: https://github.com/zfsonlinux/zfs/blob/master/OPENSOLARIS.LI...

I have read it, but not all of the files are under the "later" clause. Its a small number right now, but it will probably increase. So Oracle cannot do the whole OpenZFS in one swoop.

The majority of OpenZFS hasn't exercised the opt-out (and most importantly, the portions that are from the original ZFS are definitely not exercising the opt-out). There are two possible options:

1. Re-implement those files. 2. Ask the current copyright holder to remove the opt-out.

Given how small the number of lines is[1], I would be surprised if re-implementing would take more than a few weeks.

[1]: https://news.ycombinator.com/item?id=14866179

They agreed to that when they released the code under CDDL without specifying that it was restricted to version 1.0. Look at how Wikipedia was relicensed from GFDL to CC-BY-SA for an example of this.

>Oracle does not own the the copyright to all of OpenZFS

True, but I don't think the OpenZFS developers would be against relicensing their code to be GPL compatible,they are offering a Linux version of OpenZFS after all, so if Oracle would re/dual license their part of the code in a GPL compatible manner I'm sure the OpenZFS devs would do the same.

I would imagine the FreeBSD groups might object because it gives their project an edge over Linux. I can see if it went to a BSD license, but let's be real this is friggin Oracle. They won't do it because there is no actual advantage for them. Grateful developers are about their lowest priority. Maybe if it helped them win a contract that paid a lot of money they'd do it.

> I would imagine the FreeBSD groups might object because it gives their project an edge over Linux.

Or, they might object because this hypothetical new license is incompatible with FreeBSD for various reasons, legal or otherwise, and they would not be able to get new contributions back into FreeBSD.

I've read it. That doesn't mean that all of the files are licensed with the any-or-later clause.

I believe it was in the same talk that Cantrill likened Ellison to a lawnmower, but an ex-Sun employee talked about how the tangled legal web of who owned what part of Solaris precluded them from being able to release it under the GPL, and thus the CDDL was born. My understanding is that, if any of these bits that they do not own themselves and have restrictions on how they can license them, were licensed in such a way that they could be switched to the GPL or a GPL-compatible license, then Sun and now Oracle would probably be out of compliance with the terms they are bound by. My educated guess is that the files that have opted out of the update mechanism are the files that are in this situation.

It's also unlikely that Oracle would be the ones to sue Canonical - the CDDL license doesn't include any provisions that would give them the ability to sue. I'm sure they have copyrights on some parts of the Linux kernel, which they could potentially use to sue if they truly believe that they could win a case in court to show that OpenZFS is a derivative work of the kernel.

> I've read it. That doesn't mean that all of the files are licensed with the any-or-later clause.

You're right, only 96% of the files and 99.5% of the code are.

> My educated guess is that the files that have opted out of the update mechanism are the files that are in this situation.

The files that have opted out contain very little in the way of interesting code, so I don't believe this to be true.

Fair enough! I retract my statement.

> It is impossible for Oracle to release a version of the license that is GPL compatible without completely removing all of these third party components they do not hold the copyright to.

I don't think this can be accurate. Ownership of ZFS-related code is not tied to being the license steward - Oracle could theoretically pass off license steward duties to a third party without passing ZFS copyrights or obligations to the same third party. That third party could then change the terms of the CDDL without having any obligations towards those third parties.

In any case, it doesn't make sense - the CDDL is more permissive than GPL 2.0 other than its patent clause, and (as far as this discussion is concerned) the only relevant party covered by 6.2 is Oracle.

So, uh, citation strongly needed.

there is a lot of self-confidence in your reply, but it doesn't address his/her point: that there is essentially a "loophole" that Oracle could exploit if they wanted to by writing a new version of the CDDL.

his/her contention is that most of the code has been released without the explicit opt-out for a more recent version of CDDL.

there's no need to get nasty; just bring the facts.

As others have pointed out, some parts of the ZFS code exercise the opt-out and do not include the update mechanism.

> Almost all of ZoL is under "CDDL 1.0 or later"

Actually no, it is not.

CDDL requires you to opt out of later versions. 9 files (out of 219) totaling 950 lines (out of over 190,000) in the ZoL kernel code claim to be 1.0 only. What definition of "Almost all" are you using?

> Oracle could release a new version of CDDL that explicitly made the ZoL project GPL compatible.

By allowing ZFS-derived works to be licensed under GPL, I suppose. I wonder if they could do it without allowing for a GPL fork which would become unmergable to the upstream?

The problem would be similar to MIT or Apache licensing a project. It is very uncommon for someone to create a fork of an existing project _just_ to change the license. Most of the people working on OpenZFS are unlikely to just switch licenses, the net result would just be to allow dual-licensing under GPLv2 so you can use it in Linux.

People working on OpenZFS are unlikely to switch licenses, but somebody (presumably a company) could possibly develop an "improved" fork to make money on it and refuse to contribute back, at which point Oracle would be forced to switch to GPL if the fork takes off.

Dunno, it's just a hypothetical question and speculation whether there are any sensible reasons for Oracle to maintain status quo.

ZoL and upstream ZFS have already diverged significantly, since Oracle stopped releasing source several years ago.

Why would Oracle care about the number of people using ZFS on anything but Solaris?

I don't know if they do care about these things, but it is conceivable they might care about: Selling support, increasing the amount of engineers familiar with their stuff, finding some new angle to try to sue Linux out of existence with or any one other goal that is furthered by the network effect.

Reply on news.ycombinator.com