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.
[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.