On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote: > The dual license makes a difference because if someone wants to make a change > that Aether doesn't want it can easily be incorporated here since the > original class could be taken and modified as necessary.
Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse? The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it. The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back. > We'd have to figure out how to stitch those changes together, but from the > guidance I got I don't believe this would be prohibited by the board. > Without the dual licensing it would be much harder to create these sort of > enhancements as the original class could only be used in binary form. > > I don't believe anyone is concerned with Aether becoming "unusable" for > Maven. My understanding of the concern is that interaction with the > repository(ies) and artifact resolution are areas that people still feel has > lots of room for improvement and don't want to go to a different community to > do it. The idea that one has to go outside of the Maven project to make > changes to part of what many to be a core function is what is of concern. This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether. > > Ralph > > On Jul 30, 2011, at 10:31 AM, David Jencks 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: [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] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
