Can a GPLv2 program rely on Apache-licensed libraries?

Question

Can a software program licensed GPL (version 2) rely upon libraries licensed under APLv2 without running afoul of the GPL? The language here suggests to me perhaps not.

In my specific case I'm looking at a daemon that uses some APLv2-licensed external libraries.

UPDATE (In response to answers/comments.)

1. For the purpose of this question, I cannot relicense the main program (the daemon)
2. The main program has been extended with functionality that uses apr-util and perhaps other APLv2 components

My question is, can I release the extended daemon under the GPLv2, or is this something I need to keep to myself (no distribution) and/or re-implement without APLv2 if I am committed to (a) releasing this extension, and, (b) keeping the daemon GPL'd?

Answer 1

Let's clarify some terminology first. When the FSF says a license is compatible with the GPL they don't mean what many people interpret that to mean. Many interpret "compatible" to mean the two pieces of software can happily co-exist in the same application.

That's close to what the FSF means, but the copyleft provision of the GPL takes things a little bit further.

From the GPL FAQ, emphasis mine.

It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program.
All GNU GPL versions permit such combinations privately; they also permit distribution of such combinations provided the combination is released under the same GNU GPL version.

So a license is compatible with the GPL if its terms can be absorbed underneath the GPL.

---

So let's look at the APLv2 and the GPLv3.

• APLv2_Lib + GPLv3_Lib => Combined lib as GPLv3 is okay.
• APLv2_Lib + GPLv3_Lib => Combined lib as APLv2 is not okay.

And Apache says as much here:

We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license.

---

But you're working with a daemon that was licensed under GPLv2, not v3.

FSF is pretty clear that what you want to do is not acceptable for a public distribution.

Please note that this license 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.

So, to answer your question:

No, you may not distribute the combined daemon using GPLv2 and APLv2 licensed material.
FSF explicitly calls out that combination as not allowable for public distribution.

Alternatives:

1. You are allowed to use it privately.

2. You would also be okay to re-write the APLv2 functionality and then combine your new work with the GPLv2 work.

3. You could see if the daemon can be changed to GPLv3. If so, you would then be in the clear to merge the APLv2 work into the now GPLv3 daemon.

Answer 2

My view is in agreement with OP based on the text of OP's ASF link.

ASF (Apache Software Foundation) doesn't like the idea of ASFv2 code being any part of a system that uses GPLv2, based on the limited information of your case and my understanding of the various FOSS licenses: regardless of whether the umbrella project has GPLv2, or the umbrella project is GPLv2, attempting to include ASFv2.

Further it seems a ASFv2 umbrella project that has GPLv3 code should not happen, but a GPLv3 umbrella project can have ASFv2 code.

The caveot, perhaps (according to Gnu), is how they interact with each other. If linked, sharing the same copies of data during execution, they are one in the same program; however, if they are working as seperate processes (ie. forked) passing data between different distinct processes, what you are doing might be permissible because they are, to them, seperate programs. If it uses shared data-space during execution, and doesn't operate with distinct processes, then what you are doing might not be allowed, because to them, they are the same or too tightly coupled to be distinct or independant.