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?