LWN: Comments on "SFLC: The Linux Kernel, CDDL and Related Issues"

SFLC: The Linux Kernel, CDDL and Related Issues

ghane — Thu, 03 Mar 2016 15:59:07 +0000

The Attorney I go to, and respect, (for 15 years) has *always* advised me not to proceed with any issue in court. Over time, my take has become that no lawyer (I have met in Singapore) is more aggressive than his client. I have sat in in very large commercial cases, and our lawyers have always said things like: "Of course I will vigorously put your point across in court, but I assume the other law firm are not idiots, and they would not be advising their client to proceed if things were as you say".

Clients hide facts from lawyers, slant their stories, and leave them looking stupid as opposing depositions are filed.

The *law* is clear to all lawyers, but how you put the facts to him affects his advice,

And as my friend says, 50% of all cases are lost. What does that tell you about "it is an open-and-shut case"?

A lawyer's opinion, especially one that is designed to be released publicly by the client, is similar to a football team manager's pre-match statement. Of course we will win!

SFLC: The Linux Kernel, CDDL and Related Issues

nye — Tue, 01 Mar 2016 17:23:40 +0000

>Apparently Canonical's ZFS plans violate the CDDL too

That article states this as fact, but provides nothing to support that assertion and in fact, by referencing CDDLv1§3.6, contains specific argument to the contrary.

The basis for the argument appears to be a claim that Canonical is distributing CDDL code under the GPL, which would indeed be in violation of the license but is also is entirely fictitious - that's rather the problem from the GPL/Linux side. This article appears to be claiming, simultaneously, that Canonical is violating the GPL by not providing ZFS under the terms of the GPL, *and* violating the CDDL by distributing ZFS under the terms of the GPL. These are contradictory statements; they can't both be true.

There's simply no argument (and of course they don't try to make it) that ZFS itself becomes derivative of Linux, only that the combined binary (and glue code) does. Their interpretation is that the entire source used to build the resulting executable (kernel module) needs to be distributed under the GPL, even those parts which are not, themselves, derivative of GPL work. This is a somewhat extreme but not entirely unreasonable position to take, but the end result of not doing this - given that position - would be that the resulting kernel module violates the *GPL*. The CDDL on the other hand is okay with it (as per §3.5 and 3.6).

Overall I'm deeply unimpressed by this post which seems to be so poorly reasoned that the uncharitable might conclude that it is *intentionally* misleading.

SFLC: The Linux Kernel, CDDL and Related Issues

pabs — Tue, 01 Mar 2016 14:16:35 +0000

Apparently Canonical's ZFS plans violate the CDDL too:

https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

SFLC: The Linux Kernel, CDDL and Related Issues

nye — Tue, 01 Mar 2016 12:43:25 +0000

It's bizarre that people seem to be implying that Oracle has been secretly funding the SFLC to influence their position, because this position is directly contrary to Oracle's interests.

Remember that the OpenZFS code that we're talking about - whose copyrights are held mostly by Oracle - is in direct competition with Oracle's own proprietary ZFS. If it weren't already available under a copyleft license, they'd be keeping it tightly under wraps.

Oracle don't want ZFS in Linux because it would largely eliminate the only market segment where Solaris is still relevant, and if they eventually give up on Solaris and actually *do* start wanting ZFS in Linux, it would be *their* ZFS rather than the version that is currently Free software.

It's fortunate for Canonical that the CDDL is somewhat more permissive than the GPL and pretty clearly allows what they're doing, and it's thus only the GPL where this is disputed, because it means that the most likely litigant - Oracle - doesn't have standing to sue. If Canonical believed there was a risk of violating the CDDL on Oracle's code I rather suspect they'd be a lot less likely to take that risk versus arguably (and it is only arguable, not fact) violating the GPL on Linux.

SFLC: The Linux Kernel, CDDL and Related Issues

Wol — Tue, 01 Mar 2016 00:37:21 +0000

What he's saying is that this is the SFLC's view. Any lawyer working for the SFLC will have a bias to slant things in SFLC's favour.

And where is the pressure for bias in the other direction? I can't see any! So the GP is right to be *suspicious*.

I'd be suspicious for other reasons, and I had this run-in with PJ on many occasions - she always said "consult a lawyer". Well, my personal experience of dealing with lawyers is that, like any other group of people, you have good ones, you have bad ones, and you have ones that make mistakes!!! I think pretty much EVERY lawyer I've ever had to deal with, I've had to cross-check their work and make sure it was correct - I've found some appalling mistakes.

Cheers,
Wol

SFLC: The Linux Kernel, CDDL and Related Issues

rahvin — Tue, 01 Mar 2016 00:34:59 +0000

This is wrong. Any statement made by the rights holder can be considered in a copyright proceeding.

Outside statements will only be considered if the plain language of the license is deemed "vague" by the court. The only time the preamble or any other developer statements would be considered by the court would be if the court found the license wasn't clear on some terms of the license which were in contention. The only exception to this would a violation that the developer involved in the suit had told the defendant was ok.

SFLC: The Linux Kernel, CDDL and Related Issues

rahvin — Tue, 01 Mar 2016 00:29:47 +0000

Thus if the kernel developers state they will not sue for doing XYZ then they won't sue.

At least in the US it only takes a single developer to disagree with a consensus if it exists within the community because as you noted, it doesn't necessarily matter what they think, only what the law (and case law) is.

There is another thing about copyright law that makes it dangerous. It doesn't matter one bit if the author tolerates or ignores violations of the license for 20+ years then launches suit for violations. The only exception would be if that particular developer had made statements that it was ok in the past and that someone else relied on those statements. As long as a developer never condones the violation they can bring suit at any time and they have not waived any rights by not reacting in the past and if the copyright is registered they can claim statutory damages, which are very significant. In the US copyright doesn't fade and it doesn't get diluted by not reacting to known infringement.

SFLC: The Linux Kernel, CDDL and Related Issues

jra — Mon, 29 Feb 2016 18:12:45 +0000

Also:

http://blog.emacsen.net/blog/2016/02/28/why-is-sflc-sidin...

dtrace

nix — Mon, 29 Feb 2016 17:52:36 +0000

The purpose of the first of those commits (or rather of the series of which it was a part) was to slice apart things that were previously entangled in ways that felt seriously iffy to me (we literally had GPL and CDDL things next to each other in the same files in our early-development internal never-released repo, which bore a major risk in my eyes of accidentally combining things licensed one way with things licensed the other) so that we could rewrite history before public release to drop them into separate version control and at least have a *degree* of an idea as to which parts were GPLed and which parts were CDDLed, and minimize the interface between the two as much as possible. It wasn't something every detail of which was overseen by lawyers or anything like that. It was an attempt to keep the kernel developers from getting too unhappy.

(I might note that taking commit comments I wrote on any subject whatsoever and assuming they constitute legal advice is the height of foolishness! I'm not sure I can even hand out "anti-legal advice" to not trust any legal advice from me, let alone any other sort of legal advice. My cousin, now, *he* can hand out legal advice, but I don't think Oracle would be too happy having a Google lawyer hand out legal advice on their behalf, cousin or not. :) )

As for the DTrace-related code in the UEK source tree, it's almost all in kernel/dtrace, though a big chunk used only at build time is in scripts/dwarf2ctf (relying on the dual-licensed libdtrace-ctf library, also in oss.oracle.com/git) and, well, you have the names of both authors in the commits you quote and can git grep just like anyone else.

SFLC: The Linux Kernel, CDDL and Related Issues

tmarble — Mon, 29 Feb 2016 16:57:01 +0000

Is SFLC Shooting Open Source in the Foot?

http://info9.net/wiki/tmarble/posts/is-slfc-shooting-open...

dtrace

jhoblitt — Mon, 29 Feb 2016 14:59:00 +0000

I don't know what stub code Oracle has or hasn't been added to the uek main source tree but all of the loadable dtrace modules have CDDL header comments. Eg.

https://oss.oracle.com/git/?p=dtrace-modules.git;a=blob;f...

There are two commits in the same repo that mention the GPL:

https://oss.oracle.com/git/?p=dtrace-modules.git;a=commit;...
https://oss.oracle.com/git/?p=dtrace-modules.git;a=commit;...

Those changeset comments seem to imply that one may write a shim function around a EXPORT_SYMBOL_GPL symbol and that the GPL would not apply to users of the shim symbol.

If we were talking about literature, I think a reasonable analogy would be taking a copy of another parties novel, wrapping it with a few paragraphs, and then embedding the entire works into your own publication while claiming that the "wrapper paragraphs" isolate your work from being considered derivative of the original novel.

SFLC: The Linux Kernel, CDDL and Related Issues

mjthayer — Mon, 29 Feb 2016 14:18:15 +0000

It is perfectly clear that you did not mean "literally" literally.

SFLC: The Linux Kernel, CDDL and Related Issues

dwmw2 — Mon, 29 Feb 2016 13:15:55 +0000

I am a pedant, and I am familiar with the difference between the meaning of the words "literally" and "figuratively". I enjoyed that XKCD cartoon the first time I saw it. You'll note that the word is used in the past tense in the cartoon.

I will leave it as an exercise for the reader to determine whether I really meant that I expected the lawyers to subject me a physical attack, or whether it was hyperbole.

SFLC: The Linux Kernel, CDDL and Related Issues

tao — Mon, 29 Feb 2016 12:44:23 +0000

John Jackson: "I say your three cent titanium tax goes too far."
Jack Johnson: "And I say your three cent titanium tax doesn't go too far enough."

SFLC: The Linux Kernel, CDDL and Related Issues

abo — Mon, 29 Feb 2016 09:01:16 +0000

Isn't it also true that the ability to refactor and rearrange code, to simplify by reducing duplication of code, to reuse useful pieces, etc etc, is integral to the development process of the Linux kernel and that this would be severely hampered by the license-imposed need to keep certain code "separate"?

SFLC: The Linux Kernel, CDDL and Related Issues

micka — Mon, 29 Feb 2016 08:45:48 +0000

> my lawyers will literally nail me to the wall ...

I won't assume it's what the previous poster meant, but I expect lawyers to be very careful about not doing *physical* attacks, nailing someone on the wall is very traumatic, depending of the kind of nails you use and the way you insert them. And shed lots of blood.

That would put them in front of the law themselves and I'm sure they're caution enough to avoid that.

https://xkcd.com/725/

SFLC: The Linux Kernel, CDDL and Related Issues

rsidd — Mon, 29 Feb 2016 08:10:50 +0000

Did you read Linus's quote in the article? He specifically talks about kernel modules and whether or not they may be considered derived works. He brings up the Andrew file system, which in his opinion was not a derived work and he was willing to say so. In your opinion, maybe AFS and ZFS are both derived works despite clearly having been written for other systems. Maybe a court will agree with you. But it is not as cut-and-dried as you imply.

SFLC: The Linux Kernel, CDDL and Related Issues

dwmw2 — Mon, 29 Feb 2016 08:08:26 +0000

> > my lawyers will literally nail me to the wall ...
> Really? I don't think so...

Well, perhaps you haven't met my lawyers.

Or perhaps you just haven't fully contemplated the mindboggling stupidity it would take for me to stand in their office and argue that although I'm not actually in compliance with the licence, what I'm doing should be considered "good enough".

When a bunch of grumpy pedants (who happen to have standing) have already clearly stated that it is not.

I think their defence would probably be that it wasn't homicide because I was already brain dead.

SFLC: The Linux Kernel, CDDL and Related Issues

rsidd — Mon, 29 Feb 2016 08:04:34 +0000

Who are you saying is Eben Moglen/SFLC's client here? Linus or other kernel developers? Canonical? Oracle? If you're alleging conflict, please elaborate, don't just vaguely insinuate it.

dtrace

snits — Mon, 29 Feb 2016 07:01:34 +0000

There are the bits in dtrace-modules which is CDDL and ships in its own rpm. There also is a bunch of code in the UEK kernel itself. The repos are at https://oss.oracle.com/git/

SFLC: The Linux Kernel, CDDL and Related Issues

charlieb — Mon, 29 Feb 2016 04:07:52 +0000

> my lawyers will literally nail me to the wall ...

Really? I don't think so...

dtrace

jhoblitt — Mon, 29 Feb 2016 01:32:59 +0000

Could you provide a download link for this GPLv2'd version of dtrace? All source I can't find is clearly CDDL licensed.

SFLC: The Linux Kernel, CDDL and Related Issues

drag — Sun, 28 Feb 2016 17:56:59 +0000

What is being discussed here is subtle:

Their restrictions cannot go _beyond_ what is defined as "derivative works". The GPL is a copyright license and thus it itself limited by the scope of copyright law.

In this way you are absolutely correct that the Kernel Devs/FSF opinion on what they define as 'derivative works' is irrelevant. A classic example of this is the FSF claim that linking to GPL library creates a derivative work of that GPL library and thus is subject to the restrictions laid in place by the GPL license. That is FSF's opinion, however it does not mean they are correct in their opinion. You very well may be able to link to GPL libraries without having to adhere to GPL restrictions (due to not being legally defined as 'derivative works') in some instances while in others it does meet the legal requirements for derivative works and thus falls under the GPL copyright restrictions.

HOWEVER...

This does not stop the copyright holders from creating _allowances_. After all that is what allows things like the GPL to exist in the first place. People have created allowances, but retain some copyright restrictions for the purpose of 'copyleft'.

Remember that the only people that have any case in a copyright lawsuit is the copyright holders. This means that the only people that matter, in this case, are the kernel developers. Thus if the kernel developers state they will not sue for doing XYZ then they won't sue. It's as simple as that.

In this case the license of the Linux kernel can be described as GPLv2 + API allowances.

If they let it be publically known that they allow this sort of 'linking' or 'binding' as kernel modules then the case against the CDDL-licensed ZFS code is rather weak.

Remember this stuff has happened in the past. OpenAFS file system support is a classic example of a kernel module that is tolerated by the Linux community even though it may technically violate the GPLv2 license.

SFLC: The Linux Kernel, CDDL and Related Issues

mjw — Sun, 28 Feb 2016 17:02:22 +0000

Who is the intended target audience of this text? Has it been written in response to a specific request from a client of the SFLC? And if so, what was the specific question that is answered by this text?

Most of it seems clear and matches other interpretations of the situation. Shipping the larger (binary) work including parts which are explicitly GPL-incompatible because the CDDL doesn't allow redistribution of the source of the work under the terms of the GPL is not allowed. And distributors should cease distributing such combinations. It does provide some advice on how one could approach that situation in a pragmatic way by mimicking what Debian is proposing to do.

But then there is also a lot of speculation about an hypothetical "equitable interpretation" of the GPL where all copyright holders wouldn't see any harm in providing an exception for this infringing use. That last part seems mostly academic since there are copyright holders which have already said that they don't want to provide an exception to the GPL for such kernel modules and that they do see harm from the fact that not all source code is available under the terms of the GPL.

The same seems true for the last part about dtrace. Is that in response to a request from a client to redistribute the dtrace code under the GPL, and an explanation of the SFLC how they would defend that client when they do that and Oracle as copyright holder objects? Or is it also mostly an academic exercise?

In both cases of course Oracle could simply clarify they do intent the code of ZFS and dtrace to be available and redistributable under the terms of the GPL (or GPL compatible terms). As long as they don't explicitly do so, it seems most of this really is all academic.

dtrace

vonbrand — Sun, 28 Feb 2016 17:01:21 +0000

Oracle is distributing dtrace under GPLv2 as their Linux kernel. Nothing "implicit" in this. They haven't taken any action with respect to ZFS, and that is a very big difference.

SFLC: The Linux Kernel, CDDL and Related Issues

vonbrand — Sun, 28 Feb 2016 16:53:28 +0000

What the FSF or the kernel developers deem to be derivative works is irrelevant, it is defined by law. What the cited text does is to add an exception to GPLv2: programs are allowed to use the system call interface without comming under GPLv2 as derivative works. If they are derivative works under the law, they don't need to be under GPLv2. If they aren't, well, it doesn't matter.

SFLC: The Linux Kernel, CDDL and Related Issues

jejb — Sun, 28 Feb 2016 16:24:08 +0000

We can't extend the term, so we can't say binary modules are derivative works. However, we can restrict the term, and saying user space code which only interacts through the syscall API isn't a derived work is a permissable restriction

SFLC: The Linux Kernel, CDDL and Related Issues

jejb — Sun, 28 Feb 2016 16:15:48 +0000

This is wrong. Any statement made by the rights holder can be considered in a copyright proceeding. The question would be whether it could reasonably be relied on. So a chance remark you overheard me make at a bar while drunk would likely not be considered reasonably to be relied on. However, a statement made within the four corners of the document outlining the licence would definitely be considered reliable.

SFLC: The Linux Kernel, CDDL and Related Issues

anselm — Sun, 28 Feb 2016 15:27:02 +0000

Maybe you can't, but if the license of the Linux kernel says that – as far as its developers are concerned – software using the Linux system call interface isn't considered “derived” from the Linux kernel, then as the Linux kernel developers are the only people with standing to sue for a license violation it doesn't really matter what “copyright law” says about derived works. In effect this is a roundabout way of saying “you won't be sued (by us, and we're the only ones who could) for writing code that runs on Linux, so by all means go right ahead, knock yourselves out”.

The “what is ‘derived’ according to copyright law” question would only become pertinent if the kernel developers were in fact trying to argue the opposite case, i.e., that some program written against the Linux kernel syscall interface was “derived”, in a legal sense, from the kernel. This is because then presumably some judge would have to decide whether that was legally the case. As long as the Linux developers don't actually sue anybody over writing code that runs on Linux, the details of copyright law don't enter into the debate.

You could quibble about the point that the declaration in question is not part of the actual license, but that only means you need to trust the Linux kernel developers that they actually mean what they say. But as a Linux user you already trust the Linux kernel developers to do all sorts of things, so it doesn't seem like a huge leap of faith.

SFLC: The Linux Kernel, CDDL and Related Issues

fhuberts — Sun, 28 Feb 2016 14:56:30 +0000

The FUSE case is totally different: it uses syscalls.
ZFS is in-kernel, using in-kernel interfaces, thus making it a derivative work.
The GPL is quite clear about those: not allowed unless also licensed under GPL.

dtrace

fuhchee — Sun, 28 Feb 2016 14:52:20 +0000

It seems to rely on unsubstantiated assumptions on exactly what terms apply to which parts, when the bits arrive in Oracle's customers' hands.

SFLC: The Linux Kernel, CDDL and Related Issues

fuhchee — Sun, 28 Feb 2016 14:39:18 +0000

You can't define terms differently from copyright law. Calling something a "derived work" according to LKML does not making it so, and vice versa.

SFLC: The Linux Kernel, CDDL and Related Issues

rahulsundaram — Sun, 28 Feb 2016 14:28:27 +0000

Not sure how I misremembered that. Thanks for the correction!

SFLC: The Linux Kernel, CDDL and Related Issues

dwmw2 — Sun, 28 Feb 2016 13:21:32 +0000

Also, when they say that no convincing record exists to demonstrate whether copyright-holders intend a literal or equitable interpretation... they seem to have overlooked the fact that SF Conservancy, who represent an increasing coalition of Linux kernel developers, have clearly indicated the former.

SFLC: The Linux Kernel, CDDL and Related Issues

micka — Sun, 28 Feb 2016 12:37:48 +0000

Well, if it's two different interpretations of the same mythology, it can't be very different.

SFLC: The Linux Kernel, CDDL and Related Issues

dwmw2 — Sun, 28 Feb 2016 11:27:37 +0000

The argument is interesting, and makes a certain amount of sense. However, I believe it suffers a fundamental flaw.

It is based on the premise that there is no harm, and that the resulting combined distribution is compatible with the intent of the GPL although not its letter. I believe that to be false.

A fundamental premise of the GPL is reciprocity. If you go and work on enterprisey file system stuff using the kernel I contributed to, then I expect to be able to make use of the work you did. If you worked on ext4 or btrfs, that would clearly be the case. However, if you have chosen to work on ZFS, then I cannot benefit from your "contribution". There are at least two good reasons why I can't, and why many people are in the same position:

my lawyers will literally nail me to the wall if I suggest violating the terms that are written in the licence — even if I claim that "it's OK; we'll get away with it".
unlike Canonical, I might actually have a reputation in this field for being a good player, and I might not want to suffer the loss of that reputation.

So the initial premise, that distribution under CDDL is "good enough", and that it "falls within the equity of the [GPL]", seems to me to be false. Sure, I can see the source. But I can't necessarily use it. It's about as much use as the historical Microsoft "shared source" was.

That aside, it is good that we skip straight over the nonsense arguments about ZFS itself not being a "derived work", and clearly accept that since it is being shipped as part of a greater whole alongside the Linux kernel, rather than as a separate work, it does need to be "good enough" to comply with the GPL — even if there is debate about what would be "good enough".

I look forward to applying this same logic to the numerous similar violations where there's nothing to debate because the source isn't available at all, such as the Broadcom binary modules in router products which are even more clearly a coherent whole comprising kernel + module than the Ubuntu distribution is.

I know there are those who bizarrely argue that the mere aggregation on a volume of a storage or distribution medium" clause is actually so broad that it serves to contradict and render pointless the entirety of the paragraphs that precede it. It's good to see that old chestnut not being offered here in Canonical's defence.

dtrace

rsidd — Sun, 28 Feb 2016 06:35:36 +0000

Sorry, I meant last section, not last paragraph, and my line was a tl;dr of that section.

dtrace

rsidd — Sun, 28 Feb 2016 06:34:40 +0000

I think the tl;dr should have been the last paragraph: by Oracle's own actions, Oracle has legitimised dtrace being included in the linux kernel (either mainline or in a distro version).

SFLC: The Linux Kernel, CDDL and Related Issues

butlerm — Sun, 28 Feb 2016 06:18:49 +0000

> It would help to know how much weight I (as a non-lawyer) should give to your interpretation of IP law, as against that of the two exceptionally highly qualified and well-respected IP lawyers who wrote the article.

No, I am not a lawyer, but one thing I do know from ample observation is there are few sources less trustworthy than that of a lawyer arguing on behalf of a client. The SCO case is a classic example of that, and there are many many others.

Anything that comes out of a lawyer's mouth should be understood as slanted in the most imaginative way possible in favor of his client's own interests. That is their job, their obligation, and their fiduciary responsibility. As a rule, no one should take a lawyer's opinion as a neutral take on anything.

SFLC: The Linux Kernel, CDDL and Related Issues

zenaan — Sun, 28 Feb 2016 06:13:52 +0000

It's ironic - to say it's smaller than something "really quite big/ significant" tells you its not particularly small or insignificant. That's how I read it anyway. I think it's quite a funny quip really... with overtones of implied religiosity/ religious fervour in the debate as well - very clever :)