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?

  • Once you compile using the headers, it is a derived work. Besides, in cases 2 and 3 the user is still getting L from you, because you downloaded (via X).
    – Jan Hudec
    Jul 21, 2014 at 10:51
  • @JanHudec so merely compiling X with Y's headers (or equivalent) makes X a derived work of Y? Makes sense. What if X is distributed in source code form only?
    – user253751
    Jul 21, 2014 at 11:23
  • Distributing in source code is somewhat grey area. It would probably be derived work if it depends on Y specifically and not if there are alternatives. But it's difficult to predict what you'd get away with at court (which further depends on jurisdiction) even for a lawyer and I am not one.
    – Jan Hudec
    Jul 21, 2014 at 12:48

2 Answers 2


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.

  • 1
    Note that FSF does have lawyers and they worked over the wording quite a bit. But due to the variations in copyright law in different countries whether it would stand in court is more a question in which courts it would stand.
    – Jan Hudec
    Jul 21, 2014 at 12:53
  • 2
    @JanHudec: It is not so much the wording of the license, but the underlying ideas that might not stand up, especially if dynamic loading is involved. See also law.washington.edu/lta/swp/law/derivative.html Jul 21, 2014 at 13:07
  • To my understanding, Library L's license only applies if you're distributing Library L, regardless of what the wording says.
    – user253751
    Jul 22, 2014 at 0:26
  • 1
    This has to be wrong. There is no way the FSF can stop me distributing my own source code to anyone I like on any terms I like, regardless of what external dependencies it may have. They control their source code, I control mine.
    – david.pfx
    Jul 22, 2014 at 5:25
  • @immibis: That is the problem with infectious licenses, like the GPL. They try to extend beyond the code that is placed under the license. Jul 22, 2014 at 6:12

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.

  • For 2, the owners of X are not merging anything, but distributing a script that will merge things when run.
    – user253751
    Jul 22, 2014 at 7:31
  • @immibis: I disagree. If you write a script to set off a bomb, it's under your control. Whoever owns and controls the script is liable for what it does.
    – david.pfx
    Jul 22, 2014 at 10:38
  • @david.pfx: If it is a question of control, would it suffice to make end user check an "Install dependencies" option?
    – jalanb
    Jul 24, 2014 at 9:37
  • @jalanb: Could be OK. They would have to accept licence agreements for the dependencies but that's OK, no-one reads those anyway.
    – david.pfx
    Jul 24, 2014 at 11:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.