Grsecurity: Potential contributory infringement and breach of contract risk

But, that's orthogonal to the problem of small, poorly funded, teams ending up being responsible for major infrastructure, including major security infrastructure. The kernel is one of the few really important pieces that isn't understaffed or underfunded. So, generally, I just trust that the kernel team and my distro of choice are doing good things and use what they give me.

I'm not afraid to patch the kernel, and I've even maintained custom kernel modules and kernel packages in the past, but I'm not going to slap random stuff into my kernel just because a company that profits from it tells me it's better, especially when Linus says it is "garbage" (his word, not mine).

Let's back up for a moment just to make sure we're talking about the same "they." "They" being the author of this article, absolutely said almost verbatim what I claimed they said.

My post: "It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code"

The article: "This is tantamount to the addition of a term to the GPL prohibiting distribution or creating a penalty for distribution. GPL section 6 specifically prohibits any addition of terms."

>If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.

Now it seems you're talking about GRsec and not the author of the article, but I definitely didn't claim GRsec said anything, I only made assertions about what the article said.

Then, going a step further, what you're arguing is yet another separate issue entirely, which is more relevant but still different than anything in this thread: Your claim is that their contract's rules of punishing someone for redistribution is not covered by GPL section 6. This may well be true, but I would personally guess not.

"You may not impose any further restrictions on the recipients' exercise of the rights granted herein" seems pretty clear cut to me. It implies that you can't impose any further restrictions. You can't even write a contract regarding the terms of redistributing GPLv2 software. And indeed, as far as I can tell, there's absolutely no precedence for being able to do that. If you could do that, then anyone could defeat the GPL by making a contract with sufficient punishment for redistribution.

"However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly."

But gnu.org also states:

"If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?

Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL."

But over at the Wikipedia article there's this:

"Some people believe that while static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak copyleft). Linux author Linus Torvalds agrees that dynamic linking can create derived works but disagrees over the circumstances.

A Novell lawyer has written that dynamic linking not being derivative "makes sense" but is not "clear-cut", and that evidence for good-intentioned dynamic linking can be seen by the existence of proprietary Linux kernel drivers."

Now Lawrence Rosen, one-time Open Source Initiative general counsel argues this:

"The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work."

But what there's more! The GPLv2 allows for a linking exception clause if the original developer(s) want to offer it.

"If you're using GPLv2, you can provide your own exception to the license's terms. The following license notice will do that. Again, you must replace all the text in brackets with text that is appropriate for your program. If not everybody can distribute source for the libraries you intend to link with, you should remove the text in braces; otherwise, just remove the braces themselves."

Much of it seems to come down to intent and good faith. While the pure application GPLv3 pretty much says no to linking, both dynamic and static, the legal definition of what constitutes a derivative work creates a grey area. It seems to come down to the intent of the developer(s) who license it as to whether it would be enforced that way but the dynamic linking issue is untested in court so no one seems to be sure if it's enforceable. Who knows? GNU, making simple things complicated since 1983.

I gave a longer rant about this in a separate thread: https://news.ycombinator.com/item?id=14733131