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.
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.
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.
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.
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.
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.
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 !
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.
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.
[+] [-] blasdel|16 years ago|reply
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.
[+] [-] jacobian|16 years ago|reply
[+] [-] kingkilr|16 years ago|reply
[+] [-] tptacek|16 years ago|reply
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.
[+] [-] pqs|16 years ago|reply
[+] [-] imajes|16 years ago|reply
Jacob: the question you were missing:
"What happens if a Judge finds the GPL unenforceable?"
That's the big elephant in the room.
[+] [-] flatline|16 years ago|reply
[+] [-] jbronn|16 years ago|reply
http://ssrn.com/abstract=585922
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.
[+] [-] jerf|16 years ago|reply
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.
And the general case is just absurd.
[+] [-] jojhbugbt|16 years ago|reply
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
[+] [-] yason|16 years ago|reply
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.
[+] [-] theBobMcCormick|16 years ago|reply
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.
[+] [-] callahad|16 years ago|reply
[+] [-] tjr|16 years ago|reply
[+] [-] eli|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] danbmil99|16 years ago|reply
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.
[+] [-] Semiapies|16 years ago|reply
[+] [-] callahad|16 years ago|reply
[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.
8. Sharing modified versions between internal teams does not count as conveyance, so long as those teams are within the same business entity. See http://www.fsf.org/licensing/licenses/gpl-faq.html#InternalD...
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.
[+] [-] cschwarm|16 years ago|reply
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.
For further information, see:
http://www.law.washington.edu/lct/swp/Law/derivative.html
[+] [-] kingkilr|16 years ago|reply
[+] [-] callahad|16 years ago|reply
[+] [-] vinutheraj|16 years ago|reply
[+] [-] caffeine|16 years ago|reply
[+] [-] asciilifeform|16 years ago|reply
A) has anything at all to fear from the GPL, and
B) isn't a (would-be) parasite. See this as an example: http://news.ycombinator.org/item?id=610764
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] blasdel|16 years ago|reply
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.
[+] [-] jacobian|16 years ago|reply
> 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.
[+] [-] alain94040|16 years ago|reply
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.
[+] [-] flatline|16 years ago|reply
[+] [-] riferguson|16 years ago|reply
Care to try again?
[+] [-] mncaudill|16 years ago|reply