See below Sent from my iPhone
On Jul 30, 2011, at 10:33 AM, Jason van Zyl <ja...@sonatype.com> wrote: > > On Jul 30, 2011, at 4:16 PM, Ralph Goers wrote: > >> See below. >> >> Sent from my iPhone >> >> On Jul 30, 2011, at 9:39 AM, Jason van Zyl <ja...@sonatype.com> wrote: >> >>> >>> 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. >> >> We have been told by the VP of legal we cannot do this. >> > > It can't be for legal reasons. They are telling you that you don't have the > right to take a codebase and fork it for which the license allows? For which > Apache 3rd party policies states you can consume as a binary? I'm not saying > you want to do this but I can't see how you're legally not entitled to do > this. > It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. >> >>> How are you stopped from doing anything with the code? Including actually >>> contributing to the project at Eclipse? >> >> We are not. My assumption has always been that what has been discussed is >> wrt something that Aether wouldn't accept - a purely hypothetical situation >> right now. > > You probably couldn't care less what the main body of Aether does and there > are extension points which allow you to do pretty much anything you want. The > maven-aether-connector is a good example. > >> >>> The only difference you site is being within ASF SVN or not. Nothing stops >>> you from forking the code and modifying it. >> >> Are you saying you would be willing to provide a software grant to allow us >> to do so? That would change the situation dramatically. > > No, I'm not saying that. I believe in the EPL and the function it serves. You > don't have to agree with me but I ask you respect my choice. I don't think > this adversely affects anything with respect to Maven. The same counter to > the merit wall argument I'm willing to extend to anyone who wants it. If you > wanted to be listed as a committer you can be. Would that make you feel more > comfortable? Politics don't stand at Eclipse so there would be no way I could > do anything to force you out of the project once you were part of it, if that > concerned you. Mike would toss me out before he let me attempt to throw > someone else out. Then if you chose to implement anything nothing would stop > you. > > Additionally, I'm sure at some point in the future if you pointed at some > harmful change in Aether the board would let you fork the project at Github > and absorb the binary you produced. There is already precedent for absorbing > EPL binaries so I can't see how that could legally be a problem. > >> >>> 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: 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 >>>> >>> >>> 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 >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
