Hi Barre! Thanks for your response!
Adding a classpath exception to your license would certainly make it easier for other projects to consume macker. ad 1) I don't think it's possible to change the license (minor change but it's basically a license change) for an already release project. So I guess you'd have to do all the voting stuff / getting the agreement of all major contributors and then create a new version of macker with that GPL+ClassPathException license which we can consume later on. At least that would be the safe route. ad 2) The macker-maven-plugin is still in the sandbox and didn't yet got released ad codehaus. So I think a transition over to your team would also be pretty easy - especially since Wayne wrote almost all the code and did already agree + it seems you need to write lot of the stuff from scratch anyway after changing your interfaces. But I'm not a codehaus official, so please consider this as a private opinion from whom who doesn't like to get sued for license infringement ;) I think we all gained awareness now and I'm sure you folks will find a solution for this in the next few weeks. txs and LieGrue, strub --- On Fri, 5/21/10, Barre Dijkstra <[email protected]> wrote: > From: Barre Dijkstra <[email protected]> > Subject: Re: [mojo-dev] [legal] mojo plugins for GPL licensed core libs? > To: "Mark Struberg" <[email protected]> > Cc: [email protected], "Jasper de Vries" <[email protected]>, > [email protected] > Date: Friday, May 21, 2010, 9:04 AM > Hey, > > sorry for the delay in my response. > > I've been looking at the exempt clause in the GPL license > (I've never > had to use it before in any my licensing) and it looks like > a good > option. > As far as my response on the 3 options of Mark; > 3 is indeed a theoretical option, since both other options > are more > plausible ;-) > > For the next (actually first) major release of macker the > commiters of > macker are currently doing a major overhaul of macker which > includes > seperating the program entry points (cli, maven plugin, ant > plugin, > etc.) from the rest of the logic and making writing new > ones as easy > as 1...2...3..., so a rewrite of the plugin will be > necessary for that > release anyway. As discussed briefly with Wayne, we would > indeed like > to migrate the code to the current codebase (or write our > own version) > so a maven connector can/will be distributed with macker by > default > (or as part of a connector package, which is still under > consideration). > What we can do is add the exempt clause for the current > version of > macker since it won't break the current licensing, just > clarify (and > further legalise) it. > > Again, sorry for my late response and could you reply if > this option > is acceptable from your point of view? > > As for macker moving to codehaus; this is not something > that we can do > in the short term since it adds some extra > restrictions/demands to the > codebase and the project. This does not mean that we're > not > considering it for the future, we will just need to make a > small > analysis of the impact of the move on the project, etc. > > With kind regards, > > Barre Dijkstra > > On Fri, May 21, 2010 at 8:10 AM, Mark Struberg <[email protected]> > wrote: > > Folks, I didn't hear anything now for 4 days. > > > > Imo we should go on and drop the macker-maven-plugin > from the sandbox, since this obviously contains a legal > threat. > > > > LieGrue, > > strub > > > > --- On Mon, 5/17/10, Mark Struberg <[email protected]> > wrote: > > > >> From: Mark Struberg <[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, 8:25 PM > >> 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 > >> > >> > >> > > > > > > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
