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'll tell you what misconception annoys me the most. It's the idea that you need to agree to the GPL in order to use the software. I find it highly irritating to be asked to click-through a EULA window containing the GPL when I install a piece of software. The GPL is not a EULA, and you don't really have to agree to the GPL if you only intend to use the software. The GPL gives you rights to modify and redistribute the software; if you don't agree to the GPL, there is nothing else that would give you such rights. The right to use the software is implicit in the fact that it was legally distributed to you.
1. The GPL is viral
2. The GPL is unenforceable
3. You can't charge for GPL software
4. The "liberty or death" clause applies absolutely
5. Distributors only need to ship the source code they alter
6. Distributors only need to supply source code, and not the means to use it
7. Distributors don't need to provide offers of source code
8. Distributors only need to offer source code to their customers
9. Distributors only need to link to the license text
10. I don't think that word means what you think it means
Basically it says something like "Your sourcecode is to be available, penguins are to be worshipped, but are to be referred to as GNU/Penguins, and men are not to shave". If you don't care about all that, you can skip to the end, which is a good part and has Marvin in it.
Actually it doesnt go towards the end user. The GPL is totally irrelevant to the end user. Now it does matter to other developers, but in all honesty the actual user of a project could give a damn. The GPL is not a EULA, because it has no relevancy to the user of the program, but rather dictates what people that want to involve themselves in other activities such as redestribution.
A chef having to give away his recipe because he used GPL spices...worst analogy ever. Reverse it and it would be correct because a developer is not going to take a small amount of gpl code and use that, they are gonna add their small amount of code to a largely GPL base. (well atleast 99% of the developers out there).
How does the GPL force a developer that chooses it as a license to do anything. They made a decision to use it because they like it as a license, they arent forced into using anything. The people that bitch about the GPL are developers that already decided against it, and because they dont use they somehow think it is an "unfair" license (to whom i dont know since they have already chosen not to use it)
I think developers need to get this concept in their head...just because the source is available, doesnt mean you have to use it, and doesnt mean you have the right to use it either. You simply have the option to use it.
The phrase "more better" is acceptable English. suck it grammar Nazis
If you are developing your code from scratch, you are free to other versions of it under whatever license you see fit -- the GPL is a non-exclusive license, so you are free to license your creative work in other ways at the same time.
If you are trying to use someone else's GPLed code, track down that person and try to get a non-GPL license from them. Is that so hard? It's exactly what you'd have to do to get access to someone else's proprietary code, except that you get to preview the source.
If the author want to license his code to you in a non-GPL way, well, it's his creative work -- he can do what he wants. Start from scratch or find another vendor.
Actually, one line might be considered fair-use excerpting...
Seriously, if you don't want to GPL your application, just don't use any GPL code in it. Why is that so hard? Nobody whines about not being able to incorporate pieces of Microsoft Office into their code. The only difference is that you gan ogle the beautiful source code of GPL applications, so that it's more of a temptation.
You're not going to lose the rights to your software if you invoke GPL code with it. You're not going to lose the rights to your software if you use GPL code to make it (e.g. gcc and emacs don't tarnish your C code). You're only going to have to GPL your code if you actually incorporate someone else's work into it.
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.
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
In every instance I've been involved with in the past 20 years or so of professional programming, this statement is 100% wrong-- at least from the commercial angle. We've gernerally got an application that is filling a particular need and we're looking to add functionality to the already 100's of thousands to millions of lines of code we've already written. The first thing we do is look and see if anyone has already solved the problem, and if so if we can use it; if we find something and it's GPLed, we can't use it. Adding an extra 10,000 lines of GPL code written last year to our legacy system in use for the past 10 years and now suddenly our legacy app is a derivitave work of the GPL code is out of the question. Which means that we end up either looking for (or buying) an alternative if we can't work out a deal with the original copyright holders (which so far has been nigh on impossible-- we've gotten exactly one license from a GPL project that we needed to use). If that fails, we end up writing our own code, which now is by default non-free.
While I'm not disputing the quantity of GPLed software out there, I know that many of these projects are giving up help just because of the license. As an example, in one case we had determined that we'd need to allocate at least 3 people to implement a particular feature that a specific GPL project already had (mostly) working. I contacted the project "leader" and tried to negotiate a different license for the use of their project that involved a cash payment and allocation of a full time employee for a year to help bring it up to spec. We were unable to come to terms not because of any desire on their part not to, but because they used code that was also GPLed. No one was ever able to locate every one of the copyright holders to get permission and so it never went anywhere.
Don't take the above as a gripe-- whatever license you want to use is fine by me-- if I can use it I will, if not I won't, no skin off my nose either way; I'm sure I'll be able to get my job done with your product, your competitor's project, or I'll become your competitor if I need to.
rob.
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