Slashdot Mirror
Misconceptions About the GPL
lisah writes "Misconceptions about the widely used GNU General Public License (GPL) continue to plague the free software user community and, according to the ITManagersJournal, 'the confusion is frequently based on misreadings, rumors, secondhand accounts, and what is convenient to believe.' In order to clarify some of the more common misunderstandings about the GPL, Bruce Byfield consulted with three experts: attorney Richard Fontana, one of the main drafters of the third version of the license; Harald Welte of the GPL-Violations project; and David Turner who is assisting with revisions of the license. Together, they help clarify the distributor's role in providing source code to customers, whether GPL is viral or unenforceable, and why some misunderstandings are really rooted in varied interpretations of the law." ITMJ and Slashdot are both owned by OSTG.
"I am giving up my freedoms as a developer"
Consider the case that you are creating a tool and your goal is to ensure its always available as a service to the community. The way I understand it, the GPL can ensure that works based on your source will still always meet your goal. So look at it more as continuing to be true to your intent, if your intent is openness.
Here's the text of the actual license.
http://www.gnu.org/copyleft/gpl.html
No. The GPL applies on redistribution, not on distribution. The GPL puts no requirements or restrictions on the copyright holder whatsoever.
Incorporating BSD-licensed software could put you in violation if you remove the copyrights, or GZIP if you claim you wrote it (as Winzip used to do), or commercial software that you have source code to.
Fact is, it isn't the GPL that's restricting anyone doing anything. Copyright law already has these restrictions. The GPL gives you license to do things you otherwise wouldn't have a right to do.
But as I mentioned, it doesn't enter into effect at all unless you're redistributing someone elses code that is GPL licensed.
Not in theory. It has no effect whatsoever on the distribution of your own application. It only has an effect when you want to redistribute code that you aren't the copyright holder to.
Guess what: you don't have the right to redistribute other people's code. The GPL had nothing to do with this.
That's absolutely correct, but guess what: His secret recipe, as valuable as it is, was done on the backs of others. If he can build his secret recipe without stealing from other people, then he's welcome to.
You can do this with GPL software as well. MySQL (among other people) offer licenses for their software that gives you additional redistribution abilities.
But note, at no point here, did the GPL take away any of your rights as the copyright holder, or any of your rights as a redistributer. All the GPL does is give you rights, and only in certain circumstances.
The GPL is not a restriction on code use, it is a restriction on code distribution. You don't lose the rights to your code simply because it invokes or uses another library.
For example, dynamically linking to a GPLed library does not taint your code -- that is a separate piece of software that you code uses. On the other hand, if you distribute the GPLed library, you better also distribute the source code to it.
There is no question what the GPL says if you listen to RMS in the new documentary "Alternative Freedom"! He is not only the inspiration for the title, but also the most direct and to-the-point interview in the documentary.
Check out: http://alternativefreedom.org/
Documentary also features Lawrence Lessig, Danger Mouse (of Gnarls Barkey), and others...
There's no paradox. Software with unrestricted freedom will always remain free, just as software under the GPL will. If Johnny uses libfoo in his closed-source project, this does not prohibit anyone else from using libfoo, improving upon it, and possibly even releasing changes. The original code is still available, even if Johnny keeps the parts of the code that he wrote himself closed.
One question I've wondered about the GPL. If I write a program that links to a shared library that is GPL'd, do I need to GPL my application as well?
There are two schools of thought on this, and the answer to your question is pretty hotly debated.
The "stricter" school of thought, unsurprisingly the one favored by the FSF, is that statically or dynamically linking an executable to a library forms a work which can be considered a derived work of both sets of code. Under this theory, your application's source code doesn't have to be GPL, but its license does have to be compatible with the GPL since the linked work (app + library) taken as a whole is in part derived from the library and hence must be under the GPL. For instance, your app's source code could be licensed as LGPL or two-clause BSD in this situation with no problem, but could not be (for instance) CDDL or 4-clause BSD. Most Linux distributions follow this stricter, more conservative view.
On the other hand, it has been pointed out that this strict interpretation can sometimes lead to a peculiar conclusion. Suppose a work-alike copy of a GPL library is written from scratch and licensed permissively. Then a program linked against the GPL lib could also be used with the permissive library that forms a drop-in replacement. The strict theory of linking then implies that the license of your application is GPL if the GPL library is on your system, but not if the replacement library is instead. If this is not an acceptable conclusion, then it must be that dynamic linking against a GPL library does not make the application be under GPL as well.
This looser interpretation effectively defangs the GPL and makes it essentially equivalent to the LGPL, because anyone could change GPL'ed code they want to use into a shared library, then link their proprietary application against it.
Note that the interpretations differ only in the case of dynamic linking. When an application is linked statically against a GPL library, parts of the library object code end up in the compiled executable and therefore this is indisputably a derived work of both application code and library, hence under GPL. Proponents of the strict interpretation point out that from an end-user's viewpoint, there is no difference between static and dynamic linking other than the "-static" flag given to the linker, so the two methods of linking should not be legally distinguished either.
To the best of my knowledge (IANAL) there isn't any legal precedent favoring either interpretation.
- Kevin B. McCarty
While dynamic linking to DLL's doesn't.
No, dynamic linking counts, too. Both static and dynamic linking are considered creating a "derivative work". (The only exception is that the GPL allows linking if the library is something that is standard; e.g., distributed with an OS. So GPL'd Windows apps don't need to worry about linking to all the non-GPL DLLs that ship with Windows.)
You have to decide or research the answer to this question (which is a question about copyright, not the GPL): does calling other software's functions, cause the caller to be a derived work?
If your lawyer says Yes, then yes, your app that calls OpenSSL is a derived work of OpenSSL and you are subject to its terms. The good news is that every single application that runs on MS Windows and MacOS (assuming the app does any I/O or allocates any memory) are derived works of those OSes, so you're still at a tremendous advantage. Almost the whole software industry is about to go out of business while tied up in courts for the next few decades, and all you have to worry about is pleasing the OpenSSL guys. You've got it made. On the other hand, you're at a disadvantage because you have a dumb lawyer who told you something utterly preposterous.
If your lawyer says No, calling a function does not cause the caller to be a derived work, then OpenSSL's license is irrelevant because you're not bound by it. It doesn't matter whether or not OpenSSL says you have to release your code under GPL, because -- who asked them? You're not trying to do anything that causes you to want to get any sort of permission from them.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Absolutely not.
It requires the person you hire to change the code, to give you the code.
You never, under any circumstances have to give changes back to the original project or for that matter, anyone that didnt recieve the binary. The only person that the binary was distributed to was me, which means I must also recieve the code changed code. Obligation met.
If there is only one person the modification is "distributed" to, there is only one person that code must be given to.
The phrase "more better" is acceptable English. suck it grammar Nazis
I resent the notion that I'm simply trying to "steal just a little bit". My point, which you obviously missed, remains that you either have to subscribe to it 100% to participate in any way.
Your feelings of resentment aside, the idea that you would use code that, I wrote in a way that I don't intend is wrong. Stealing is a loaded word, but it sure is freeloading.
If I take a piece of code, make it better, return that change to the OSS community, I still can't use it in my software without make it GPL as well. So now that leaves ME at a disadvantage because there is no proportionality to the give and take. Because of that, I just avoid that game all together. At least the LGPL offers a more reasonable solution, in that sense. Sadly, it has the stigma of GPL with it. This ALL or NONE of GPL makes it more cult-like than many are comfortable with.
If that's what the original creator intended, then they (the author) and you have two choices.
The first choice is that the original author may use another license than the GPL. If it's software where they want this sort of arangement, they might use the Lesser General Public License (the LGPL), which is designed exactly for the sort of thing you're pointing out.
Or, if this is really important to you, you could go to the developer and propose to make you a special licensed version of the program, just for you. I'm a Free Software developer (though not a prolific one) and if you said you wanted to use my code in a proprietary project, but that you agreed to improve anything directly related to it, I'm sure you and I could come to an arangement that would involve this contract in writing and compensation (which would allow me to write more Free Software).
I can't speak for everyone, but I think many folks would find this aragement acceptable.
The fact that the "myths" are trying to be discounted shows that the GPL community wants to go mainstream, but like a certain political party, it feels that the idea of bringing the two groups together is for the other side to simply join them where they stand.
Without getting too much into actual politics here, compromise is one way of trying to gain acceptance of an idea. The other is to hold one's ground and wait for people to come around to your ideas. If you look at how much ground the Free Software community has gained in the last 20 years, I think it's hard to deny that this method, though slow, is working.
It's very easy to make a clear statement about GPL virality, so I really don't understand why the interviewees didn't take the opportunity to do so. Here's my off-the-cuff attempt at an explanation:
Unfortunately, a nice simple summary like that doesn't carry the whole truth.
The problem is that the derivation of programs carries a double semantic under the GPL, and this is the source of endless debate and discontent because it is partly inappropriate in a distribution license.
One of the two meanings of derivation relates to physical modification of the original GPL source code to create a new ("derived") work through the process of code extension. By any rational assessment, this is a self-evidently fair provision, in that if you take someone else's source code and modify it in some way, then your new program is derived by ancestry. and thus quite reasonably should inherit the license of its progenitor.
In contrast, the other meaning relates quite illogically to *using* GPL'd library code through linking to it, despite having made no modification whatsoever to that GPL'd code. This could make sense in a usage license (which the GPL is not, in theory), but it is quite out of place in a license dedicated to protecting the availability of the original source code and any modified versions thereof. That semantic is clearly in the license "for other reasons".
Remember the discredited attempt by some content providers a few years ago to equate web links and the content to which they point as being one and the same thing? We "obviously" knew that that was ridiculous at the time, yet the GPL tries to claim that linking for usage is the same thing as copying the source for derivation by extension. It's "obvious" that this is incorrect, and that therefore the client application should not become affected virally. There is no derivation by ancestry, so by what mechanism is the license inherited? Well the answer is that it's not inherited --- instead the new, non-derived client code has been tainted by usage.
This second semantic has no business being in the license at all, because consistency would then require us to taint everything else that comes into contact with GPL code through simple USAGE, and that includes web applications. Usage is usage, you can't make arbitrary exceptions to it without totally undermining your platform of logic.
It's quite a mess. Maybe we need a good chat with Eben Moglen; I think he'd understand the problems inherent in tainting by usage very clearly.
So you see, those 3 paragraphs don't really tell the whole story. Still, they certainly define GPL virality a lot better than the article did.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
The biggest problem I've seen with GPL is that static linking your (completely NON GPL) code with a GPL library seems to make the entire program subject to the GPL. While dynamic linking to DLL's doesn't.
Wrong. Copyright law does not make any distinction between static and dynamic linking. Neither does the GPL. The LGPL specifically allows *dynamic* linking, where as static linking is only allowed when the object files are distributed so that the user can re-link with a different version (basically doing the same thing manually as dynamic linking does automatically).
So, does linking (remember: no distinction between static and dynamic) create a derivative work? In the end, that's for lawyers and judges to argue about, but a reasonable (IMHO) way of seeing it is: Does the program (all of it) work without the library? If yes, it's not derived. If no, it must be derived, if the library did not exist, the program would be different. Putting an if() around the part that uses the dynamic library is not enough, the part inside the if() block is still derived. If the library did not exist, the if() block would not exist either.
On the other hand, if two different libraries with the same ABI exist, one of them being GPL, and the other BSD, your program is probably not derived from the GPL one. Just make sure you distribute it with the BSD version.