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 answ

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#InternalDistribution 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.