Re: [VOTE] Incorporate EPL Ether in Maven Releases

[Brett Porter <br...@apache.org>]

On 31/07/2011, at 8:57 AM, Jason van Zyl wrote:

> Ok, I'll pick up from Ralph's discussion.
> 
> On Jul 29, 2011, at 1:16 PM, Brett Porter wrote:
> 
>> -0
>> 
>> I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives.
>> 
>> However, I would strongly prefer it to remain dual licensed:
>> - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time
> 
> If you can't fork any version of Aether per ASF board guidelines/mandate (I'm only repeating what Ralph said) then what does it matter? And let's say this is not the case, worst case you fork it at Github, make your changes and create a binary. This doesn't hinder you from doing anything if the board changed it's mind on this policy. My preference would certainly be not to fork it but the license affords you that right.

I think what has been said is the same in this regard. We can certainly legally fork it, but it's not a great idea.

What I'm saying is that, as Maven is a project under the Apache License, it would give us more options if Aether was too. Just one example is If there is an insufficient abstraction and we need to make a customisation, we can pull a class or two in to Maven (even temporarily). That's preferable for everyone than having an unofficial fork at github, or having to replace the whole thing, or having to straddle two projects.

I don't want us to be in a situation where we need to exercise the additional rights provided by the license, but that doesn't mean they're not a good thing to have.

>> 
>> - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0.
> 
> There's precedent for redistributing EPL at the ASF, and the EPL is commercially friendly. Millions of people use Eclipse, extend Eclipse so I really don't think users have a problem with the EPL.


Yes, that's true. I'm not saying we can't accept it at all. It does however impose more conditions than any previous release of Maven, so given the history and current state of things I feel like it would be better to be able to continue to use it under the Apache License. 

There's also plenty of precedent for dual-licensing at Eclipse - JGit and Jetty come to mind.

I don't see what problem has been solved for either project by removing it. If changing it back cools this down and saves us all some time writing mail about hypotheticals, surely that's worth it alone :)

> 
>> - it had the terms of the AL 2.0 when we agreed to incorporate it
>> 
> 
> As I said to Mark things here have changed I prefer in the EPL and what it affords. If I have a choice of organization it's the Eclipse Foundation and the preference is not to dual license. We may not agree about foundations or licenses but our commonality is Maven users. If you believe you can serve them better by forking the code and not joining the Aether project then that's your prerogative. I can't honestly see how that would be, but you're free to do what you like.
> 
> I can't see what danger Maven would ever be in with Aether being at Eclipse and EPL. Even less if people here chose to be committers on the project. The current count is 6 people here being committers on Aether. The more people from here over there the more likely your requests for change will be incorporated.
...
> 
> 
> The chances that upstream requests for change are not accepted are close to zero, especially with a bunch of committers here on Aether. This is virtually no different than Plexus and Modello. Kristian made the last set of changes on a Plexus project and released them. I don't know when the last release of Modello happened but I think that was Hervé.

I believe that to be true, and to remain the case, but what I believe doesn't matter. I think you should also be listening to the fact that both of those people you mentioned voted -1 until the code was released at Eclipse. I don't want to put words in their mouth (so correct me if I'm wrong), but I interpret that as a sign that even with a low barrier, the current process is not optimal.

Going back to your first paragraph above again, I don't want the only options to be "join Aether" or "fork the code". I'd like to fix any Maven bug without having to do those things 99% of the time.

It is time to break the cycle of having to straddle projects. If some folks want to participate in Aether because they find that something fun to work on, that's great. I'm glad there's a low barrier. But nobody should be forced to join just because they want to serve Maven users. If that's the case, it's broken and we need to fix it.

You've claimed that is possible - others here are saying its not. We should deal with more concrete examples there. Whatever the reality is in the mean time we can't make that assumption.

As you've said above, circumstances change. They may change again. Aether is not yet at Eclipse, and even then will take some time to establish a sufficiently independent community, and level of maturity that we would have the same certainty about it as other dependencies. The decision making process is clearly different than if we were deciding whether to incorporate, say, Equinox.

If you were to consider retaining a dual license on the code, then we don't have to rethink our policies, we don't have to get stuck in limbo for weeks or months, and it reduces the risk of anyone making rash short term decisions. It gives us more certainty, and some more options if we need them, while we wait for the landscape to mature.

Whatever the outcome of this or subsequent votes, I still hope you'll reconsider that decision.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org