Stephen, The problem we have here is that, under point (2), the horse has already left the barn. Or, at least, we'd need to re-evolve from Hyracotherium (Maven 2.2) back to Equus to really get rid of this problem. Maybe the move to Eclipse will result in a more open and equitable process of establishing merit for those components. That's the hope.
The PMC could have chosen to require a grant as a condition of incorporating any version of AEther into Maven, and it didn't. That's the history. At this point, who said or promised what to whom at that point doesn't matter. Commits were made that caused Maven to depend on code outside of Apache. What's now clear is that this was a one-way street, *whatever the license on the code*, due to the policy requirement for voluntary contributions. Under point (1), well, it's clear that the board would take a dim view if a group of people indistinguishable from the Maven PMC were to undertake what I labelled as (b). I'm not sure what they'd think of some other variations with the same effect. Mostly, the tone of the remarks is that the Maven community comes across to them as a bunch of whiny children. This may or may not be a fair characterization. In my limited experience of reading board@, the board tends to adopt this tone until someone shows them a really good reason not to. A manager of mine long ago used to claim that one of the jobs of an executive was to impose a tax on people who used their time, to incent those people to solve problems for themselves. The board's harsh tone looks to me like a message along those lines. Now, some people have found the AEther merit wall impenetrable, and some haven't. The board is looking for the PMC to make a serious, adult, attempt to work this out with the legal owner of the code before they hear about deviations from policy or end-arounds. Trading more or less insulting public emails with Jason does not qualify under that rubric, in my opinion. The PMC could make an effort to engage Sonatype more formally either now, or after a move to Eclipse, in an effort to work out a tolerable solution to the 'merit barrier' problem. If such an effort fails, then it would make sense to approach the board and ask for help and advice. Me, if I had a vote, I'd vote for now, in an effort to avoid stalling useful bug fixes any longer than necessary. As for the 'leaking API' problem, anyone who felt strongly enough could start typing a set of shims in org.apache.maven that are a simple pass-through to AEther. Plugins could call it, and in the (unlikely) event that someone ever pulls up their socks and does AEther all over again, it can drop in. In my very personal opinion, a change back to a dual-license tomorrow would make only a symbolic difference. It would not suddenly enable a fork-back, and it would not change the merit barrier. So my view is that efforts should focus on the real issue, which is the ability a more or less cohesive Maven community to maintain Maven, and not to a fight about the licenses. --benson On Sat, Jul 30, 2011 at 2:12 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 1. are you seriously telling me that if acme corp were to fork aether, and > do a shed-load of work on it, resulting in a far better aether than the > eclipse hosted one and it was still epl licensed, that the board would view > that as a breach of policy? if the answer is yes, then this is a sad sad > world we live in. > > 2. i cannot speak for anyone else, but i am concerned that core maven > functionality is being moved behind another merit wall... if i want to fix a > bug in core, my gut tells me 8 times out of 10 i will need to hit aether... > having to cross a merit wall to do so is nuts... the whole point of aether > being developed at github was to remove a merit wall... but then Jason > decided to move aether to eclipse, and the sonatype cla discouraged > collaboration, and we are where we are. there may be others who object > because they feel Jason is pushing our hand, and stealing another OSS > project to eclipse... but i am not obey of them. i am a merit wall objector. > the only merit to work on a project is the work you are doing right now... > Jenkins and github teach us that... eclipse is a higher merit wall than > apache, and that is my gripe with eclipse.... i have a similar gripe with > apache, but it is less if an issue for me as i am inside the wall! > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 30 Jul 2011 18:32, "David Jencks" <david_jen...@yahoo.com> wrote: >> I also was just about to point out that the legal discuss thread indicated > that (b) and (c) are equivalent violations of apache policy. >> >> Since jason/sonatype doesn't want this code at apache, and the board > doesn't want us forking it somewhere else to use it because jason/sonatype > doesn't want the code at apache, I don't see why the dual licensing would > make any difference. We still can't bring the code here or fork it anywhere > else to use it inconsistently with the owners wishes. I think we either use > it as-is, or don't use it at all. >> >> I'm not sure I understand the thinking behind the idea that sonatype will > make aether unusable for maven (isn't this the basic concern over using > aether?). I don't see this as a plausible scenario. >> >> thanks >> david jencks >> >> On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: >> >>> The board made it pretty clear that option b is also highly discouraged > so I wouldn't list that as an option. The only viable path I see will be to > ultimately include the EPL version of Aether and then replace it with our > own code when someone decides there is something they want to do that > requires it. A dual licensed version of Aether would probably insure a > complete replacement is never necessary. >>> >>> Ralph >>> >>> On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: >>> >>>> I'd like to to try to put a little oxygen into this thread now, given >>>> the rather clear results of the vote thread. >>>> >>>> Ralph posed the following question on Legal Discuss: 'Can the Maven >>>> PMC pull a dual-licensed version of AEther back into Apache without a >>>> grant from Sonatype?' >>>> >>>> The answer was, "legally yes, but it is counter to long-established >>>> policy, and strongly discouraged by a number of senior ASF people >>>> (including a board member or two)". >>>> >>>> So, the community has some choices. It seems to me that the viability >>>> of these different choices depends on the viability of walking away >>>> from AEther. In practical terms, the choices are: >>>> >>>> a) Use versions of AEther controlled by 'someone else'. >>>> b) Create our own 'someone else' at apache-extras or elsewhere. >>>> c) Go down the path of becoming an exception to the policy and take on >>>> reworking AEther from the last dual-licensed version. >>>> d) Start All Over Again from Maven 2.2. >>>> >>>> From the vote comments, it seemed to me that a plurality of people >>>> felt that EPL at Eclipse was tolerable. So that argues for sitting >>>> still for now. I offer only the observation that forking into >>>> apache-extras 'works' the same way today, or after the code appears in >>>> Eclipse. In other words, adopting what's out there today only makes >>>> choice (c) harder, it doesn't have any impact that I see on a, b, or >>>> d. However, a 'no' vote is a 'no' vote, so this is all just food for >>>> thought. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
