Actually, from the responses given to my question I'm sure the board would not look fondly on a fork at github either.
On Jul 30, 2011, at 10:28 AM, Ralph Goers wrote: > The board will not look fondly on Maven switching to a fork hosted at Apache > Extras. However, I'm not sure what they would think about a github fork > since sonatype-aether is hosted there and that is precisely what github > promotes. > > Ralph > > On Jul 30, 2011, at 9:50 AM, Mark Struberg wrote: > >> The 'funny' thing is that I always hear the ranting about how complicated >> the code handling at Apache. But then: it took them way over 2 years to get >> m2eclipse cleared in Eclipse! >> So their arguments against the ASF are just moot. It looks like it's nothing >> more than a personal problem. >> >> If we have no ability to fix bugs in that stuff, then we gonna kick it out >> sooner or later. I'll dig into the problems we have in our CI atm, and if it >> turns out to be another aether bug, then I'll start a fork over to >> apache-extras where every Maven committer can participate if he likes. >> Of course, the doors are not closed, but we are currently doomed to be >> completely depending on an external project which was a central part of >> maven-core short time ago. >> >> >> LieGrue, >> strub >> >> >> --- On Sat, 7/30/11, Stephen Connolly <[email protected]> >> wrote: >> >>> From: Stephen Connolly <[email protected]> >>> Subject: Re: [DISCUSS] incorporate EPL Aether >>> To: "Maven Developers List" <[email protected]> >>> Date: Saturday, July 30, 2011, 1:00 PM >>> well it seems to me that we need to >>> ensure that aether is not leaking into >>> our public api. if it is entirely private from plugins, >>> then i really don't >>> care if it is epl or dual... dual would be nicer, and truer >>> to the original >>> plan whereby the code would be developed at github for >>> speed, and then given >>> back to maven. that plan changed, and now the code is >>> (likely) ending up at >>> eclipse... Jason has reasons for eclipse... that is just >>> reality. personally >>> i feel that it is another merit hurdle to have the code at >>> eclipse, but then >>> having maven at apache is a legal pain for m2eclipse >>> because of eclipse's ip >>> review policy, so i can see why Jason would want as much of >>> the code >>> m2eclipse depends on at eclipse. >>> >>> in any case, let's wait >>> >>> - 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 12:47, "Benson Margulies" <[email protected]> >>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
