You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Benson Margulies <bi...@gmail.com> on 2011/04/01 17:40:05 UTC
Cobertura's view of the apache license versus the GPL
Disclaimer:
The following is only peripherally an Apache issue, at most. If you
read this and are inclined to reply by explaining that to me, I can't
stop you, but I beg your forbearance.
The following web page
http://cobertura.sourceforge.net/license.html
makes a claim: that 'license incompatibility' prevents the use of an
ant plugin containing GPL code unless there's an extra level of JVM in
there somewhere. Reading Larry Rosen's writings, this strikes me as
fantasy. If someone bundled up ant and a gpl plugin and distributed
the combination of the two, then there might, perhaps, be an argument
about aggregation versus derivation. Personally, even that strikes me
as weak.
My first question is, would anyone official at ASF feel that it was a
worthwhile use of time to try to convince the owner of this page to
stop publishing a false and misleading claim about the terms of the
AL? This isn't intended rhetorically; I pretty much expect that the
answer will be 'no'.
My second question has to do with the recent discussion of reflection
as a solution to GPL dependencies. I fully appreciate that here at ASF
we have multiple reasons to avoid GPL dependencies. Even if we all
follow Larry Rosen's line of reasoning that calling a subroutine
doesn't make a derived work, etc, we want to build things usable to
people who don't agree, or who are lumbered with managers or lawyers
or customers who dont'.
At the same time, I'm comparing two scenarios:
1) Source code that compiles with no GPL-licensed artifacts in the
same county. Maybe there's a test module that, when asked, downloads a
GPL item and uses it in a test.
2) Source code with a build system (e.g. Maven) that automatically
downloads GPL-licensed artifacts and uses them to enable compilation
-- however, the resulting 'thing that gets built' works fine at
runtime if you leave all the GPL-licensed items in orbit around
Jupiter.
Is this a distinction with a difference? (Again, I'm not asking if
it's a big enough difference to change ASF policy. I'm trying to
understand this to address a situation outside the ASF.)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Benson Margulies <bi...@gmail.com>.
Jochen,
I think it's also important to note that the distinction between
'Cobertura Ant Tasks' and 'Cobertura' is not reflected in a jar file
boundary. The same jar contains both the ant tasks and the rest of
their API
The license page says 'you may use the ant tasks under 1.1'. It
doesn't define the term 'ant tasks', so (to me) it's entirely unclear
whether this means 'you may use ant to run cobertura' or 'you may
incorporate cobertura in a larger component under the terms of 1.1 if
you only call the classes that make up the ant tasks.'
--benson
On Fri, Apr 1, 2011 at 2:13 PM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> Perhaps a small picture might help. So far, the situation is like this:
>
> Maven => Cobertura-Maven-Plugin => Cobertura Ant Tasks => Cobertura
> ASL 2.0 ASL 2.0 ASL 1.1
> GPL 2
>
> And so far, we believed this to be fine.
>
> Now we would like to change the picture like this:
>
> Maven => Cobertura-Maven-Plugin Cobertura
> ASL 2.0 ASL 2.0 GPL 2
>
> Question is whether that's possible, assuming that we do not
> distribute Cobertura's jar files or source code.
>
>
>
>
> On Fri, Apr 1, 2011 at 5:40 PM, Benson Margulies <bi...@gmail.com> wrote:
>> Disclaimer:
>>
>> The following is only peripherally an Apache issue, at most. If you
>> read this and are inclined to reply by explaining that to me, I can't
>> stop you, but I beg your forbearance.
>>
>> The following web page
>>
>> http://cobertura.sourceforge.net/license.html
>>
>> makes a claim: that 'license incompatibility' prevents the use of an
>> ant plugin containing GPL code unless there's an extra level of JVM in
>> there somewhere. Reading Larry Rosen's writings, this strikes me as
>> fantasy. If someone bundled up ant and a gpl plugin and distributed
>> the combination of the two, then there might, perhaps, be an argument
>> about aggregation versus derivation. Personally, even that strikes me
>> as weak.
>>
>> My first question is, would anyone official at ASF feel that it was a
>> worthwhile use of time to try to convince the owner of this page to
>> stop publishing a false and misleading claim about the terms of the
>> AL? This isn't intended rhetorically; I pretty much expect that the
>> answer will be 'no'.
>>
>> My second question has to do with the recent discussion of reflection
>> as a solution to GPL dependencies. I fully appreciate that here at ASF
>> we have multiple reasons to avoid GPL dependencies. Even if we all
>> follow Larry Rosen's line of reasoning that calling a subroutine
>> doesn't make a derived work, etc, we want to build things usable to
>> people who don't agree, or who are lumbered with managers or lawyers
>> or customers who dont'.
>>
>> At the same time, I'm comparing two scenarios:
>>
>> 1) Source code that compiles with no GPL-licensed artifacts in the
>> same county. Maybe there's a test module that, when asked, downloads a
>> GPL item and uses it in a test.
>>
>> 2) Source code with a build system (e.g. Maven) that automatically
>> downloads GPL-licensed artifacts and uses them to enable compilation
>> -- however, the resulting 'thing that gets built' works fine at
>> runtime if you leave all the GPL-licensed items in orbit around
>> Jupiter.
>>
>> Is this a distinction with a difference? (Again, I'm not asking if
>> it's a big enough difference to change ASF policy. I'm trying to
>> understand this to address a situation outside the ASF.)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Benson Margulies <bi...@gmail.com>.
Mark,
I've sent them an email message proposing that they change their page
to say that they grant the AL 1.1 license to any use of cobertura in
an open source build tool. That struck me as the fairest solution to
the whole business. However, if they are very attached to their views
of 'license incompatibility' they may not be very receptive.
--benson
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Mark Struberg <st...@yahoo.de>.
+1, well said.
It's basically like one would sue the ASF because someone used httpd to illegally serve mp3 files...
But I'd be happy if we ask the cobertura guys if this interpretation is ok with them. Don't think they will like us to remove the cobertura-maven-plugin :)
LieGrue,
strub
--- On Fri, 4/1/11, Benson Margulies <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: Cobertura's view of the apache license versus the GPL
> To: legal-discuss@apache.org
> Date: Friday, April 1, 2011, 6:34 PM
> >
> > Even if we don't Cobertura's jar files or source code
> with
> > Cobertura-Maven-Plugin but on the other hand, and
> IIUC, a user will
> > not be able to run Cobertura-Maven-Plugin unless
> Cobertura's jar files
> > are in the class-path, in which position does this
> put
> > Cobertura-Maven-Plugin as licensed under ASL 2.0
> relative to the usage
> > restrictions of GPL 2.0 ?. Looking forward to your
> reply.
>
> Mohammad,
>
> The interesting thing about maven is that it does this for
> you. Now,
> I want to be careful about 'we'. The cobertura-maven-plugin
> is not an
> ASF product. It comes from Codehaus.
>
> When someone releases the c-m-p, a jar file goes to maven
> central and
> a pom file goes with it. The pom files declares, "Hey, to
> use this,
> you also need these two cobertura jars."
>
> So, when I create a maven POM for a build and specify the
> c-m-p, and
> run a build, maven downloads the c-m-p pom and jar. It
> reads the pom,
> sees the dependency, and then downloads the cobertura
> jars.
>
> Net result: I (the end user) have both AL code and the GPL
> code
> running, and stored on my disk in my local maven repo.
> However, at
> least by my interpretation, no one has published a work
> that combines
> them. The c-m-p as published doesn't incorporate the GPL
> code, it just
> expresses a requirement. Maven itself doesn't incorporate
> either.
>
>
> --benson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Benson Margulies <bi...@gmail.com>.
>
> Even if we don't Cobertura's jar files or source code with
> Cobertura-Maven-Plugin but on the other hand, and IIUC, a user will
> not be able to run Cobertura-Maven-Plugin unless Cobertura's jar files
> are in the class-path, in which position does this put
> Cobertura-Maven-Plugin as licensed under ASL 2.0 relative to the usage
> restrictions of GPL 2.0 ?. Looking forward to your reply.
Mohammad,
The interesting thing about maven is that it does this for you. Now,
I want to be careful about 'we'. The cobertura-maven-plugin is not an
ASF product. It comes from Codehaus.
When someone releases the c-m-p, a jar file goes to maven central and
a pom file goes with it. The pom files declares, "Hey, to use this,
you also need these two cobertura jars."
So, when I create a maven POM for a build and specify the c-m-p, and
run a build, maven downloads the c-m-p pom and jar. It reads the pom,
sees the dependency, and then downloads the cobertura jars.
Net result: I (the end user) have both AL code and the GPL code
running, and stored on my disk in my local maven repo. However, at
least by my interpretation, no one has published a work that combines
them. The c-m-p as published doesn't incorporate the GPL code, it just
expresses a requirement. Maven itself doesn't incorporate either.
--benson
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Sorry I am not so into the legal stuff but I was so interested in this
thread. I have a question:
Even if we don't Cobertura's jar files or source code with
Cobertura-Maven-Plugin but on the other hand, and IIUC, a user will
not be able to run Cobertura-Maven-Plugin unless Cobertura's jar files
are in the class-path, in which position does this put
Cobertura-Maven-Plugin as licensed under ASL 2.0 relative to the usage
restrictions of GPL 2.0 ?. Looking forward to your reply.
On Fri, Apr 1, 2011 at 8:13 PM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> Perhaps a small picture might help. So far, the situation is like this:
>
> Maven => Cobertura-Maven-Plugin => Cobertura Ant Tasks => Cobertura
> ASL 2.0 ASL 2.0 ASL 1.1
> GPL 2
>
> And so far, we believed this to be fine.
>
> Now we would like to change the picture like this:
>
> Maven => Cobertura-Maven-Plugin Cobertura
> ASL 2.0 ASL 2.0 GPL 2
>
> Question is whether that's possible, assuming that we do not
> distribute Cobertura's jar files or source code.
>
>
>
>
> On Fri, Apr 1, 2011 at 5:40 PM, Benson Margulies <bi...@gmail.com> wrote:
>> Disclaimer:
>>
>> The following is only peripherally an Apache issue, at most. If you
>> read this and are inclined to reply by explaining that to me, I can't
>> stop you, but I beg your forbearance.
>>
>> The following web page
>>
>> http://cobertura.sourceforge.net/license.html
>>
>> makes a claim: that 'license incompatibility' prevents the use of an
>> ant plugin containing GPL code unless there's an extra level of JVM in
>> there somewhere. Reading Larry Rosen's writings, this strikes me as
>> fantasy. If someone bundled up ant and a gpl plugin and distributed
>> the combination of the two, then there might, perhaps, be an argument
>> about aggregation versus derivation. Personally, even that strikes me
>> as weak.
>>
>> My first question is, would anyone official at ASF feel that it was a
>> worthwhile use of time to try to convince the owner of this page to
>> stop publishing a false and misleading claim about the terms of the
>> AL? This isn't intended rhetorically; I pretty much expect that the
>> answer will be 'no'.
>>
>> My second question has to do with the recent discussion of reflection
>> as a solution to GPL dependencies. I fully appreciate that here at ASF
>> we have multiple reasons to avoid GPL dependencies. Even if we all
>> follow Larry Rosen's line of reasoning that calling a subroutine
>> doesn't make a derived work, etc, we want to build things usable to
>> people who don't agree, or who are lumbered with managers or lawyers
>> or customers who dont'.
>>
>> At the same time, I'm comparing two scenarios:
>>
>> 1) Source code that compiles with no GPL-licensed artifacts in the
>> same county. Maybe there's a test module that, when asked, downloads a
>> GPL item and uses it in a test.
>>
>> 2) Source code with a build system (e.g. Maven) that automatically
>> downloads GPL-licensed artifacts and uses them to enable compilation
>> -- however, the resulting 'thing that gets built' works fine at
>> runtime if you leave all the GPL-licensed items in orbit around
>> Jupiter.
>>
>> Is this a distinction with a difference? (Again, I'm not asking if
>> it's a big enough difference to change ASF policy. I'm trying to
>> understand this to address a situation outside the ASF.)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Jochen Wiedmann <jo...@gmail.com>.
Perhaps a small picture might help. So far, the situation is like this:
Maven => Cobertura-Maven-Plugin => Cobertura Ant Tasks => Cobertura
ASL 2.0 ASL 2.0 ASL 1.1
GPL 2
And so far, we believed this to be fine.
Now we would like to change the picture like this:
Maven => Cobertura-Maven-Plugin Cobertura
ASL 2.0 ASL 2.0 GPL 2
Question is whether that's possible, assuming that we do not
distribute Cobertura's jar files or source code.
On Fri, Apr 1, 2011 at 5:40 PM, Benson Margulies <bi...@gmail.com> wrote:
> Disclaimer:
>
> The following is only peripherally an Apache issue, at most. If you
> read this and are inclined to reply by explaining that to me, I can't
> stop you, but I beg your forbearance.
>
> The following web page
>
> http://cobertura.sourceforge.net/license.html
>
> makes a claim: that 'license incompatibility' prevents the use of an
> ant plugin containing GPL code unless there's an extra level of JVM in
> there somewhere. Reading Larry Rosen's writings, this strikes me as
> fantasy. If someone bundled up ant and a gpl plugin and distributed
> the combination of the two, then there might, perhaps, be an argument
> about aggregation versus derivation. Personally, even that strikes me
> as weak.
>
> My first question is, would anyone official at ASF feel that it was a
> worthwhile use of time to try to convince the owner of this page to
> stop publishing a false and misleading claim about the terms of the
> AL? This isn't intended rhetorically; I pretty much expect that the
> answer will be 'no'.
>
> My second question has to do with the recent discussion of reflection
> as a solution to GPL dependencies. I fully appreciate that here at ASF
> we have multiple reasons to avoid GPL dependencies. Even if we all
> follow Larry Rosen's line of reasoning that calling a subroutine
> doesn't make a derived work, etc, we want to build things usable to
> people who don't agree, or who are lumbered with managers or lawyers
> or customers who dont'.
>
> At the same time, I'm comparing two scenarios:
>
> 1) Source code that compiles with no GPL-licensed artifacts in the
> same county. Maybe there's a test module that, when asked, downloads a
> GPL item and uses it in a test.
>
> 2) Source code with a build system (e.g. Maven) that automatically
> downloads GPL-licensed artifacts and uses them to enable compilation
> -- however, the resulting 'thing that gets built' works fine at
> runtime if you leave all the GPL-licensed items in orbit around
> Jupiter.
>
> Is this a distinction with a difference? (Again, I'm not asking if
> it's a big enough difference to change ASF policy. I'm trying to
> understand this to address a situation outside the ASF.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Benson Margulies <bi...@gmail.com>.
Mark,
Well, no, not quite.
1. The 'tasks' that are executed include code that extends classes in
cobertura. These classes have Apache IP notices; invalid Apache IP
notices, no less, since they claim that the code has been licensed to
the Foundation when it was not (it lives at Codehaus). So the plugin
does contain code that compiles against cobertura, not just
command-line invocations.
2. A recent proposed patch to fix aggregation introduced more calls to
more Cobertura apis. This has produced a debate as to whether, on the
one hand, the existing implementation complies with the license page,
or on the other hand, whether the strictures of the license page have
any legal validity.
--benson
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Cobertura's view of the apache license versus the GPL
Posted by Mark Struberg <st...@yahoo.de>.
please note that this doesn't affect the cobertura-maven-plugin as we only invoke cobertura via cli resp. via reflection.
Afaik the ant plugin is implemented in a similar fashion.
LieGrue,
strub
--- On Fri, 4/1/11, Benson Margulies <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Cobertura's view of the apache license versus the GPL
> To: legal-discuss@apache.org
> Date: Friday, April 1, 2011, 3:40 PM
> Disclaimer:
>
> The following is only peripherally an Apache issue, at
> most. If you
> read this and are inclined to reply by explaining that to
> me, I can't
> stop you, but I beg your forbearance.
>
> The following web page
>
> http://cobertura.sourceforge.net/license.html
>
> makes a claim: that 'license incompatibility' prevents the
> use of an
> ant plugin containing GPL code unless there's an extra
> level of JVM in
> there somewhere. Reading Larry Rosen's writings, this
> strikes me as
> fantasy. If someone bundled up ant and a gpl plugin and
> distributed
> the combination of the two, then there might, perhaps, be
> an argument
> about aggregation versus derivation. Personally, even that
> strikes me
> as weak.
>
> My first question is, would anyone official at ASF feel
> that it was a
> worthwhile use of time to try to convince the owner of this
> page to
> stop publishing a false and misleading claim about the
> terms of the
> AL? This isn't intended rhetorically; I pretty much expect
> that the
> answer will be 'no'.
>
> My second question has to do with the recent discussion of
> reflection
> as a solution to GPL dependencies. I fully appreciate that
> here at ASF
> we have multiple reasons to avoid GPL dependencies. Even if
> we all
> follow Larry Rosen's line of reasoning that calling a
> subroutine
> doesn't make a derived work, etc, we want to build things
> usable to
> people who don't agree, or who are lumbered with managers
> or lawyers
> or customers who dont'.
>
> At the same time, I'm comparing two scenarios:
>
> 1) Source code that compiles with no GPL-licensed artifacts
> in the
> same county. Maybe there's a test module that, when asked,
> downloads a
> GPL item and uses it in a test.
>
> 2) Source code with a build system (e.g. Maven) that
> automatically
> downloads GPL-licensed artifacts and uses them to enable
> compilation
> -- however, the resulting 'thing that gets built' works
> fine at
> runtime if you leave all the GPL-licensed items in orbit
> around
> Jupiter.
>
> Is this a distinction with a difference? (Again, I'm not
> asking if
> it's a big enough difference to change ASF policy. I'm
> trying to
> understand this to address a situation outside the ASF.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org