ASL 1.1 is not compatible with GPL, but ASL 1.1 code is linked with GPL-only code.
Only the ant task seems to be under ASL 1.1. Maybe the solution would be removing the ant task, but I don' know if it's needed by something.
As far as I can tell, this is acceptable. The following is from upstream's documentation:
The use of the Apache Software License in Cobertura is very straight forward. Cobertura includes a set of ant tasks which can be used to call Cobertura. Ant itself is licensed under the Apache Software License, Version 2.0. Because ant tasks are loaded directly into the runtime of ant, and the GPL is incompatable with all versions of the Apache Software License, ant tasks can not be licensed under the GPL.
For this reason, the Cobertura ant tasks are licensed under the Apache Software License, Version 1.1. And because these ant tasks are not GPL-compatable, but the rest of Cobertura is GPL, when these ant tasks invoke Cobertura they must do so by exec'ing a new JVM.
So the cobertura library only exists in a separate process -- I don't think that can be called "linking" in any sense.
(Although it would be less muddy if they used the GNU Classpath Exception...)
> So the cobertura library only exists in a separate process -- I don't think
> that can be called "linking" in any sense.
There is direct static linkage between GPL and ASL 1.1 code.
ASL 1.1 cannot be loaded without loading GPL code. For example:
From InstrumentTask.java (ASL 1.1):
> import net.sourceforge.cobertura.util.CommandLineBuilder;
But CommandLineBuilder.java is GPLv2+ only (with no exception).
You could have given that example in the original bug description and saved me writing that comment... ;-)
I will raise it with upstream.
Actually in the latest version of cobertura, it states in the CommandLineBuild.java:
* Note: This file is dual licensed under the GPL and the Apache
* Source License (so that it can be used from both the main
* Cobertura classes and the ant tasks).
So looks like they were already made aware of the problem.
Could be the solution is to just upgrade it to the latest version. Thoughts?
> So looks like they were already made aware of the problem.
> Could be the solution is to just upgrade it to the latest version. Thoughts?
If all files shared between separate JVM processes (which you mentioned in comment #1) are dual licensed (GPL or ASL) then updating to latest upstream may solve the problem.
Looks like the obvious fix is to upgrade to the latest upstream.
cobertura-18.104.22.168-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cobertura-22.214.171.124-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Fixed in F18