GPLv3 vs. Apache License 2.0: Irreconcilable Differences?
Allison Randal: In the early days of the GPLv3 revision process, compatibility with the Apache License 2.0 was given as one of many motivations for the update. At the 5th GPLv3 conference, Richard Stallman was recorded saying:
GPL version 3 is designed to be compatible with two important licenses: the Apache license and the Eclipse license. It will be possible to merge code under those licenses into GPL3 covered software once the GPL version 3 is really out.I was suprised and disappointed to find that goal abandoned in the rationale document for the third draft (page 33):
We regret that we will not achieve compatibility of the Apache License, Version 2.0, with GPLv3, despite what we had previously promised.
I've watched many failed attempts at merging GPL and Apache licensed code. They all ended up giving up their negotiations, giving rise to the phrase "clean room reimplementation of GPL-ed code."
With GPLv3 still incompatible with Apache License 2.0, I guess we'll see more of these kinds of debates in the next few years.
There's nothing irreconcilable there
There are two gaps preventing GPLv2/AL2 compatibility.
FSF has bridged one of those so far in GPLv3. Richard's statement only says that FSF can't bridge the second gap on their own, which is different from saying that the gap is irreconcilable.
This could still work out.
There's nothing irreconcilable there
I don't understand why the Harmony project decided to use a licence that was incompatible with GNU Classpath and all the other free software java components that already existed.
The only answer people give is "it's Apache Foundation policy", but that level of rigidity is self-defeating. The GNU project has a policy of using the GPL, but it also uses the LGPL when some compromise is needed, and even permissive X11/MIT style licences are used occasionally.
Maybe the Harmony developers/funders actually wanted to be incompatible with the other projects in their field. This sounds absurd, but it happened with OpenSolaris. Management in Sun wanted to use the GPL, but the developers specifically objected to the use of any GPL-compatible licence. (Danese Cooper explained this at one of the DebConfs.)
The only answer people give is "it's Apache Foundation policy", but that level of rigidity is self-defeating. The GNU project has a policy of using the GPL, but it also uses the LGPL when some compromise is needed, and even permissive X11/MIT style licences are used occasionally.
Maybe the Harmony developers/funders actually wanted to be incompatible with the other projects in their field. This sounds absurd, but it happened with OpenSolaris. Management in Sun wanted to use the GPL, but the developers specifically objected to the use of any GPL-compatible licence. (Danese Cooper explained this at one of the DebConfs.)
There's nothing irreconcilable there
Practically speaking, Apache license is not incompatible with the GNU Classpath license in either direction.
The problems only arise in conjuction with GPLd VMs binding to GPL-incompatible VM interfaces, and in conjuction with ahead-of-time compilers like gcj, where having an ALv2 licensed core class library would have resulted in undistributable binaries when an ahead-of-time compiler is used to combine an ALv2 licensed class library with ALv2-incompatible code into an executable.
Both cases made Harmony's ALv2-only licensed class library unattractive for the majority of VMs already using GNU Classpath (which are licensed under the GPL). On the other hand the ASF (at that time, at least) did not feel that adding permissions on top of GPLv2 a la linking exception results in a valid license, leading to ASF's inability to collaborate on a common code base, in particular since the ASF didn't even have a third party license policy at the time.
Re: GPLv3 vs. Apache License 2.0: Irreconcilable Differences?
Not so fast. :) That part has raised some attention as a problem to be solved in the next draft, according to a recent committee A meeting. See http://radar.oreilly.com/archives/2007/04/gplv3_committee.html
Given that most people I talked to understood FSF's statement as a kind of final decision, rather than a report on the current status of discussions, I think the FSF screwed up badly in presenting their case. But that's an authentic FSF tradition. :)