Jacob brings up a point I haven't seen clearly expressed before -- the GPL's design directly leads to questions like these (now more than ever with Python/Ruby and Javascript), but the FSF not only does not provide clear or useful answers, there is no mechanism for arriving at decent answers.
The problem with the GPL is not really the evangelical copyleft (as annoying as those people can be), the problem is that it's too fucking complicated to deal with in real-world situations.
Yeah, that's really the nut of the problem, isn't it. Short of finding a lawyer qualified to speak to these issues -- which I can't afford -- my only other option is to simply avoid the GPL. Which sucks.
Another option is to operate in reasonably good faith, try to observe the "spirit" of the GPL, and hope that you will not be the target of legal action.
I don't really like that solution either (it kind of defeats the purpose of having a legally binding license), but it's the current solution silently adopted by a lot of people interoperating with GPLed code using any of the techniques described in your article.
In a world where technology advances an order of magnitude faster than legal theory, it's just going to be a fact of life for a long time that there are many technological questions that have no clearcut legal answers.
> Another option is to operate in reasonably good faith, try to observe the "spirit" of the GPL, and hope that you will not be the target of legal action.
And talk with the copyright holder of the software you're using! It's a good idea in any case, and will probably go a long ways towards getting an idea of what they're comfortable with, and what they think their rights are under that license.
If we're going to go with "spirit", why not use the less restrictive license without the potentially scary legal ramifications for large company X? That is, can you tell me why:
-- Here's this GPL licensed code. Go ahead and use it, and so long as you keep with the "spirit" of open source, I won't bother suing you. When I die, however, and the executors of my estate notice that they now control copyright on this GPL'd code that you might have used to grow your multi-billion dollar company...all bets are off.
...is better than:
-- Here's this BSD licensed code. I'm not going to require anything of you to use it, but I expect you to keep with the "spirit" of open source and contribute back to the community. If you don't I have no legal means to force your hand, but if you die and haven't contributed back, your fork dies with you.
Like I said, talk with the person/people/org, and understand their situation. I've talked with some people who are real GPL zealots, who are really not interested in the idea of proprietary software at all, and you can take their code as is, or leave it. Others are willing to work with you when they see some potential advantages to a more liberal license. A lot of people, probably the majority, just don't want to feel "ripped off", so if you're using their software, you should respect the license (it's not that hard with the GPL) both in the spirit (which may vary from person to person) and in the letter, and see if there's a way to come to an agreement if things don't quite match. And sometimes people in this latter category don't understand the GPL well either, so talking with them is likely to smooth things over in any case, if what you're using is something important to your business.
And consider that in the worst case, you're no worse off than if you encountered a proprietary-licensed library that was too expensive for you to use.
I've found that most of the fear comes from the misconception that the GPL could force your code open against your wishes. In the US, that's simply not possible.
I've found it helpful to clear up that misconception, point to past infractions / events, and try to humanize the free software community. In most cases, there isn't a litigious company lurking in the shadows, and a show of good faith will go a long way. It's also quite useful to direct attention to high profile products that are safely using and modifying GPL'd code, like the Kindle.
I've never thought the fear was that proprietary code would be forced to have its source opened. I was under the impression that the fear for large companies has more to do with injunctions on sale and/or distribution as a result of license violation. Try to tell Microsoft that they can't sell Windows for the next week and see what they think of that...
Both are very real concerns; the CTO of our division, representing a large chunk of a 50,000 person organization, was certainly very concerned about the chance that things would be forced open.
The problem is not just the case where a company does get hit with a lawsuit if it should violate the GPL as it might nebulously apply to myriad situations.
It is the very possibility of such an event that will scare away those who might otherwise fund your company or who might otherwise acquire it.
I know. I deal with funding rounds and M&A very frequently in real-world situations. Believe me, if the GPL pops up in due diligence, general panic ensues unless it involves only some incidental use that can be worked around or it involves a very clear-cut case of how the license applies.
As an entrepreneur, you can lose and lose badly in such situations even where no lawsuit is ever filed.
Nice troll; too bad that's all it is. I mean, damn all those BSD/MIT/Apache 2.0/etc licensed products, which comprise the bulk of the Python software and library ecosystem.
The FSF provides an opinion on some of these questions, unfortunately their opinion, that any import or dynamic linking triggers the GPL, a) has never been tested in court, ever (unlike for static linking), and b) is often not matched by the users of the GPL, such as the famed disagreement between RMS and Linus Torvalds with regard to whether Linux in it's current form complies with the GPL.
Ok, but if you're not going to take their word for what is and isn't covered by the license, then I think the only possible answer is to get a good IP lawyer.
The complexity is a feature. Simply put: if you want to work in the open, noncommercially, with maximal sharing, use something other than GPL. If you ever intend to commercialize your work, use GPL.
GPL's complexities are a problem for downstream developers, not for the author. That's essentially what you want if you're doing the Open Source / Commercial dual license play.
The complexity is a feature. Simply put: if you want to work in the open, noncommercially, with maximal sharing, use something other than GPL. If you ever intend to commercialize your work, use GPL.
I disagree. All of my work is under the GPL, not out of any concern with commercial use, but to ensure that any users have the same rights to the code as I do. The complexity of the GPL is undesirable and unwanted, though currently necessary.
I used to use the BSD license for my personal projects, under the reasoning that having the source "somewhere out there" would be enough. Then somebody modified my work and passed it on to users without the source. It was a very minor project, and there was no legitimate reason why he couldn't have provided the modified source to his users. After he stopped supporting it, the whole mess was dumped in my lap, with several miserable people wondering why I couldn't help support their "BSD-licensed" software.
The fundamental difference between the BSD/MIT and GPL modes of thought is in whose rights are more important, the developer or the user.
Exactly. If you go down this road, you want big companies to be scared of potential liability. Then you offer to grant them a traditional software license for a traditional sum of money, just like they're used to, and everyone goes home happy.
I think that the GPL is not the problem. Intelectual property is the source of the problem. The GPL is a hack to make the system work in a way it was not thought to work.
It's not that complicated for lawyers - i am certain most M&A ends up being more convoluted. It's just that no-one has really tried this in court -- that's really the pain point. Till then it's just a bit of paper that everyone freaks out over because there are so many unanswered questions.
Jacob: the question you were missing:
"What happens if a Judge finds the GPL unenforceable?"
Nice list of questions...I've used GPL'd software extensively, read numerous discussions about the license, and read the GPL several times through, and am still uncertain (or at least uncomfortable) about the answer to most of these questions.
Greg Vetter, a former law professor of mine at the University of Houston, has written about the pitfalls of 'infectious' open source licenses such as the GPL. I highly recommend taking a look at his paper on the topic:
Ambiguities in copyright precedent about what actually constitutes a derivative work will continue to vex the GPL for some time. The unfortunate truth is that there are no clear legal answers to many of these questions -- and that's kind of the point that Jacob is making in asking them in the first place.
"Ambiguities in copyright precedent about what actually constitutes a derivative work will continue to vex the GPL for some time."
That itself is a problem that basically stems from this question: What is the legal definition of "one program"?
If that's too hard, what is the technical definition of "one program"?
I can't answer that. I've thought about it a lot, and it's just unanswerable.
You can only construct one if you make some very limiting assumptions. The GPL itself does a decent job of clearly delimiting its boundaries, but only if you are in a pure-C environment. If you actually read the license, it is basically only applicable to such programs, despite its widespread use outside of that language. Even GPLing an emacs lisp module (staying entirely within the FSF's direct interests) is somewhat dubious.
> Fortunately there are no ambiguities anywhere else in the law, which is why all civil lawsuits are decided in 10mins by a secretary and an intern
Unlike a simple civil contract dispute, for example, where the ambiguity usually lies in the terms of the agreement between the parties, what I'm referring to is the ambiguity inherent in the federal case law precedent surrounding derivative works -- let me explain.
Derivative works, as defined by the Copyright Act of 1976, are those "based upon one or more preexisting works" that have been recast, transformed, and/or adapted from their original form. [1] Specifically, there is differing authority as to the requisite level of originality required for a derivative work. For example, in Gracen v. Bradford Exchange, Judge Posner held that a "derivative work must be substantially different from the underlying work to be copyrightable." [2] Compare this approach with that of the second circuit in Alfred Bell & Co. v. Catalda Fine Arts, Inc., which rejected any novelty requirement, holding that a "distinguishable variation" of the original work would suffice to trigger copyright for a derivative work based on public domain sources. [3]
The required amount of originality has produced a circuit level split in cases involving the infringement of the exclusive right to prepare derivative works. Particularly, pictures taken from lawfully purchased books and mounted to a tile were considered, by the ninth circuit, a "recast or transform[ation of] the individual images" sufficient to infringe the original artist’s section 106(2) right. [4] The seventh circuit, in a strongly worded opinion by Judge Easterbrook, rejected this approach finding that the pictures were merely "bonded to a slab of ceramic ... [and] not changed in the process." [5] Easterbrook opined that the seventh circuit’s inclusive view of derivative works would create an expansive moral rights regime not explicitly authorized in the 1976 Act. [6]
In other words, until the Supreme Court rules definitively and resolves the circuit split, the threshold of originality necessary for a derivative work depends on the precedent your jurisdiction follows. Hence why it's more ambiguous than is typical of other topics in federal law.
[3] Alfred Bell & Co. v. Catalda Fine Arts, Inc., 191 F.2d 99, 102 (2d Cir. 1951) ("It is clear, then, that nothing in the Constitution commands that copyrighted matter be strikingly unique or novel. Accordingly, we were not ignoring the Constitution when we stated that a 'copy of something in the public domain' will support a copyright if it is a 'distinguishable variation' ").
[5] Lee v. A.R.T. Co., 125 F.3d 580, 582 (7th Cir. 1997).
[6] See id. at 582. Easterbrook observed: "If Lee (and the ninth circuit) are right about what counts as a derivative work, then the United States has established through the back door an extraordinarily broad version of authors’ moral rights, under which artists may block any modification of their works of which they disapprove. No European version of droit moral goes this far."
It's universal that you can't both have and eat the cake. 99% of problems with GPL arise from the fact that companies and individuals want exactly that.
GPL is more indifferent to many real-world aspects than people assume it is.
It is an idealistic license and it only cares about the right to use the program and the availability of source code, to ensure free use and reuse of the program. This ideal is rather neutral towards any commercial and business aspects: it only conflicts with some of the established practices and beliefs of the current business world.
GPL does not intend to compete or lock-out other software while that may indeed happen if you're playing a different game and holding tightly on to contradicting views of what you think is important.
In reality, there are no other limitations in GPL than that effectively no single author or distributor can't enforce control over or killing the software.
For companies, there are two possible outcomes:
1) secrecy of the company source code is more valuable. Conclusion: there's no rational reason to even consider incorporating GPL code in the company. What's the problem?
2) benefits from reusing GPL'ed software is more valuable. Conclusion: GPL your stuff as well to gain the benefits and avoid any legal problems. What's the problem?
Otherwise the company is holding on to the belief that they can have and eat the cake, and effectively just wasting their own time.
This would be a much more interesting article if the author had at least tried to get answers to his questions (perhaps from the GNU foundation or the Software Freedom Law Center, etc) and included that with his questions. That would have been an interesting article, and possibly useful to hackers and software entrepreneurs.
As it is, I'm surprised and disappointed that an article with so little substance has made it so high on the HN front page.
Just because "this is broken" wasn't followed by "...and here's how to fix it" doesn't mean that pointing out the initial flaw was without merit or substance. Still, I too wish someone at a qualified institution (FSF, SFLC, etc) would weigh in.
Yes, it would be more interesting. These questions may very well shed light on ambiguities in GPLv3. If so, then I imagine that the FSF would want to take this into consideration for GPLv4.
No, he's being downmodded for suggesting that the author should have to contact one particular organization to get answers to simple questions about something as widely used and discussed as the GPL.
Then he's being downmodded unjustly, as he listed two specific organizations, included an "etc." in his list of organizations, and prefaced the entire list with a "perhaps".
Regardless of where the answers to these questions come from, it would be good to share the confusion with the FSF, in hopes that they can remedy it. I do not believe their goal is to inflict confusing licenses upon the general public, but they do have rather specific goals and attempt to address those goals in their licenses.
Well, there's no such thing as the GNU Foundation (there's the Free Software Foundation and the GNU Project), so technically there's only one. :)
Assuming that he meant Free Software Foundation, his mention of The Free Software Law Center invalidates my point, though, because clearly they're not closely tied to the Free Software Foundation. Otherwise, they wouldn't say "Open Source" on their home page without going into a diatribe about the term.
The real answer is, if someone distributes a Python module in GPL (as opposed to LGPL or other more liberal license), they clearly are either A) stupid/ignorant of the issues surrounding open source licensing, or B) don't want anyone to use their code who isn't also going to go whole-hog down the GPL rabbit hole.
In real life, any useful plugin/loadable lib/module/etc that is intended to be used in a non-academic/research/bits-want-to-be-free-like-speech-and-beer environment is not going to be released exclusively under the GPL.
The GPL is ultimately about ideology, not software. Note all the comments by GPL-boosters demanding to know what kind of unsavory license-bending the poster really wants to engage in due to his asking a few simple questions with a distressing lack of clear answers.
Quick attempt to answer these based on my understanding of the GPL, and just a quick cursory skim of version 3. I am not a lawyer.
[Edit: It seems like my answers to the first few are a bit contentious and should really be "it depends"; see comments below.]
1. Yes, by using foo.py as a library, your bar.py must also be GPL'd. This would be different were foo.py under the Lesser GPL.
2. Not shipping foo.py does not change the answer to #1; you still depend on it, thus your work still counts as a derivative.
3. Not depending on foo.py, but using it if available does not change the answer to #1. Once your code makes use of the GPL'd library, it must also be GPL'd.
4. Yes, calling GPL'd libfoo.so via Ruby/DL requires that your code be GPL'd; the full GPL does not have library exceptions like the LGPL.
5. Separate distribution does not change the above.
6. GPL'd foo.js and proprietary bar.js can be combined into a single foobar.js and retain their respective licenses, so long as they are functionally independent. "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate." (Last line of Section 5 of GPLv3)
7. I'm not sure of the specifics of XUL, but I'd imagine depending on a GPL'd .js file and including that in the XUL app would indeed create a derivative work, and require the XUL app to be GPL'd.
9. Unsure, but I'm learning towards distribution to a fully-owned subsidiary still counting as conveyance to an outside entity, and thus triggering the GPL. If they're different entities to the IRS, they're probably different entities to the FSF.
10. Conveyance to a majority-owned subsidiary seems like conveyance to an outside entity, and would thus trigger the GPL.
11. Price isn't a factor; the applicability of the GPL is wholly determined by the distribution counting (or not counting) as "conveyance" to an outside party.
12. As per the FSF's FAQ, conveying the work to a contractor for use off site does trigger the GPL.
13. The mechanism matters. If Jane uses the software off-site or is able to make or receive copies, then it would trigger the GPL.
14. Giving the modified Foo.exe to consultants does trigger the GPL, as per the FSF FAQ above.
15. Using a company-owned terminal with company-modified GPL app does not count as conveyance, and does not trigger the GPL.
16. Allowing outside parties to download the modified Foo.exe, even though they are on-site, does trigger the GPL; consider it akin to purchasing software from a brick and mortar point of distribution. Where you received it doesn't matter, it's the fact that you can take it home.
17. The Job Applicant is not yet an employee of Initech; if they receive the modified Foo.exe, it's been conveyed to an outside entity, and thus triggers the GPL. The means of conveyance are not important.
18. Making the modified Foo.exe freely available on a public web server clearly triggers the GPL's conveyance clause.
19. Password protecting the download of Foo.exe does not matter if an outside entity can legitimately receive it; it's still conveyance.
20. My shot at a basic principle for laypeople: "If you can walk away with the application in any form, it is conveyance."
Bonus: Jacob shouldn't have these problems since he's a Django developer; "Mere interaction with a user through a computer network, with no transfer of a copy, if not conveying." Make the Django site live in a well defined place, and make all the interaction happen in the browser. Congratulations, you've used the software-as-a-service loophole.
> 2. Not shipping foo.py does not change the answer to #1; you still depend on it, thus your work still counts as a derivative.
I don't know whether your answers are correct but you should not use the term "derivative" or "derivative work". It's a rather clear legal term. The GPL3 does not use that term, anymore.
In fact, if we would be arguing about a derivative work in the copyright sense, your answer to 2 and 3 (and depending on the circumstances also 1) would be wrong (with the usual disclaimer IANAL).
A software B that uses a library A by "loose" linking does not constitute a derivative work. Courts in the US have develop a test for that: First, B is a complement to A. Second, it doesn't distribute any of A's code when distributing B. Third, thinking otherwise would chill the market, since no library would be used by anyone anymore, for this would make using a library an infringement of the library owner's copyright.
You answer the first 3 questions quite definitively, however I spoke with the Software Freedom Law Center just this past week about these same questions and was told the answer to all of them was "maybe" as this has never been tested in court.
I'd love to gain a better understanding of these matters; did the SFLC cite any scenarios where those first three would tip the other way? That was really an attempt to lay out my understanding of the situation, not provide definitive answers. Any corrections or refinements you can provide would be awesome. Sorry if I sounded a bit more confident than warranted.
I'm mainly basing my response to the top 3 on what I recall of the readline debate, and the personal idea if those worked any other way, there wouldn't be much of a reason for the LGPL to be around. Or at least, I think the answers to #2 and #3 are clearly defined for an LGPL'd foo.py.
Do you mean that if you call any function which is part of a GPL'd library then consequentially your work is a derivative. Going by that logic can anything running on Linux be a non-GPL'd commercial product ?! I am really confused right now !
Not quite -- the GPL makes exceptions for that in Section 1: "However, [the "Corresponding Source"] does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in [generating, installing, running, or modifying the work] but which are not part of the work."
Basically, system stuff is exempt.
But you're right to be confused. If bright, prominent developers like jacobian and jnoller can't definitively answer these questions, then there's a problem with the implementation of either the GPL or the US legal system. After all, if the developers themselves can't fully grok the GPL, then who is it for?
I'm not sure why this was voted down; here's the relevant text:
NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".
I voted it down because it was so ming-bogglingly stupid that I yelled and spun around in my chair! I briefly considered unsubscribing from your blog before I calmed down.
The note in COPYING is just to allay FUD, it's not actually necessary and certainly isn't a GPL exception.
For starters, nearly all programs (by volume) making syscalls don't use any specific to Linux -- there's no way it's derivative if it runs fine on another kernel. Furthermore, responding to syscalls is what Linux is FOR in 'normal use' -- not even the FSF is jackass enough to claim that bash scripts are derivative works, even if they are riddled with bash-isms.
These questions are interesting with regards to the Goldman Sachs proprietary code that was stolen recently. It seems likely (dare I say inevitable) that some part of GS's infrastructure (just like everybody else's) links GPL'd libraries. When part of the program gets "released" to e.g. an enterprising employee, the FBI, and (possibly) to the general public (as it possibly will), does this force GS to release other code as well?
GNU Readline is a GPL library controlled by the FSF, that implements basic interactive line editing. For a long time it was more or less the only one. RMS believes that if you link with it in any way, even as a compile-time default-off option, your product must be GPL: http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/...
As a result, for years and years, non-GPL (not just closed-source, BSD too) programs on Unix systems had shitty user-hostile REPLs. In large part, they still do.
A programming language implementation is not a derivative work of an optional command-line editing library in my world, but it is in RMS's.
You're glossing over some of the complexities of this rather interesting situation.
In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline, and you had to enable it for the program to work. A similar issue is with two-part programs; one part non-GPL, one part GPL, which are left up to the user to link himself.
What matters is not what RMS says (nobody cares about RMS), but what the lawyers say. Apparently, the law is extremely harsh on this sort of "hack", which may seem fine to a programmer, but to a judge will be seen as an obvious attempt to work around the terms of the license and will be greatly punished.
In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline
That's not true. If you read the story you'll see that the guy had a working program for years before he used readline. The use of readline only improved an already working program. Not to mention, the program in question was a language implementation and readline had nothing to do with it. It was a user interface perk.
At one point he said he'd distribute a working program without readline or readline support even enabled by default and leave it up to the user to configure it. It was only going to have an interface to readline without including any readline code. He was told he couldn't even do that.
In the end he chose to GPL the entire language implementation. To him, it probably didn't make a difference what the license was and it was easier than replacing readline. Personally, I would have replaced it with a BSD-licensed alternative just out of spite given the way the whole thing was approached. The line about how a judge wouldn't be convinced the program didn't violate the GPL read like a thinly veiled threat to me.
At one point he said he'd distribute a working program without readline or readline support even enabled by default and leave it up to the user to configure it. It was only going to have an interface to readline without including any readline code. He was told he couldn't even do that.
Then RMS was wrong. The SFLC says you're quite allowed to do that, a classic example being ffmpeg, which can be LGPL, GPL, or even non-redistributable depending on what external libraries you link it to on compile-time.
People have to learn that RMS is not God and that just because he says something about the GPL doesn't mean that the lawyers agree.
What if there was a proof-of-concept of a forthcoming replacement for the GPL'd part, and it happened to be vaporware? I'm not too familiar with all of this.
The farther you get into the gray area, the less of a clear answer you can get, because it becomes more than anything else an issue of which way the judge rules. This is why generally it's a good idea to err on the side of caution with any type of software license.
I think that particular area is ripe for further exploration. Especially in the context of Jacob's second and third questions:
Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function? Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?
If GPL foo.py is the only library that can fill that void, then sure, once your app runs a code path that takes it through foo.py, it's a derivative work. But what something else could fill that void?
For instance, what would happen if Editline exposed a Readline compatibility layer?
This is actually a very practical question, as IIRC Editline was readline compatible on some levels.
What follows is all my hazy recollection.
If memory serves, the answer was this, although obviously if you ask RMS you get slightly different answers depending: you have to GPL your code (if you distribute it) if you link to GPL code. If you can plausibly link to several different libraries, not all of which are GPL, you don't. So when readline was alone in the world, everything that used it had to be GPL. The BSD folks wrote editline specifically to avoid this--initially, editline was extremely lame compared to readline and I think might still be, but because the API was equivalent they could say "We're BSD licensed through and through; use our code for anything you want" and still have a non-horrible CLI and yet at link time decide to use the good library.
I think the reason this works legally, although I'm not a lawyer, is because yes, when you link your program with readline that executable cannot be distributed except under the terms of the GPL. Because you have multiple potential targets for this sort of thing, nobody can argue that you are trying to technically evade the requirements.
editline is intended to be API compatible, and has weakened the argument that linking implies work-derivation at least somewhat. As far as I know, nobody has ever been willing to test that theory in court since they'd lose so much political face in the process.
Sometime last year, I saw an article claiming that because of libedit's existence, we could all link against readline from whatever we wanted (or at least that this showed that the dynamic-linking-is-deriving was crap), but I can't find the article now.
Using Readline with mzscheme was the first time I, as a user was made aware of the inconvenience of the GPL. It figures, LISP always shows how everything else is flawed.
Well, sorry, but apparently I'm not as smart as you; even reading carefully I can't see the answer to whether a dynamic language import/require/load/whatever counts as a derivative work.
> Total FUD. If you don't like the license, don't use it.
See, that's my point exactly. I'd like to use GPL'd code, and I'd like to help my clients do the same. But since I can't get good answers to questions like these, I have to simply avoid GPL'd code like the plague. And that leaves a very bad taste in my mouth.
The text of the license is smaller than that blog post. And, yes, it contains answers to all the posted questions
The author is pointing out that the text is ambiguous. So yes, although it's shorter, it may not indeed contain all the answers. We can argue whether the poster is correct and whether there are ambiguities in the GPL, but your argument doesn't address the question.
I don't know the answers to those questions and I'd be surprised if anyone could answer all of them with certainty.
Good point, the GPLv2 was very clear. The GPLv3 left me scratching my head about why, exactly, libraries, interfaces, object code, etc., were all enumerated separately, mangling the section about derivation into legalese that is very difficult to decipher.
During the GPLv3 drafting process, we joked that GPLv2 became perfect only once GPLv3 was published. I have to agree. I've been dealing with these issues since 1997 or so for companies big and small, and the gpl keeps things...interesting.
Its funny ,one of the reasons we mostly release using the permissive licenses (apache 2 and sometimes bsd and mit) is that they are both usable by both commerical and gpl'd software but also because the added administrative overhead (policing use, etc) that is introduced by releasing software under the GPL isn't necessarily worth the patches you might force out of those that might use your code.
Because corporations were using these to circumvent the GPL.
Think of it as an evolutionary process, as the attempts to use the code released under the GPL while violating the spirit of the GPL increased in sophistication the GPL evolved to counter those abuses. This made it longer (bugfixes!).
The problem with the GPL is not really the evangelical copyleft (as annoying as those people can be), the problem is that it's too fucking complicated to deal with in real-world situations.