Hacker News Reader

Unless the GPl'd work provides a novel API that the GPL code implements; that has been tested in court. The API is protected, by copyright, and linking to that API requires the use of the API. That's why you can't just link to GPL'd code will-he–nill-he, without the possibility of serious repercussions.

That phrase you're looking for is willy nilly. You did a bone apple tea.

Bone apple tea, with an em dash to boot

will (hypen-minus) he (en-dash) nill (hyphen-minus) he

Shakespeare had it as will he nill he in Hamlet:

> “If the man go to this water and drown himself, it is, will he nill he, he goes - mark you that.” (Hamlet.V.1)

Though I admit I didn't know this until I actually looked it up just now :)

“Will he nill he…” huh, I wonder if that’s the etymology of the modern expression. “Willy-nilly” just seems like a nonsense phrase. “Will he nill he” could be read as “will he or will he not,” right? It seems like only a couple short conceptual hops to go from “whether or not he decides to do something” to “look at all the random things he could do.”

I largely agree with you, but I can imagine a scenario where there is some connection to "Will he? Won't he?" semantically.

> Will he nill he…” huh, I wonder if that’s the etymology of the modern expression.

Well, that's at least what the internet told me, last time I checked.

I suppose I should have looked it up! For some reason I just looked up the definition of nill and tried to work out a plausible folk etymology from there.

API protected by copyright? Sounds like a judge somewhere dun goofed, that just makes no sense on the face of it. The specific IMPLEMENTATION of an API maybe, but not the API itself.

https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America%2...

Yea, that seemed like a massive mistake even at the time. The interface binding code together doesn't strike me as work worthy of protection.

> Another, possibly far bigger problem, is that it's entirely possible to effectively neuter the GPL with a secondary contract.

I don't really think that's a problem, per se.

Regarding your second example, that's totally fair: effectively the theme maker (who is presumably also the sole copyright holder) did not actually give the theme to the other party licensed under the GPL: they licensed it differently in that sale, which is 100% their right to do.

The Red Hat example is a little more complex, I think. The GPL says you cannot add extra conditions to redistribution. If Red Hat owned the copyright for everything they distribute, that would be fine: they couldn't say RHEL was GPL-licensed, but they'd be in the clear.

I'm actually surprised they've gotten away with this: as far as "ambiguity in GPL enforcement" goes, I feel like it's not all that ambiguous that RH is committing a GPL violation by adding that condition. All it would take would be for rightsholders of a major component of RHEL (like perhaps the Linux kernel) to complain about this. (Then again, there may be no publicly-stated contract or policy here; RH may just cut off customers who share, and cite vague "we reserve the right to cut you off for any reason" policies.)

(Also I might be getting details wrong here; I'm just going by your description and haven't done my own research into these cases.)

This is not adding any conditions to the GPL: "If you redistribute this GPL software, then we will refuse to license later versions to you."

It's pretty clear what it means, based on the goals of the license: To allow the user to easily replace/modify the (L)GPL licensed (part) of a program.

For GPL, that means you can only include GPLed code if you make the whole program available for user to modify and redistribute.

For LGPL, you can include LGPLed code if you make just the LGPLed part of the app available for easy replacement. (so normally this means some form of dynamic linking, and very commonly used in practice with eg. glibc)

So if some company statically links (L)GPLed code to their app or makes it in other ways hard to modify/replace, it's a violation.

Except the "whole program" bit is in question here. A lot of legal scholars doubt that using the GPL in the way the FSF wants it to be used when it comes to linking would actually confer the terms of that license to the final product (because the FSF wants it to be considered a derivative work of the GPL code). In the EU, it's to the point where the EU themselves have written guidance that they doubt this interpretation applies[0]. This would effectively limit the scope of the GPL to always function like the LGPL/MPL (or any other copyright license that limits the copyleft element to the parts of the program actually licensed as such, as opposed to spreading it across the whole work.)

The problem is that the GPL isn't the law; it's something (a license or a contract, the interpretation of which is a toss-up; the FSF wants it to be a license since it allows shrinkwrapping the terms, all legal enforcement has it treated as a contract) that relies on existing law to function. Which fails to work if it tries to do something that legal framework doesn't allow you to do. You can't enforce copyright over derivatives if it's not considered a derivative to begin with.

If the FSF conceded that the GPL was actually a contract and were to write more explicit terms stating that this is a requirement to using GPL'ed source code, they'd probably not run into this problem, but because they insist on forcing it through the framework of copyright the virality of the license only goes as far as the definition of derivative works go.

[0]: https://joinup.ec.europa.eu/collection/eupl/licence-compatib...

> as well as a far more direct legal case in Germany where a WordPress theme maker was able to prevent distribution of a theme they made by arguing that the contract made when the theme was sold overrode the terms of the GPL and prevented the buyer from sharing the theme because of agreed to terms in the contract.

What case was that?