How restrictive are the GPL's linking restrictions really?

Question

To my basic understanding, software licenses only apply when redistributing software. Even if I am wrong about this in general, the GPL states that you need not agree to the GPL in order to receive or run a GPL-covered program.

Say there is Program X. Program X requires Library L to run. Program X is covered by a GPL-incompatible license (e.g. the Eclipse Public License, or a proprietary license). Library L is covered by the GPLv3.

Program X cannot be distributed alongside Library L - the combination would need to be covered by the GPL, which would violate the EPL.

1. What prevents users from separately installing Program X and Library L, and then using Program X?

2. Perhaps more relevantly in the modern world of auto-updaters, what prevents Program X from including a wrapper which downloads Library L from the Internet (say, from Library L's official website) and then executing Program X?

   In both of these cases, nothing from Library L is distributed by the authors of Program X, so Library L's license should not apply.

3. What, if anything, changes if Program X instead requires Library L', a fork of Library L by the authors of Program X, which is only available from the same website as Program X and is only usable with Program X, but is never distributed in the same package as Program X?

4. What if this is all in a dynamic language, and no part of Library L is required to compile Program X?

5. What if Program X is distributed in source code form, so that the distribution was not compiled from Library L's headers?

Answer 1

From the standpoint of the FSF, program X can not be distributed at all. The reasoning here is that if Program X needs Library L to function and they don't communicate at arms length (separate processes that communicate through an inter-process interface or files), then the GPL applies to Program X as well.
If Program X isn't licensed under a GPL-compatible license, then Program X can't be distributed.

To quote their FAQ:

I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? (#GPLInProprietarySystem)

You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too.

A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

In how far the standpoint of the FSF is legally valid is a bit uncertain, but I wouldn't want to be the testcase to see how the courts find on it.

Answer 2

Q1. Nothing. A user can merge X and L as long as they comply with all licence requirements.

Q2. No good. The owners of X are now in control and are performing a merge on-site, which brings them under the L licensing terms. But there is room for a lawyer's picnic.

Q3. Still falls under the merge provisions.

Q4. Dynamic language: no change. Depends where and how the merge happens.

Q5. X in source form: no change.

Ultimately if the distributor of X owns and controls the merge, they are bound by the licence that covers the distribution of merged versions, even if they 'arrange' for that merge to be performed on the client site. Either that or there is a strong argument and a fierce legal battle before anyone is certain.

But if you can distribute X and pass the decision to use and merge X with L entirely on to the recipient you would not be bound by the licence for L. You could write licence terms to that effect and be reasonably sure they could not be challenged, or if they were, that you were indemnified by the recipient. Another lawyer's picnic.