Viral GPL Misconceptions Elegantly Explained

Scot W. Stevenson writes "Our favorite paralegal Pamela Jones of Groklaw has put together a short FUD-killer on the General Public License that explains why you can't lose your proprietary code if you inadvertently incorporate GPL code. This is not the only text of its kind, but it is so well explained that you might want to bookmark the page for future reference."

Comments

Re:Main GPL Misconceptions

[Hrothgar The Great]

The GPL is tied up with Stallman's and the FSF's free software philosophy. I'm not saying that there's anything wrong with that; just providing a possible explanation for the irony you mentioned. The GPL is designed around the idea that all software should be open source, and it does seem intended to cause more people to release more source code as time goes on. It also really seems to be effective in accomplishing this goal.

Though to tell you the truth, I never got the whole "free as in beer" thing. Beer is expensive, damn it, and when I use it up, it's all gone and I get a hangover.

The real problems with the GPL

[ikewillis]

1. The language is, in many places, ambigouous and misleading. The concept of a derived work is not explicitly defined, nor has specific attention been paid to dynamic versus static linking.
2. No definitive interpretation by a court has been made. This article is completely the interpretation of a single individual and its relevancy to a definitive interpretation within a courtroom setting is dubious at best. There exists Linus's interpretation of this matter, which would preclude the possibility of binary only kernel drivers, but shouldn't this carry over to any code which utilizes system calls in Linux? Wouldn't such code be considered a derived work and be forced to be distributed under the terms of the GPL? Consequently, it doesn't seem possible for glibc to legally be LGPL, as it utilizes the Linux system call table and is consequently a derived work of the GPL'd Linux kernel. This opens up a whole nasty can of worms...
3. The GPL has many bizarre concessions and terms, such as requiring those who distribute GPL software to distribute it by mail at anyone's request, charging only the cost of media.

Re:Linux Kernel Headers Require Programs GPLed?

[EvilTwinSkippy]

Headers are considered to be documentation for all sakes and purposes. They are intended to be an outline for external code to communicate with the major subsystems. That is why the headers are available seperately from the kernel sources.

This same system is used for proprietary binaries. They give you a pre-compiled binary or library with a set of headers for your code.

That said, the community has always looked unfavorably on binary-only drivers in the Kernel. They only tend to work for the major distros, and they also tend to lack the polish and peer review that goes into the normal bevy of OSS driver.

I for one don't understand why a vendor would only go halfway in supporting Linux. Release a patch and let the community support your device, or always be a day late and a dollar short trying to keep up with the developments in the system.

Ok. I do see one case: where the kernel "implements" a major function of the device in software. Even there a better approach exists. Simply provide the minimal communication hooks in the kernel itself, and devise a user-space program to perform the software control functions. The user space program can be as proprietary as you want, and it won't get stomped on as the kernel changes.

In brief:

[ScottSpeaks!]

A licence grants rights in only one direction; a contract grants rights (and obligations) in both directions. Because the GPL is merely a licence, those using GPL code cannot be required to give up the rights to their own code.

Re:gcc and other OO development software

[zippity8]

One thing that's made me wonder is, if I want to use gcc or another gpl compiler, would the resultant project automatically be gpl'd?

http://www.gnu.org/licenses/gpl-faq.html#IfInter pr eterIsGPL
When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.

Re:But, what about...

[cayenne8]

What if you put an application together using Open Source tools. Let's say your application uses Linux as the OS, and PostgreSQL as the database.

Now, would the database schema/design now be GPL or would it be proprietary? It isn't compiled or linked to any 'librarys'. It is just instantiated into a physical instance. So, it should not be GPL'ed should it? What about a bunch of PHP scripts you run on Apache...those aren't GPL'ed are they?