There has been much debate over whether or not merely linking to a piece of code makes it a derivative work. I know FSF says "yes", so according to them I can't dynamically link a non-GPL compatible program to a GPL library and distribute the whole. But I could do that for private use, as long as no code is released to the public.
That made me wonder: what if I don't redistribute the GPL code at all? If my program can work alone (reinforcing my claim that it's not a derivative work), but can do more if the GPL library is also installed to the system, couldn't I just release my application under my own licensing terms - without including any GPL code - and post instructions for anyone interested to separately download the GPL code and do the integration "for their private use"?
I know it's against the "spirit" of the GPL, so I'm not suggesting it's a good idea to do that. However, this question is bugging me for some time, specially because of the implications of each answer:
If I can not do that:
- can I write another library with a similar API? (before answering "of course you can", remember that having the same API would allow both libraries to be swapped at will by my customers - so I don't need to work too hard on my library or even make it "working". How to determine if a similar program is just similar or is a circumvention attempt?)
- (Edit: as @Karl Bielefeldt pointed out, that library would be a derivative work, so this point is moot)
If I can do that:
- can I also be paid to perform the service of installing the GPL library for a customer? (I sell them my program, install it in their machines, download and install the GPL library too)
- (Edit: this practice would be evidence of my intent to combine both programs, reinforcing the claim that mine was conceived witht the goal of being combined - and thus is a derivative work)
- can I put the two programs in the same website? In two different CDs? (I know I said the idea was not to redistribute the GPL code, I'm just thinking in excuses people could use to claim they're not redistributing even though they are)
- (Edit: that would be an "aggregate", so no problem with it)
Update: having analyzed @Eli Rosencruft's and @Karl Bielefeldt's answers and links, and read some external resources, I'm getting closer to a conclusion. I made some edits to the question according to the feedback, and below I'll post a few of my findings so far:
- The intrinsic qualities of both programs is a more determining factor when deciding whether or not one derives from another than the technological means to achive their integration. The intent of the authors of achieving some goal is also as relevant as the means they used to reach it (in this scenario). Quoting a blog post that - though not authoritative on the subject - I believe is relevant to the question (emphasis mine):
Since under the GPL the end-user can do whatever they want with the code (short of redistribution constraints), the end-user can always PULL various software on the Net and choose to combine and use them in any way they wish (assuming all parts are legits and legitimately obtained of course). (...) It does NOT mean that I can offer (PUSH) to the user a proprietary software that has been conceived with the goal/intent of being combined with a GPL software (whether it is deemed to be combined before or after distribution).
- Whether legally significant or not, I now comprehend the motivation behind FSF's insistence on static vs dynamic linking: a non-free program that interfaces with a free one in complicated ways is de facto restricting the users' freedom over the latter, since they can't modify it substantially without breaking the integration (this also enables EEE, in case the free part is also modified to fit the non-free one). So, if one cares for the free software movement, s/he should comply to their terms or, at the very least, take the necessary measures to safeguard the receiver's freedoms.