Kirkland: ZFS licensing and Linux [LWN.net]

Dustin Kirkland justifies Ubuntu's plans to ship the ZFS filesystem kernel module. "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 and even proprietary (hi, nvidia.ko) kernel modules."

to post comments

Kirkland: ZFS licensing and Linux

Posted Feb 18, 2016 23:07 UTC (Thu) by juliank (guest, #45896) [Link] (20 responses)

I can only say that the Conservancy continues to "investigate the evolving situation."

https://twitter.com/conservancy/status/700094818035245057

Well, I could say more, but I really shouldn't.

Kirkland: ZFS licensing and Linux

Posted Feb 18, 2016 23:09 UTC (Thu) by juliank (guest, #45896) [Link] (19 responses)

Oh, with regards to nvidia.ko: I'm working on getting pre-compiled bits removed from Debian:

http://bugs.debian.org/815060

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 16:33 UTC (Fri) by fandingo (guest, #67019) [Link] (18 responses)

> Several lawyers and people believe

As other commenters say, please produce these opinions, so we can evaluate them. How are you qualified to make legal decisions?

>Legal issues prevent me from saying more

Then table the proposal until you can discuss it freely. There's nothing requiring immediate action, so a deliberate path is best.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 16:40 UTC (Fri) by juliank (guest, #45896) [Link] (6 responses)

The first comment was obviously not entirely correct, as it missed a few points, but I assumed everyone knew the issue at hand: Combining GPL-incompatible works with GPLed work should be considered a copyright violation.

The second comment: I meant to say: I cannot say who says what, as that discussion was confidential. I can only say that people involved in kernel GPL compliance were notified in that process, whether by accident or planned.

Ben now wrote an email detailing his position, so this is already taken care of (others might comment too). Having Debian's kernel maintainer and major kernel contributor say that he considers it a violation of the kernel license should make it obvious that we need to take action on it.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 18:41 UTC (Fri) by fandingo (guest, #67019) [Link] (4 responses)

> I cannot say who says what, as that discussion was confidential.

Then, I assume you understand we can't give those sources any weight. We can't evaluate the opinions, and we can't evaluate the credibility of those making the opinions. They are spurious.

> Having Debian's kernel maintainer and major kernel contributor say that he considers it a violation of the kernel license should make it obvious that we need to take action on it.

Not really. Is he a lawyer? Does this person have some unique knowledge of international copyright law that qualifies him to reach a conclusion? This is a bunch of software developers who want to play lawyer on the Internet. The claims you're (and others in the thread are) making about violating licenses and stuff are unsubstantiated and uncredible without supporting materials.

You guys may well be right, but the argument and evidence presented don't formulate anything that can be used to reach a conclusion. Barring such convincing items, the proper action is to defer any decision -- letting the current behavior remain -- until a conclusion can be reached.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 19:08 UTC (Fri) by juliank (guest, #45896) [Link] (2 responses)

We don't need lawyers to make an internal decision to move out of a potential copyright violation, thank you very much. There's no reason for us to be involved in such shady business. This is a proactive action to avoid that. That avoids work and also saves money for more important GPL enforcement efforts like the VMWare case or the ZFS thing.

Technically, there also is no real benefit for everyone, given that both dkms and module-assistant packages are provided.

Kirkland: ZFS licensing and Linux

Posted Mar 22, 2016 1:03 UTC (Tue) by Rudd-O (guest, #61155) [Link] (1 responses)

Not commenting on the legal issues.

From a practical standpoint, use of DKMS effectively prevents distro installers from installing distros to ZFS file systems. It also HUGELY complicates ZFS upgrades, particularly if they need to make their way into the initial RAM disks necessary to support systems that require ZFS to boot.

If that was shipped as a kernel module and matched with the distribution's offering of kernel modules, all of that would be a thing of the past.

Of course, that would require the relevant bloodsuckers to agree instead of to fight.

Kirkland: ZFS licensing and Linux

Posted Mar 22, 2016 11:56 UTC (Tue) by tao (subscriber, #17563) [Link]

zfs-fuse for the installer (which isn't really performance critical), native module built using dkms for normal operations.

Also, what's "HUGELY" complicated about using dkms? dkms will automagically rebuild your kernel modules and install them to the initrd, no manual work necessary.

All that said I wouldn't touch ZFS with a ten-foot pole unless they change their license.

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 8:49 UTC (Sat) by Del- (guest, #72641) [Link]

> You guys may well be right, but the argument and evidence presented don't formulate anything that can be used to reach a conclusion. Barring such convincing items, the proper action is to defer any decision -- letting the current behavior remain -- until a conclusion can be reached.

It seems you are playing it into the hands of those who want to abuse copyleft. For a company like Canonical, the intent of a license should suffice for them to honour it. With your statements your are supporting those who look for technical weaknesses in current law for their own profit, willingly breaking the intent of the law. There are many examples of it, usually driven by greed at the expense of society.

You need to ask yourself, did the copyright holder of ZFS specifically intend for ZFS not to be used in GNU/Linux? Then ask yourself, do the copyright holders of Linux specifically intend for kernel modules being GPL compatible? Then it should not be so damn hard to conclude. Canonical is going down a path I cannot follow, heck even Facebook puts their resources into btrfs rather than breaking license terms. Is it so damn hard to be a decent member of the open source community.

Kirkland: ZFS licensing and Linux

Posted Feb 28, 2016 17:37 UTC (Sun) by Wol (subscriber, #4433) [Link]

> The first comment was obviously not entirely correct, as it missed a few points, but I assumed everyone knew the issue at hand: Combining GPL-incompatible works with GPLed work should be considered a copyright violation.

Except that this is EXPLICITLY PERMITTED by the GPL.

DISTRIBUTING such a combined work, on the other hand ...

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 17:42 UTC (Fri) by Wol (subscriber, #4433) [Link] (10 responses)

> Then table the proposal until you can discuss it freely

Isn't that what he just did - tabled it so we could discuss it?

:-) Hint - "table it" is not a very good phrase to use - I suspect it means the complete opposite to me than to you - it has a completely different meaning in English. (As opposed to American.)

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 18:25 UTC (Fri) by fandingo (guest, #67019) [Link] (9 responses)

Table means to postpone consideration. It means that in both languages. The only discrepancy is the expectation on when consideration will resume. British English implies soon, but American English implies later or possibly never.

You could use either definition and not lose my meaning.

You seem to believe that things "on the table" are under active consideration. That's not true in either language.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 19:01 UTC (Fri) by Pc5Y9sbv (guest, #41328) [Link]

Actually, there are two different idioms understood consistently in all English dialects, except for certain members of either population who may be ignorant of one of the idioms. Tabling a discussion point is not the same idiom as putting something on the table.

A completely different metaphorical mapping is at play for "tabling" versus "putting/taking on/off the table". The former invokes a governmental procedure to change topics away from the item being tabled, while the latter invokes including/excluding a topic or item for negotiation or transaction in a business or gambling setting. The very specific syntax of table as a verb versus putting or taking are the idiomatic signals for these two different metaphors.

This post is about interoperable communication so I think is somehow on topic for LWN and license lawyering. :-)

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 22:51 UTC (Fri) by pjtait (subscriber, #17475) [Link]

I think it is true in non-US English, according to OED: "(a) To present or submit formally for discussion or consideration." Seems to imply "active consideration", no mention of postponement....

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 5:08 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link]

fandingo writes:

> Table means to postpone consideration. It means that in both languages.

As someone from the UK who has spent more than a decade living in Australia I've never heard it used in that manner in either country (so far).

However, my 1990 copy (14th edition) of Brewers Dictionary of Phrase and Fable surprised me in that it gives both meanings as being used; both to postpone discussion and to put a matter up for discussion.

Language is a wonderfully bizzare thing. :-)

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 10:04 UTC (Sun) by paulj (subscriber, #341) [Link] (5 responses)

I never knew that "to table a discussion" could mean "to postpone indefinitely" to an American speaker, if the timeframe of that discussion is left implicit.

The Irish & British use might not mean "under active consideration" right now, but it does imply some imminence to that discussion. At the very least, one would expect that the next discussion will include that topic, so if there is any discussion then that topic should be part of it.

Learn something new every day.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 12:37 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

There's a great story about Churchill and Roosevelt, meeting in mid-Atlantic in 1942, where some advisor came up with a good idea.

"We need to table that" says Churchill.

"No no, we mustn't table it" says Roosevelt.

Cue some quiet amusement when they realised what had happened :-)

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 16:48 UTC (Sun) by shmget (guest, #58347) [Link] (2 responses)

"The United States and Great Britain are two countries separated by a common language. " (uncertain attribution)

Kirkland: ZFS licensing and Linux

Posted Feb 25, 2016 19:48 UTC (Thu) by Wol (subscriber, #4433) [Link]

Just to add to that, as I understand "to table something" it doesn't necessarily mean to discuss immediately, but in *English* it very definitely gives the topic some urgency.

Used outside of a meeting, it would be understood as "this needs to be on the next agenda", and in a meeting we would typically say "this needs to be tabled for the next meeting".

Having watched one of my local council meetings, it was very definitely the case that if it wasn't on the agenda it wouldn't get discussed, so tabling something would make sure it got on the next one.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Mar 22, 2016 1:04 UTC (Tue) by Rudd-O (guest, #61155) [Link]

Obviously by Oscar Wilde.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 17:16 UTC (Sun) by Pc5Y9sbv (guest, #41328) [Link]

It doesn't necessarily mean indefinite postponement to Americans. It really just means let's stop talking about this and move on to other items in an agenda. The ambiguity of intention may come from a cultural awareness of US congressional tactics, where tabling something may be a precursor to sending it to a smaller committee, where it may be mangled beyond recognition or left to die before it is ever brought before a full session again. So, it can have this connotation of terminating broad debate and handing off to power brokers.

Kirkland: ZFS licensing and Linux

Posted Feb 18, 2016 23:24 UTC (Thu) by ldo (guest, #40946) [Link] (34 responses)

As pointed out in the comments to that post, isn’t Oracle suing Google over claims of infringement of its copyright in an API? And isn’t this ZFS module copying the Linux API?

In other words, if one API is copyrightable, then so is the other.

And by the way, isn’t Oracle the owner of the copyright in ZFS?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 0:02 UTC (Fri) by drag (guest, #31333) [Link]

Linux kernel has a history of tolerating 'non-derivative' works. Classic example is the support for OpenAFS has been shipped by many distros for ages.

Also it's a good idea to stop pretending that copyright makes sense. It's very arbitrary. You have to predict the reasoning a judge may choose to base his ruling on and he will have a wide selection of criteria to pick and choose from.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 0:52 UTC (Fri) by marcH (subscriber, #57642) [Link] (18 responses)

> In other words, if one API is copyrightable, then so is the other.

If a book is copyrightable, then so is one word.

Kirkland: ZFS licensing and Linux

Posted Feb 22, 2016 8:31 UTC (Mon) by yoe (guest, #25743) [Link] (17 responses)

Sorry, it doesn't work that way.

Copyright is not about "words", it's about "creativity". You can't copyright anything unless a step of creativity was involved. The recent invalidation of the "Happy Birthday" copyright shows that: the original (out-of-copyright) text of "Good Morning to you" from which "Happy Birthday" was derived differed in only three words (and some repetitions) from that of "Happy Birthday", and this was considered not creative.

Thus, no, one word is not copyrighteable. Exceptmaybeifitsaverylongword, but then you're just obnoxious.

Kirkland: ZFS licensing and Linux

Posted Feb 22, 2016 10:34 UTC (Mon) by tao (subscriber, #17563) [Link]

Supercalifragilisticexpialidocious would probably be a good candidate for such a word :)

Kirkland: ZFS licensing and Linux

Posted Feb 25, 2016 12:26 UTC (Thu) by simosx (guest, #24338) [Link] (15 responses)

Define "creativity". In a non-subjective, non-culturally biased way.

It is a common pattern to try to "solve" vagueness by inventing something else to deal with it. And that "something else" is still vague.

Kirkland: ZFS licensing and Linux

Posted Feb 25, 2016 17:58 UTC (Thu) by yoe (guest, #25743) [Link] (14 responses)

Why?

Law is not math. Room for judicial interpretation is a feature, not a bug. As such, there is no need to have things be strictly defined.

Kirkland: ZFS licensing and Linux

Posted Feb 25, 2016 22:35 UTC (Thu) by marcH (subscriber, #57642) [Link] (12 responses)

> Room for judicial interpretation is a feature, not a bug. As such, there is no need to have things be strictly defined.

?!?

Not every member of the legal profession contemplates with satisfaction the job security ensured by the complexity and ambiguities of his or her respective legal system. Just like IT professionals, many of them are decent, not evil human beings working towards "making themselves redundant" whenever they can, aspiring to a fairer and better world and trying to define things as strictly as they possibly can (which is still not much; granted). And just like in IT they know that there'll always be more work for them anyway, especially for the best of them.

Now of course they face a much tougher job than us since they deal with human beings and natural languages instead of machines. Their complexity is only partially artificial. But no, none of this makes judicial interpretation a "design feature". It's just an absolutely necessary evil.

Kirkland: ZFS licensing and Linux

Posted Feb 26, 2016 9:43 UTC (Fri) by yoe (guest, #25743) [Link] (11 responses)

This has nothing to do with law professionals. I can see, and probably agree, that to them it is a necessary evil. But it isn't to you and me.

If the law did not leave any room for judicial interpretation, a judge would not be necessary. You could, theoretically, just have a computer decide who's right and who's wrong. That doesn't happen though, for a (good) reason. Of course, the law needs to be clear, but it shouldn't be strict.

Creativity isn't entirely well defined, but it's also not so vague as to be entirely useless. Any reasonably competent judge will be capable of deciding, within the context of the rest of the case, whether it happened. This allows the judge to make a decision that matches not only the facts, but also the context. Counting words doesn't give you that; a gray area as created by a not completely defined term does.

Kirkland: ZFS licensing and Linux

Posted Feb 26, 2016 15:54 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (1 responses)

> Creativity isn't entirely well defined, but it's also not so vague as to be entirely useless. Any reasonably competent judge will be capable of deciding, within the context of the rest of the case, whether it happened.

The question is whether the ruling is *reproducible*. If you put the same question to another judge, with the same context, are they likely to come to the same conclusions?

The law doesn't need to be as well-defined as a computer program, but it should still be reasonably objective. If the outcome of a case depends significantly on the specific judge that heard it, that is a flaw, not a feature.

Kirkland: ZFS licensing and Linux

Posted Feb 27, 2016 6:14 UTC (Sat) by raven667 (subscriber, #5198) [Link]

> The question is whether the ruling is *reproducible*. If you put the same question to another judge, with the same context, are they likely to come to the same conclusions?

That's what appeals are for, to get more and more judges to come to a consensus on what the right answer is and drown out any individually poor signal. The judicial systems have been refined over hundreds of generations of people based on empirical observation, even without complete scientific rigor, they still aren't crazy or unreasonable.

Kirkland: ZFS licensing and Linux

Posted Feb 26, 2016 16:25 UTC (Fri) by marcH (subscriber, #57642) [Link] (8 responses)

> Counting words doesn't give you that; a gray area as created by a not completely defined term does.

Legal texts always strive for the best possibly defined terms. Even knowing it'll never be perfectly defined, people are still doing their best.

There's a science of counting that leaves plenty of gray area: it's called Statistics. For instance:
- Most books which do not rely on copy/paste are copyrightable.
- Most single words are not copyrightable.

Grey areas somewhere in the middle.

Kirkland: ZFS licensing and Linux

Posted Feb 26, 2016 19:45 UTC (Fri) by micka (subscriber, #38720) [Link] (7 responses)

> There's a science of counting that leaves plenty of gray area: it's called Statistics.

Actually it doesn't. It's as hard a science as you get.
In people's mind it doesn't appear like that because it treats with random things. But that's all.

Statistics

Posted Feb 27, 2016 6:36 UTC (Sat) by marcH (subscriber, #57642) [Link] (2 responses)

> In people's mind it doesn't appear like that because it treats with random things. But that's all.

Yes, people should be fixed. It's important.

For instance the next time my doctor friend tells one of her patients:
"In the past, 54.2% of people with our stage X cancer survived more than 2 years".

I'll suggest she adds from now on:
"This number is based on hard science and exact statistics - no grey area whatsoever".

They'll be delighted not to ever make this semantic mistake again.

Statistics

Posted Feb 27, 2016 8:25 UTC (Sat) by micka (subscriber, #38720) [Link] (1 responses)

> Yes, people should be fixed. It's important.

That's called "educated" in most places.

And the call to empathy you seem to be doing next doesn't change the facts.

Statistics

Posted Feb 27, 2016 11:40 UTC (Sat) by micka (subscriber, #38720) [Link]

And by the way, you seem to be mixing statistics (the name for the branch of mathematics) and it's application in other fields.
In that cas, medecine is a common engeneering field that uses biology, chemistry and statistics.

Kirkland: ZFS licensing and Linux

Posted Feb 27, 2016 12:17 UTC (Sat) by paulj (subscriber, #341) [Link]

The "science" (well, mathematics - which may reasonably be considered something other than science) may be very "hard" and rigorously defined, however it inherently deals in probability/uncertainty and probabilistic distributions of entities. MarcH is obviously referring to the latter.

Kirkland: ZFS licensing and Linux

Posted Feb 27, 2016 13:41 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

> Actually it doesn't. It's as hard a science as you get.

Actually, I'd disagree very strongly with that. Statistics is NOT a Science. It's Maths.

And my feelings on that are well known - science and maths are complementary, they do not overlap. So things must be one or the other, not both.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 27, 2016 18:30 UTC (Sat) by micka (subscriber, #38720) [Link] (1 responses)

Well, yes, I'm also sometimes mixed on the subject.
But your feelings mean nothing. You don't get to define science the way you want. The fact is there is no complete consensus on the subject, and that any way to classify things, with or without maths, works as well as the other one.

Kirkland: ZFS licensing and Linux

Posted Feb 28, 2016 17:44 UTC (Sun) by Wol (subscriber, #4433) [Link]

Yes I don't get to define Science the way I want. But if I use Philosophy (that is, the study of logic) to try and define what Science and Maths are, I end up with two complementary definitions.

Science is *using* observations and logic to predict the future.

Maths *is* logic.

I cannot, logically, reconcile the two into one. (Other people think they can.)

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Mar 22, 2016 1:05 UTC (Tue) by Rudd-O (guest, #61155) [Link]

It's a shit feature if you ask me.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 11:02 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (12 responses)

ZFS is definitely not copying the Linux APIs in the same way as Android was. You won't find #define spin_lock(lock) or anything like that in the ZFS code. Much less it's copying the "structure, sequence and organization" of the Linux APIs.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 20:39 UTC (Fri) by jepler (subscriber, #105975) [Link] (11 responses)

Let us look into the Linux spin_lock function for a moment, since you made it an example.

Linux defines spin_lock as a 'static inline' in the header <linux/spinlock.h>.

spl's <sys/mutex.h> (indirectly, apparently) includes the definition of this function and in turn uses it in the macro mutex_exit. In turn, mutex_exit is used frequently in zfs, e.g., in module/zfs/arc.c.

I'll leave it to you to decide whether "zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel" (as Ubuntu/Canonical lawyers have apparently decided) or whether directly incorporating GPL code into zfs.ko via preprocessor macros and inline functions makes it a derivative work.

(the definition of spin_lock is pretty trivial TODAY, in that it just calls raw_spin_lock, but there are MANY GPL headers included from spl headers, and probably additional instances of direct code inclusion via macros and inlines. If you think the triviality argument is a good one, then you need to be confident that all the macros and inlines used are trivial not only today but for future kernels which have not yet been written)

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 10:16 UTC (Sun) by paulj (subscriber, #341) [Link] (8 responses)

If the core of ZFS is derived from Linux, then the NVidia binary blob must be too.

The core of ZFS is at least Free Sofware. Even if there are a few technical incompatibilities (particularly around the patent MAD licensing language), the broad goal of the CDDL is to be a copyleft licence, as with the GPL[1].

The NVidia binary blob (and others probably) clearly is not at all free software. Further, it's been, what, more than a decade since they ported the original windows-specific core to Linux via an open shim. More than a decade of development to that core while supporting Linux makes you wonder think it's highly unlikely the core hasn't been adapted to take Linux internals into account - unless NVidia could /demonstrate/ they have had stringent internal firewall between the two.

It is somewhat strange to try defend the principle of Linux being licensed as copyleft free software by attacking the use of other copylefted free software with it, while giving a free pass to those shipping binary blobs for use with Linux and that (by now) likely have adaptations for Linux.

It's also sad Oracle havn't re-licensed ZFS.

1. Ok, so the CDDL tries to restrict itself to files, but it still covers any derived works of those files, so not convinced that aspect is much of a distinction.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 16:38 UTC (Tue) by Wol (subscriber, #4433) [Link] (7 responses)

> It is somewhat strange to try defend the principle of Linux being licensed as copyleft free software by attacking the use of other copylefted free software with it, while giving a free pass to those shipping binary blobs for use with Linux and that (by now) likely have adaptations for Linux.

Except nVidia *have* taken steps to explicitly keep within what is acceptable. Namely, the shim is GPL'd, the module itself is NOT a linux module (aiui it works on Windows too), and nVidia *actively* *avoid* shipping the two together. So do most distros.

Bear in mind what the end user does it outwith the scope of the GPL, so if the end-user is legally liable for mixing GPL and non-GPL code, the GPL doesn't care.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 16:54 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

That was touted as the reasoning originally, yes NVidia developed their Linux driver by taking their existing Windows binary blob, and writing a shim around it. They GPL the shim, and the Windows blob clearly had nowt to do with Linux, so no need to distribute that under GPL compatible terms.

However, that was well over a decade ago. In which time NVidia have been developing that binary core. It's more than possible that development since has caused adaptations to be made to the binary core because of Linux, and I thought I've read somewhere this was the case to an extent. Regardless, time, of itself, has made the "the binary core was only developed for Windows, so can't derive from Linux" part of that argument not be automatically obvious. In which case, NVidia need some other argument as to why their binary core does not derive from Linux - as we would tend to assume for any other.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 17:52 UTC (Tue) by bronson (subscriber, #4806) [Link] (4 responses)

This seems like a stretch without any supporting evidence.

Do you really think anybody familiar with Linux internals is contributing to the nVidia binary? If so, then nVidia has some managers that need to be fired.

Cleanroom development has been an industry practice since the 80s (or before?). Common sense would suggest that nVidia would employ it here as well. Alas, I have no evidence one way or the other, other than they seem reasonably competent.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 18:00 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

> Do you really think anybody familiar with Linux internals is contributing to the nVidia binary?

Given the extent to which it's gaining support for new features in the graphics stack? Yes, clearly.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 22:06 UTC (Tue) by bronson (subscriber, #4806) [Link] (2 responses)

Interesting... I'd thought most of the new kernel changes were going in the shim layer.

If new kernel features being passed straight through to the binary and back then yep, that's pretty clear evidence that nVidia isn't using clean room techniques and has probably contaminated their binary.

That would be a rookie mistake! If so, I hope they get shown the error of their ways.

(More speculation: maybe they're intentionally betting the GPL is toothless... though that seems like an irrational decision since it wouldn't cost much more for clean room dev. Clean room should be less than the lawyer fees anyway.)

Kirkland: ZFS licensing and Linux

Posted Feb 24, 2016 15:16 UTC (Wed) by martinfick (subscriber, #4455) [Link] (1 responses)

Most things that can't be tied to financials have no teeth. Who is nvidia hurting financially that would be willing to go after them? And if they win, what would they win? And most importantly to nvidia's lawyers, how would nvidia suffer if they lost?

Kirkland: ZFS licensing and Linux

Posted Feb 29, 2016 18:11 UTC (Mon) by bronson (subscriber, #4806) [Link]

All good points. That would be disappointing if the most sensible business case is, "eh, let's just see if it bites."

Kirkland: ZFS licensing and Linux

Posted Feb 28, 2016 20:11 UTC (Sun) by Wol (subscriber, #4433) [Link]

> It's more than possible that development since has caused adaptations to be made to the binary core because of Linux, and I thought I've read somewhere this was the case to an extent.

And actually, this is totally irrelevant :-)

Let's assume that nvidia.ko did start as a Windows module. All nVidia need to do is keep the code separate, and make sure no code crosses from the linux source tree into the nVidia source tree.

All commits to the nVidia build system need to be of nVidia-written code (or suitably bought-in or licenced code). So long as no linux code is brought in (or if it is, it is checked for "necessity" or non-copyrightability, such as enums or constant #defines), then the nVidia.ko clearly remains a non-derived work.

If any nVidia code needs to touch the kernel, then it has to go in the shim. No question.

And then nVidia (and others) refrain from distributing the shim and the module together. Provided that protocol is stuck to, then it's fine to modify nVidia.ko to take advantage of all sorts of kernel functionality, to have all sorts of linux-specific code in it. So long as the linux-specific stuff is (c) nVidia, there is no problem at all.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 16:32 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> (the definition of spin_lock is pretty trivial TODAY, in that it just calls raw_spin_lock, but there are MANY GPL headers included from spl headers, and probably additional instances of direct code inclusion via macros and inlines. If you think the triviality argument is a good one, then you need to be confident that all the macros and inlines used are trivial not only today but for future kernels which have not yet been written)

Not to make any claims as to the legality or not, but I understood that .h files were *supposed* to contain only declarations, and as such are *not* *supposed* to contain any copyrightable code.

"Yer onner - we assumed those .h's did what .h's were supposed to do - how are we supposed to know they contain stuff they shouldn't?"

(Oh - and if zfs.c doesn't actually call any of those more complicated definitions, their existence *shouldn't* be a problem.)

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Mar 3, 2016 20:24 UTC (Thu) by nix (subscriber, #2304) [Link]

Not to make any claims as to the legality or not, but I understood that .h files were *supposed* to contain only declarations, and as such are *not* *supposed* to contain any copyrightable code.

Nobody who's written C code at the level needed to be included in kernels or similarly low-level stuff could seriously be expected to believe that.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 14:42 UTC (Fri) by smoogen (subscriber, #97) [Link]

They are copyright owners of the parts that don't have the Linux API. The parts that have the Linux API are someone else's work. That said... drag's comment is spot on: Don't assume the law makes any sense or can be logically derived... especially because it has several thousand years of old code which has to be parsed when making a decision.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 0:33 UTC (Fri) by kevinm (guest, #69913) [Link] (33 responses)

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

Sure. And it's equally obvious that a system made up in part of a Linux kernel binary together with a zfs.ko binary is a derivative work of both of those constituent parts. Nvidia don't ship nvidia.ko and a Linux kernel together as part of a single work, do they?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 1:23 UTC (Fri) by butlerm (subscriber, #13312) [Link] (32 responses)

In what sense do they make a single work rather than a mere aggregation of compatible components?

Under U.S. law, "A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work” (17 USC 101).

Does merely putting two files on the some medium with no particular creativity involved make the result a derivative work? Or is it merely an aggregation of two independent works, like two books sitting next to each other on a bookshelf?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 1:52 UTC (Fri) by emunson (subscriber, #44357) [Link] (6 responses)

Sure, if you didn't need one book to make any use of the other. zfs.ko doesn't stand alone, it is useless without the rest of the kernel and depends on parts of that kernel.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 5:40 UTC (Fri) by butlerm (subscriber, #13312) [Link]

"it is useless without the rest of the kernel and depends on parts of that kernel."

As far as U.S. law is concerned both of those attributes are absolutely irrelevant. Wishful thinking, without foundation, someone's wild imagination, you name it.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 8:30 UTC (Fri) by gowen (guest, #23914) [Link] (4 responses)

This copy of Fallout 3 is useless without a Playstation 3, therefore it is a derivative work of the PS3 and belongs to Sony. This copy of Photoshop is useless without a MacBookPro therefore it is a derivative work of the MacBook and belongs to Apple. This copy of Snapchat is useless without a Android Phone therefore it is a derivative work of Android and belongs to Google.

It's a totally specious argument. To depend on X is not the same thing as to be a derivative of X.

Strawman bingo

Posted Feb 19, 2016 10:42 UTC (Fri) by oldtomas (guest, #72579) [Link]

> This copy of Fallout 3 is useless without a Playstation 3
... so far, so good

> therefore it is a derivative work of the PS3

...maybe

> and belongs to Sony.

Strawman!

(The other strawmen are left as an exercise for the reader)

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 17:07 UTC (Fri) by Tester (guest, #40675) [Link] (2 responses)

> This copy of Fallout 3 is useless without a Playstation 3, therefore it is a derivative work of the PS3

Yes, I'm entirely sure that every Playstation games disk cntains code that is copyrighted by Sony and therefore you can only make Playstation games with the explicit permission from Sony, you need to sign a contract, etc.. This is also true of other platforms, except that some copyright owners just allow anyone to write applications (think of MacOS or Windows), but they could certainly restrict those rights if they wanted to.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 23:21 UTC (Fri) by butlerm (subscriber, #13312) [Link] (1 responses)

> they could certainly restrict those rights if they wanted to.

That is not settled law, not in the United States at any rate. Unlike a Windows clone, a Windows application does not copy or reimplement the "structure, sequence, and organization" of the Windows API. Nor does a Win32 application (generally speaking) include any Microsoft code. Nor has it been determined whether the implementation of a compatible API is fair use or not in any case.

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 19:33 UTC (Sat) by Wol (subscriber, #4433) [Link]

Plus I think there is a long-standing SCOTUS decision that says "it doesn't matter if it's copyrighted or not, if it's needed for compatibility copyright cannot be enforced".

Was it Sega, or Nintendo? The console checked for a copyright statement in the cartridge and rejected the cartridge if it couldn't find it. SCOTUS effectively gutted that and said that in those circumstances the text was meaningless and unenforceable. So that should - if it goes to the Supreme Court - be a good precedent. Especially as that was a pretty clear copyright case, whereas all this "compatible API" stuff is a lot more fuzzy.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 1:56 UTC (Fri) by rahvin (guest, #16953) [Link] (21 responses)

The part of the module that interfaces to and calls kernel API's directly is a derivative work of the kernel. That should be obvious. I don't think that means the whole thing is a derived work after all that's the reason Nvidia ships an open source shim. There is undeniably a portion that is a derivative of the kernel.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 6:09 UTC (Fri) by butlerm (subscriber, #13312) [Link] (7 responses)

By that standard, every Windows application would be a derivative of Microsoft Windows, every Java application would be a derivative of the JDK, a great many Linux applications would be derivatives of the Linux kernel, and so on. And that is just the beginning. Think about how many applications would be derivatives of MySQL or OpenGL.

If that sort of thing is not fair use, soon every sizable vendor on the planet is going to start suing any consumer or producer of an API or ABI they invented. MS could demand a 10% royalty on all Win32 applications, Oracle could demand the same on all Java apps and MySQL apps, Khronos could start taxing OpenGL applications, and so on ad infinitum.

If compatibility makes something a derivative work, then we could shut down the patent office tomorrow. Why would anyone need a patent if any compatible product was a copyright infringement?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 7:43 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

> By that standard, every Windows application would be a derivative of Microsoft Windows, every Java application would be a derivative of the JDK, a great many Linux applications would be derivatives of the Linux kernel, and so on.

Regarding Linux there is an explicit statement clarifying that. It is by Linus, but I assume that contributors implicitly agree. I don't have a copy of Windows handy, does anyone know if they give explicit or implicit permission to run applications on top of it in the EULA?

Kirkland: ZFS licensing and Linux

Posted Feb 25, 2016 19:30 UTC (Thu) by davidstrauss (guest, #85867) [Link]

> Regarding Linux there is an explicit statement clarifying that. It is by Linus, but I assume that contributors implicitly agree. I don't have a copy of Windows handy, does anyone know if they give explicit or implicit permission to run applications on top of it in the EULA?

Authors don't get to define what is or is not a derivative work; that is a matter for the courts. What the GPL leverages is the assumption that courts will determine linking (or similar relationships between software) to create a derivative work, thus allowing the GPL to specify the terms under which linking is allowed.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 7:45 UTC (Fri) by marcH (subscriber, #57642) [Link]

> By that standard, every Windows application would be a derivative of Microsoft Windows...

This example will be relevant when Windows will be GPL-licensed.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 16:27 UTC (Fri) by juliank (guest, #45896) [Link]

> Java application would be a derivative of the JDK,

They are, which is the reason the classpath exception is used for the JDK, to allow people to build apps without them having to be GPL.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 22:36 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> If that sort of thing is not fair use, soon every sizable vendor on the planet is going to start suing any consumer or producer of an API or ABI they invented. MS could demand a 10% royalty on all Win32 applications, Oracle could demand the same on all Java apps and MySQL apps, Khronos could start taxing OpenGL applications, and so on ad infinitum.

I'm pretty sure this is exactly how this works, the reason that you can build/run Windows apps with VS or Java with the JDK is that there are explicit exceptions written into the licenses for the OS or base libraries allowing it. Without those exceptions you wouldn't have the rights to distribute your program which used the APIs without permission of, and possibly compensation to, the copyright holder of the API. This is how Sony makes their money on PlayStation games, or Epic on Unreal Engine, this is why the LGPL exists and why GCC has special exceptions for libgcc, it's the same.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 23:24 UTC (Fri) by butlerm (subscriber, #13312) [Link]

> Without those exceptions you wouldn't have the rights to distribute your program which used the APIs without permission of, and possibly compensation to, the copyright holder of the API.

Applications generally speaking do not copy or reimplement the structure, sequence, and organization of a lower level API at all, and as a consequence cannot infringe upon it. Even if they did, it may well be fair use, that question has not been decided yet.

Kirkland: ZFS licensing and Linux

Posted Feb 26, 2016 18:40 UTC (Fri) by Wol (subscriber, #4433) [Link]

> Oracle could demand the same on all Java apps and MySQL apps, Khronos could start taxing OpenGL applications, and so on ad infinitum.

IBM could start demanding a royalty on all Oracle database apps (including MySQL ...:-)

I really think Oracle shouldn't have sued Google - it looks like it could be a pretty tempting self-destruct button ...

Cheers,
Wol

Re: and calls kernel API's directly is a derivative work

Posted Feb 19, 2016 8:18 UTC (Fri) by ldo (guest, #40946) [Link] (12 responses)

It is a derivative work, not because it calls APIs, but because it copies actual Linux kernel code.

Re: and calls kernel API's directly is a derivative work

Posted Feb 19, 2016 8:34 UTC (Fri) by gowen (guest, #23914) [Link] (10 responses)

An 8-year-old argument by analogy written by someone who isn't a lawyer, cites no case law, and doesn't really support your argument. Really? That's your rebuttal?

Re: and calls kernel API's directly is a derivative work

Posted Feb 19, 2016 13:54 UTC (Fri) by drag (guest, #31333) [Link] (9 responses)

Be nice. Nobody is interesting in reading you trying to rack up 'logic points'. This isn't reddit.

There are valid arguments about copyrights on both sides because copyright is not something that is set is stone and there is no such thing as a 'strictly correct' interpretation of copyright law. It's all up to interpretation and outcomes can change significantly based on what judge your case will end up in front of and which jurisdiction a possible lawsuit will end up being. Approaching copyright in the same manner you would tackle technical issues is a mistake.

Also it's worth keeping in mind is that ZFS is _free software_. This is a far cry from, say Nvidia.ko, which is tolerated by the Linux kernel community (and by community, I mean the only people that actually matter in a copyright case: copyright holders).

It is entirely possible that one kernel module can be considered by the courts to be 'derivative products', while the other is completely safe. It all depends on the specific technical details of the module and the thought process and precedents that a judge potentially chooses to rely on.

I am sure that Canonical talked to lawyers about this and it's important to realize that to get a accurate answer will cost you money.

Also it's worth pointing out there that lack of mainstream support of ZFS on Linux is a example of how destructive 'copyleft' licenses can be and can negatively impact technical decision making. GPL and CDDL are both strong 'Free Software' licenses and ZFS and Linux are both Free software projects, yet they are both isolated from one another by their respective copyright restrictions. That is not to say that 'copyleft' is bad, but only that it does have it's price.

Re: and calls kernel API's directly is a derivative work

Posted Feb 19, 2016 14:20 UTC (Fri) by pizza (subscriber, #46) [Link] (8 responses)

> Also it's worth pointing out there that lack of mainstream support of ZFS on Linux is a example of how destructive 'copyleft' licenses can be and can negatively impact technical decision making. GPL and CDDL are both strong 'Free Software' licenses and ZFS and Linux are both Free software projects, yet they are both isolated from one another by their respective copyright restrictions. That is not to say that 'copyleft' is bad, but only that it does have it's price.

This isn't a problem with copyleft; it's a problem due to two different licenses having incompatible terms.

And it's worth mentioning again that the CDDL was *deliberately* designed to be incompatible with the GPL -- for the specific purpose of keeping ZFS out of Linux. [1] This, coupled with Oracle's demonstrated aggressiveness over copyright matters, really makes me wonder how Canonical can reasonably conclude that acting against both the letter and spirit of the licenses is a remotely sane path to pursue.

[1] https://en.wikipedia.org/wiki/Common_Development_and_Dist...

Re: and calls kernel API's directly is a derivative work

Posted Feb 20, 2016 2:22 UTC (Sat) by rahvin (guest, #16953) [Link] (2 responses)

Don't blame Oracle for the CDDL, that was Sun's doing. They wanted to make sure Solaris had something Linux didn't, so they wrote a deliberately incompatible license. The simple fact is Sun did this before Oracle even thought about purchasing Sun and it was entirely deliberate. This is the reason up until this that no one dared ship ZFS as part of a Linux Distribution and all the code, modules and even packages were outside the main distribution channels.

Personally I think if Oracle decides they don't want this they will kick Canonical's butt in court.

Re: and calls kernel API's directly is a derivative work

Posted Feb 20, 2016 14:57 UTC (Sat) by pizza (subscriber, #46) [Link]

> Don't blame Oracle for the CDDL, that was Sun's doing.

Oh, that wasn't my intent, and I completely agree with what you wrote.

But it is worth pointing out that Oracle could chose to re-license ZFS if they were so inclined. Personally that's the outcome I'm hoping for (ZFS is frickin' awesome!).

Re: Don't blame Oracle for the CDDL, that was Sun's doing

Posted Feb 22, 2016 21:40 UTC (Mon) by ldo (guest, #40946) [Link]

Yes, we can blame Oracle for the CDDL. Because they have assimilated Sun, and all its copyrights. They could rescind the CDDL if they wanted to, and replace it with something sane, but they choose not to.

Re: and calls kernel API's directly is a derivative work

Posted Feb 21, 2016 12:31 UTC (Sun) by paulj (subscriber, #341) [Link] (4 responses)

And it's worth mentioning again that the CDDL was *deliberately* designed to be incompatible with the GPL

This has been gone over a good few times here before on LWN, with the likes of Bryan Cantrill (influential Solaris engineer) replying even. I won't rehash, but it has to be said that the CDDL most definitely could not have been chosen just to be incompatible with the GPL. Not even Danese Cooper said that, her claim was that it was "partially because".

I wasn't privy to the licence discussions, but my mentor at Sun was. And I'm pretty confident Simon Phipps' description of things is much more representative. There were many factors involved in choosing a licence, and all the ones I know about had nothing to do with Linux. Even if it were true that some involved wanted to make it harder for code to get into Linux, that doesn't change the fact there were several other factors that would still have prevented Sun choosing the GPLv2. In particular, the lack of defensive patent protections clauses, the desire to not impose open-sourcing requirements on 3rd party ISVs (Sun didn't want to require driver writers to have to open their code), etc.

Further, if using the licence to deny ZFS and DTrace and what not to Linux was the goal, then the CDDL of itself does not accomplish that. The CDDL itself is pretty much fine with being incorporated with other works as long as the CDDLed portions stay CDDLed. Authors of GPLed works can just give themselves an exception to include CDDLed works - the licence goals of both are broadly similar too (copyleft licences).

"Ah, but there's far too many people involved in Linux, so it could never realistically grant itself an exception; don't even know who they all are!". Well, Linus *did* unilaterally change the licence at least once. Further, other big projects have relicensed even while not being able to contact every copyright holder (can't remember the project right now).

Anyway, what I know for sure is that, at worst, Linux compatibility was but 1 of a number of concerns that led to Sun choosing the CDDL, and that the wholly-non-Linux-related concerns would also have ruled out choosing the GPLv2.

Re: and calls kernel API's directly is a derivative work

Posted Feb 21, 2016 17:09 UTC (Sun) by raven667 (subscriber, #5198) [Link] (2 responses)

> just to be incompatible with the GPL. Not even Danese Cooper said that, her claim was that it was "partially because".
> [...]
> Anyway, what I know for sure is that, at worst, Linux compatibility was but 1 of a number of concerns that led to Sun choosing the CDDL

Wait, what is the purpose of all these words, you are conceeding that you agree that GPL incompatabily was a requirement in the crafting of the CDDL, but the point you want to add is that this wasn't literally the _only_ license criteria, a point that was not under serious criticism? It seems like the real difference in opinion is not in the facts but in how much you personally value them, the deliberate incompatabily is a bigger deal for some people than for you.

Re: and calls kernel API's directly is a derivative work

Posted Feb 21, 2016 20:07 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

I didn't concede that at all. I never heard of Linux incompatibility being a motivating factor, and I had a chat with a mentor of mine about this who was involved (as well as a brief chat with the director of Solaris engineering in a 1:1, when he visited our site).

Danese is the only person who has said that, and she said "partially".

All I wanted to do was point out that there were other reasons why Sun would not have chosen the GPLv2. E.g., one being that a lot of Solaris engineers (inc. the former engineers in management) were much more BSD-aligned and just anti-GPL - nothing to do with Linux, just reflecting a long-standing, often dogmatic, split in the free Unix world between BSD and FSF aligned camps; the other being that Sun legal wanted stronger patent lawsuit defences than the GPLv2 provides. All I'm saying is that Simon Phipps' account rings much more true to me.

AFAIK, regardless of the truth behind Danese's comment, the outcome was just not to be one where Solaris would have been GPLv2 (or compatible licensed) - independently of the Linux question.

Basically, the conspiracy theories on this are way overblown.

If it was said it was cause there was a visceral dislike for the GPL amongst many inside Solaris eng and Sun legal and management were never going to agree to a BSD licence, then - that'd ring a lot more true.

Re: and calls kernel API's directly is a derivative work

Posted Feb 21, 2016 21:28 UTC (Sun) by paulj (subscriber, #341) [Link]

Oh, and I've gone and listened to that Debian workshop video on licenses to hear Daneses exact words, and she did *not* mention Linux, she said the "Mozilla [licence] was selected partially because it is GPL incompatible".

So the comments here saying it was because of /Linux/ incompatibility are twisting Danese's words somewhat.

Where she said that there were people from engineering in the discussion pushing very hard for the BSD licence, and some for the GPL - that's exactly what I heard from my mentor (I suspect my mentor would have been one of the ones who had pushed for GPL). And Simon Phipps at ~36 minutes says the same thing - that the Solaris engineering community wanted the BSD licence. Phipps goes on to say the "we" (I guess himself, Danese, ??) didn't want that, because they wanted a copyleft licence.

Next, you have to know Sun was already using a Mozilla based licence; that Sun (e.g. Phipps) didn't want to use a strong copyleft licence (didn't want to force ISVs to have to copyleft); that Sun wanted strong patent protections for itself and other community members. Phipps also states (38m) that engineering would have "quit" if they'd picked GPLv2.

That last bit is consistent with my limited experiences. And it had nothing to do with Linux. It had to do with very strong BSD v GPL licensing views within Solaris engineering, and Solaris engineering having very strong Unix/BSD roots.

Remember, the engineers - the ones who largely ruled out the GPLv2 as a valid choice - would have chosen BSD otherwise! So it just could _not_ have been about screwing Linux, cause if they'd got their way, the code would have been under a licence that was perfectly compatible (one way) with going into Linux!

As per previous, I think the GPL was ruled out for Solaris more because of bias around the licence, and ancient BSD/FSF divides, than anything to do with Linux directly.

Re: and calls kernel API's directly is a derivative work

Posted Feb 25, 2016 1:33 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Oh, come on. When Linus changed the license from the original "no commercial use" to GPLv2 he was still the person who had written almost all of the kernel himself, with help of perhaps a half dozen close collaborators.

Re: and calls kernel API's directly is a derivative work

Posted Feb 19, 2016 17:33 UTC (Fri) by butlerm (subscriber, #13312) [Link]

> It is a derivative work, not because it calls APIs, but because it copies actual Linux kernel code.

Copies Linux kernel code? The linked page claims no such thing. It makes a specious argument based on no legal principles whatsoever. At the very least one should cite a law in favor of one's position. There is no trace of that there.

For years now, the conventional wisdom on derivative works has been based more on rumor and wishful thinking than anything resembling legal analysis. Under U.S. law, compatibility as such is irrelevant, as is ability or inability to be used for another purpose. A derivative work is a work that is "based upon" one or more preexisting works. That is 17 USC 101. That is it. Nothing else can make something a derivative work under U.S. law.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 10:48 UTC (Fri) by xav (guest, #18536) [Link] (2 responses)

The whole Ubuntu distribution is a derivative work of its components.

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 11:33 UTC (Sat) by HIGHGuY (subscriber, #62277) [Link] (1 responses)

Negative. It's an "aggregation" of its components.
GPL specifically makes the difference between those terms.

Kirkland: ZFS licensing and Linux

Posted Feb 22, 2016 12:09 UTC (Mon) by ewan (guest, #5533) [Link]

The GPL makes the distinction, but it's not clear on which side of the line Ubuntu falls. At one extreme there's a simple case of a CD with two separate tarballs burned to it which is clearly 'mere aggregation' and at the other there a single executable file built from two sources, which is clearly a derivative of both. A Linux distribution like Ubuntu is not simply the product of 'mere aggregation' of projects on to a disk, it's the product of significant integration work to produce a single coherent system.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 4:03 UTC (Fri) by rsidd (subscriber, #2582) [Link] (3 responses)

What's wrong with the DKMS method? It takes a minute or two at most on a system capable of running ZFS. (And yes, I use ZFS.) Why ship zfs.ko?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 8:43 UTC (Fri) by fishface60 (subscriber, #88700) [Link] (2 responses)

Because you then can't have a ZFS rootfs unless you put a C compiler in your initramfs.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 9:45 UTC (Fri) by jengelh (subscriber, #33263) [Link]

Why in initramfs? Normally, kernel modules are "precompiled" in a full system for a new initramfs image.

Kirkland: ZFS licensing and Linux

Posted Feb 26, 2016 13:10 UTC (Fri) by yoe (guest, #25743) [Link]

The initramfs is irrelevant here, but the installer isn't.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 5:35 UTC (Fri) by gdriggs (guest, #107165) [Link] (31 responses)

This horse has been beaten to death for years on several ZFS, Solaris, BSD, & Linux lists & fora. Please have a look at this before stomping on this poor beast yet again... http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 7:19 UTC (Fri) by rsidd (subscriber, #2582) [Link] (30 responses)

The last link in that FAQ is indeed very interesting reading. Notably, it is from 2006, before the Android -fueled explosion of proprietary modules. Given that ZFS is open source, and given what the author says about copyright protections, it is very hard to imagine that distributing zfs.ko would cause any problems, in particular that any court would rule it illegal. The most one can argue is that it goes against the intentions of the kernel developers and therefore is not a nice thing to do -- but I'm not aware that Linus has spoken on zfs one way or the other. But even if it is a problem, compiling it via dkms should be perfectly OK and should be just as transparent to the end-user.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 7:50 UTC (Fri) by mjthayer (guest, #39183) [Link] (29 responses)

> But even if it is a problem, compiling it via dkms should be perfectly OK and should be just as transparent to the end-user.

I have to think of something Bradley Kuhn mentioned at this year's FOSDEM (don't remember now whether it was in or before his talk on copyleft) - that judges tend not to like technical measures which seem to have no purpose beyond getting around laws.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 8:29 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (4 responses)

Exactly this.

Although you should remember that a judge is not a mindless automaton, they decide actual cases not hypotheticals, if the actual case presented offers an opportunity to fix a clear injustice based on a tiny technicality, don't be surprised if the judge leaps on it even though that same judge might in other circumstances think the technicality hardly matters. This is the "judicial activism" so amusingly scorned by a recently dead US Supreme Court justice, and which he was apparently blind to in his own decisions.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 5:36 UTC (Sun) by marcH (subscriber, #57642) [Link] (3 responses)

> This is the "judicial activism" so amusingly scorned by a recently dead US Supreme Court justice, and which he was apparently blind to in his own decisions.

Scalia seems like he was much more misunderstood than blind. In a number of controversial cases he just disagreed with the Supreme Court being used as a workaround to override and invalidate "unpleasant" laws passed with a majority. In other words he thought that the Constitution was not intended to work around Democracy and be some kind of protection and magic cure for every and any random moronic law voted by a majority of morons.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 17:01 UTC (Sun) by shmget (guest, #58347) [Link]

Except when that did not serve _his_ agenda like in Gonzales v Oregon
https://en.wikipedia.org/wiki/Gonzales_v._Oregon

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 20:46 UTC (Sun) by josh (subscriber, #17465) [Link] (1 responses)

> In other words he thought that the Constitution was not intended to work around Democracy and be some kind of protection and magic cure for every and any random moronic law voted by a majority of morons.

Protecting against the "tyranny of the majority" is one of the specific purposes for which the Constitution was designed. There's a much higher bar to amend the Constitution than a simple majority.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 23:18 UTC (Sun) by marcH (subscriber, #57642) [Link]

The bar is typically higher for constitutional changes than for mere legal changes because a constitution sets the ground / "meta-" rules as opposed to the laws themselves; so it requires some higher level of stability. I can't see how this relates to the "moronocity" and/or compatibility with a constitution of a randomly given law though.

Sure, constitutions protect against the most blatant abuses of legislative power; but only against these. The spectrum of possibilities left open for unfair/appalling/anachronistic/<insert personal point of view> yet valid laws and rulings is still pretty much infinite.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 8:35 UTC (Fri) by rsidd (subscriber, #2582) [Link] (23 responses)

But the judge would first have to decide that zfs.ko is a derived work of the Linux kernel, before deciding whether dkms is ok. Assuming it gets to a judge. And in this case the "technical measure" (distributing the source) is not something with "no purpose", but is something built into the GPL -- by design (and because that's how copyright law works) the GPL only restricts how you may redistribute a GPL'd work; what you do with it at home, including mixing in proprietary code, is your business. It seems to me that the judge is just as likely to ask, given that compiling the module on your computer is explicitly OK, why is it wrong to distribute the compiled module?

Also, if the binary zfs.ko is a derived work of the Linux kernel, so is the source. The judge would have to rule that anything using the Linux API is a derived work. (Note that this is a different question from whether the API is copyrightable. In Oracle vs Google, Google was accused of copying Oracle's API in their own Java implementation. Here zfs is using the Linux API, not copying/reimplementing it.)

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 8:50 UTC (Fri) by mjthayer (guest, #39183) [Link] (7 responses)

I wonder whether this is comparable to writing a novel which is the continuation of another novel. Would that count as a derived work in US copyright? (I am not in the US, but that seems to be what is under discussion.)

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 9:00 UTC (Fri) by rsidd (subscriber, #2582) [Link] (5 responses)

Fictional characters are subject to copyright. So you cannot write your own Mickey Mouse story without permission from Disney (copyright terms keep getting extended every time Mickey is in danger of entering the public domain). Until recently, you couldn't write a Sherlock Holmes story either (in the US) -- because though the first story appeared in 1887, the last was in 1927 and the Conan Doyle estate claimed that the copyright is valid for 95 years after that. However, the courts have now ruled that Holmes is in the public domain.

Now if someone argues that APIs are like characters in a story, things may get interesting...

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 9:24 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

Am I right in thinking that "character" here also applies to fictional events and places with a well-defined character? For the sake of the argument imagining a work of fiction which is a made-up story about "real" historical figures.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 11:36 UTC (Fri) by rsidd (subscriber, #2582) [Link]

Well, if you clone Narnia with the same features and a different name, you'd be in trouble... Depends on whether the similarities are "reasonable" (for a fantasy land) or not. If you write a story about real historical figures, and someone else writes a story about the same real figures, their figures had better be based on the historical characters and not your figures. You can include Julius Caesar in your story but not the Asterix version. To get back to Holmes -- the courts in fact ruled that the last 10 stories are still under copyright and you can not use attributes of Holmes in your work that were first introduced in those stories.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 10:09 UTC (Fri) by NAR (subscriber, #1313) [Link] (2 responses)

On the other hand there's a huge amount of fanfiction written using clearly copyrighted characters...

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 10:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

And commercial use of fanfiction is very rarely legal. Even non-commercial distribution is questionable, but most authors simply politely ignore fanfiction. Because otherwise they would have to take legal action and suing your fans is a Bad Move(tm)(r)(c) for an author.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 10:37 UTC (Fri) by andreasn1 (guest, #88420) [Link]

Published only on the Internet, or by a publisher in physical books without written consent from the copyright holder of the characters?
The first one probably flies under the radar, or is actively ignored for PR-reasons by the copyright holder, the latter probably not.

Kirkland: ZFS licensing and Linux

Posted Feb 22, 2016 9:18 UTC (Mon) by tao (subscriber, #17563) [Link]

Not quite about continuation, but a very interesting case concerning derived works:

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

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 11:43 UTC (Sat) by HIGHGuY (subscriber, #62277) [Link] (14 responses)

> It seems to me that the judge is just as likely to ask, given that compiling the module on your computer is explicitly OK, why is it
> wrong to distribute the compiled module?

Interesting question but in my opinion licenses spell out your rights and obligations.
In this case, GPL says that you must release any derivative work under the GPL when you perform the act of distributing it. If it is decided that derivation is the case, then Canonical is in violation of those terms, because it doesn't hold the rights to release under GPL. Even if a home user can easily combine the 2 works, there is no act of distribution, so the GPL doesn't even come into play.

But still, you're making an interesting case.

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 19:40 UTC (Sat) by Wol (subscriber, #4433) [Link] (13 responses)

Given that the reason behind the GPL is to enforce the four freedoms, allowing the end-user to compile the work themselves clearly is in line with the four freedoms and the intent of the GPL.

Distributing a precompiled ZFS.ko, without source (as I believe is allowed by the CDDL) means the end user does not necessarily have the four freedoms.

If that is the case, then the fact that both CDDL and GPL are open source licences is unlikely to sway a judge to say "it doesn't matter".

Remember, licences are a means to an end. Frustrate the end, and the licence (and wording) matter. If the end sought by the CDDL was to keep ZFS out of linux, then the Judge will enforce the letter of the CDDL if someone puts ZFS into linux.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 7:56 UTC (Sun) by rsidd (subscriber, #2582) [Link] (12 responses)

You could ask the same of a BSD-licensed module. The (2 clause) BSD licence is compatible with the GPL in that you can mix code from both licences and release the whole under the GPL. But what about a module that is separately BSD-licensed? Does the act of compiling it into a .ko cause it to become GPL-licensed? If so, yes, zfs.ko has a problem too. But if not, then you can release the module without needing to release the source.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 15:11 UTC (Sun) by Wol (subscriber, #4433) [Link] (11 responses)

Rule 1 of copyright - you can NOT (normally) change the licence on code you receive.

Rule 2 of copyright - to make copies you need to comply with ALL relevant licences.

That's the magic of the GPL - it says that in order to be compatible, if you comply with the GPL you are complying with anything else.

So the big question that needs to be asked is "does the act of compiling pull in 3rd-party GPL code?". If the answer to that is "no", then your bsd.ko can be distributed under the BSD licence, and zfs.ko can be distributed under the CDDL.

If the answer to that question is "yes", then bsd.ko can be distributed under the GPL (because BSD is compatible, so by complying with GPL you are complying with BSD). However, zfs.ko cannot be distributed, because you must comply with both GPL and CDDL, and they conflict ...

This is why incompatibly licenced stuff can be distributed as source and left to the end-user to build, because the GPL explicitly does not apply to the end user's actions, and if you want to distribute other peoples' GPL source there are (in practice) pretty much no restrictions.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 16:25 UTC (Sun) by rsidd (subscriber, #2582) [Link] (8 responses)

The "third party GPL code" that is "pulled in" is headers, so we are back to the question of whether APIs can be copyrighted. But, as I said above, this is different from the Google-Oracle case. In Google's case the question was, can they re-implement the same API compatibly? So far the courts seem to have ruled no, but lots of intelligent people think a no ruling would be a terrible precedent. In the case of a .ko file, the question is, can you pull in the header file without getting infected (I use the word deliberately) by the GPL? I'm not aware of a court ruling on this.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 16:52 UTC (Sun) by HIGHGuY (subscriber, #62277) [Link] (7 responses)

API's are one thing, but what about inline functions and macro's?
If you can find one of those being used (especially the former), then it might become a lot clearer a lot faster.

Also the zfs.ko module is built as to dynamically link to GPL code, so how about that compared to if the kernel were LGPL.

Oracle's legal dept. is having a field day for sure!

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 20:29 UTC (Sun) by paulj (subscriber, #341) [Link] (5 responses)

As long as the CDDLed ZFS source code is published under the CDDL, there's no issue with the CDDL.

The CDDL applies to the covered files and any files that are modifications thereof. This is one key difference between the CDDL and GPL - the CDDL tries to avoid relying on the murkier legal system term of "derived work" and instead uses its own self-defined term "Modification". Whether that achieves the aim, I don't know. However, the intent is to restrict the scope of the CDDL and somewhat have it be more like the LGPL than the GPL (and Andy Tucker has written words to that effect about the intent).

tl;dr: It seems highly unlikely that porting and distributing CDDL ZFS for Linux could breach the CDDL, if you just make sure that any code that came from ZFS stays CDDLed. Hence, unlikely Oracle would have any grounds to launch a lawsuit based on ZFS licence infringement.

Seek your own counsel, etc.

Kirkland: ZFS licensing and Linux

Posted Feb 22, 2016 12:17 UTC (Mon) by ewan (guest, #5533) [Link]

unlikely Oracle would have any grounds to launch a lawsuit based on ZFS licence infringement

If they have any Linux kernel copyrights though (and I'm pretty sure they do) they could potentially launch one based on GPL infringement, were they motivated to want to stop this happening.

Kirkland: ZFS licensing and Linux

Posted Feb 22, 2016 19:08 UTC (Mon) by HIGHGuY (subscriber, #62277) [Link] (3 responses)

I'm not so sure that's the only case...

Let's say Oracle's legal dept. interprets the GPL in such way as to conclude that the resulting zfs.ko becomes GPLv2 through contamination, when built+shipped the way Canonical plans to. I'd be inclined to think that they can still sue because Canonical does not own copyrights to change the license from CDDL to GPL.

So, I still think that they can act in this way. Who knows, they might try to make a bad case in front of a judge in an attempt to weaken the GPL, but that's me speculating due to the bad taste Oracle left after their previous legal encounters...

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 8:50 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Describe the problem /exactly/. Copyright has a lot of areas that are extremely context specific.

E.g., if you're saying parts of the CDDLed ZFS were modified by *others* to depend on and derive from Linux GPLv2 bits, then what? If those bits are shipped under a CDDL licence, the licence of ZFS is fulfilled and Oracles' copyright is respected. Now, that could indeed mean some code deriving of Oracles' GPLv2 Linux code is being distributed under CDDL instead of GPLv2.

But then what?

Oracle would have to argue in court that code they were happy to ship with Linux under GPLv2 is being infringed by the existence of code that derives from that code by having adapted another lump of Oracle free software to work with it? Further, both lumps of code are copyleft, free software licences, and have the same goal of keeping the software free. What is the harm to Oracle? That GPLv2 code they have copyright over is being distributed under a similar licence, except the similar licence has technical differences that strictly speaking are incompatible - but those technical incompatibilities are all things Oracle is _happy_ with (specification of venue; patent MAD clauses). Further, Oracle is the *steward* of the licence that supposedly infringes, so Oracle can revise it as they wish!

Walk me through Oracles' argument in court...

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 20:41 UTC (Tue) by HIGHGuY (subscriber, #62277) [Link] (1 responses)

> If those bits are shipped under a CDDL license ...

But that ignores the viral nature of the GPL, doesn't it?
By shipping zfs.ko which contains CDDL code that was modified to include GPLv2 code, the CDDL parts would have to be distributed as CDDL+GPLv2. But Canonical does not own the copyrights to dual-license the code and due to the apparent conflicting nature of CDDL and GPLv2, nothing else grants Canonical the right to distribute the combined work.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 21:15 UTC (Tue) by paulj (subscriber, #341) [Link]

That's great, and someone perhaps could sue.

If you're worried about Oracle, again, I'm really curious to hear what you imagine Oracles' complaint would be in court, and how they have been harmed by code they released under one copyleft licence being infringed by being combined with code under another copyleft licence because of additional restrictions in that other licence which; a) Oracle agree with; b) Oracle have full control over, as the stewards of that licence.

If you're worried about other GPLv2 licensors of Linux code, that seems potentially a little more plausible. Though I would similarly be curious about the argument for harm.

That said, I agree the GPLv2 is incompatible with the CDDL - in the sense that the CDDL doesn't mind the combination, but the GPLv2 does; and hence ideally you'd avoid making that combination with other people's GPLv2 code. If the GPLv2 code is your own code, there's no issue at all, as you can just give the required exception, of course. However, if you can't avoid it or you don't realise about the incompatibility, the harm to the copyright holder seems rather technical and minimal (given both are copyleft licences) and if so the risks likely are too.

Kirkland: ZFS licensing and Linux

Posted Mar 22, 2016 1:08 UTC (Tue) by Rudd-O (guest, #61155) [Link]

Technically the zfs.ko module only links dynamically to symbols that are not marked as GPL. In other words, distributing a compiled version of zfs.ko is supposedly allegedly not in breach of the GPL according to some subset of opinions.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 16:30 UTC (Sun) by rsidd (subscriber, #2582) [Link] (1 responses)

Sorry for second reply, but I did not grasp this point.

If the answer to that question is "yes", then bsd.ko can be distributed under the GPL (because BSD is compatible, so by complying with GPL you are complying with BSD).

What if you distribute bsd.ko without distributing the source? That's compatible with BSD but not GPL. Which is the whole point here.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 21:26 UTC (Sun) by Wol (subscriber, #4433) [Link]

In other words, you're distributing GPL code under the BSD licence. Which you can't (legally) do.

Part of the point of my post was that the reverse - distributing BSD code under the GPL licence - is okay because by complying with the GPL, you are automatically complying with the (2-clause) BSD licence too ...

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 9:46 UTC (Fri) by m.alessandrini (guest, #36991) [Link] (3 responses)

Aren't some parts of the kernel restricted to GPL modules, i.e. checking the license declared by the module? Does that apply here?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 10:36 UTC (Fri) by m.alessandrini (guest, #36991) [Link]

For example, there was that famous module cheating on its license:
https://en.wikipedia.org/wiki/Loadable_kernel_module#Linu...
What was the point in cheating if a module's license does not matter?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 12:15 UTC (Fri) by lkundrak (subscriber, #43452) [Link] (1 responses)

By looking at the "ZFS on Linux" tree, it seems that they have a build-time option to cheat about the MODULE_LICENSE. Nevertheless they seem to be careful not to use the GPL-only symbols. Note that it doesn't imply that the kernel with the module loaded is not a derivative work of the kernel; the purpose of the mechanism is merely to taint the kernel if there's a module whose source might not be available.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 14:37 UTC (Fri) by m.alessandrini (guest, #36991) [Link]

Nice build option :-) Anyway, if I build a software myself, I guess I can cheat as I like and nobody would stop me, but distributing it, that would be serious, I hope they didn't go that path.
And about GPL-only symbols, just out of curiosity, does anybody know what parts of the kernel they concern? I can't find a clear documentation, but it seems like they must be some marginal ones, provided something like a filesystem can be implemented without them.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 10:43 UTC (Fri) by farnz (subscriber, #17727) [Link] (8 responses)

Key to all of this licensing talk is "who's going to litigate?". If no-one is willing to take it to court, then it doesn't matter whether there's a license incompatibility or not - there are no consequences to face. This is where Welte's history of litigation and Hellwig's case against VMWare are really important, regardless of the eventual outcomes - it establishes that non-compliance with the license has real costs.

So, in this case, who's going to litigate against Canonical? And are they going to see support from the wide Linux community, or vitriol?

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 11:32 UTC (Fri) by amacater (subscriber, #790) [Link] (4 responses)

I'm not sure who would litigate against Canonical although this remains a risk, however unquantifiable.

Oracle could, if they really wanted to - ZFS is their code and they could assert that they don't want CDDL mixed with GPL. For myself, I've avoided this mess since a package called cdrecord and a vocal developer war.

Individual kernel developers could, if they felt like it, but not many would.

Linus himself could weigh in with an opinion about GPL and proprietary code. Since the Linux kernel is unequivocally GPL2 with the number of contributors there have been, it would be effectively impossible to relicense the kernel.

FSF/Software Conservancy have an interest: two free licenses that are not compatible together and an interest in where the nexus lies.

Neil McGovern - and Debian - have taken the path of compiling the module as DKMS - in just the same way as you would do for an Nvidia module - source you build on your system and load into your own kernel. The source is in Debian contrib - free source which may depend on non-free components. debian-news@lists.debian.org - latest copy of Debian Project News

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 11:53 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

Oracle can't just assert that they don't want that mixture; they have to show that Canonical has used their code in a form that the CDDL doesn't permit. If they haven't, then the CDDL applies and gives Canonical rights - this only matters if Canonical use a right that they have under the GPL but not under the CDDL. Otherwise, it's the GPL code authors whose rights are infringed, as the GPL requires the combination to give you all GPL rights, and the CDDL does not.

Linus's opinion doesn't matter unless it's litigated - so we can discount that one, unless he shows signs of lawyering up.

Individual kernel developers could, but if they won't, then there's no risk. This is the wild card in the bag - there may be one who decides that this is the straw that broke their back.

FSF/SFC both have to show standing to sue - they'd need someone with copyrights to actually help them litigate.

And it sounds like Debian have decided to avoid the risk - sensible if you don't have the resources to litigate, but has no impact on Canonical's actions.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 12:37 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> Oracle can't just assert that they don't want that mixture; they have to show that Canonical has used their code in a form that the CDDL doesn't permit.

Given that Sun deliberately wrote the CDDL to be incompatible with the GPL, this wouldn't exactly be difficult to demonstrate. And unlike the Android/Java thing which involved a lot of handwaving, this one seems pretty cut-n-dry.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 12:59 UTC (Fri) by farnz (subscriber, #17727) [Link]

As written, the issue with the CDDL and the GPL is that the GPL puts obligations on a distributor of code that the CDDL does not permit (specifically, the CDDL requires that any binaries built from CDDL code come with full CDDL licensed source, and places weaker restrictions on distributing your original source than the GPLv2 does). If Canonical assert that their Linux+ZFS build is CDDL licensed, then Oracle has faced no harm, as they've got what they asked for from Canonical (including a copy of Linux under the CDDL); however, this then means that anyone who holds copyright in Linux and has licensed their code under GPLv2 is harmed.

So, depends on who acts first - if Canonical claim to a court that their build is legal because they supply Linux+ZFS under the terms of the GPLv2, then Oracle can act. The converse doesn't apply - the CDDL's requirements on distributors are weaker than the GPLv2's, so if you meet CDDL requirements, nothing is asserted about whether or not you fail to meet GPLv2 requirements.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 10:41 UTC (Sun) by paulj (subscriber, #341) [Link]

I don't think Oracle could sue. The CDDL only applies to the files of ZFS and derivatives of those files. I think it'd be hard to argue any of the GPLv2 Linux code is deriving of the ZFS source code files.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 16:15 UTC (Fri) by SLi (subscriber, #53131) [Link] (2 responses)

You are missing another reason why it matters: Many companies are not willing to base their critical infrastructure on products with murky legality, because if the allegedly violated copyright owner suddenly becomes or is paid to be interested, that product will probably no longer be available.

Kirkland: ZFS licensing and Linux

Posted Feb 21, 2016 14:58 UTC (Sun) by farnz (subscriber, #17727) [Link]

That's another variation on "who's going to litigate?". If the allegedly harmed copyright holder is never going to sue, then there's no risk; thus, if you can identify who could sue, and ensure that they're not going to do so, then the risk goes away.

Re: Many companies are not willing to base their critical infrastructure on products with murky legality,

Posted Feb 22, 2016 21:47 UTC (Mon) by ldo (guest, #40946) [Link]

O RLY?

I don't get it...

Posted Feb 19, 2016 12:00 UTC (Fri) by pr1268 (guest, #24648) [Link] (57 responses)

I'm a little confused, but on a bigger scale than merely questions of licensing...

What, exactly, is Mr. Kirkland's (or Canonical's / Ubuntu's) motivation for doing this? Is there a clientele for Ubuntu demanding ZFS be included in their Linux offerings?

I've been following the development of ZFS and other filesystems for the past decade or so... I do realize ZFS is incompatible with GPLv2 (and thus the Linux kernel)—even though it is open source—but there seems to have been a flurry of new filesystems added to the Kernel in the past few years, many of which incorporate the so-called "killer features" customers want (and presumably of which ZFS provides).

While there was a big stink shortly after ZFS's release (because of its license), my perception is that the Linux community has done well without it (e.g. Btrfs, Ext4, XFS, OCFS2, various SSD-optimized FSes, etc.).

But now, Mr. Kirkland / Ubuntu / Canonical are audaciously plowing ahead in questionable legal territory here. Why? Is the plethora of currently-available filesystems in Linux lacking something that only ZFS can provide? If so, why haven't the Linux FS developers scratched that itch? Licensing issues aside, why should the Linux community (or merely the Ubuntu portion thereof) concede superiority to someone else's FS?

One of the reasons (among literally dozens) I abandoned other OSes for a Linux-only home computing environment (August 2004) was because I was tired of seeing the others merely play catch-up with the latest trends in OS software. I saw the Linux development model and user community as one where the brightest ideas in computing came together in an open model and could be studied and developed, and everyone benefited. (It also goes without saying that, at the time, I was studying CS at a university which had liberally embraced Linux as an academic tool.)

I've raised questions in the past about whether Linux appears to want to "borrow", re-engineer, or copy wholesale others' features, or otherwise feel jealous for not being able to include them in the kernel. Yet, we (the Linux community) still seem to push the envelope with regards to modern and scalable OS design. Are we falling behind?

I don't get it...

Posted Feb 19, 2016 12:22 UTC (Fri) by gdriggs (guest, #107165) [Link] (6 responses)

Everyone is missing the fundamental reason why this isn't an issue; the CDDL guarantees that no single entity can own ZFS -- every contributor owns their contributions to the project. So in order to sue Canonical or Red Hat or Linus Torvalds or Walt Disney Linux, Inc, you'd have to get a class action suit together from everyone living or deceased that's contributed to ZFS since its inception in 2001.

I don't get it...

Posted Feb 19, 2016 12:40 UTC (Fri) by pizza (subscriber, #46) [Link] (5 responses)

No, anyone who made a significant contribution could bring suit independently. (Witness Hellwig's suit against VMWare)

I don't get it...

Posted Feb 19, 2016 16:35 UTC (Fri) by gdriggs (guest, #107165) [Link] (4 responses)

The Hellwg suit is over enforcement of the GPL. Have you actually read the CDDL? Feel free to do some actual research instead of arguing your opinions as fact. https://en.wikipedia.org/wiki/Common_Development_and_Dist...

I don't get it...

Posted Feb 19, 2016 17:03 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

Yes, I have read the CDDL. Have you? Nowhere does it state that you have to get every contributor on board in order to file suit or claim damages.

Hellwig's suit is over the GPL, not the CDDL, but that's irrelevant, because as the actual copyright holder he gets to enforce the license over stuff he authored.

I don't get it...

Posted Feb 19, 2016 17:33 UTC (Fri) by gdriggs (guest, #107165) [Link] (2 responses)

You yourself have just claimed that your own prior comments are irrelevant. Well played, sir.

I don't get it...

Posted Feb 19, 2016 18:47 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

You have claimed "in order to sue Canonical or Red Hat or Linus Torvalds or Walt Disney Linux, Inc, you'd have to get a class action suit together from everyone living or deceased that's contributed to ZFS since its inception in 2001."

However, the only support for your statement is: "The CDDL guarantees that no single entity can own ZFS -- every contributor owns their contributions to the project."

But if each contributor retains ownership over their individual contributions, then they also retain the right to take independent action over their contributions, without anyone else being on board.

I used the Hellwig's GPL enforcement action against VMWare as an example. But it's not the GPL that gives Hellwig enforceable rights, it's copyright law. Hellwig would have the same enforceable right to take action had his code been licensed under the CDDL.

If you disagree with me, fine, but please back up your assertion with an actual citation so that I may improve my understanding of the situation.

I don't get it...

Posted Feb 20, 2016 19:46 UTC (Sat) by Wol (subscriber, #4433) [Link]

> > You yourself have just claimed that your own prior comments are irrelevant. Well played, sir.

> If you disagree with me, fine, but please back up your assertion with an actual citation so that I may improve my understanding of the situation.

I think the GP is confusing you with someone else ... :-)

(Hint - in reply to your post, he said "your own prior comments", except there are no such prior comments in the thread ...)

Cheers,
Wol

I don't get it...

Posted Feb 19, 2016 12:40 UTC (Fri) by kiko (subscriber, #69905) [Link] (13 responses)

> What, exactly, is Mr. Kirkland's (or Canonical's / Ubuntu's) motivation for doing this?
> Is there a clientele for Ubuntu demanding ZFS be included in their Linux offerings?

We're only going through the effort because ZFS is amazing and a significant fraction of our user, partner and customer base would love to have it on Ubuntu. And as is clear from this comment thread, whether there is an actual licensing problem is debatable -- we definitely don't see one.

I don't get it...

Posted Feb 19, 2016 12:44 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

Yeah, let's take the various opinions of a bunch of wankers on a forum as evidence that the problem "is debateable".

There is undeniably a problem. The only question is whether or not anyone in a position to hold Canonical to task actually cares enough to do so.

When one of said folks is Oracle, perhaps the question should be "whether or not anyone cares enough to do so at any point in the future"

I don't get it...

Posted Feb 19, 2016 23:38 UTC (Fri) by butlerm (subscriber, #13312) [Link] (2 responses)

> There is undeniably a problem.

It would be more accurate to say that it is undeniably rumored to be a problem. There is no case law establishing that it actually is a problem, and no shortage of solid arguments that it isn't. At this point, the idea that it is a problem is mostly speculation and wishful thinking with only the most tenuous connection to any type of legal analysis.

For example, dynamic linking does not create a derivative work. Why? Because in the United States at least, copyright only subsists in original works of authorship fixed in a tangible medium of expression. Loading a driver hardly makes the resulting binary image in memory an original work of authorship and it definitely does not result in anything fixed in a tangible medium. See 17 USC 102.

I don't get it...

Posted Feb 20, 2016 1:22 UTC (Sat) by pizza (subscriber, #46) [Link]

> It would be more accurate to say that it is undeniably rumored to be a problem.

The inverse is also true; it's undeniably rumored to not be a problem.

Which is, in a nutshell, the crux of the matter. If you can't definitively say it's not a problem, the uncertainty itself makes it a problem.

> For example, dynamic linking does not create a derivative work.

Not according to the FSF, Oracle, Microsoft, and many other major players -- To the point where they have explicitly granted license exemptions for runtime libraries and other such things.

I don't get it...

Posted Feb 25, 2016 2:01 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Linking doesn't create a derivative work, what could do so is to write against the API, include snippets of code via #include, copying the stretch calling foo(), ... In Linux's case, the API to interface a module with the rest of the kernel, moreso the complex machinery to handle a filesystem, make the claim that the ZFS module doesn't depend on Linux at least doubtful. Said adjustment to ZFS making it compatible with Linux is not Sun's/Oracle's work either. I.e., the situation is not cut and dried. And that is the whole point.

Oracle could relicense ZFS under GPLv2 (or BSD, or dual-license), and they haven't. They could also state (in legally binding way) that they are OK with ZFS in Linux (perhaps with a specific license exception). They haven't either. That they keep silent about this matter is a (weak) indication that they do care in keeping ZFS out of Linux. Remember they do ship their own Linux distribution, and do have copyright standing in the kernel too (not exactly top ten contributor ever, but still).

I don't get it...

Posted Feb 19, 2016 13:33 UTC (Fri) by nhippi (subscriber, #34640) [Link] (7 responses)

And what are you going to do when your customers come ask you to fix any of the 955 zfs issues[1]? There is exactly one commit from canonical in zfs[2] and it doesn't exactly scream "we have filesystem experts that can fix your issues".

[1] https://github.com/zfsonlinux/zfs/issues
[2] https://github.com/zfsonlinux/zfs/commit/8f3439733f72a083...

I don't get it...

Posted Feb 19, 2016 14:04 UTC (Fri) by clump (subscriber, #27801) [Link] (6 responses)

"Support" may well be a more timely issue for ZFS on Linux than the license incompatibilities. The maintainers of filesystems, kernel subsystems, and distributions go to great lengths to ensure there's no corruption of storage data. The legal ambiguity of ZFS on Linux wouldn't make me confident that many hardware and software players have put it through rigorous testing.

"foreign" filesystem

Posted Feb 21, 2016 23:31 UTC (Sun) by marcH (subscriber, #57642) [Link] (5 responses)

Based on Ubuntu's decision and some personal experiences shared in this thread and despite some bug counts it looks like enough customers think that A currently carries less risk than B:

A) QA and field-proven outside Linux + risk of porting to Linux
B) wet paint + native to Linux

I imagine the more you know about VFS and other related abstractions and the better you can compare the two?

"foreign" filesystem

Posted Feb 22, 2016 0:24 UTC (Mon) by viro (subscriber, #7872) [Link] (4 responses)

I don't know whether you realize that or not, but for anybody actively working on Linux storage stack (including VFS, VM, filesystems, dm, etc.) ZFS source is off-limits. I have no idea how they are maintaining the glue layer, but logistics involved can't be fun.

As the result, when I do something in VFS, I *can't* look and see if it will cause problems for their code. And given the choice between freezing every damn in-kernel interface and risking that they'll have an unknown amount of PITA trying to cope with the changes, I'll certainly go for the latter. Out-of-tree code has not just no promise of interface stability, it has no promise that adjusting for interface changes will be feasible.

I certainly won't go out of my way to screw them over, but if things break for them, it's Not My Problem(tm). And when a consumer of an interface is not just out of tree, but can't be even pulled and looked at, it *will* be ignored while planning the changes. Not out of any kind of malice, but that's not a lot of consolation. I can't speak for e.g. VM folks, or block layer ones, etc., but whatever attitude they might have, the "can't look there" constraint applies to all of us.

I've no idea how well will they (== glue layer maintainers in oracle) be able to cope, but that sure as hell isn't a job I'd wish on anybody.

"foreign" filesystem

Posted Feb 23, 2016 10:09 UTC (Tue) by rleigh (guest, #14622) [Link] (2 responses)

Why exactly is it off limits (genuinely curious)? It's not proprietary code. It's under a free software licence. So the CDDL and GPL might be incompatible, and restrict binary redistribution of the compiled code, but I don't see how that taints it to the point of not being safe to even *read*.

"foreign" filesystem

Posted Feb 26, 2016 8:45 UTC (Fri) by nhippi (subscriber, #34640) [Link] (1 responses)

The risk is that you inadvertently copy some CDDL code into the GPL'd kernel. Not as in copy-paste, but some idea from CDDL code gets stored into your memory and at a later date you re-implement the same code in kernel without remembering where you got the idea from. That's quite far in the "err in the side of caution" territory tho.

"foreign" filesystem

Posted Mar 4, 2016 18:47 UTC (Fri) by paulj (subscriber, #341) [Link]

Copyright doesn't cover ideas though. It's OK to re-implement an idea. (And yes, there's a line, and in some cases that line may not be clear).

"foreign" filesystem

Posted Feb 23, 2016 22:43 UTC (Tue) by kiko (subscriber, #69905) [Link]

I don't think the SPL is maintained by Oracle: https://github.com/zfsonlinux/spl/commits/master

I don't get it...

Posted Feb 19, 2016 15:28 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

Considering the recent history over Canonical's legal opinion concerning GPL licensing and Canonical's IP policy...
I think its fair to say that hearing "we definitely don't see an issue" coming from inside the Canonical fenceline is cold comfort to many outside the fenceline. Canonical's track record isn't so good with regard to opinioneering with regard to GPL licensing requirements.
I'm going to be blunt, some of us have a hard time understanding why you trust your legal team's understanding of the GPL.

The long protracted...discussion...getting Canonical to bring its own IP policy into GPL compliance, or to even get Canonical to admit there was a problem with the policy at all.. is just too fresh in everyone's memory. I think you'll find that Canonical burned a great deal of trust and benefit of the doubt concerning the veracity of C's internal legal team in the IP policy discussion. Bridges were burned, and we can still see your legal team holding the torches that started the fires. You can't really expect people to forget recent history and just take C's legal opinion over ZFS/GPL without questioning the rationale.

Hell man, up until Dustin edited the Ubuntu wiki page this week, the Ubuntu wiki page on zfs specifically stated there was a license incompatibility... for YEARS. This has sort of been settled consensus for years. Hey maybe we are all flat earthers and Canonical's finally got it right...but make the case. If there has been a significant rethink..even just inside Canonical... concerning the licensing an actually explanation of the reasoning for the change of opinion is sort of warranted.

Let's go back nearly a full decade and get some perspective:
http://gensho.acc.umu.se/pub/debian-meetings/2006/debconf...

Start at about minute 12 in that video... a decade old video....about CDDL/GPL incompatibility.
Oh look Mark Shuttleworth is there talking in the video.
Minute 19 - 22 discussion about GPL incompatibility.
Minute 34 concerning a future SCO-like lawsuit scenario is awesome....
Minute 35 to 46..... more specific discussion concerning CDDL/GPL incompatibility. Really focus on the opinion expressed about the need to reimplement ideas as new gpl code at the kernel level. And the GPL2 OS exception is even mentioned....

At no point in this discussion did anyone dispute CDDL was GPL incompatible. Take a second and let that sink in.

A decade later Canonical wants to say the licenses are compatible now...okay...why? what's changed? It's a head scratcher. Mark was in the room, he was helping moderate the discussion...... a decade ago.... praising Debian Legal noless.

-jef

I don't get it...

Posted Feb 19, 2016 16:49 UTC (Fri) by rsidd (subscriber, #2582) [Link] (9 responses)

Is the plethora of currently-available filesystems in Linux lacking something that only ZFS can provide?

Yes. ZFS's combined FS+LVM, checksumming, large filesystem support, and above all snapshots, are not available in any other stable FS. Btrfs does aim to provide it but it's not ready for general use.

If so, why haven't the Linux FS developers scratched that itch?

Because it's hard. (Btrfs is an attempt, but is far from succeeding.)

I've been using ZFS for a year and a half on my work machine, and a few months on my laptop. Zero issues and I'm not going back. Snapshots are an absolute lifesaver -- like having your entire system under version control. The online compression and (on my work machine) deduplication means despite vast quantities of genome data and NGS data the disk space used is ridiculously tiny. I started with the Ubuntu PPA, now it's the official Ubuntu package on Wily.

I don't get it...

Posted Feb 19, 2016 18:21 UTC (Fri) by clump (subscriber, #27801) [Link] (8 responses)

Yes. ZFS's combined FS+LVM, checksumming, large filesystem support, and above all snapshots, are not available in any other stable FS. Btrfs does aim to provide it but it's not ready for general use.

I'm more familiar with Btrfs and LVM, however LVM (with any file system) and Btrfs both provide flexible snapshots. Last I've seen ZFS (not on Linux, however) it was pretty far ahead in terms of features and integration. NFS integration particularly impressed me. Snapshots, on the other hand, are well covered in Linux already.

Snapshots

Posted Feb 19, 2016 20:32 UTC (Fri) by rleigh (guest, #14622) [Link] (7 responses)

ZFS snapshots are in some ways better than LVM and Btrfs snapshots.

LVM snapshots are fixed size. Unless you allocate the same size to the snapshot as the size of the original LV, the snapshot will cease to work if the number of touched blocks in the original filesystem exceeds the snapshot size. In practice, this means that your snapshot can cease to function at an indeterminate time in the future. For heavily-used filesystems, this might not be as long as you'd think! Historically, there have also been nasty udev races which interfere with lvremove and other commands, which break them (e.g. unable to remove an LV which is "in use" by some udev helper kindly keeping it open).

Btrfs snapshots are much more flexible, not having this type of size constraint. However, snapshots are not immutable, so if you're snapshotting for backup purposes, it's still possible for the backup snapshot to be changed. If you want to guarantee it's an actual "snapshot" as opposed to "writable copy", this isn't possible at the moment. Lots of snapshotting can also unbalance a largely empty filesystem into unusability within a very short timeframe (18 hours is my record).

ZFS snapshots are immutable, and so are a point-in-time snapshot of the dataset state at that point in time; they can also be made recursively on the whole dataset heirarchy. If you want a writable copy, you then have to "clone" a new dataset from the snapshot, so the "snapshot" and "clone" operations together are equivalent to the Btrfs behaviour. If you're using snapshots to "zfs send", then the immutability is essential. Likewise for keeping a historical record which is guaranteed no to change; I use this to periodically snapshot home directories and data directories--if there's ever a disaster, I can instantly revert to the old version or retrieve selected bits out of a clone. There's also a parent-child relationship between datasets, snapshots and clones which can be useful in determining the provenance of a snapshot or cloned dataset (this can be broken if needed, since sometimes it's annoying due to preventing the removal of a referenced snapshot). You can even delegate the permissions to snapshot and clone to users and groups, so end users can snapshot their home directory dataset at will.

After having used all three snapshot methods extensively, I'd rank ZFS quite a way above Btrfs, which also ranks well above LVM.

The NFS integration on FreeBSD is really nice. I use it to provide NFSv4 exports over IPv6. The inheritance of the export properties for child datasets is really slick. If the Samba/CIFS integration became as transparent I'd be very happy (the interface is there; the backend integration is missing).

Snapshots

Posted Feb 19, 2016 22:20 UTC (Fri) by MattJD (subscriber, #91390) [Link] (1 responses)

> Btrfs snapshots are much more flexible, not having this type of size constraint. However, snapshots are not immutable

Btrfs snapshots can be immutable, AFAIK. It sounds like Btrfs calls snapshot is what ZFS calls snapshot and clone. Unless there is some other difference I'm missing?

By default, Btrfs snapshots are mutable, you do have to specify an argument to the command line client. But once you do you can't modify that snapshot unless you make a new snapshot that is writeable (and won't affect the read only one).

Snapshots

Posted Feb 20, 2016 0:08 UTC (Sat) by rleigh (guest, #14622) [Link]

Ah, great, looks like you can now create read-only snapshots with Btrfs then.

While I didn't initially like the two-step snapshot+clone process with ZFS, after being used to Btrfs snapshots, I'm now preferring it. From a git point of view, a snapshot is kind of like a git tag, being a reference to the dataset state at a certain point; while a clone is like a checkout of a tag to a new branch, ready to be modified.

Snapshots

Posted Feb 20, 2016 0:36 UTC (Sat) by ricwheeler (subscriber, #4980) [Link] (2 responses)

Your information about current LVM snapshots being fixed size is simply wrong (and has been for several years).

Snapshots

Posted Feb 20, 2016 9:58 UTC (Sat) by rleigh (guest, #14622) [Link] (1 responses)

Yes, I was forgetting about the newer thin provisioning features. While they are a big improvement, they are still somewhat clunky--you still have to keep an eye on the space usage and maintain the free blocks in the thin pool, though this can be automated to an extent. If you're using LVM it's certainly a nice additional improvement, but it's not a zpool. Ultimately though, it's still a snapshot of the raw block device rather than the filesystem content, and the ZFS and Btrfs snapshots don't come with that complication, or the udev bugs.

Snapshots

Posted Feb 20, 2016 12:54 UTC (Sat) by ricwheeler (subscriber, #4980) [Link]

What a user sees in either case is a snapshot that consumes space only for the delta. Any copy on write file system (btrfs and zfs included) will always have huge challenges in managing the real space consumed behind the virtual view of the file system exposed to users. You always have to watch for out of space issues with the backing pool, unfortunately with non-standard tooling so far at least.

Not clear what udev bugs you are talking about, Red Hat has been shipping dm-thinp for years now and we build lots of layered products on top of that.

There is some new and interesting work to add reflink support to xfs which will allow per-file COW (snapshot effectively).

Snapshots

Posted Feb 20, 2016 17:06 UTC (Sat) by jra (subscriber, #55261) [Link]

" If the Samba/CIFS integration became as transparent I'd be very happy" (Off-topic, sorry).

Mail me directly (jra@samba.org) and let's see if we can fix this for FreeNAS (FreeBSD-based) which already ships with zfs included. I'd like to know what isn't working so Samba can fix it !

Snapshots

Posted Feb 22, 2016 14:17 UTC (Mon) by anton (subscriber, #25547) [Link]

If immutability of snapshots is desired, NILFS2 fits the bill. Works nicely for me.

I don't get it...

Posted Feb 19, 2016 20:56 UTC (Fri) by rleigh (guest, #14622) [Link] (24 responses)

> Is there a clientele for Ubuntu demanding ZFS be included in their Linux offerings?

> While there was a big stink shortly after ZFS's release (because of its license), my perception is that the Linux community has done well without it (e.g. Btrfs, Ext4, XFS, OCFS2, various SSD-optimized FSes, etc.).
[...]

There is definitely a demand for it. Consider it this way: what does Linux have to offer that is comparable to and competitive with ZFS?

The unfortunate answer is that it has nothing comparable. That's not to say that the individual filesystems Linux offers are bad, but the feature set and tools which ZFS provides are simply not provided by any of them. Not even Btrfs, which is still not stable enough for serious use after all this time. And LVM is simply not as flexible or robust as a zpool.

After trying out ZFS on Linux a few years back, I have since deployed a few servers using FreeBSD with ZFS. The primary reason for doing this was for the excellent ZFS support. When Ubuntu offers native ZFS support, you can bet I'll be using it. It's definitely not suitable for all cases; I might not want it on small systems or systems which require fast I/O with relaxed integrity guarantees e.g. scratch space on a compute cluster or a build daemon. But on file servers or my workstation, yes please.

I don't get it...

Posted Feb 22, 2016 2:30 UTC (Mon) by malor (guest, #2973) [Link] (23 responses)

>Not even Btrfs, which is still not stable enough for serious use after all this time.

I think it's probably a fairly safe bet that btrfs is never going to be production-ready.

If they haven't managed to get it fully stable *yet*, there's probably something broken in the basic design.

Btrfs stability and production-readiness

Posted Feb 22, 2016 22:04 UTC (Mon) by pr1268 (guest, #24648) [Link] (22 responses)

If they haven't managed to get it fully stable *yet*, there's probably something broken in the basic design.

Umm, the Wiki says it's "no longer unstable". It does mention that Btrfs is still "under heavy development"—mostly for feature enhancements and performance improvements, from what I gather.

I think it's probably a fairly safe bet that btrfs is never going to be production-ready.

Novell/SUSE would beg to disagree with you on that one.

Of course, your definition of "stability" and "production-readiness" may differ. YMMV.

Btrfs stability and production-readiness

Posted Feb 22, 2016 22:27 UTC (Mon) by malor (guest, #2973) [Link] (21 responses)

>Umm, the Wiki says it's "no longer unstable".

It says the disk format is stable. There is vast gulf between that and being functionally stable. (ie, you can actually use it and trust it.)

>Novell/SUSE would beg to disagree with you on that one.

After seeing the sheer number of catastrophic, stupid failure stories about btrfs on LWN and other places... I suspect they're probably making a fairly severe mistake.

>Of course, your definition of "stability" and "production-readiness" may differ. YMMV.

"I can trust it not to crash and never to lose data without a hardware failure" is a pretty good definition for filesystems, and I strongly suspect either the btrfs codebase or dev team is not capable of getting it there.

It's been nine years now, and it's still not ready yet. To me, that speaks of a design that's either fundamentally wrong in some way, or which can't be reliably implemented by humans.

Btrfs stability and production-readiness

Posted Feb 23, 2016 0:04 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

>I suspect they're probably making a fairly severe mistake.

They have filesystem developers on-board and they have disabled features they don't consider stable. Unless you can point to any real bug reports with their implementation, whatever feelings you may have isn't based on evidence.

Btrfs stability and production-readiness

Posted Feb 23, 2016 5:55 UTC (Tue) by malor (guest, #2973) [Link] (2 responses)

>whatever feelings you may have isn't based on evidence.

Which is why I said I suspect they're making a mistake, rather than asserting that they absolutely are.

And that feeling is based on evidence, just not evidence with their specific code base. Maybe they've whipped it into shape, but I certainly wouldn't bet my own data on it.

Btrfs stability and production-readiness

Posted Feb 23, 2016 18:17 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> And that feeling is based on evidence, just not evidence with their specific code base. Maybe they've whipped it into shape, but I certainly wouldn't bet my own data on it.

aiui, they have btrfs configured so your two choices are basic or mirrored. And that is working fine. There is a trickle, and I mean trickle, of reports where a combination of snapshots and disk-full causes a serious problem.

Beyond that, it seems pretty stable and solid.

(I follow the linux-raid list, and this sort of stuff gets touched on, so this appears to be the "current state of play".)

Cheers,
Wol

Btrfs stability and production-readiness

Posted Feb 24, 2016 10:32 UTC (Wed) by jezuch (subscriber, #52988) [Link]

> There is a trickle, and I mean trickle, of reports where a combination of snapshots and disk-full causes a serious problem.

Btrfs has an annoying habit of returning ENOSPC while df shows plenty of GBs left, yes. Since I maintain a history of snapshots for quick-and-dirty "oops, let's restore from an older snapshot" kind of "backups", I noticed that applications react *very* poorly to out-of-space conditions.

Btrfs stability and production-readiness

Posted Feb 23, 2016 9:18 UTC (Tue) by rleigh (guest, #14622) [Link] (6 responses)

They may well have disabled buggy features. But what about fundamental design flaws? Did they fix the repeated unbalancing problem? Having a filesystem that can go read-only at some indeterminate time in the future is simply unacceptable! A regular rebalance kills performance and still doesn't provide any guarantees, so isn't a proper solution.

Btrfs stability and production-readiness

Posted Feb 23, 2016 14:18 UTC (Tue) by niner (guest, #26151) [Link] (5 responses)

The balancing issue has been fixed for quite a while now.

All in all your arguments seem to be based on outdated information. May I suggest you viewing your experience in that light when you enter the next discussion about this topic?

Btrfs stability and production-readiness

Posted Feb 23, 2016 17:22 UTC (Tue) by malor (guest, #2973) [Link] (4 responses)

I certainly would consider doing so, if anyone would actually give me anything substantive.

What I've seen in this thread has been weak agreement with my belief, specific complaints about specific bugs, and absolutely nothing concrete from the other side at all.

I'm absolutely willing to re-evaluate my position. The btrfs devs standing up and saying "it's done" would be a HUGE step toward doing so. The fact that they still haven't, nine years later, really makes me think that it's never really going to work properly.

Btrfs stability and production-readiness

Posted Feb 23, 2016 18:24 UTC (Tue) by Wol (subscriber, #4433) [Link] (3 responses)

> I'm absolutely willing to re-evaluate my position. The btrfs devs standing up and saying "it's done" would be a HUGE step toward doing so. The fact that they still haven't, nine years later, really makes me think that it's never really going to work properly.

Raid isn't done yet - aiui that's very definitely experimental.

And as I said, there is a known corner-case with disk full and snapshots - which they can't debug because they can't reproduce it reliably :-(

But have the devs of other file systems - ext for example - ever stood up and said that? Most every file system has issues, and ext3 was a nightmare by all accounts ...

I'm interested in databases, and integrity, and that is a HARD problem. Different filesystems take different approaches, different databases take different approaches, the interactions are, shall we say, interesting ... don't blame a filesystem for behaving "as advertised" and then a "buggy" app trashes your data because the devs didn't read the spec ... and I'm looking at ext3 here ... as I said, this problem is HARD.

Cheers,
Wol

Btrfs stability and production-readiness

Posted Feb 23, 2016 18:39 UTC (Tue) by pizza (subscriber, #46) [Link]

> shall we say, interesting ... don't blame a filesystem for behaving "as advertised" and then a "buggy" app trashes your data because the devs didn't read the spec ... and I'm looking at ext3 here ...

There's a big difference between recently-written data being lost due to an unclean shutdown (ie the ext3 situation) vs the filesystem eating itself on its own across a clean unmount/mount cycle.

Both of my btrfs experiments ended with massive, filesystem-wide data loss.

Btrfs stability and production-readiness

Posted Feb 24, 2016 2:28 UTC (Wed) by pr1268 (guest, #24648) [Link] (1 responses)

But have the devs of other file systems - ext for example - ever stood up and said that?

Umm, yes, Ted Ts'o did just that for Ext4 in October 2008.

And Linux 2.6.28 had Ext4 marked as "stable" upon its release two months later.

Btrfs stability and production-readiness

Posted Feb 24, 2016 7:36 UTC (Wed) by niner (guest, #26151) [Link]

He said (full quote) "The ext4 filesystem is getting stable enough that it's time to drop the "dev" prefix. Also remove the requirement for the TEST_FILESYS flag."

That's quite different from the "it's done" that's requested from the btrfs developers. It's more along the lines of btrfs no longer being marked experimental.

Btrfs stability and production-readiness

Posted Feb 23, 2016 1:46 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> After seeing the sheer number of catastrophic, stupid failure stories about btrfs on LWN and other places... I suspect they're probably making a fairly severe mistake.
You've probably never used ZFS on FreeBSD...

Btrfs stability and production-readiness

Posted Feb 23, 2016 5:56 UTC (Tue) by malor (guest, #2973) [Link] (8 responses)

>You've probably never used ZFS on FreeBSD...

I haven't. Is this relevant to btrfs somehow?

Btrfs stability and production-readiness

Posted Feb 23, 2016 6:10 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

It's about as crashy as btrfs. So it's not like ZFS is somehow fundamentally more reliable.

Btrfs stability and production-readiness

Posted Feb 23, 2016 6:16 UTC (Tue) by malor (guest, #2973) [Link] (5 responses)

Well, maybe it's not a good idea either, then.

But it sure seems to have a lot of very vocal supporters out there. I don't remember seeing anyone bitching about it.

Well, no, I remember seeing some problems with ZFS on Linux... the biggest complaint I saw was that it needs a lot of RAM to run well. (I think the minimum people were recommending was 8 gigs on a machine that wasn't doing anything but file serving, and the more you could throw on there, the better.)

But on BSD? I don't remember reading any complaints at all, and a hell of a lot of praise. I've been contemplating building a FreeBSD server because of it.

Btrfs stability and production-readiness

Posted Feb 23, 2016 8:07 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

ZFS is OK if you have backups and want to have a nice fileserver with cheap snapshots. Its RAID support is also still better than in btrfs.

But that's pretty much it. ZFS has its own pagecache so it needs a lot of RAM and it's not terribly fast for a lot of workloads.

On the other hand, btrfs is designed to be a good Linux citizen and plays nicely with its pagecache. So when we get hugepages for pagecache you can be sure that btrfs will support them, for example.

Btrfs stability and production-readiness

Posted Feb 23, 2016 8:16 UTC (Tue) by malor (guest, #2973) [Link]

>But that's pretty much it.

It has the reputation, at least on BSD, of being very reliable. Personally, I find that to be an extremely attractive feature in a filesystem... as in, the single most attractive one.

I'm willing to accept that it might not be as good as I've heard, but a vague assertion that it's no better than btrfs doesn't sound especially credible, on its own. The problems with btrfs are legion, and I haven't seen substantial ZFS complaints, except that it needs a lot of RAM to work well.

Oh, and that because of the RAM thing, it's really best on 64-bit systems. On FreeBSD, at least, UFS is supposed to be better for i386 kernels.

Btrfs stability and production-readiness

Posted Feb 23, 2016 9:56 UTC (Tue) by rleigh (guest, #14622) [Link] (2 responses)

The RAM usage is a non-issue. It's only excessive if you enable deduplication (so don't enable it). And you can constrain the ARC if you need to; it will still work just fine. It's a high-end filesystem, so if I'm running a fileserver, then who cares if it's using lots of RAM? It's not like it's going to be used for anything else. Likewise for my workstation with RAM to spare. It's using it to fulfil the system's primary purpose.

Regarding performance, at the low end with a single disk or simple mirror ZFS will be slow in comparison with ext4 and other simpler filesystems. Those data integrity guarantees don't come for free. The performance is still better than Btrfs though, which is generally abysmal, but Btrfs has to pay the same price here, which is then compounded by design mistakes and implementation problems. The thing is though, that ZFS *scales* up where other filesystems can't. You can fill up a pool with multiple zvols of mirrors or raid sets, and have it stripe the reads and writes over the array of arrays, and add SSD cache and log devices (which can also be mirrored). This can perform very well.

As for Btrfs being a "good citizen" (the unwritten implication being that ZFS is somehow "bad"), since it's a terrible filesystem it doesn't really matter either way. It's an irrelevant consideration.

Btrfs stability and production-readiness

Posted Feb 23, 2016 10:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> The RAM usage is a non-issue. It's only excessive if you enable deduplication (so don't enable it).
Yet btrfs manages dedup without gobbling up all of the RAM.

> It's a high-end filesystem, so if I'm running a fileserver, then who cares if it's using lots of RAM?
I certainly do. I prefer my memory to be used for something that's relevant, rather than letting it sit as a deadweight. And I'm using btrfs on my private machine for easy snapshots (+send/receive for backups) and on our Docker farm (for obvious reasons).

Dedicated file servers? That's sooo last millennium.

> The performance is still better than Btrfs though, which is generally abysmal, but Btrfs has to pay the same price here, which is then compounded by design mistakes and implementation problems.
Actually, btrfs has a much more thought out design. ZFS is already hobbled by its reliance on the fixed block sizes that later had to retrofitted for compression.

BTRFS suffers from the same problems as ZFS during its first 10 years or so.

> The thing is though, that ZFS *scales* up where other filesystems can't.
And this is just a marketing bullshit. Linux LVM can use SSDs for metadata devices, BTRFS supports that natively as well.

About the only missing piece is RAID-Z, and that's being worked on. Regular mirroring/striping already works perfectly fine.

Btrfs stability and production-readiness

Posted Feb 24, 2016 12:42 UTC (Wed) by nye (guest, #51576) [Link]

>Yet btrfs manages dedup without gobbling up all of the RAM.

Only in the sense that it doesn't do it, but provides an interface for some other utility to dedupe by creating block references, thus making it Somebody Else's Problem. Despite considerable opposition, there is some work on in-line dedupe, but it's experimental (not sure if it's in-tree yet) and ... requires tonnes of RAM.

>I certainly do. I prefer my memory to be used for something that's relevant,

What's more relevant to a fileserver than fileserving?

>rather than letting it sit as a deadweight

You might find https://en.wikipedia.org/wiki/Cache_(computing) to be a useful educational resource.

>Actually, btrfs has a much more thought out design. ZFS is already hobbled by its reliance on the fixed block sizes that later had to retrofitted for compression.

One of ZFS's main headline features is (and has always been) variable block sizes

>BTRFS suffers from the same problems as ZFS during its first 10 years or so.

This is so nonsensical that, as the saying goes, it isn't even wrong.

>And this is just a marketing bullshit. Linux LVM can use SSDs for metadata devices, BTRFS supports that natively as well

That is completely unrelated to the point you were replying to.

>About the only missing piece is RAID-Z, and that's being worked on

We've been hearing that it's technically possible for longer than it took for ZFS to go from an idea to wide production use, and still no indication that it will ever actually be done.

Btrfs stability and production-readiness

Posted Feb 23, 2016 9:31 UTC (Tue) by rleigh (guest, #14622) [Link]

Do you have any evidence for that? I've seen some historical bugs from FreeBSD 8 and earlier, but even then they tend not to be severe dataloss bugs. For current releases, it seems pretty solid; I've not seen any awful bugs in recent years.

After suffering from several incidents of non-recoverable dataloss with Btrfs, as well as the unbalancing issues making things unusable, and the woeful fsync behaviour killing performance, ZFS has so far for me been absolutely solid over the last 30 months (on Linux and FreeBSD), and I have zero complaints about it. Something which I can't say for Btrfs, which promises to be wonderful but has let me down every time.

While I can't claim any statistical significance to my observations, my 8 years of Btrfs use and 2.5 years of ZFS use have demonstrated to me that ZFS is indeed fundamentally more reliable and better designed than Btrfs.

Why Canonical NEED ZFS?

Posted Feb 20, 2016 16:46 UTC (Sat) by dowdle (subscriber, #659) [Link]

To answer your question about why... ZFS is an integral part of their LXD "hypervisor" for LXC "machine containers" which are a major new feature in the 16.04 LTS release. ZFS is needed for the quick startup, snapshots, copy and publish features. Docker's problem was that they initially relied on an out-of-tree union filesystem (AUFS). Additional filesystem backends appeared but none of them seem performant, feature complete nor completely stable... so ZFS really fits the bill. If LXD required users to install their own ZFS and get it going it would be a major barrier compared to how much easier it is by being there by default.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 19:53 UTC (Fri) by dmarti (subscriber, #11625) [Link] (1 responses)

"We are not interested in debating license compatibility" is corporate speak for "if LWN commenters have any healthy carpal tunnel tissue left, this will finish them off."

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 11:59 UTC (Sat) by HIGHGuY (subscriber, #62277) [Link]

Actually, legal arguments are never published before a lawsuit. It's like putting your cards on the table while the poker game is still busy.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 19:53 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (1 responses)

It presumably #includes lots ot pieces of kernel source. If the module uses GPL-only symbols, by the definition of the copyright holders it is a derivative of the kernel. And nothing as intimately tied to the kernel core as a filesystem is likely to avoid them.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 20:44 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> It presumably #includes lots ot pieces of kernel source.

what matters is whether any included piece is protected by copyright or not. what is protected by copyright depends on what the law says, in general the work has to be original and creative, neither of which applies to every single line of the kernel (or any software FWIW).

> If the module uses GPL-only symbols, by the definition of the copyright holders it is a derivative of the kernel.

copyright holders don't define what constitutes a derivate work, the law does. whether EXPORT_SYMBOL_GPL has any legal value is unknown.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 21:03 UTC (Fri) by lmb (subscriber, #39048) [Link] (4 responses)

So, one of the key questions is whether anyone brings this to court.

Oracle is a direct competitor of Canonical, and is not exactly known for their relaxed business practices. Not even Oracle has brought ZFS to their Linux officially - from which I conclude they either want to push Solaris, or consider the risk of individual contributors suing too high. (Because clearly, even Oracle won't sue itself.)

If individual Linux kernel contributors in the relevant areas can sue, many of them are employed by direct competitors. Or are zealots. Or are represented by zealots (FSF/Conservacy).

From this I can only conclude that Canonical must be very sure of themselves here. Brass, if not steel, one is forced to assume.

(The question how big the Canonical ZFS team is also comes to mind.)

After the SCO story has stopped being entertaining for years, would someone hand me the popcorn?

(Speaking for myself, not my employer's opinion, not a lawyer, etc, etc.)

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 22:51 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (2 responses)

Canonical lives in the UK, not USA. Copyright laws there are different.

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 19:54 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

Firstly, they're similar. Berne and all that.

Secondly, IF Canonical are breaking UK law, it's actually far more serious than breaking US law. Under US law, it's a civil tort. Under UK law, it's a criminal offence.

That said, you're now relying on the DPP to take an interest, and given the Sony debacle, I'd be surprised if they're interested.

Cheers,
Wol

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 16:15 UTC (Tue) by amacater (subscriber, #790) [Link]

Very strictly indeed - Canonical lives == is headquartered and domiciled in the Isle of Man. Although copyright law is (probably) identical to mainland England/Wales and responsibility for this may be devolved to Westminster, the IOM is not necessarily a state signatory to Berne in its own right. Responsibility for taking on criminal/civil cases is also an on-island matter.

Kirkland: ZFS licensing and Linux

Posted Feb 19, 2016 22:53 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> Because clearly, even Oracle won't sue itself

They are pretty litigious, I wouldn't put it past them 8-)

Kirkland: ZFS licensing and Linux

Posted Feb 20, 2016 0:07 UTC (Sat) by cjcox (guest, #60378) [Link]

How about: ZFS paints Linux

A play on ***** taints Linux. Why? It's like tainting, but with pretty colors available.

Five scenarios

Posted Feb 20, 2016 13:40 UTC (Sat) by dowdle (subscriber, #659) [Link] (5 responses)

Most everyone has agreed for well over a decade now that there is a conflict between the CDDL and the GPL... and it is often stated that the CDDL was intentionally created to be GPL incompatible... yet, Canonical says there is no problem and that they have confirmed that with some unnamed parties that they can't divulge (or maybe I'm misunderstanding that part of the background?)? That doesn't make any sense unless something else is going on. As far as I can see, there are only five potential explanations:

1) Canonical wants ZFS so badly that they have deluded themselves into believing there is no problem.

2) There is some backroom deal between Canonical and Oracle... and Canonical doesn't think the GPL community has the balls (or financial resources) to go after them. This almost makes sense. Risking being perceived as too Red Hat-centric, I think Oracle feels threatened by Red Hat. They make a commercial clone of RHEL after all. Canonical wants so bad to be profitable and Red Hat seems to be their biggest competitor. Oracle and Canonical could be working together to harm who they see as a shared competitor. This is not the case if others can also use ZFS without Oracle going after them... but hey, as already pointed out, Oracle doesn't offer ZFS in their own Linux distribution.

3) It is possible that Oracle wants to change their ZFS strategy even if the CDDL licensing terms are still as clear as ever... and they have given Canonical reassurances that regardless of the legal conflict that exists between the CDDL and the GPL, Oracle now cares more about ZFS gaining marketshare than they care about upholding their license. If that were the case, I would imagine Oracle would change the ZFS licensing terms... and if so, maybe that is forthcoming?

4) The people that Canonical gets legal advice from are bad at their job. Perhaps Canonical picked them because they provide answers they want to hear? This is sort of a restated #1.

5) There is something else going on that we haven't figured out yet.

Five scenarios

Posted Feb 20, 2016 14:20 UTC (Sat) by madscientist (subscriber, #16861) [Link] (1 responses)

Canonical is not saying that the CDDL is actually compatible with the GPL.

What they're saying is that they have concluded that ZFS is not a derived work of the Linux kernel, and vice versa, and so there's no licensing issue with providing both in the same download and having them work together.

This is the major issue with copyright law: knowing when something is or is not a derived work is very confusing and the only way you can tell for sure is to ask the courts (and even then you'll likely get different answers in different courtrooms).

Canonical believes they've done enough due diligence to convince themselves that they're in the clear here. Or, as has been mentioned, maybe they're just confident they won't get taken to court anyway.

Five scenarios

Posted Feb 20, 2016 16:52 UTC (Sat) by dowdle (subscriber, #659) [Link]

DUH. Ok. So, as a module of the kernel... and I know I'm retreading here... I assume the ZFS module is as self-contained as possible and doesn't borrow any general purpose, filesystem related stuff from the rest of the kernel code? That would lead itself a lot of redundant code but if that's what it takes to not be a derivative, I guess it is worth it.

I'm hoping if Canonical "gets away with it" that is to say... no one files any lawsuits... then does that mean "ZFS for everyone" aka many other top level distros will adopt it too... to be competitve? I certainly hope so. The worst case scenario is that Canonical "gets away with it" and everyone else is still too hesitant to risk it. Maybe we should thank Canonical for sticking their neck out... so we can all see if they get their head cut off or not.

Five scenarios

Posted Feb 22, 2016 12:37 UTC (Mon) by ewan (guest, #5533) [Link] (2 responses)

Oracle and Canonical could be working together to harm who they see as a shared competitor. This is not the case if others can also use ZFS without Oracle going after them

You seem to be assuming here that if someone were to sue, it would have to be Oracle suing over the ZFS licence being breached, whereas is could instead be a Linux copyright holder suing over the Linux licence being breached. In that case Red Hat would be in an excellent position to strike back using their extensive Linux kernel copyrights if they felt this was indeed harming them.

Five scenarios

Posted Feb 22, 2016 16:01 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

Oracle has contribution to the kernel, so they can also sue over the GPL! It would not be the first time.

Five scenarios

Posted Feb 22, 2016 16:15 UTC (Mon) by ewan (guest, #5533) [Link]

Well indeed, but they're not going to if this whole thing is the result of an Oracle/Canonical stitch-up, but if it's just a matter of Canonical unilaterally deciding to do something that Oracle (or at least, Sun) didn't want to have happen, then they might get a nasty surprise.

Wouldn't it be strange if one of the first really major GPL enforcement cases came from Oracle of all companies.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 18:09 UTC (Tue) by jepler (subscriber, #105975) [Link] (5 responses)

An example of GPL code copied from Linux Kernel linux.git to zfsonlinux's zfs.git:

linux.git, author date 2010-09-03 09:56:16:

+/**
+ * blk_queue_flush - configure queue's cache flush capability
+ * @q:         the request queue for the device
+ * @flush:     0, REQ_FLUSH or REQ_FLUSH | REQ_FUA
+ *
+ * Tell block layer cache flush capability of @q.  If it supports
+ * flushing, REQ_FLUSH should be set.  If it supports bypassing
+ * write cache for individual writes, REQ_FUA should be set.
+ */
+void blk_queue_flush(struct request_queue *q, unsigned int flush)
+{
+       WARN_ON_ONCE(flush & ~(REQ_FLUSH | REQ_FUA));
+
+       if (WARN_ON_ONCE(!(flush & REQ_FLUSH) && (flush & REQ_FUA)))
+               flush &= ~REQ_FUA;
+
+       q->flush_flags = flush & (REQ_FLUSH | REQ_FUA);
+}
+EXPORT_SYMBOL_GPL(blk_queue_flush);

zfs.git, author date 2011-09-05:

+/*
+ * 2.6.36 API change,
+ * The blk_queue_flush() interface has replaced blk_queue_ordered()
+ * interface.  However, while the old interface was available to all the
+ * new one is GPL-only.   Thus if the GPL-only version is detected we
+ * implement our own trivial helper compatibility funcion.   The hope is
+ * that long term this function will be opened up.
+ */
+#if defined(HAVE_BLK_QUEUE_FLUSH) && defined(HAVE_BLK_QUEUE_FLUSH_GPL_ONLY)
+#define blk_queue_flush __blk_queue_flush
+static inline void
+__blk_queue_flush(struct request_queue *q, unsigned int flags)
+{
+       q->flush_flags = flags & (REQ_FLUSH | REQ_FUA);
+}
+#endif /* HAVE_BLK_QUEUE_FLUSH && HAVE_BLK_QUEUE_FLUSH_GPL_ONLY */

Thanks to the comment block, we even know that the ZoL author/committer was aware at the time that they were copying GPL code.

Kirkland: ZFS licensing and Linux

Posted Feb 23, 2016 23:26 UTC (Tue) by rleigh (guest, #14622) [Link] (4 responses)

While this gets legally murky, I thought that things like the SCO lawsuit demonstrated that reimplementing interfaces for the purpose of interoperability was OK. In their case, POSIX error code values and the like.

And for this specific example, we're talking about an inline helper that sets two bit flags. Is it copying, or is it more the case that there's only a single reasonable way to achieve this? From the look of it, it's just a bit of glue to allow it to work with both old and new kernel versions. It's not actually *using* the "GPL only" interface; it's reimplementing its own equivalent, and then using that instead. Why do you consider that a problem?

I'd have to say that there's so little of substance in their one-line function that I really struggle to see a problem here. If there was direct copying of a significant amount of code, then yes that would be bad, but if this is it and there's only one reasonable way to set those flags, then is this really legally counted as copying at all?

Kirkland: ZFS licensing and Linux

Posted Feb 24, 2016 1:43 UTC (Wed) by jepler (subscriber, #105975) [Link] (2 responses)

Here's another one. linux.git, circa April 2010:

int bdi_setup_and_register(struct backing_dev_info *bdi, char *name,
                           unsigned int cap)
{
        char tmp[32];
        int err;

        bdi->name = name;
        bdi->capabilities = cap;
        err = bdi_init(bdi);
        if (err)
                return err;

        sprintf(tmp, "%.28s%s", name, "-%d");
        err = bdi_register(bdi, NULL, tmp, atomic_long_inc_return(&bdi_seq));
        if (err) {
                bdi_destroy(bdi);
                return err;
        }

        return 0;
}

zfs.git, circa November 2011:

static inline int
bdi_setup_and_register(struct backing_dev_info *bdi,char *name,unsigned int cap)
{
        char tmp[32];
        int error;

        bdi->name = name;
        bdi->capabilities = cap;
        error = bdi_init(bdi);
        if (error)
                return (error);

        sprintf(tmp, "%.28s%s", name, "-%d");
        error = bdi_register(bdi, NULL, tmp,
            atomic_long_inc_return(&zfs_bdi_seq));
        if (error) {
                bdi_destroy(bdi);
                return (error);
        }

        return (error);
}

Kirkland: ZFS licensing and Linux

Posted Feb 24, 2016 5:34 UTC (Wed) by SeanPowers (guest, #106840) [Link] (1 responses)

Since you took the time to look up the commits, please do enlighten us as to the author of the commit introducing the bdi_setup_and_register helper function into the mainline kernel (calling a "pretty trivial helper" to boot) and who their employer was at the time...

That doesn't make it without issue but I'm afraid it isn't exactly a legal slam dunk either. Maybe the ZFS on Linux authors aren't complete idiots and picking stuff randomly from include/linux/*.h to present as a clear case of infringement is not the best use of one's time?

Kirkland: ZFS licensing and Linux

Posted Feb 24, 2016 22:56 UTC (Wed) by jepler (subscriber, #105975) [Link]

The author and committer of the code in linux.git is an @oracle.com email address. You know, the company who won against Google in court for copying 9 trivial lines of Java.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/lin...

Kirkland: ZFS licensing and Linux

Posted Feb 24, 2016 21:32 UTC (Wed) by Wol (subscriber, #4433) [Link]

> While this gets legally murky, I thought that things like the SCO lawsuit demonstrated that reimplementing interfaces for the purpose of interoperability was OK. In their case, POSIX error code values and the like.

Actually, and if you're picking nits, this is most fundamentally NOT the case. What has finally come out of the SCO case (which, if you're still following it - look at the grokthelaw website) was that TSCOG does not have legal standing to sue.

Yes, what you say APPEARS to be the case. But the lawsuit doesn't actually say it IS the case :-(

Cheers,
Wol