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? Jul 27, 2015 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. Jul 27, 2015 at 5:21
  • 1
    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. Jul 27, 2015 at 5:33
  • 3
    @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. Jul 27, 2015 at 7:22
  • 3
    @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, 2015 at 15:47

3 Answers 3


(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.
  • 1
    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). Jul 28, 2015 at 15:50

Section 2 of the GPLv2 states that the GPLv2 license applies to the whole. However, section 3 of the GPLv2 states that as a special exception, this does not apply to system libraries that come with the operating system.

So, if a GPLv2 software is linked to and is dependent on a library that is Apache 2.0-licensed, then the combination of these would have to be licensed as a whole under the GPLv2.

The library itself, when used in this combination, would be licensed under the terms of both the Apache 2.0 License AND the GPLv2 simultaneously.

The Apache 2.0 License imposes patent-related terms and conditions (in sections 3 and 9) which the GPLv2 does not have.

Section 6 of the GPLv2 states:

You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

So, the Apache 2.0 License conflicts with GPLv2, because Apache 2.0 has additional terms and conditions on patent, while GPLv2 does not allow imposition of further restrictions.

This is why a GPLv2-licensed software cannot be linked to a Apache 2.0-licensed library, unless the GPLv2-licensed software is licensed as "GPL version 2 or later", in which case the combination can be relicensed under GPLv3. The Apache 2.0 License is compatible with GPLv3.

The Mozilla Public License 2.0 (MPL2) avoids this problem by allowing the licensee to relicense the whole software under GPLv2 (one of the Secondary Licenses defined in MPL2). This means that when the GPLv2 software is linked to a MPL2-licensed library, the combination or the whole would be licensed under GPLv2 alone and the terms of the MPL2 (including the patent-related terms) are no longer applicable.

The MPL2 states:

... this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).

The LLVM project solved this problem by adding a special exception to the Apache 2.0 License that waives conflicting terms and conditions:

In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 ("Combined Software") and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.

The third solution is dual-licensing under Apache 2.0 and a GPLv2-compatible license.


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.

  • 4
    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. Jul 27, 2015 at 5:36
  • 1
    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.) Jul 27, 2015 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. Jul 27, 2015 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. Jul 27, 2015 at 5:55
  • Let us continue this discussion in chat. Jul 27, 2015 at 5:56

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.