Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Posted Aug 4, 2023 17:07 UTC (Fri) by intelfx (subscriber, #130118)In reply to: Making life (even) harder for proprietary modules by spmfox
Parent article: Making life (even) harder for proprietary modules
Posted Aug 4, 2023 17:31 UTC (Fri)
by spmfox (subscriber, #125241)
[Link]
So until that happens, yeah I'd like ZFS to keep working and not have the dev's work be harder to do.
Posted Aug 4, 2023 19:29 UTC (Fri)
by darmengod (subscriber, #130659)
[Link] (8 responses)
There really *is* no substitute, it's a fantastic filesystem (storage stack?) and nothing in the Linux ecosystem quite compares to it yet.
Posted Aug 4, 2023 23:44 UTC (Fri)
by shemminger (subscriber, #5739)
[Link] (7 responses)
Posted Aug 5, 2023 7:20 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
This is not an idle question. If it doesn't make them any money, then they will not do it. See discussion in https://youtu.be/-zRN7XLCRhc?t=2085 for more information.
Posted Aug 5, 2023 9:03 UTC (Sat)
by james (subscriber, #1325)
[Link] (5 responses)
Traditionally, ZFS was a reason to buy Solaris, but with that going end-of-life in 2034, very few enterprises are going to do fresh installs on Solaris. ZFS is no longer a killer feature for Solaris.
But if ZFS is a first-class filesystem on Oracle Linux, that might encourage clients to buy support from Oracle even if other distros have it. It would certainly help sell Oracle Linux instead of Windows.
Posted Aug 5, 2023 19:10 UTC (Sat)
by willy (subscriber, #9762)
[Link] (4 responses)
Posted Aug 7, 2023 12:47 UTC (Mon)
by james (subscriber, #1325)
[Link]
I'm saying that it would be worth Oracle's while to allow ZFS into the Linux kernel and support it on Oracle Linux: this wouldn't negatively affect commercial Solaris (since its days are numbered), but would benefit Linux in general and Oracle Linux in particular.
Posted Aug 8, 2023 16:42 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
This is also the answer to NYKevin's question: Oracle could make more money by relicensing ZFS to be GPL compatible as that would allow them to ship ZFS with Oracle Linux, and market it as "We invented it, so we can support it best!".
The slight problem there is that a lot of ZFS on Linux development has been done outside of Solaris, and most (all?) of the Sun ZFS developers have long left Sun/Oracle.
Posted Aug 11, 2023 16:34 UTC (Fri)
by BenHutchings (subscriber, #37955)
[Link] (1 responses)
Posted Aug 11, 2023 18:38 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 5, 2023 7:12 UTC (Sat)
by cyphar (subscriber, #110703)
[Link] (13 responses)
Critically, in contrast to the shenanigans of proprietary module developers -- ZFS is free software under a copyleft licence, and does not attempt to subvert Linux's module loading license rules. I'm sure the OpenZFS developers would love it for it to be accepted by Linux as a first-party filesystem. They are not the bad guys here.
The licensing issue is very unfortunate, I understand the trepidation. But let's not paint people who work on CDDL code with the same brush as out-of-tree developers who seem to enjoy making things worse for everyone.
Posted Aug 5, 2023 7:26 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (12 responses)
Posted Aug 5, 2023 7:42 UTC (Sat)
by cyphar (subscriber, #110703)
[Link] (11 responses)
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.
Posted Aug 5, 2023 9:37 UTC (Sat)
by snajpa (subscriber, #73467)
[Link] (10 responses)
Posted Aug 5, 2023 12:58 UTC (Sat)
by pizza (subscriber, #46)
[Link] (9 responses)
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.
Posted Aug 6, 2023 3:38 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
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...
Posted Aug 6, 2023 12:46 UTC (Sun)
by pizza (subscriber, #46)
[Link] (7 responses)
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.
Posted Aug 6, 2023 17:06 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
Posted Aug 6, 2023 22:41 UTC (Sun)
by pizza (subscriber, #46)
[Link] (4 responses)
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.
Posted Aug 8, 2023 5:39 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
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.
[1]: https://www.law.cornell.edu/uscode/text/17/507
Posted Aug 8, 2023 11:43 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
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.
Posted Aug 8, 2023 14:53 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
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,
Posted Aug 10, 2023 0:37 UTC (Thu)
by dvdeug (guest, #10998)
[Link]
Posted Aug 6, 2023 17:16 UTC (Sun)
by DemiMarie (subscriber, #164188)
[Link]
Posted Aug 5, 2023 9:01 UTC (Sat)
by snajpa (subscriber, #73467)
[Link]
In case you haven't noticed, OpenZFS does not focus on a single kernel; integrating with Linux is not happening, as it isn't the project's goal. Which also makes for +1 argument that it is _not_ a derivative work of Linux. It was developed independently and while Linux was the only kernel for a while, now there are two, FreeBSD and Linux - and support for more is coming.
I guess some really, really envy what OpenZFS can do and Linux can't? But this vitriol is not the way how to persuade people to abandon working on OpenZFS and make them see the light and go re-develop it from scratch for Linux. If anything, it'll make us double down working on OpenZFS. As a cherry on top, one doesn't have to deal with the awful dev experience that the LKML brings :-D
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
It is a waste of effort for developers to spend time finding license backdoors.
Making life (even) harder for proprietary modules
How much does Oracle Linux compete with non-Linux OSes, and how much is it in a space where we've won?
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
And Oracle Linux has no USP over other Linux distributions, except that you can get support from the same company that supports your database if you're unfortunate enough to have an Oracle database.
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
>
> 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.").
[2]: https://casetext.com/case/danjaq-llc-v-sony-corporation
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Wol
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules