> > I think you are going to have to. Mark isn't the only one who has expressed > the sentiment. Some of the discussions I've seen on changing the relationship > Maven has with repository managers would surely require changes at the Aether > layer.
I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. So, I can imagine a thread of discussion about forking Aether (or anything else) to achieve control, but that's not this thread. My primary view in opposition to forking is the this: Sonatype and the Maven PMC share an interest in the success of Maven. The current situation isn't ideal, but it could be a whole lot worse. Based on recent history, I don't personally believe that dramatic tactics are the best option to achieve cooperation here. Forking would, in my opinion, come in under the category of 'a dramatic tactic.' My secondary argument has to do with workload. This development community is trying to maintain a giant raft of stuff. Deciding to fork these components without any visible plan to find the effort to work on them would be, in my opinion, 'shooting ourselves in the feet'. I might go so far as to ask people proposing a fork to list their recent commits to core Maven code. Another way to put this: If there is a majority of PMC members willing to vote +1 to just accept Aether as EPL (which means more work if relations with Sonatype degenerate and we wish to disentangle), let's do that. If there isn't, then the next step in my view is to talk to Sonatype about the dual license. I personally thing that it is nuts to fork without talking to Sonatype first. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
