Hi! I see 3 ways to go for the macker plugin
1.) move it to sf.net and make it GPL too 2.) add a ClassPath Exception clause to macker.jar 3.) invoke macker only via a jvm fork 'commandline call' I personally would see 3) as only being of theoretical nature ;) And yes, I think this discussion is also important to create/refresh some awareness for all other plugins too. LieGrue, strub --- On Mon, 5/17/10, Wayne Fay <[email protected]> wrote: > From: Wayne Fay <[email protected]> > Subject: Re: [mojo-dev] [legal] mojo plugins for GPL licensed core libs? > To: [email protected] > Cc: "Barre Dijkstra" <[email protected]> > Date: Monday, May 17, 2010, 7:37 PM > I was actually contacted just > recently by Barre Dijkstra (added to CC > list) who is taking over the Macker project from Paul > Cantrell who was > the creator. > > Barre would like to take over the macker-maven-plugin as he > will also > be managing Macker itself, and I said that I had no > particular > objections. I do not expect that he will join Codehaus and > the Mojo > team but rather move it to his own groupId. > > Given the legal situation, it may make sense for Barre to > simply > rewrite the plugin (its very small) rather than making > things more > complicated by reusing it... > > This would make the entire conversation moot, unless we > want to figure > out how to handle this situation in the future for other > plugins. > > Wayne > > On Mon, May 17, 2010 at 2:10 PM, Robert Scholte <[email protected]> > wrote: > > Reading these messages, it seems like we could add a > goal to the ianal-m-p, > > namely 'verify-code' to check the usage > of imports/FQN in combination with > > the license of it's artifact. I'm pretty sure most of > us aren't lawyers, so > > it would be nice to have a plugin which could help > with these delicate > > issues. > > > > - Robert > > > >> Date: Sun, 16 May 2010 16:25:47 -0700 > >> From: [email protected] > >> To: [email protected] > >> Subject: Re: [mojo-dev] [legal] mojo plugins for > GPL licensed core libs? > >> > >> BTW, Codehaus forbids GPL licensed project > >> > >> -Dan > >> > >> On Sun, May 16, 2010 at 3:29 PM, Mark Struberg > <[email protected]> > wrote: > >> > Yea, that would be an option to write an > interface and pull in the > >> > actual implementation via > java.util.ServiceLoader or simply classForName. > >> > > >> > As far as I read the codehaus licensing > guidelines [1] we are _not_ > >> > allowed to host GPL licensed plugins at > codehaus. > >> > > >> > LieGrue, > >> > strb > >> > > >> > [1] http://codehaus.org/customs/licenses.html > >> > > >> > --- On Sun, 5/16/10, Stephen Connolly <[email protected]> > >> > wrote: > >> > > >> > From: Stephen Connolly <[email protected]> > >> > Subject: Re: [mojo-dev] [legal] mojo plugins > for GPL licensed core libs? > >> > To: [email protected] > >> > Date: Sunday, May 16, 2010, 10:22 PM > >> > > >> > IANAL, > >> > > >> > If the GPL code has tainted the > macker-maven-plugin, then we need to > >> > change the license on macker-maven-plugin to > GPL... a change that AFAIK is > >> > possible (i.e. you can go ASL-2 -> GPL you > just cannot go GPL -> ASL-2 ) > >> > > >> > > >> > I guess the question is has it been tainted? > >> > > >> > When dealing with GPL libraries, if you want > to keep yourself taint free > >> > the best way is to interface via an API that > has multiple implementations, > >> > that way you can prove that the GPL code is > only dynamically linked with > >> > your code and as there are non-GPL > implementations of the API, everything is > >> > hunky-dorey > >> > > >> > > >> > As java is all dynamic linking (except for > uberjars) the question of > >> > taint basically boils down to what API the > library you are using is... for > >> > example, if you write a JDBC client, IANAL > but my understanding is that it > >> > can safely be ASL-2 even if 99.99% of the > time it is using a GPL JDBC > >> > driver. > >> > > >> > > >> > So for example with the vcc.dev.java.net > project, I have designed a > >> > virtualization api independently from any of > the implementations... the api > >> > is ASL-2... the fact that the xen > implementation of the api will have to be > >> > GPL is OK, because I have the ASL-2 licensed > VMware implementation as the > >> > reference implementation. > >> > > >> > > >> > -Stephen > >> > > >> > On 16 May 2010 11:58, Mark Struberg <[email protected]> > wrote: > >> > > >> > Hi! > >> > > >> > > >> > > >> > I recently tried to help with the > macker-maven-plugin [1] and figured > >> > that macker [2] itself (the underlying > library being used) is GPL licensed. > >> > > >> > > >> > > >> > So, since the Mojos in macker-maven-plugin > import files from the macker > >> > library, this imo conflicts with the ASL-2 > license used in the > >> > macker-maven-plugin. Do be more specific, the > macker-maven-plugin being > >> > ASL-2 licensed conflicts with the GPL > license. > >> > > >> > > >> > > >> > > >> > So, what to do? > >> > > >> > > >> > > >> > LieGrue, > >> > > >> > strub > >> > > >> > > >> > > >> > PS: please note the distinction between GPL > and LGPL and ClasspathGPL. > >> > > >> > > >> > > >> > > >> > > >> > [1] http://mojo.codehaus.org/macker-maven-plugin/ > >> > > >> > [2] http://www.innig.net/macker/ > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > --------------------------------------------------------------------- > >> > > >> > To unsubscribe from this list, please visit: > >> > > >> > > >> > > >> > http://xircles.codehaus.org/manage_email > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > --------------------------------------------------------------------- > >> > To unsubscribe from this list, please visit: > >> > > >> > http://xircles.codehaus.org/manage_email > >> > > >> > > >> > > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > > > > ________________________________ > > New Windows 7: Find the right PC for you. Learn more. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
