incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Third Party Jars
Date Fri, 11 Mar 2011 16:18:16 GMT

Le 10 mars 2011 à 14:14, Stefan Bodewig a écrit :

> On 2011-03-10, Jean-Louis Boudart wrote:
> 
>>>> So plugins could be released under apache licenses and specify in their
>>>> dependencies such as :
>>>> <dependency org="checkstyle" module="checkstyle" revision="xxx"/>
> 
>>> It is not possible to write a checkstyle plugin that was licensed under
>>> any license incompatible with the LGPL - this includes the Apache
>>> Software License.  Unless you write a task like Cobertura's Ant task
>>> that jumps through a hoop or two in order to insulate itself from the
>>> GPL.
> 
>> Then how maven checkstyle plugin could be hosted and distributed under ASL ?
> 
> Because there is a backdoor that I have neglected so far:
> <https://issues.apache.org/jira/browse/LEGAL-54> - it is OK to have a
> dependency on LGPL projects if they are for optional components.
> 
> In case of the Maven checkstyle plugin the Maven PMC likely sees the
> plugin as optional part of Maven so it looks OK.  I would consider the
> plugin itself the unit of distribution and thus the checkstyle
> dependency was all but optional for the plugin.  Obviously people can
> have different opinions on this.
> 
> [SNIP]
> 
>> And if dependencies are not distributed within easyant but retrieved from
>> public maven repositories at runtime by project using coberta plugin ?
> 
> How is this going to happen?  People download EasyAnt and the plugin
> from Apache thinking the code is Apache licensed and as soon as they run
> the plugin a GPLed jar is downloaded without asking them?  I can't say I
> like the idea.  At least the download page of the plugin should tell
> them.

The plugin would be downloaded (and therefore the associated third party jars) only if they
explicitly want to use that plugin. If they do want to use checksyle in their build, then
they need to declare it in their easyant build file. Then everything gets automatically downloaded.
So checkstyle is optional regarding the core of easyant, but required for the easyant-checktyle-plugin.

I think that our easyant plugin glue is OK regarding the ASF rules as the user explicitly
declare he wants the checkstyle integration and I would assume that he then knows the checkstyle
license requirements.

But as you pointed out, we may want to notify to the user that he is downloading an non ASL
compatible artifact at some point. This make me think of the plugin installer in Eclipse.
We can add external repositories within Eclipse. And at the actual install of an external
plugin, there is a page indicating the license of the plugin to download and the end user
have to "accept" it before continuing. Maybe we could set something like this ?

As Jean-Louis also pointed out, our use case is not different from the Maven one. There is
the core and there is some optional glue here and there to bridge with some third party dependencies.
Would the Maven guys doing it wrong from the start ? (even if I'm thinking very loud about
their technical design, I am only talking here about the legal stuff, don't get me wrong here
;) ).

Nicolas


Mime
View raw message