Can I link a Apache 2.0 library into software under GPLv2?

Question

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?

Answer 1

(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.

Answer 2

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.

Answer 3

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.