Twenty questions about the GPL(jacobian.org)
jacobian.org
Twenty questions about the GPL
http://jacobian.org/writing/gpl-questions/
10 comments
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.
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.
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.
-- 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.
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.
The spirit of the GPL and BSD licenses are different, especially for libraries (ignoring people who accidentally use GPL instead of LGPL).
"...and hope that you will not be the target of legal action."
I think that's a hope that I, jacob and many others are not willing to sign up to.
I think that's a hope that I, jacob and many others are not willing to sign up to.
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.
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.
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.
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...
Yet, oddly, they don't seem to fear the very real consequences of the BSA coming and shutting them down for an "audit".
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 business world abhors legal uncertainty.
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.
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.
"Hope" is not a strategy. Full stop.
i imagine your questions would be great for a hypothetical final exam at an established law school...
Yeah better off sticking to those simple licenses from IBM,Oracle, SAS and MSFT - any child can understand them.
Actually SAS licenses are simple - you are allowed to use the product to send SAS all your money, any other use is probably forbidden.
Actually SAS licenses are simple - you are allowed to use the product to send SAS all your money, any other use is probably forbidden.
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.
Perhaps people choose the GPL over one of those licenses because they don't want you linking your proprietary code to their library for free.
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.
c) Does not matter.
The FSF does not get to write copyright law and decide what is or is not a derivative work.
The FSF does not get to write copyright law and decide what is or is not a derivative work.
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.
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.
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.
The complexity is a feature.
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.
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?"
That's the big elephant in the room.
Jacob: the question you were missing:
"What happens if a Judge finds the GPL unenforceable?"
That's the big elephant in the room.
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:
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.
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.
"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.
And the general case is just absurd.
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.
So perhapse the GPL shouldn't be used outside of the pure-C environment. Or the FSF should be forced to make the definitions for new environments.
>Ambiguities in copyright precedent
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
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
> 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."
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."
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.
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.
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.
I bet if you did that and reposted the questions with answers on your blog, it would make it to the front page again
HN is largely anti-GPL. You are being dowmodded for that reason.
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.
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.
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.
[deleted]
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.
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.
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.
[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.
> 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.
For further information, see:
http://www.law.washington.edu/lct/swp/Law/derivative.html
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
That essay is excellent. Thanks for posting it.
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.
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?
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?
Linux made an exception to the GPL so that Linux programs don't have to be GPLed.
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".
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.3...
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...
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.
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?
I am still waiting for an example of anyone who:
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
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
[deleted](6)
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.