Hacker News new | past | comments | ask | show | jobs | submit login

First, things don't become legal precedent until someone sues and a judge rules on it (and preferably the ruling is upheld on appeal).

Second, what makes you think FSF/SLFC have standing to sue Canonical in this matter in the first place? Unless the rights of the FSF or SLFC themselves are infringed, they can't sue, even if they happen to have strong opinions on this matter. Either Oracle, some other OpenZFS contributor, or a Linux kernel contributor would have to be the ones bringing suit here - and of all these parties, probably only Oracle would actually want to do so.




The FSF/SFLC who are the authors and therefore guardians of the GPL maintain, publicly, that Canonical is in violation of its license. And yet, no legal action, no cease and desist has been sent.

In UK law, failure to enforce a claim or right is taken as reasonable assertion that the owner doesn't see the right as conscionable.

For better or worse, the FSF/SFLC is risking, through inaction which allows Canonical off the hook for claimed non-compliant behaviour, of having the soi-disant 'virality' of the GPL potentially ruled unconscionable (in Europe).


1) UK law should not be generalized worldwide.

2) The writer of the license has no special powers to interpret, enforce, or guard code licensed under that license. They can express strong opinions, which (if it's a well written license) garner attention, but they don't have any actual legal rights in the matter. Only the copyright holder (or someone they've delegated their rights to) can bring suit.

3) Even if the rights are estopped due to being left unenforced, if you go out tomorrow, contribute some code to the linux kernel, and then wait for canonical to link that with ZFS, you would almost certainly have your own right to bring suit. You're not estopped by someone else's failure to enforce their own rights, independent and unrelated to yours.

In any case, the arguments over ZFS have always boiled down to a few technical incompatibilities between the GPL and CDDL, mostly centering around some patent licensing clauses in the CDDL. While plenty of parties theoretically have standing to sue, in practice the Linux folks would love to merge it if they could, as would the OpenZFS authors - with the notable potential exception of Oracle, who remains silent on the issue. As such, none of the open-source developers are suing to enforce any sort of technical licensing problem because it's not in their interests to do so. And if Oracle gives up some rights, well, that's a good thing, right?

In short, most everyone involved doesn't want there to be a lawsuit - and so there isn't. And that's not a bad thing. The problem the FSF/SFLC keep going on about is that there's a lot of uncertainty - i.e. "someone _could_ cause you a lot of trouble by suing, so please stop doing this before you get yourself or your customers sued by someone else".


Just because someone uses your license, doesn't give you ownership rights or a legal cause of action regarding the code they licensed. What matters is who wrote OpenZFS, not who wrote the GPL.


Since ZFS isn't under the GPL I think copyright holder(s) of the Linux kernel, not the copyright holder(s) of OpenZFS, would have to sue Canonical.


The FSF and SFLC have as much authority to sue people for infringing the kernel's copyright as I have: absolutely none. Only the copyright holders can do that. Likewise, I can't sue people for trespassing on my neighbor's property.

In the US, (1) you can't let an issue get bigger simply so you can claim more damages the way SCO tried; and (2) when there's a specific statute of limitations -- like there is with copyright -- courts are less likely to say somebody delayed filing suit for too long, unless they made statements about trying to make a record to qualify for more damages, the way SCO did.

In the US, it used to be possible to lose copyright if you failed to enforce it, but that hasn't been the case for decades.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: