Wasn't this the, "if the source is in your tree everything is GPL" and otherwise "if it's downloaded module as a package it is not"? Or was that LGPL? Asking to show clarification for everyone.
edit: the question was stated as ignorant to get a few decent explanations. Thank you for the effort!
1. You give your user a non-GPL python package with requirements.txt file (no bundled dependencies)
2. Your user pip-installs the dependencies (including some GPL-licensed ones)
3. Your user runs the application
As long as your country doesn't consider use of an API prohibited under the copyright of the implementing code, I think steps 1-3 would be fine (though not very practical for a product).
I'd be curious for others input, though, as this has bugged be for a while in the R community where several core libraries (like the Matrix package) are GPL licensed but many packages that depend on GPL packages claim to be licensed under MIT or some other license.
And then it becomes a problem of proving your users violating the GPL. So you'd have to go after each one of them, which will be incredibly difficult, and proving damages would be even more difficult.
It's an asshole way of exploiting "Wo kein Kläger, da kein Richter" (where's no plaintiff, there's no judge) since actually proving that the developers violated the GPL will be difficult, unless they have a CI system that readily documents this.
However, distribution also happens in places you might not expect. As a business, I'd stray far away from such constructs even if I only use this construct internally.
However, this is purely based on the wording of the GPL. For example, the EUPL explicitly covers the creation of derivative works - and I'd argue that the proposed circumvention would create a derivative work.
Though I can certainly imagine that a multinational company might not be confident of the copyright status of API usage in all countries they operate in.
What you described only okay with LGPL
Pretty sure the prevalent opinion was that it was going to be the end of the world if the US Supreme Court ruled that APIs were copyrightable in the Oracle v Google case.
Just say'n.
1.) Hire a bonafide poet (e.g., someone with an MFA degree in Creative Writing).
2.) Have them write Haikus on salary for your company ("work made for hire" under copyright law).
3.) Use the Haikus in your API names.
e.g. for a sqrt() function in Java:
public double sqrt___an_ancient_pond_$_a_frog_jumps_in_$_the_splash_of_water(double number);
Within this discussion if you take a GPL'd piece of software, a "program", and interface to it via pipe/exec you're just using an external program, you're not linking to it and are 'immune' from GPL 'contamination'. If not it would effectively not be possible, or very difficult, to run commercial license programs on Linux, for instance.
If you are (for example) shipping a product which is effectively a thin wrapper around a GPL 'd component, but instead of linking to a GPL'd library you've written and dutifully GPL'd a small shim program that turns the library into an executable and reads function arguments over a pipe, then you call that from your 'non-GPL' code... I don't think you'll find the process boundary is some sort of absolute defence in law.
In fact you may be looked upon unkindly in court for having knowingly attempted a license circumvention mechanism.
The law is not necessarily sensitive to the exact inner workings of a turing machine, and the definition of a derivative work may or may not be affected by such shenanigans.
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
I use the pipe/exec loophole to include a GPL program in a proprietary one. I personally decided that the proprietary code can be considered an independent and separate work because it's still does something useful without the GPL component. Also, you could swap the GPL component for a 3rd party proprietary one, which actually exists and uses the same interface for communicating via files. So to me, it's just a generic interface and I'm distributing the GPL program together as "aggregation" of separate works. For the sake of human relations, I also got approval from the GPL program's author to do this but he admitted he wasn't sure, and neither am I.
An example of what I have in mind: Let's say that you write a program and for some functionality it needs to grep files. Now, instead of programming this from scratch you just exec/pipe grep and grab its output. That's does not make your program GPL'd although grep is.
Packaging grep with your program to make distribution easier (if needed) does not, either.
The ambiguity is in whether the two programs (proprietary and GPL) together count as a "work based on the program". Your grep example seems to support the idea that they don't, and it wouldn't fall under the operating system components exemption because it "accompanies the executable". But then where is the boundary? Others have said you can't make a GPL shim to convert a library to an executable then use it in this way.
A GPL library is a trickier case because it's all about linking to it and potentially how that is done.
My guess is that if the shim converts the library into an executable that is usable in itself generically then you're fine (e.g. you turn some 'libgrep' into grep then uses grep). But if it only implements something like RPC through pipes specifically for use with your own program then someone might decide that this is just convoluted 'linking' and falls within the licence.
"But when you distribute the same sections as part of a whole which is a work based on the Program..."
No matter how you distribute them, they never formed a "work based on the Program" anyway so the GPL doesn't spread.
If all that's correct, it seems to leave a loophole that I mentioned where you can fork the original program to make it specially compatible with your proprietary program and redistribute it under the GPL. Now when you combine them you're not modifying it because you (or your friend if need be) did that before you obtained it and the modification is none of your business.
"GPL-2.0, with an explicit syscall exception"
That's for the kernel, right?
My comment was general and about all the interactions betweem programs.
Edit:
yes! And it in the general case it get really twisty and interesting. The classic example is a GPL cloning the functionality of a closed source program, down to arguments and options. Now, if you made some sort of closed source plugin for the GPL program, that's OK, if the plugin API was part of the originally cloned program.
However, if the plugin API was an innovation in the GPL program, then a proprietary plugin the can easily be infringing. (And as always with GPL, only on distribution.)
LGPL allows dynamic linkage without open sourcing your components.
GPL requires any linkage to open source your parts, but allows for process boundary to not be viral.
AGPL is the nuclear don’t touch because it is vital to all possible usage types.
Again, that’s trivializing because there’s many subtle details that in many cases are intentionally not clarified in the licenses themselves
The only difference between the AGPL and the GPL relates to software you don't distribute, but that you make available over a network, such as hosting an AGPL web server. The AGPL says that as long as public users interact with this web server, they have the right to get the code and deployment instructions and AGPL rights to be able to run the exact same service themselves, just as if they had downloaded the software.
The FSF's (very reasonable) position is that linking to a piece of software makes your software a derivative work, but that launching it as a separate process or accessing it over a network generally doesn't. However, if you exchange very complex internal data structures with this GPL software running in a separate process, whether you do it over a network or through pipes or command line arguments or whatever, then your program is still a derivative work, in their opinion.
That is, if you run gcc in a separate process but then mmap() it's memory and search for its entry points and jump to the memory locations of GCC functions in order to generate optimized code for a piece of GCC AST you provide, then your program is a derivative of GCC (according to the FSF, at least) even though GCC is running in a separate process.
If you instead, modify/customize the source of the AGPL-covered service, then you are required to make available your changes to AGPL-covered product under a AGPL license.
Is this a correct understanding of the situation? If the product implements a publicly documented protocol to communicate over the network (ie, not "complex internal structures", and/or replaceable with another product), is that permitted?
Also static linkage provided you provide users with the object files so that they can re-link with a modified library.
> GPL requires any linkage to open source your parts
With the exception of system components. Maybe that is what is causing the confusion because it's not intuitive why you can ship proprietary software that uses glibc but can't ship proprietary plugins for a GPL program.
> AGPL is the nuclear don’t touch because it is vital to all possible usage types.
That is an absurd viewpoint bordering on FUD. Affero licenses are only a problem if you are trying to work around the license terms. The license does fix loopholes for networked use that allowes SAAS providers to skirt the GPL but it is NOT any more viral than the GPL. Commercial use of AGPL software is absolutely possible - see e.g. cloud providers. Most GPL software probably should be AGPL.
One person’s skirting is another person’s complying. Most of what AGPL proponents argue is skirting GPL by SaaS companies seems like straightforward compliance/conformance to me.
And I’m not saying that AGPL can’t be used, in the same way I’m not saying other GPL can’t be used. You’re misunderstanding the context of the comment.
The comment was in regards to: what are you allowed to do without having to fall under the purview of the license.
In that sense, the AGPL specifically exists to close off many areas that the GPL didn’t touch.