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]
