“Integratable” but not “integrated” GPL

Question

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.

Answer 1

First, verify that the library with which you wish to link your code really is GPL and not LGPL. As Karl Bielefeldt notes below, most of the common libraries are already either LGPL or dual licensed.

The FSF use of "derivative work" with regard to either static or dynamic linkage is problematic from a legal perspective. See "Example 3" and "Example 4" from University of Washington School of Law. Example 4, regarding plug-in technology is particularly illuminating.

But, if we assume the FSF interpretation of "derivative work" being defined by dynamic linkage, then any claim that a work is not derived when it in fact can be linked with a GPL work and such linkage provides additional features would be a specious claim.

On the other hand, who would bring action against you for this? I think that only the original copyright holders of the library against which you link could be party to an action, not your customers.

However, even reading against the GPL FAQ, and even assuming that there is no one to bring an action, do you really want to be here from a business perspective?

If your software really is going to be popular, then damage to your public image for even appearing to violate the GPL might not be worth the cost of developing your own proprietary library.

If your software will have only limited distribution and is pricey, then you should provide the software to your customers under a contract rather than a license. See Robert Pierce. Under the contract, you would provide the packaged product to the customer, along with the complete source code, as if you had developed the work for hire solely for that particular customer. You could stipulate that if the customer redistributes the product, he would do so at some agreed price from which he would pay you a percentage in royalties. It is likely that most of your customers aren't in the business of distributing or supporting software products, so this last clause would probably never be exercised. You could probably also stipulate conditions for securing the source code against disclosure risks, such as limiting access to the source code.

Answer 2

Is this a hypothetical question? I'm only aware of one major open source library that uses the GPL instead of the LGPL, and that's mysql which also offers a commercial license to cover what you want to do. I imagine most other GPL libraries would also offer commercial licenses, or else they would just make it LGPL. If it's not a hypothetical question, it might be helpful to mention what library you're talking about.

I believe it's not enough that your program can work without the library. The part of your program that uses the library must be severable and able to be distributed separately. Take nvidia's kernel drivers as an example. They distribute a binary library. They also distribute an open source wrapper to that library that provides an interface between their library and the kernel headers. To install it, you compile that wrapper.

The key here is that the kernel and their binary library can change completely independently of each other, and you just have to modify the wrapper to make it work. Proof of this is that third parties have been able to distribute changes to that wrapper when the kernel interface changed and nvidia hadn't caught up yet in their official release. Someone could also use that wrapper for other drivers, although to my knowledge no one has done so.

As for your other questions, writing another library with a nearly identical API is most definitely a derived work. The GPL does not prohibit getting paid for installation or for aggregating a GPL work on a CD.