Twenty questions about the GPL
jacobian.org
jacobian.org
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.
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.
I think that's a hope that I, jacob and many others are not willing to sign up to.
Check out this article on Groklaw ("The GPL is a License, Not a Contract, Which is Why the Sky Isn't Falling") for more: http://www.groklaw.net/article.php?story=20031214210634851
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.
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.
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.
-- 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.
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.
Actually SAS licenses are simple - you are allowed to use the product to send SAS all your money, any other use is probably forbidden.
The FSF does not get to write copyright law and decide what is or is not a derivative work.
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 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.
Jacob: the question you were missing:
"What happens if a Judge finds the GPL unenforceable?"
That's the big elephant in the room.
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.
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.
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.
[1] 17 U.S.C. § 101.
[2] Gracen v. Bradford Exchange, 698 F.2d 300, 305 (7th Cir. 1983).
[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' ").
[4] Mirage Editions v. Albuquerque A.R.T., 856 F.2d 1341, 1344 (9th Cir. 1988).
[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."
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.
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.
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.
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.
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.
[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.
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.
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?
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".
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.3...
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.
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:
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