|
|
Subscribe / Log in / New account

Making life (even) harder for proprietary modules

Making life (even) harder for proprietary modules

Posted Aug 5, 2023 7:26 UTC (Sat) by mjg59 (subscriber, #23239)
In reply to: Making life (even) harder for proprietary modules by cyphar
Parent article: Making life (even) harder for proprietary modules

CDDL defaults to having a "or later" clause that would allow Oracle to publish a GPL-compatible version of the license that solved most of this problem, but at least one OpenZFS developer has chosen to license their work specifically under CDDL 1.1 without that, so I'm not sure that it's universally true that OpenZFS developers would love it to be accepted.


to post comments

Making life (even) harder for proprietary modules

Posted Aug 5, 2023 7:42 UTC (Sat) by cyphar (subscriber, #110703) [Link] (11 responses)

I'm aware, and if I could make Oracle do one thing, making the CDDL GPL-compatible would be high on the list. However, given the way Oracle dealt with dtrace-on-Linux (by dual-licensing it), it seems very unlikely they will ever do that.

As for the CDDL-1.1-only code, I don't know which developer you are referring to, but unless they've explicitly stated that they wouldn't want their code to be GPL-compatible, it's also possible they were worried that CDDL could be changed by Oracle to allow for proprietary forks (if they did, it would allow them to use OpenZFS in their proprietary ZFS fork). As usual in license discussions, the risks cut both ways.

Making life (even) harder for proprietary modules

Posted Aug 5, 2023 9:37 UTC (Sat) by snajpa (subscriber, #73467) [Link] (10 responses)

I would _love_ to see this supposed GPL vs CDDL incompatibility challenged in court, btw. So far it's only the Linux kernel community kicking and screaming they're incompatible, but both of these are FOSS licenses and those are not code, intents matter. No harm to either side when combining these two works matters IMHO even more. => IMHO the licenses are not as incompatible as some paint them to be

Making life (even) harder for proprietary modules

Posted Aug 5, 2023 12:58 UTC (Sat) by pizza (subscriber, #46) [Link] (9 responses)

> I would _love_ to see this supposed GPL vs CDDL incompatibility challenged in court, btw. So far it's only the Linux kernel community kicking and screaming they're incompatible, but both of these are FOSS licenses and those are not code, intents matter

Intents only matter when the text is ambiguous, which is not the case here.

The fundamental conflict between the CDDL and the GPL is that they both require derived works to be licensed solely under that license. While broadly similar, the licenses are not identical, and the differences (eg the CDDL has stricter patent language) become "additional restrictions" that are not allowable under the other. Therefore the licenses are incompatible.

Oh, it's a lot more than the linux kernel community saying this -- Sun folks are on the record saying the CDDL was intentionally drafted to be incompatible with the GPL, and pretty much every F/OSS lawyer (other than the ones on Canonical's payroll) also agrees on this front.

Sure, ultimately it's up to a court and a zealous deep-pocketed plantiff to test this, but while you can probably trust a typical Linux contributor to not stir the pot, OpenZFS's rights are still largely held by Oracle, whose lawyers have shown time and time again they will happily boil the oceans if they think they can get away with it.

Making life (even) harder for proprietary modules

Posted Aug 6, 2023 3:38 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (8 responses)

> Oh, it's a lot more than the linux kernel community saying this -- Sun folks are on the record saying the CDDL was intentionally drafted to be incompatible with the GPL, and pretty much every F/OSS lawyer (other than the ones on Canonical's payroll) also agrees on this front.

I'm not sure that's a fair characterization of the issue. The SFLC has a long and nuanced post on the issue (see [1]) which I would summarize as "it's complicated, but arguing over ZFS on the internet is not a productive use of anybody's time. The kernel developers should either send Canonical a C&D letter, or stop whining."

[1]: https://softwarefreedom.org/resources/2016/linux-kernel-c...

Making life (even) harder for proprietary modules

Posted Aug 6, 2023 12:46 UTC (Sun) by pizza (subscriber, #46) [Link] (7 responses)

> "it's complicated, but arguing over ZFS on the internet is not a productive use of anybody's time. The kernel developers should either send Canonical a C&D letter, or stop whining."

As I said in the message you replied to; its not the kernel authors that Canonical (or the other kernel devs) should worry about; Instead it's Oracle's lawyers, who are well known for suing over software licensing minutae.

Making life (even) harder for proprietary modules

Posted Aug 6, 2023 17:06 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (5 responses)

Hasn't Canonical been doing this for years now? Where's the lawsuit?

Making life (even) harder for proprietary modules

Posted Aug 6, 2023 22:41 UTC (Sun) by pizza (subscriber, #46) [Link] (4 responses)

> Hasn't Canonical been doing this for years now? Where's the lawsuit?

Perhaps Oracle doesn't think Canonical has deep enough pockets to be worth suing, and is biding their time unti a more lucrative target (if only Canonical in a few more years) presents itself?

As both the stewards of CDDL and copyright holder of most of the ZFS codebase, Oracle could make this problem go away completely if they wanted to. Yet they have not.

Making life (even) harder for proprietary modules

Posted Aug 8, 2023 5:39 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (3 responses)

You can't just do that. The US gives you three years from the date of the infringement to file a (civil) suit, and most other jurisdictions have similar statutes of limitations (although they may not all be exactly the same length). See 17 USC 507.[1]

They could still sue for ongoing infringement after that point, assuming Canonical continues to distribute ZFS, but common law jurisdictions may apply the doctrine of laches if the plaintiff was aware of the infringement and intentionally delayed enforcement to prejudice the defendant, regardless of whether the statute of limitations applies. See for example Danjaq LLC v. Sony Corp., 263 F.3d 942 (9th Cir. 2001).[2] The key quote (in my opinion):

> Next, we conclude that claims of infringement stemming from re-releases of Bond movies on DVD have been "delayed" for purposes of laches. On the one hand, we recognize the seemingly paradoxical nature of this conclusion. After all, how can it fairly be said that a lawsuit filed in 1998, relating to a DVD released in 1997 (to take the example of Dr. No) was "delayed"? The answer is simple: Where, as here, the allegedly infringing aspect of the DVD is identical to the alleged infringements contained in the underlying movie, then the two should be treated identically for purposes of laches. It would be incongruous indeed to hold the opposite — to say, that is, that McClory's claim for infringement on a re-release survives, despite the dismissal for laches of the same claim regarding the original work. This exception would effectively swallow the rule of laches, and render it a spineless defense. In analogous contexts, similar theories have been roundly rejected. See, e.g., Hot Wax, Inc. v. Turtle Wax, Inc., 191 F.3d 813, 821-22 (7th Cir. 1999) (trademark case; rejecting the argument that each new instance of infringement must start the clock anew on laches: "Without the availability of the application of laches to a claim arising from a continuing wrong, a party could, theoretically, delay filing suit indefinitely."). We decline to reach such a result here.
>
> For similar reasons, we reject McClory's argument that laches may never bar a claim for infringement brought within the statute of limitations. We have already determined that laches may sometimes bar a statutorily timely claim. Kling, 225 F.3d at 1039; Jackson, 25 F.3d at 888. And, although such an application of laches may be unusual, see Telink, 24 F.3d at 45 n. 3, it is appropriate here. Even leaving aside the special circumstance of re-releases, we conclude in any event that McClory's extraordinary delay and the extraordinary prejudice to Danjaq render laches appropriate despite the statute of limitations. Id. at 46 n. 5 ("If the defendant can show harm from the delay, the court may, in extraordinary circumstances, defeat the claim based on laches, though the claim is within the analogous limitations period.").

[1]: https://www.law.cornell.edu/uscode/text/17/507
[2]: https://casetext.com/case/danjaq-llc-v-sony-corporation

Making life (even) harder for proprietary modules

Posted Aug 8, 2023 11:43 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> You can't just do that. The US gives you three years from the date of the infringement to file a (civil) suit, and most other jurisdictions have similar statutes of limitations (although they may not all be exactly the same length). See 17 USC 507.[1]

Thanks for that, but for purposes of my own understanding, how is this current scenario materially different from the delays from initial infringement-to-enforcement in SCO v IBM (which I think is _still_ not quite technically over) and more recently, Oracle v Google? Ultimately both were more about ongoing infringement, no?

The SCO debacle in particular is where the Linux kernel's Developer Certificate of Origin came from, and I think it's safe to state that, regardless of any technical/stylistic/etc issues, there's no way [Open]ZFS would ever get accepted into the mainline without "signed-off-by: legal@oragle.com" or shipping [Open]ZFS binaries as part of OracleLinux.

Making life (even) harder for proprietary modules

Posted Aug 8, 2023 14:53 UTC (Tue) by Wol (subscriber, #4433) [Link]

> Thanks for that, but for purposes of my own understanding, how is this current scenario materially different from the delays from initial infringement-to-enforcement in SCO v IBM (which I think is _still_ not quite technically over) and more recently, Oracle v Google? Ultimately both were more about ongoing infringement, no?

Firstly, it's very easy to sue in the US even when you have no case.

Secondly, certainly in the SCOG case we think the initial aim was to get IBM to buy them off, and then (for SCOG) it turned into an existential fight for survival plus a fraud to milk the company. So they were simply prolonging the case any which way they could.

And then, when you really have a case, it gets summarily dismissed (WP vs MS) - based on a mis-direction by a Judge I believe. WordPerfect thought that the statute of limitations had been stayed by Netscape vs MS, only to discover when they tried to litigate using Netscape as precedent, that it hadn't and they were out of time. I think what they *should* have done was launch the suit and at the same time ask the Judge to stay the case until NS vs MS was over. But either counsel misled them, or they mis-understood counsel.

Cheers,
Wol

Making life (even) harder for proprietary modules

Posted Aug 10, 2023 0:37 UTC (Thu) by dvdeug (guest, #10998) [Link]

This seems to have been overruled by Petrella v. Metro-Goldwyn-Mayer, Inc., 572 U.S. 663 (2014), where the Supreme Court said "Laches cannot bar a claim for damages brought within the three-year window. By permitting retrospective relief only three years back, the limitations period takes account of delay."

Making life (even) harder for proprietary modules

Posted Aug 6, 2023 17:16 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]

And nobody is claiming that the ZFS license is being infringed.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds