A collection of information

Are GPLv2 and CDDL incompatible?

Canonical recently threw this issue into sharp relief by their decision to ship CDDL licensed ZFS as a module of the GPLv2 licensed Linux kernel. Reading their legal justification for this leaves me somewhat unconvinced because it’s essentially the same “not a derivative work” argument that a number of dubious actors have used to justify binary modules. So what I’d like to do is look at this issue from a completely different viewpoint. First by accepting the premise that CDDL and GPLv2 are incompatible (since there’s some debate on this) and secondly by accepting the even more controversial proposition that creating a kernel module is a derivative work. I don’t want to debate these premises because it’s a worst case assumption I’m using as inputs to make the following analysis possible.

What is compliance?

One of the curious thing about CDDL and GPLv2 is that they’re both copyleft (albeit in differing forms) and the compliance requirements: the release of complete corresponding source code for your binary containing the licensed work. In fact, the only significant difference is the requirement for build scripts, which is in GPLv2 but not in CDDL. Therefore you can say that if you follow the compliance regime for GPLv2 on CDDL code, you’ll be in full compliance with the CDDL. The licences do, in fact, have compatible compliance requirements. This fact becomes very relevant when you consider the requirements for bringing a copyright lawsuit in the first place.

Where’s the Harm?

Copyright law is something called a tort in law. That essentially means a branch of law for resolving disputes between individual parties. However, in order to stem what could be seen as frivolous lawsuits, bringing a claim under tort law requires not just a showing that someone broke the rules of whatever agreement they were under but also that quantifiable harm resulted1. The essential elements of a tort claim are a showing of a violation, a theory of the harm produced and a request for damages based on the harm2.

All of the bodies which do GPL enforcement recently published a charter in which they make clear that the sole requirement from an enforcement action should be compliance with the terms of the licence. However, as I showed above, it is perfectly possible to be compatibly in compliance with both the CDDL and the GPLv2. So the question becomes if the party is already in compliance, even though there’s a technical violation of the terms of the licence produced by the combination, what would our theory of harm be given that we don’t really seem to have anything extra we’d ask of the violating party?

Of course, one can wax lyrical about the “harm to the licence” of allowing incompatible combinations. However, here we’re on a very sticky wicket because there have been a lot of works published (including by the FSF itself) bemoaning the problems of licence incompatibility. Indeed, part of the design of the GPLv3 process was to make the licence more amenable to combination with other open source licences. So suddenly becoming ardent advocates for the benefits of licence incompatibility is probably to be unlikely to fly before a judge as a theory of harm.

Conclusion

What the above analysis shows is that even though we presumed combination of GPLv2 and CDDL works to be a technical violation, there’s no way actually to prosecute such a violation because we can’t develop a convincing theory of harm resulting. Because this makes it impossible to take the case to court, effectively it must be concluded that the combination of GPLv2 and CDDL, provided you’re following a GPLv2 compliance regime for all the code, is allowable. This conclusion is the same as the one Canonical reached, but the means by which I got there are very different.

Note that this conclusion would apply to mixing any open source licence with GPLv2: provided the compliance regimes are compatible and the stricter one is followed, it’s difficult to develop a theory of harm and thus the combination is allowable.

Final Thought

The above analysis is all from the point of view of the Linux kernel compliance activities. However, with ZFS, there is another copyright holder: Oracle. Nothing prevents Oracle suing for copyright violation with a theory of harm that says something like the CDDL was deliberately designed to be incompatible with GPLv2 to prevent ZFS being shipped in Linux and as the shipper of products base on ZFS, they’ve suffered commercial harm (which would be quantifiable) by this action.

This is a gross simplification, because copyright is a strict liability tort, I’m ignoring things like duty and intention

in the US, provided the copyright was registered before the violation took place, damages may be statutory rather than actual But even for statutory damages, they come in a range which must be related to the harm

Post navigation

17 thoughts on “Are GPLv2 and CDDL incompatible?”

The principle of the GPL is that we have collaborative development. If one party is working on certain functionality — say, advanced file system technology — then that should be available to all.

If a party is using my code but *not* playing by those rules, then they have effectively stolen from me. All that work they’ve put into ZFS, I cannot legally use in my own product. If they’d complied with the licence and worked on file system technology that *was* compatible with the GPL, then I *would* have been able to benefit from it. That is a tangible loss.

OK, so I definitely accept the principle of us wanting collaborative development. However, if you have to follow the stricter compliance regime, which is GPLv2, you’re forced to collaborate, so I don’t really see a problem. My argument isn’t that you can slap this together and it just works, it’s that if you make the combination and the compliance regimes are compatible and you follow the stricter compliance regime, then we can’t sue you.

There is an interesting question of what happens to contributions to the combination, but that looked to be a very treacherous swamp I didn’t want to get into.

Firstly, the ZFS code existed long before BtrFS, so the fact that it is now available on Linux is not in itself a loss of effort to BtrFS. In fact, many of the ideas implemented in ZFS provide the foundation for BtrFS, and in fact provided the initial motivation to develop BtrFS in the first place.

Secondly, you appear to be conflating patent and copyright. While it is true that the license incompatibility prevents direct reuse of CDDL ZFS _code_ in GPLv2 filesystems or device mappers, and vice versa, there is nothing in the copyright preventing the _ideas_ from being reused. That relates to patents, and patents would prevented this reuse in Linux even if the code was proprietary. In this regard, CDDL is better than GPLv2 because it explicitly grants the use of patents embodied in the code (ala GPLv3) so that Oracle cannot sue ZFS users over any patents.

Thirdly, your comments imply that the presence of ZFS prevents people from working on BtfFS, or that the absence of ZFS would mean more effort on BtrFS. The truth is that people have all kinds of motivations, and while I shake my head a bit every time I see someone report “I wrote a new filesystem which does … to fix a shortcoming I found.” rather than “I improved (existing filesystem) to fix a shortcoming I found.” There is already lots of development fragmentation in the filesystem world, and the presence or absence of ZFS isn’t going to stop that.

In the end, isn’t the fact that ZFS is an _open source_ filesystem that everyone can use with Linux if they want more important than wasting time over the _potential_ of a license conflict? IMHO, the goal of GPL is to give users the choice and freedom to use and tinker and improve their code if they so choose. The complaints from kernel developers in the past about binary modules have been about lack of ability to debug and update and improve the module, but that doesn’t apply in the ZFS case at all.

The availability of ZFS on Linux brings users to the GNU/Linux ecosystem that may not otherwise be there because of real or perceived shortcomings in existing storage in Linux. ZFS on Linux exists regardless of whether it is shipped directly as a binary with Ubuntu or as a DKMS RPM or as separate source.

I applaud Canonical for stepping beyond the “safe” position and giving their users more choices to do what they want. What surprises my is that Oracle didn’t do the same thing many years ago with their own Linux distro.

OK, so I didn’t mention or consider ZFS at all in my analysis. On point 2 the argument is that CDDL code can be combined with GPLv2 because there’s no theory of harm, which is a copyright argument. On point 3, I didn’t mention btrfs at all either. Are you sure you’re replying to my blog post?

I’ll respond to your post out-of-order, if that’s OK. Firstly the patents vs. copyright thing. No, I’m absolutely not conflating those two. Having written a Linux file system from scratch, I’m perfectly cognizant of the difference between *ideas*, and an actual implementation that compiles and works within the target environment. It is definitely copyright that I’m thinking of.

Which brings us to your first and third points… aren’t they basically the same? And sure, I appreciate that in this case we’re talking about Canonical, the parasites of the open source world. It’s not as if they’re known for actually *contributing* back to the software they use anyway. But the point remains, that under the GPL they are offered the choice of using the GPL’d software and improving it if they want/need to, or *not* using the GPL’d software. By distributing it with non-GPL’d software in a fashion which I cannot (for the reasons outlined in my LWN post referenced above), they are gaining a commercial advantage by their violation of the licence.

Your discussion of fragmentation is also beside the point. Sure, lots of people go off and do their own thing instead of contributing to the things that already exist… but *whatever* they work on, if they ship it as part of a whole which is a work based on the kernel, it’s supposed to be under the GPL so that others *can* use it. Without being nailed to a wall by their lawyers, or losing their reputation as an honourable player (if, of course, they had such a reputation in the first place).

Your whole argument seems to be that we can’t guarantee that anyone would have contributed anyway, so we might as well not require it. If followed to its logical conclusion, doesn’t that mean that we might as well abandon the GPL altogether and *never* require modifications to be given back? After all, there’s “no harm” because they might just as well not have made those modifications in the first place. Regardless (in your eyes) of any commercial and competitive advantage they get over *lawful* and *honourable* players, by their malfeasance.

I was under the impression that integration of code under both licenses was fully permissible, but that the CDDL imposed a constraint on the sales and distribution of the combined product.

Is this the case? If so, then I think Oracle could very easily establish how it was harmed as it has restricted ZFS to differentiate its non-Linux products. I would further argue that while BTRFS might glean from ZFS that it further establishes the desire for differentiating operating system merits, and thus market share.

The issue I see with combining CDDL code and GPLv2 code, is that section 2(b) of the GPLv2 says:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Whereas section 3.4 of the CDDL requires that you NOT apply the additional restrictions of the GPLv2:

You may not offer or impose any terms on any Covered Software in Source Code form that alters or restricts the applicable version of this License or the recipients rights hereunder.

James, I’m afraid your assertion that a successful action for the fort of copyright infringement requires showing ‘quantifiable harm’ is not quite right (leaving aside that term’s inexact match for the terms actual, statutory, & additional damages used in copyright law). Most important: No showing of ‘harm’ is required at all, and the whole thing (in USA copyright law) is governed by 17 U.S.C. 504, which please see.

A copyright owner who’s registered the work at the Copyright Office can recover (per 17 U.S.C. 504) either actual damages (which for an open source codebase would be slim to none) plus the portion of infringer’s profits attributable to infringement , or statutory damages. In either case, plaintiff would of course also sue for cessation of infringement (injunction).

Statutory damages are in a range subject to the judge’s discretion. A totally benign infringer defendant (best case) who credibly claims to have been “not aware and had no reason to believe” they were infringing copyright, damages would typically be charged statutory damages of US $750 per work. But it goes up from there, up to $30,000 per work, I hear depending on perception of wilfulness. Courts also tend to award attorney’s fees, or not, depending on that same sort of perception.

For completeness (but only in a non-software context): In addition, ‘additional’ damages can be sought under 17 U.S.C. 504(d) if defendant asserted a 17 U.S.C. 110(5) Safe Harbor in bad faith. (This is about music licensing for bars and restaurants.)

The several types of damages decreed by the Copyright Act were just incidental detail to my point: I was saying your allegation that plaintiff must prove ‘quantifiable harm’ is simply in error, full stop, as can be seen clearly by the plain text of 17 U.S.C. 504 (and, for that matter, elsewhere in 17 U.S.C.) The tort of copyright infringement is defined by statute to be caused by exercise of reserved rights without permission (subject to some offsetting defences). That tort exists and can be enjoined entirely without respect to ‘harm’. Plaintiff can even be making a fortune from the infringement; he/she is still entitled by law to a judgement and relief for the infringement.

Point being that your entire argument pivots on inability to show harm — which is actually not relevant to the Copyright Act as written. (Outside the USA, I cannot speak to this matter very much with some exceptions such as UK law, but I doubt it’s very different.)

I think you might be confusing “harm” and “damages”. Legally they’re two separate things … also perhaps I was somewhat sloppy in the way I characterised them. Let me try to be clearer now: harm means the results of whatever injury was suffered as a consequence of the rules violation and damages means the what I’m asking for to compensate.

Our usual weapon in compelling people to comply with the GPL is an injunction because the harm to the ecosystem from not sharing the source is irreparable. You’re right in that under US copyright law there’s statutory damages which doesn’t require a showing of actual harm. However, without harm we have no injunctive relief (our usual weapon) and we’re reduced to quibbling about monetary compensation which is all statute gives and which would have to be shared amongst all the copyright holders. Part of our point in fighting for GPL compliance is that money is never enough to compensate for the ecosystem damage because that’s basically accepting a payment to tolerate the violation. We’d have to reverse all of that to go to court with a case where our only outcome could be monetary compensation … I don’t think we want to go down that route because it’s now contrary to our principles of enforcement.

I didn’t say there was no incompatibility. On the contrary, I said in the original post that Oracle could find a theory of harm to bring suit under this incompatibility. What I said was that, we, the open source community, have no viable theory of harm caused by the incompatibility, so we have no effective means of making the incompatibility actionable. That means, for us, it remains a theoretical problem only.