Single-company free software [LWN.net]

Single-company free software

Posted Oct 11, 2005 15:59 UTC (Tue) by lutchann (subscriber, #8872)
In reply to: Single-company free software by szoth
Parent article: Single-company free software

Geez, don't get so defensive, this isn't Slashdot.

I specifically linked to the article where the information came from so that everyone could draw their own conclusions as to the accuracy and bias of the source. I don't put a lot of stock in the journalistic quality of Wikipedia material, so I'm not going to take anything written there as fact without verifying it first, and I don't expect anybody else to.

I stand by the claim that the GPL is mostly untested, although I don't mean "tested" in the FUD sense. The GPL is generally considered to be a valid, well thought-out license, and nearly all of the code I write is released under the GPL or LGPL because I have faith in the legal soundness of those licenses. However, the interpretation of many of the terms in the GPL is still unclear.

To take a well-worn example, there is considerable controversy over where the line is drawn regarding dynamic linking of GPL code to closed code, particularly with regard to the Linux kernel. When proprietary software companies find an unanswered question regarding their own license, they promptly revise their license terms to clarify their intentions. However, since there is such a large body of code that will forever be licensed under the GPLv2, it is up to the courts to resolve ambiguities in the license, and that doesn't seem to happen very often.

(Log in to post comments)

Single-company free software

Posted Oct 13, 2005 6:40 UTC (Thu) by ekj (guest, #1524) [Link]

To take a well-worn example, there is considerable controversy over where the line is drawn regarding dynamic linking of GPL code to closed code, particularly with regard to the Linux kernel.

Yeah, that example is worn, allthough not well-worn. I've debunked it before, guess I'll do so again;

You are correct that it is not always 100% clear what exactly constitutes a "derived work", for example, in the case of the Linux kernel there's some disagreement as to if a kernel-module is a derived work of the kernel or not.

However, this confusion has absolutely --zero-- to do with the GPL, but is instead a general problem with copyright.

"derived work" is defined in law, and license-writers are not free to redefine it. Or put another way: if they redefined it, that redefinition would carry no weight anyway, what matters is what is, in the eyes of the law, a derived work.

If I write my own "EPL" (Eivinds Public License) in which I state that all software running on the same computer as my software is to be considered "derived" and must be released under the EPL, that would never stand up in court. If the law considers that non-derived (and that's a fair bet) there's nothing I can write to change that -- I'm not the lawmaker in any country.

Oposite, writing that I consider something *not* to be derived (even though legally it may be) will also not change the meaning of derived work. It migth however be interpreted as a permission from me to do so. (In other words I say: "I don't consider loadable modules derived from my work", the court may hear that as: "I permit loadable modules with other licenses")

Yes, it's sometimes unclear what exactly constitutes a "derived work", this is however fully a unclarity in the law, and nothing that *any* license can change.

Single-company free software

Posted Oct 13, 2005 15:24 UTC (Thu) by lutchann (subscriber, #8872) [Link]

Thank you, that is a much better explanation regarding the binary module debate than I could have managed. This particular area of confusion effectively illustrates why we desparately need more case law to shape the legal framework we've created for open source development. As you've pointed out, these issues arise not just from ambiguities in the GPL, but from ambiguities in copyright law that affect us more than commercial developers who rely instead on contract law to enforce their software licenses. Again, until we see more court cases, we can't be sure about a lot of the "common knowledge" surrounding open source software.