From easyant-dev-return-96-apmail-incubator-easyant-dev-archive=incubator.apache.org@incubator.apache.org Fri Mar 11 16:18:49 2011 Return-Path: Delivered-To: apmail-incubator-easyant-dev-archive@minotaur.apache.org Received: (qmail 87612 invoked from network); 11 Mar 2011 16:18:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Mar 2011 16:18:49 -0000 Received: (qmail 77779 invoked by uid 500); 11 Mar 2011 16:18:49 -0000 Delivered-To: apmail-incubator-easyant-dev-archive@incubator.apache.org Received: (qmail 77756 invoked by uid 500); 11 Mar 2011 16:18:49 -0000 Mailing-List: contact easyant-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: easyant-dev@incubator.apache.org Delivered-To: mailing list easyant-dev@incubator.apache.org Received: (qmail 77748 invoked by uid 99); 11 Mar 2011 16:18:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Mar 2011 16:18:49 +0000 X-ASF-Spam-Status: No, hits=1.0 required=5.0 tests=SPF_HELO_PASS,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of nicolas.lalevee@hibnet.org does not designate 216.86.168.183 as permitted sender) Received: from [216.86.168.183] (HELO mxout-08.mxes.net) (216.86.168.183) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Mar 2011 16:18:39 +0000 Received: from hibpro.anyware (unknown [84.14.163.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 334D1509B3 for ; Fri, 11 Mar 2011 11:18:17 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Third Party Jars From: =?iso-8859-1?Q?Nicolas_Lalev=E9e?= In-Reply-To: <87hbbbqfqk.fsf@v35516.1blu.de> Date: Fri, 11 Mar 2011 17:18:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74B4ABF8-508E-465E-B2FB-CBB604224FB5@hibnet.org> References: <87y64nqkvw.fsf@v35516.1blu.de> <87hbbbqfqk.fsf@v35516.1blu.de> To: easyant-dev@incubator.apache.org X-Mailer: Apple Mail (2.1082) X-Virus-Checked: Checked by ClamAV on apache.org Le 10 mars 2011 =E0 14:14, Stefan Bodewig a =E9crit : > On 2011-03-10, Jean-Louis Boudart wrote: >=20 >>>> So plugins could be released under apache licenses and specify in = their >>>> dependencies such as : >>>> >=20 >>> 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. >=20 >> Then how maven checkstyle plugin could be hosted and distributed = under ASL ? >=20 > Because there is a backdoor that I have neglected so far: > - it is OK to have a > dependency on LGPL projects if they are for optional components. >=20 > 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. >=20 > [SNIP] >=20 >> And if dependencies are not distributed within easyant but retrieved = from >> public maven repositories at runtime by project using coberta plugin = ? >=20 > 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