13

The Apache 2.0 License has a built-in linking exception:

For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

So linking a library under Apache 2.0 into a main program licensed under GPLv3 does not create a derivative work according to the the Apache 2.0 License. In other words, the library is considered a "mere aggregate" in relation to the main program.

As I understand the Apache 2.0 license, in the case of linking, it leads to a situation where each component in the collection (i.e. the library and the main program) retains its original license. If there are any patented software in the main program (under GPLv2), the patent termination and indemnification provisions of the Apache 2.0 license does not apply to it.

However, according to the FSF, you can not do this. Quote:

Please note that this license [Apache 2.0] is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions.

I have not been able to discover exactly why the FSF declares the licenses incompatible, and what this incompatibility implies. It may, however, have something to do with FSF's position on linking:

In Why Upgrade to GPL Version 3 Richard M. Stallman, president of the FSF, writes:

Fortunately, license incompatibility only matters when you want to link, merge or combine code from two different programs into a single program. There is no problem in having GPLv3-covered and GPLv2-covered programs side by side in an operating system. For instance, the TeX license and the Apache license are incompatible with GPLv2, but that doesn't stop us from running TeX and Apache in the same system with Linux, Bash and GCC. This is because they are all separate programs. (My emphasis.)

I don't think that anybody will dispute that merging or combining code (i.e. copy/pasting some code into another project) will produce a derivative, but including "linking" in the actions that shall produce a derivative is not universally recognized, but seems to be the position of the FSF (assuming its founder and president speaks on behalf of the organiation).

In this essay, which is published of FSF's official website, and therefore can be assumed to use the phrase "FSF's position" with the approval from the FSF, David Turner writes:

It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed as a whole under the terms of the GPL, an effect which can be described as “hereditary.”

However, the Apache Software Foundation disagrees about them being incompatible. They write:

Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work.

So the Apache Software Foundation says that you should not do this, because the FSF disapprove of it.

But: Could I do it?

In other words, are the licenses really incompatible - as the FSF say. Or do the linking exception in Apache 2.0 give me an explicit permission to link a Apache 2.0 library into software under GPLv2?

  • Where does the FSF say that linking "always" creates a derivative work? Are you sure they're not talking about copy/pasting some Apache 2.0 code into a GPLv2 project? – Abhi Beckert Jul 27 '15 at 5:20
  • Also this has nothing to do with "irking" the FSF and everything to do with wether or not you are violating the terms of the Apache 2.0 license. The FSF did not write the Apache 2.0 license and they did not choose to use it for licensing any software, so how could you possibly irk them? Perhaps you should remove that line from the question. – Abhi Beckert Jul 27 '15 at 5:21
  • Wether or not you are committing copyright infringement when you link against some code is a good question that has (AFAIK) never been tested in court. Personally I agree that the FSF might be wrong. But it's irrelevant here because the Apache license clearly gives you permission to link. – Abhi Beckert Jul 27 '15 at 5:33
  • 2
    @AbhiBeckert. I've added a quote from the president of the FSF and another one from David Turner - both posted on the FSF's official website. I believe these quotes somewhat clarifies the FSF's position on whether linking creates a derivative or not. Whether this position applies to linking an Apache 2.0 library with a program under GPL - I do not know. That's really what is asked in this question. – Free Radical Jul 27 '15 at 7:22
  • 1
    @Josef I'm skeptical of your claim. Why does the System Library exception (which would seem to cover your case) need to exist at all, if linking non-GPL libraries into GPL code was generally not a problem? Granted, a given GPL program could explicitly authorize exceptions, but in the general case, it seems to be the FSF's intent that the GPL's copyleft applies for links in either direction. – apsillers Jul 27 '15 at 15:47
9

(Here's my best guess. This is obviously a very hairy problem to work through, and I've tried my best to reduce the problem down to basic principles. However, I may gotten some of those basic principles incorrect. It should go without saying that this is not legal advice.)

The Apache License 2.0 (APL) is incompatible with the GPLv2 simply because of the licenses' differing rules about patents (and the GPLv2's requirement that it must apply to the work as a whole). I'm not sure which particular clause is problematic, but the APL has a clause about termination of patent licenses that looks unlike anything in the GPLv2. If the GPLv2 indeed has no similar requirement to this, the APL and GPLv2 are incompatible:

If You institute patent litigation against any entity... alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate...

Such an additional restriction is sufficient to render the licenses incompatible, since the GPLv2 could not apply to the work as a whole while the APL imposes an additional requirement.

So, this question asks whether we can sidestep this incompatibility by having the linked works not considered as a combined derivative work. For the purposes of this answer, we will assume that FSF's opinion that linking creates a derivative work is legally correct. (If it is not correct, and linking does not create a combined work, then you're home free and can ignore the rest of this answer! In that case, you need not worry about how the licenses interact, because they're not interacting -- they're completely separate works!)

The crux of this question is whether the APLs linking exception is sufficient to allow applying the GPLv2 to the entire software. I think the answer is no: even if the APL library doesn't cause the APL to apply to the GPLv2 program, the GPLv2 program does cause the GPLv2 license to apply to the library. However, the licenses are incompatible (per the patent problem, above).

It doesn't matter whether the APL considers the works combined; it matters whether copyright law considers the works combined, and whether the GPLv2's section 2(b) applies to the library as part of a work that "in whole or in part contains or is derived from the [GPL-licensed] Program."

  • If copyright law does consider them part of one work, then the library must (but cannot) be included under the work's overall GPL license.
  • If copyright law considers them separate works instead, then there is no license interaction, and therefore no incompatibility.
  • Thanks for a very well argued answer! This is an extremely hairy problem and hard to get a grip on. As you say, it really depends on whether FSF's views on linking are legally correct. We don't know the answer to this (but after reviewing related case law, I'm leaning in that direction). – Free Radical Jul 28 '15 at 15:50
-1

I think you misunderstand what the FSF and the Apache foundation have said.

Yes, you are allowed to link against Apache code from GPL code.

The Apache license clearly states that you don't need to follow any of its "derivative" terms if all you do is link against it.

  • 2
    The Apache Software Foundation (ASF), clearly say that forking some Apache licensed code into your GPL project is illegal "because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0." Regarding this, there is no disagreement between the FSF and the ASF. – Free Radical Jul 27 '15 at 5:36
  • You start your answer saying that I am "miss-understanding what the FSF snd the Apache foundation have said", without following up and saying what it is I've mis-understood. (Just for the record: I have understood that the Apache license clearly states that you don't need to follow any of it's "derivative" terms if all you do is link against it, and quote the relevant portion in my question.) – Free Radical Jul 27 '15 at 5:46
  • I tried to explain the part you're miss-understanding in my comments on the question, since it's got nothing to do with wether or not you're allowed to link against the code. – Abhi Beckert Jul 27 '15 at 5:52
  • The FSF does not say anywhere that you should not link against Apache code. You've quoted the FSF and ASF a bunch of times but neither organisation is talking about linking in any of the text you quoted. – Abhi Beckert Jul 27 '15 at 5:55
  • Let us continue this discussion in chat. – Abhi Beckert Jul 27 '15 at 5:56

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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