Re: [DISCUSS] incorporate EPL Aether
On 31/07/2011, at 6:04 AM, Benson Margulies wrote: Kristian, legal-discuss is a public list, with public archives. You can go read these remarks for yourself in the archive. I apologize for assuming that you or anyone else didn't know that. Yes I am a member, but Ralph and I are not quoting any private crap. Note that some Ralph posed a relatively specific legal question to start with, and then it grew and grew into a more complex policy discussion that board members happened to participate in. If you want a clear statement of the board's view, you can ask the board. The board in general would, I bet, rather get a coherent question from the PMC chair in the monthly report, and deal with that, but nothing stops you from sending email to board@ stating your view of the question at hand and asking for clarification. That's all true. I noticed a few people talk about board policy in this thread, and I think it's important to be clear on a couple of things. Board policy is nowhere near as heavy handed as some here may think - in particular, the board does not dictate any technical direction for a project. In the interest of protecting the Foundation, they will however ensure that all legal obligations are being met, that a project has a healthy development community, and that it is aligned with the principles of the ASF. As far as I can tell, these are all the policies relevant to this discussion: http://www.apache.org/legal/src-headers.html#3party http://www.apache.org/legal/resolved.html#category-a http://www.apache.org/legal/resolved.html#category-b http://maven.apache.org/developers/dependency-policies.html The statements made on legal-discuss have some significant weight given who made them, though I don't think they intended them to be ad-hoc policy making on behalf of the board. The comments were not so much policy setting as they are just common sense. Don't risk the project by bringing in a codebase that the main copyright holder doesn't want you to. Don't let a major piece of functionality be developed outside of the project in the first place. I will specifically mention that as a board member myself, my comments on this list should not be treated as a statement from the board unless I've said otherwise :) Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
On 31/07/2011, at 4:51 AM, Benson Margulies wrote: Trading more or less insulting public emails with Jason does not qualify under that rubric, in my opinion. Yes, personal attacks have no place here. Coming back after the weekend, I was disappointed with the tone of the thread. Everyone needs to chill out. There is a problem here, but I hope everyone involved is looking for a solution, not a victory. Thanks to those that have made constructive suggestions! Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
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
Re: [DISCUSS] incorporate EPL Aether
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 bimargul...@gmail.com 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
Re: [DISCUSS] incorporate EPL Aether
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 stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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
Re: [DISCUSS] incorporate EPL Aether
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
Re: [DISCUSS] incorporate EPL Aether
actually now the argument is that asf's processes are not rigorous enough! seemingly some of sonatypes customers think the asf ip process is too weak... but when i asked a certain person how the epl process was any stronger, given that they take signatures on the cla's on trust and don't verify them, it seemed to me that rather than answer they decided they were going to leave the pmc abduction resign as about asf member... or maybe that was just a co-incident... either way i never got an answer. back to the topic. mark do not rush to fork just yet. lets wait a week or two. rushed actions do not build a community, and it feels to me that everyone has been rushing their actions and making things worse for everyone. if we slow down a piece and get everyone to see some sense we might be able to get a resolution that is a win-win and a win for users too - 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 17:50, Mark Struberg strub...@yahoo.de 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 stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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
Re: [DISCUSS] incorporate EPL Aether
On 7/30/11 9:00 AM, Stephen Connolly wrote: 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... I agree completely. But, how can we keep it from leaking into plugins, when it's using the same plexus component system as the rest of Maven? This has long been a problem inside Maven, namely that we can't control _which_ components plugin devs have access to, and therefore we have an extremely difficult time deprecating/removing old components or reworking the internal design. Maybe firewalling and restricting the list of core components available to plugin devs is what we really need to address in order to address this concern. 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 +1 I want to at least see Aether in a stable location with some real bylaws and culture before I'll be okay with it. This was supposed to happen long ago, and as I remember it, that promise is a big part of why we adopted Aether... That, and this argument that we should give in to whatever demands are made by the People Who Are Getting Things Done Around Here. Now, we see that the pressure is off to follow up on these promises, as long as we keep agreeing to adopt versions developed without corresponding movement on the promises. I think we have to take some sort of stand, or this will not improve. Words are nice, but action is better. - 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 Marguliesbimargul...@gmail.com 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
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 stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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
Re: [DISCUSS] incorporate EPL Aether
Can we create our own, new API that plugins should use for this? Eventually all of Maven could use that instead of Aether directly. Ralph On Jul 30, 2011, at 10:25 AM, John Casey wrote: On 7/30/11 9:00 AM, Stephen Connolly wrote: 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... I agree completely. But, how can we keep it from leaking into plugins, when it's using the same plexus component system as the rest of Maven? This has long been a problem inside Maven, namely that we can't control _which_ components plugin devs have access to, and therefore we have an extremely difficult time deprecating/removing old components or reworking the internal design. Maybe firewalling and restricting the list of core components available to plugin devs is what we really need to address in order to address this concern. 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 +1 I want to at least see Aether in a stable location with some real bylaws and culture before I'll be okay with it. This was supposed to happen long ago, and as I remember it, that promise is a big part of why we adopted Aether... That, and this argument that we should give in to whatever demands are made by the People Who Are Getting Things Done Around Here. Now, we see that the pressure is off to follow up on these promises, as long as we keep agreeing to adopt versions developed without corresponding movement on the promises. I think we have to take some sort of stand, or this will not improve. Words are nice, but action is better. - 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 Marguliesbimargul...@gmail.com 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
Re: [DISCUSS] incorporate EPL Aether
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
Re: [DISCUSS] incorporate EPL Aether
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
Re: [DISCUSS] incorporate EPL Aether
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
Re: [DISCUSS] incorporate EPL Aether
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. 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. 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
Re: [DISCUSS] incorporate EPL Aether
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 stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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
Re: [DISCUSS] incorporate EPL Aether
On Sat, Jul 30, 2011 at 2:52 PM, Ralph Goers ralph.go...@dslextreme.com 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. Ralph, I'd like to really understand this, so I'm going to waste everyone' eyeballs on being picky. Assume that AEther started out as a substantive, working, code base inside Apache, and then, subsequently, it had forked out. I see how your procedure works in that case, since either fork could cherry-pick from the other. What I don't follow is how it helps given the facts on the ground. There is no code base inside Apache that is close enough to AEther to absorb patches, and there never will be, unless Sonatype grants it. So I don't understand the logic whereby a return to a dual license helps us, unless it also comes with an SGA. What am I missing? 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. 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:
Re: [DISCUSS] incorporate EPL Aether
On Sat, Jul 30, 2011 at 2:55 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, from the responses given to my question I'm sure the board would not look fondly on a fork at github either. The board members' position in those emails is very critical of any fork as the next step. What the board would say if a sincere attempt to solve the merit problem failed, or if a 'rogue element' performed a fork and made a release available, is hard to say, since the board also hates hypothetical question with the power of 1000 suns. 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 stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 11:58 AM, Benson Margulies wrote: On Sat, Jul 30, 2011 at 2:52 PM, Ralph Goers ralph.go...@dslextreme.com 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. Ralph, I'd like to really understand this, so I'm going to waste everyone' eyeballs on being picky. Assume that AEther started out as a substantive, working, code base inside Apache, and then, subsequently, it had forked out. I see how your procedure works in that case, since either fork could cherry-pick from the other. What I don't follow is how it helps given the facts on the ground. There is no code base inside Apache that is close enough to AEther to absorb patches, and there never will be, unless Sonatype grants it. So I don't understand the logic whereby a return to a dual license helps us, unless it also comes with an SGA. What am I missing? Let's say you want to change how a class in Aether works. You can take the class from either in modify it if it is under the Apache license. You can then place it somewhere in Maven. After that, it is a matter of figuring out how to wire the modified class so it is used instead of the original. Under the EPL we would have to write a new class from scratch. Just so you know, my vacation is coming to an end and I will be on airplanes sporadically today so if you have other questions you'll have to be patient. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly 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
Re: [DISCUSS] incorporate EPL Aether
lø., 30.07.2011 kl. 14.51 -0400, skrev Benson Margulies: 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. Technically I am unsure if this statement is true. At the time aether was extracted, maven3 was more or less functionally complete. Most of what has happened since then was bug-fixes. All this is slightly hypothetical, but we may be able to revert from r988749 (introduction of aether) and re-work from there. The integration test suite would pretty much tell if it's being done correctly. Do not underestimate the quality of those ITs. The code-bases are sufficiently similar that selectively re-implementing specific bugfixes is an option. Now why on earth would we do all that? Can someone please point to me to the *written* statement from the board that says we can't a) fork to apache-extras or B) fork the last asl version to maven-extras on github (together with plexus and sisu ?) I'm tired of all this word-of mouth crap I seem to be getting from management upstairs; and that includes all you ASF members. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
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.
Re: [DISCUSS] incorporate EPL Aether
Le samedi 30 juillet 2011, John Casey a écrit : But, how can we keep it from leaking into plugins, when it's using the same plexus component system as the rest of Maven? This has long been a problem inside Maven, namely that we can't control _which_ components plugin devs have access to, and therefore we have an extremely difficult time deprecating/removing old components or reworking the internal design. IIUC, this problem has been solved in M3 by DefaultClassRealmManager.java#importMavenApi: visibility changed from everything is available unless we hide it (with shade) in M2 to nothing is available unless we show it I don't know the impact of hiding aether, but hiding it should be easy Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Kristian, legal-discuss is a public list, with public archives. You can go read these remarks for yourself in the archive. I apologize for assuming that you or anyone else didn't know that. Yes I am a member, but Ralph and I are not quoting any private crap. Note that some Ralph posed a relatively specific legal question to start with, and then it grew and grew into a more complex policy discussion that board members happened to participate in. If you want a clear statement of the board's view, you can ask the board. The board in general would, I bet, rather get a coherent question from the PMC chair in the monthly report, and deal with that, but nothing stops you from sending email to board@ stating your view of the question at hand and asking for clarification. I wasn't here for the technical deep history, I'm depending on what people have written lately, and as of your message (if not before) people have written what to me is a bewildering variety of contradictory things. If your copy of history is the accurate one, then it explains Ralph's views about dual licenses. In any case, Jason's invitation to all and sundry to have commit access on day one looks like an opportunity to lower the temperature on all this. I chose those words carefully, please no one accuse me of thinking that it's a guaranteed solution in a bottle. I think you've all read enough from me on this subject to last you a good long time, so I'm going to stop typing for the rest of the weekend at least. --benson On Sat, Jul 30, 2011 at 3:37 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: lø., 30.07.2011 kl. 14.51 -0400, skrev Benson Margulies: 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. Technically I am unsure if this statement is true. At the time aether was extracted, maven3 was more or less functionally complete. Most of what has happened since then was bug-fixes. All this is slightly hypothetical, but we may be able to revert from r988749 (introduction of aether) and re-work from there. The integration test suite would pretty much tell if it's being done correctly. Do not underestimate the quality of those ITs. The code-bases are sufficiently similar that selectively re-implementing specific bugfixes is an option. Now why on earth would we do all that? Can someone please point to me to the *written* statement from the board that says we can't a) fork to apache-extras or B) fork the last asl version to maven-extras on github (together with plexus and sisu ?) I'm tired of all this word-of mouth crap I seem to be getting from management upstairs; and that includes all you ASF members. Kristian - 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
Re: [DISCUSS] incorporate EPL Aether
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. 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. 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. 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
Re: [DISCUSS] incorporate EPL Aether
Jason. please read my post carefully. i did not say you were a thief, i said there may be others who feel you are... i also said i do not agree with that point of view. i will gladly accept your offer to remove the merit wall. i am just interested in making the code easy to develop and fix, for the good of the users. - 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 20:26, Jason van Zyl ja...@sonatype.com wrote: Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly 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
Re: [DISCUSS] incorporate EPL Aether
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. 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
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 4:29 PM, Stephen Connolly wrote: Jason. please read my post carefully. i did not say you were a thief, i said there may be others who feel you are... i also said i do not agree with that point of view. Sorry, I read it incorrectly. i will gladly accept your offer to remove the merit wall. Done. You will have seen the email to Wayne Beaton on the EMO. You should be listed there on Monday. i am just interested in making the code easy to develop and fix, for the good of the users. That's all I care about. I really do not believe being at Eclipse changes that. - 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 20:26, Jason van Zyl ja...@sonatype.com wrote: Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly 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
Re: [DISCUSS] incorporate EPL Aether
Jason, please stick to the facts. Here is what I found after reading through the history in the private archives. 1.) the original artifact resolution mechanism was part of maven-core 2.) you wrote a new one which does certain things a bit better 3.) you told the Maven PMC that it will finally end up back in Maven. 4.) As a result of this promise work was done to replace the original maven owned code with your stuff. If the Maven PMC and the board would have known that aether would never made it over here, then they would NEVER EVER let any aether import hit the Maven SVN! NEVER! 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. 6.) you switched your opinion and told the community that aether will not be part of maven. So one could argue that - from the effect - you stole the maven project a year of development or the ability to fix bugs themselfs. I don't say that you originally intended to do so in an intentional way. But that's what we have now! LieGrue, strub PS: Of course I know what you did for the project in the past, but that doesn't change that very topic. --- On Sat, 7/30/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 7:25 PM Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly 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
Re: [DISCUSS] incorporate EPL Aether
Many things changed within the ASF which made me extremely uncomfortable, and everyone is entitled to change their opinions and their decisions. It's not as if everything remained immutable on the ASF side. Yes, I changed my mind and decided Eclipse was the place I would like to do the majority of my open source work. If politics, the ensuing strife and resulting frustration weren't present I would probably feel differently. But I don't believe we ever blocked anyone from contributing. On Jul 30, 2011, at 4:41 PM, Mark Struberg wrote: Jason, please stick to the facts. Here is what I found after reading through the history in the private archives. 1.) the original artifact resolution mechanism was part of maven-core 2.) you wrote a new one which does certain things a bit better 3.) you told the Maven PMC that it will finally end up back in Maven. 4.) As a result of this promise work was done to replace the original maven owned code with your stuff. If the Maven PMC and the board would have known that aether would never made it over here, then they would NEVER EVER let any aether import hit the Maven SVN! NEVER! 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. 6.) you switched your opinion and told the community that aether will not be part of maven. So one could argue that - from the effect - you stole the maven project a year of development or the ability to fix bugs themselfs. I don't say that you originally intended to do so in an intentional way. But that's what we have now! LieGrue, strub PS: Of course I know what you did for the project in the past, but that doesn't change that very topic. --- On Sat, 7/30/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 7:25 PM Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly 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
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 4:49 PM, Jason van Zyl wrote: Many things changed within the ASF which made me extremely uncomfortable, and everyone is entitled to change their opinions and their decisions. It's not as if everything remained immutable on the ASF side. Yes, I changed my mind and decided Eclipse was the place I would like to do the majority of my open source work. If politics, the ensuing strife and resulting frustration weren't present I would probably feel differently. But I don't believe we ever blocked anyone from contributing. On Jul 30, 2011, at 4:41 PM, Mark Struberg wrote: 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. This one is just inaccurate. The interfaces on the Maven side are close to 100% backward compatibility with the existing APIs. We broke almost nothing and that was a lot of work. You need zero Aether imports to do anything in plugins with respect to artifact resolution. You can use them if you like but you don't have to. But's it not like we changed all the external APIs. I believe the vast majority of the Aether imports are in the compatibility layer. 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
Re: [DISCUSS] incorporate EPL Aether
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
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 5:08 PM, Ralph Goers wrote: 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. So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 5:14 PM, Jason van Zyl wrote: It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 Also note that currently we have Eclipse committers among us. Myself, Igor, Benjamin, Milos, and Jesse. Herve, Kristian and Stephen will be as part of the Aether proposal. At one point Brett and Carlos were as well. Additionally Sonatype, Cloudbees (Stephen) and Intuit (yourself) are members at Eclipse. So it's not like it's a completely foreign land. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition 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
Re: [DISCUSS] incorporate EPL Aether
This one is just inaccurate. The interfaces on the Maven side are close to 100% backward compatibility with the existing APIs. Hum, 323 aether imports for the maven-core module alone doesn't sound non-intrusive. Thats almost 15% of all imports (2930)! LieGrue, strub --- On Sat, 7/30/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 9:08 PM On Jul 30, 2011, at 4:49 PM, Jason van Zyl wrote: Many things changed within the ASF which made me extremely uncomfortable, and everyone is entitled to change their opinions and their decisions. It's not as if everything remained immutable on the ASF side. Yes, I changed my mind and decided Eclipse was the place I would like to do the majority of my open source work. If politics, the ensuing strife and resulting frustration weren't present I would probably feel differently. But I don't believe we ever blocked anyone from contributing. On Jul 30, 2011, at 4:41 PM, Mark Struberg wrote: 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. This one is just inaccurate. The interfaces on the Maven side are close to 100% backward compatibility with the existing APIs. We broke almost nothing and that was a lot of work. You need zero Aether imports to do anything in plugins with respect to artifact resolution. You can use them if you like but you don't have to. But's it not like we changed all the external APIs. I believe the vast majority of the Aether imports are in the compatibility layer. 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
Re: [DISCUSS] incorporate EPL Aether
That's fine, but who ensures us that you wont change your mind again? But fair enough, it will be much better at Eclipse than somewhere in the wild. LieGrue, strub --- On Sat, 7/30/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 9:32 PM On Jul 30, 2011, at 5:14 PM, Jason van Zyl wrote: It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 Also note that currently we have Eclipse committers among us. Myself, Igor, Benjamin, Milos, and Jesse. Herve, Kristian and Stephen will be as part of the Aether proposal. At one point Brett and Carlos were as well. Additionally Sonatype, Cloudbees (Stephen) and Intuit (yourself) are members at Eclipse. So it's not like it's a completely foreign land. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition 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
Re: [DISCUSS] incorporate EPL Aether
I would suggest you re-read Brett's last email as to why we continue to have this discussion. He seems to be able to word things a bit better than me. Sent from my iPhone On Jul 30, 2011, at 11:14 AM, Jason van Zyl ja...@sonatype.com wrote: So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
I'm not entirely sure, but I think that there may be a false dilemma here on the subject of forks. In general, the Foundation does not permit us to absorb large amounts of code without a formal grant, even if the code carries AL markings. This has come up in the incubator over and over. So, even if Aether is dual-licensed, we cannot simply fork it back into the ASF without the cooperation of the copyright holder. If the copyright holder is cooperative, they can grant even if it's EPL, and if they are not interested in granting, then, a dual license isn't a 'license to fork' into ASF svn. On the other hand, a group of people can certainly make a fork at Codehaus or github, regardless of EPL or AL. So, if I've got this right, there is no particular advantage to us of sticking to the dual-licensed version. If there was an irreconcilable disagreement with Sonatype, we can fork outside the ASF either way, and if there's no such meltdown, we don't need to fork either way. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Just reading this thread and was surprised as I wasn't aware Aether had gone EPL only. I was about to start a thread around getting a Maven 3.0.4 release pushed out using Aether 1.12 which solves a, IMHO -MAJOR- bug in Maven that prevents artifacts from being resolved properly when they come directly third party repositories. I'm not sure if this 1.12 release is EPL only or not tho. Benson Margulies wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff.
Re: [DISCUSS] incorporate EPL Aether
1.12 is EPL only : https://github.com/sonatype/sonatype-aether/blob/aether-1.12/README.md On Mon, Jul 18, 2011 at 12:45 PM, Mark Derricutt m...@talios.com wrote: Just reading this thread and was surprised as I wasn't aware Aether had gone EPL only. I was about to start a thread around getting a Maven 3.0.4 release pushed out using Aether 1.12 which solves a, IMHO -MAJOR- bug in Maven that prevents artifacts from being resolved properly when they come directly third party repositories. I'm not sure if this 1.12 release is EPL only or not tho. Benson Margulies wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff.
Re: [DISCUSS] incorporate EPL Aether
I worked on Aether to extract Maven specific parts (into maven-aether- provider): AFAIK, we are completely free to change anything in the formats used by Maven, either for POM or repositories. About licensing, I don't have any concern about EPL at Eclipse. The initial announced intend was to move the library to Eclipse foundation (with other repository formats like Eclipse's P2), and provide dual ASL+EPL license in the meantime: everything good. But actually the license restricted to EPL-only before the move to Eclipse is done. :/ Then I'd prefer to stay with an ASL version until Aether is at Eclipse. Regards, Hervé Le dimanche 17 juillet 2011, Kristian Rosenvold a écrit : sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies: After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. Hervé and I are aether committers, and if I wasn't so /extremely busy/ here on Mallorca I'd look at your patch. Opposed to Mark and Ralph, I have no qualms accepting an EPL 3rd party dependency, If you start showing an interest in aether matters I'm sure you'll get that commit bit pretty quickly yourself. I really just want to get over this license-of-the week crap we've been seeing for aether and sisu, which I think is totally unacceptable. Assuming aether actually goes to stay at eclipse I'm happy with that, until so happens I still want to keep the asl version (and fork if necessary). Technically, not that much has happened since the last ASL versioned aether, so there's no real gap to talk about. I /wish/ there was some kind of change in the pipeline that I could say made the aether/maven split problematic. But there isn't, is there ? I am much more worried about change in maven at a higher level than interfaces. I somehow sense that pom version 5 is never going to happen; but that's not aether's fault..? Kristian - 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
Re: [DISCUSS] incorporate EPL Aether
On 7/17/11 12:08 PM, Benson Margulies wrote: I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. So, I can imagine a thread of discussion about forking Aether (or anything else) to achieve control, but that's not this thread. My primary view in opposition to forking is the this: Sonatype and the Maven PMC share an interest in the success of Maven. The current situation isn't ideal, but it could be a whole lot worse. Based on recent history, I don't personally believe that dramatic tactics are the best option to achieve cooperation here. Forking would, in my opinion, come in under the category of 'a dramatic tactic.' My secondary argument has to do with workload. This development community is trying to maintain a giant raft of stuff. Deciding to fork these components without any visible plan to find the effort to work on them would be, in my opinion, 'shooting ourselves in the feet'. I might go so far as to ask people proposing a fork to list their recent commits to core Maven code. Another way to put this: If there is a majority of PMC members willing to vote +1 to just accept Aether as EPL (which means more work if relations with Sonatype degenerate and we wish to disentangle), let's do that. If there isn't, then the next step in my view is to talk to Sonatype about the dual license. I personally thing that it is nuts to fork without talking to Sonatype first. I understand where you're coming from WRT workload, but if you haven't learned something from recent history in terms of exporting control of this project, I'd suggest you re-read whatever archives you have access to. If you need details, I can provide them. If we switch to the EPL-only version of Aether, we lose our ability to innovate in how Maven resolves artifacts...or, at least, we lose our ability to do this without the approval of the Aether folks. Normally, that may not be a bad thing, having an alliance with another project. But this is central to what Maven does...it's not just some plugin or supplemental protocol. I've hacked into the way Aether works - a little bit - to get the mirror-group-routing branch of maven3 to work (http://svn.apache.org/repos/asf/maven/maven-3/branches/mirror-group-routing/). This branch is meant to allow more flexible routing of mirrors and groupId-URLs. Anyway, I've had to hack into Aether to get this running, and it's not been fun. All of my work there was done in a way such that it would work without requiring an Aether patch, since I assumed that the Aether community wouldn't find a lot of value in my work. IMO, there's not much that we could do regarding the way Aether resolves artifacts without requiring a fork anyway. If we want to incorporate future Aether versions in Maven, I'm -1 unless Aether changes back to dual licensing, or we fork Aether into Maven and re-streamline the consolidated codebase. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
On 7/18/11 5:23 PM, Hervé BOUTEMY wrote: I worked on Aether to extract Maven specific parts (into maven-aether- provider): AFAIK, we are completely free to change anything in the formats used by Maven, either for POM or repositories. About licensing, I don't have any concern about EPL at Eclipse. The initial announced intend was to move the library to Eclipse foundation (with other repository formats like Eclipse's P2), and provide dual ASL+EPL license in the meantime: everything good. But actually the license restricted to EPL-only before the move to Eclipse is done. :/ Then I'd prefer to stay with an ASL version until Aether is at Eclipse. IMO these discrepancies between what was _said_ regarding licensing and what we've seen _happen_ regarding licensing is the best possible reason not to hand over the option to fork Aether by accepting the EPL version. If we can't fork, what control do we retain over the codebase that drives artifact resolution in Maven? What guarantees do we have that we'll be able to continue contributing, or that our contributions will continue to be available for Maven's use? Personally, I have private reasons to believe that committership in Aether would not be open to just any Maven committer who showed merit...at least, not until it becomes an Eclipse project, and maybe not even then. Regards, Hervé Le dimanche 17 juillet 2011, Kristian Rosenvold a écrit : sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies: After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. Hervé and I are aether committers, and if I wasn't so /extremely busy/ here on Mallorca I'd look at your patch. Opposed to Mark and Ralph, I have no qualms accepting an EPL 3rd party dependency, If you start showing an interest in aether matters I'm sure you'll get that commit bit pretty quickly yourself. I really just want to get over this license-of-the week crap we've been seeing for aether and sisu, which I think is totally unacceptable. Assuming aether actually goes to stay at eclipse I'm happy with that, until so happens I still want to keep the asl version (and fork if necessary). Technically, not that much has happened since the last ASL versioned aether, so there's no real gap to talk about. I /wish/ there was some kind of change in the pipeline that I could say made the aether/maven split problematic. But there isn't, is there ? I am much more worried about change in maven at a higher level than interfaces. I somehow sense that pom version 5 is never going to happen; but that's not aether's fault..? Kristian - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 2:08 PM, Mark Struberg wrote: Hi Jason! Eclipse doesn't have problems with consuming ALv2 dependencies because ALv2 explicitly allows sublicensing - but EPL doesn't! So this is an unidirectional way and exactly the reason why we imo cannot do this. The EPL also explicitly allows sublicensing. Look at the Grant of Rights in 2a[1]. Tomcat embeds the Eclipse Java Compiler for example. I'm not sure how they distribute it, they can relicense and sublicense if they wish but I don't believe they have to. I haven't looked at the distribution in a while. I think you're talking about the EPL not allowing the relicensing of source code. Once the code is EPL it remains so and this property is specifically for stability. No one, for example, could ever take core parts of the Eclipse Platform and relicense them to something that wasn't acceptable to the community. All contributors retain copyright and so it would be almost impossible to relicense anything in the Eclipse Platform. Everyone investing in the platform knows that it's always going to be in that form. The cores of things remain EPL while people can make extensions and license those under anything aside from strong copy left licenses. That all aside your argument did not appear to me to be a legal one, but that Eclipse has problems with projects where other parties control the dependencies. I think for one case in history an Apache project was forked temporarily to make a release train. I believe in this case it was Ant. Aside from that some OSGi manifests are added but generally Eclipse folks are happy not to have to maintain everything. There's certainly no proliferation of forks lying around at Eclipse, most contributions find their way back to the project which is really how it should be IMO. Btw, you should know exactly how hard it is to pass Eclipse' IP review and stuff. Wasn't that the reason why you needed to drop a few plexus dependencies because of uncertain IP? They are careful, which is a good thing. I'm intimately familiar with the process, yes. What does this have to do with your original argument? Like all 3rd party libraries that are deemed to be required the Eclipse legal team tracked down most of it and we culled/reimplemented what we needed to. What has been sanctioned lives in the maven runtime module in m2e-core. It's all in IPZilla. Couldn't you just put the ALv2/EPL dual licensing back in place and all are happy? Noone of us is eager to maintain aether or to fork it if not necessary. But otoh not being able to fork it if there were problems is imo a no-go. Also, there are a few contributors eager to ship patches it seems... Yes, that's Benson and he seems fine with Aether where it is and has even agreed to sign the CLA. Kristian and Hervé are committers and also seem to be fine with the current setup. The proposal for Aether at Eclipse has gone live[2]. I stated previously that Aether would be an Eclipse project and that Sonatype didn't wish to house this important library themselves. I believe the Eclipse Foundation and the EPL are great things for open source projects. Diversity is a good thing and working with many organizations to me has no downside. I feel the Eclipse Foundation is the right place for Aether. Though nothing stops you from forking the older ASL version, there's also nothing stopping you from contributing to Aether at Eclipse. [1]: http://www.eclipse.org/legal/epl-v10.html [2]: http://eclipse.org/proposals/technology.aether/ txs and LieGrue, strub --- On Sun, 7/17/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 4:36 PM On Jul 17, 2011, at 11:55 AM, Mark Struberg wrote: Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. Which projects are those? There are currently 85 libraries in Orbit (the IP approved repository of 3rd party components) from Apache[1] used across many projects at Eclipse. Apache doesn't have any definitive list of approved 3rd party libraries so it's hard to make a comparison but I don't believe Eclipse has a problem using code from
Re: [DISCUSS] incorporate EPL Aether
Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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
Re: [DISCUSS] incorporate EPL Aether
http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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
Re: [DISCUSS] incorporate EPL Aether
as an option, eclipse has allowed dual licensed code before, namely jetty so there is precedent for aether to be dual licensed if they so desire.. http://www.eclipse.org/jetty/licenses.php cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sun, Jul 17, 2011 at 09:15, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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
Re: [DISCUSS] incorporate EPL Aether
So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. On Sun, Jul 17, 2011 at 10:15 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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
Re: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. LieGrue, strub --- On Sun, 7/17/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 3:47 PM On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. Ralph - 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
Re: [DISCUSS] incorporate EPL Aether
I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. So, I can imagine a thread of discussion about forking Aether (or anything else) to achieve control, but that's not this thread. My primary view in opposition to forking is the this: Sonatype and the Maven PMC share an interest in the success of Maven. The current situation isn't ideal, but it could be a whole lot worse. Based on recent history, I don't personally believe that dramatic tactics are the best option to achieve cooperation here. Forking would, in my opinion, come in under the category of 'a dramatic tactic.' My secondary argument has to do with workload. This development community is trying to maintain a giant raft of stuff. Deciding to fork these components without any visible plan to find the effort to work on them would be, in my opinion, 'shooting ourselves in the feet'. I might go so far as to ask people proposing a fork to list their recent commits to core Maven code. Another way to put this: If there is a majority of PMC members willing to vote +1 to just accept Aether as EPL (which means more work if relations with Sonatype degenerate and we wish to disentangle), let's do that. If there isn't, then the next step in my view is to talk to Sonatype about the dual license. I personally thing that it is nuts to fork without talking to Sonatype first. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Sure, if aether gets back being dual licensing then all would be fine. The Maven project has good relationship with Sonatype so I'm sure the EPL is not a problem today. But if the license is not a CategoryA license, then we cannot make sure it will not become a problem in the future. Because we cannot fork it and maintain it ourself in case any problem arises! So - from a pure manager perspective - this is a imo no-go. You would also not build your business on pure good will, isn't? LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 4:08 PM I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. So, I can imagine a thread of discussion about forking Aether (or anything else) to achieve control, but that's not this thread. My primary view in opposition to forking is the this: Sonatype and the Maven PMC share an interest in the success of Maven. The current situation isn't ideal, but it could be a whole lot worse. Based on recent history, I don't personally believe that dramatic tactics are the best option to achieve cooperation here. Forking would, in my opinion, come in under the category of 'a dramatic tactic.' My secondary argument has to do with workload. This development community is trying to maintain a giant raft of stuff. Deciding to fork these components without any visible plan to find the effort to work on them would be, in my opinion, 'shooting ourselves in the feet'. I might go so far as to ask people proposing a fork to list their recent commits to core Maven code. Another way to put this: If there is a majority of PMC members willing to vote +1 to just accept Aether as EPL (which means more work if relations with Sonatype degenerate and we wish to disentangle), let's do that. If there isn't, then the next step in my view is to talk to Sonatype about the dual license. I personally thing that it is nuts to fork without talking to Sonatype first. - 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
Re: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 11:55 AM, Mark Struberg wrote: Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. Which projects are those? There are currently 85 libraries in Orbit (the IP approved repository of 3rd party components) from Apache[1] used across many projects at Eclipse. Apache doesn't have any definitive list of approved 3rd party libraries so it's hard to make a comparison but I don't believe Eclipse has a problem using code from Apache. [1]: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.orbit/?root=Tools_Project LieGrue, strub --- On Sun, 7/17/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 3:47 PM On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. Ralph - 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 - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: [DISCUSS] incorporate EPL Aether
Hi Jason! Eclipse doesn't have problems with consuming ALv2 dependencies because ALv2 explicitly allows sublicensing - but EPL doesn't! So this is an unidirectional way and exactly the reason why we imo cannot do this. Btw, you should know exactly how hard it is to pass Eclipse' IP review and stuff. Wasn't that the reason why you needed to drop a few plexus dependencies because of uncertain IP? They are careful, which is a good thing. Couldn't you just put the ALv2/EPL dual licensing back in place and all are happy? Noone of us is eager to maintain aether or to fork it if not necessary. But otoh not being able to fork it if there were problems is imo a no-go. Also, there are a few contributors eager to ship patches it seems... txs and LieGrue, strub --- On Sun, 7/17/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 4:36 PM On Jul 17, 2011, at 11:55 AM, Mark Struberg wrote: Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. Which projects are those? There are currently 85 libraries in Orbit (the IP approved repository of 3rd party components) from Apache[1] used across many projects at Eclipse. Apache doesn't have any definitive list of approved 3rd party libraries so it's hard to make a comparison but I don't believe Eclipse has a problem using code from Apache. [1]: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.orbit/?root=Tools_Project LieGrue, strub --- On Sun, 7/17/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 3:47 PM On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. Ralph - 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 - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 9:08 AM, Benson Margulies wrote: I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. There have been discussions regarding whether having a central repository is a good thing. With Aether as a separate project Maven itself can't really do much to change that. While you are correct that putting the dual license back wouldn't require a vote, what it would mean is that if someone decided to innovate and create a different way of doing things they could start with the existing Aether code base at any point in time. As it stands, they would either have to go back to the last point that Aether was under the Apache license, which becomes less and less possible as time goes on and changes are made, or convince the Aether community to incorporate their changes, which is probably a much harder sell then just changing Maven. I agree that I only see the 3 choices you presented and the most favorable would be to have Aether continue to be dual licensed. When it comes to which of the other 2 options are better than I see pluses and minuses on both sides. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
There's a technical point of interest here. Aether has a very extensive separation of interface and implementation. So, there's a great deal that we could do unilaterally while still using the EPL core. The existence of 'central', I'm reasonably sure, is not inside of Aether itself at all. I don't expect this to be a killer argument in any direction, but I thought it was worth noting. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
'central' is defined in pom-4.0.0.xml [1] which resides in maven core. LieGrue, strub [1] http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 7:44 PM There's a technical point of interest here. Aether has a very extensive separation of interface and implementation. So, there's a great deal that we could do unilaterally while still using the EPL core. The existence of 'central', I'm reasonably sure, is not inside of Aether itself at all. I don't expect this to be a killer argument in any direction, but I thought it was worth noting. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies: After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. Hervé and I are aether committers, and if I wasn't so /extremely busy/ here on Mallorca I'd look at your patch. Opposed to Mark and Ralph, I have no qualms accepting an EPL 3rd party dependency, If you start showing an interest in aether matters I'm sure you'll get that commit bit pretty quickly yourself. I really just want to get over this license-of-the week crap we've been seeing for aether and sisu, which I think is totally unacceptable. Assuming aether actually goes to stay at eclipse I'm happy with that, until so happens I still want to keep the asl version (and fork if necessary). Technically, not that much has happened since the last ASL versioned aether, so there's no real gap to talk about. I /wish/ there was some kind of change in the pipeline that I could say made the aether/maven split problematic. But there isn't, is there ? I am much more worried about change in maven at a higher level than interfaces. I somehow sense that pom version 5 is never going to happen; but that's not aether's fault..? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
kristian, I want to repeat that b.b. has been perfectly hospitable about my little patch and proposal for a bigger one. your message, with which I have no disagreement, might give a casual reader another impression. On Jul 17, 2011, at 4:35 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies: After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. Hervé and I are aether committers, and if I wasn't so /extremely busy/ here on Mallorca I'd look at your patch. Opposed to Mark and Ralph, I have no qualms accepting an EPL 3rd party dependency, If you start showing an interest in aether matters I'm sure you'll get that commit bit pretty quickly yourself. I really just want to get over this license-of-the week crap we've been seeing for aether and sisu, which I think is totally unacceptable. Assuming aether actually goes to stay at eclipse I'm happy with that, until so happens I still want to keep the asl version (and fork if necessary). Technically, not that much has happened since the last ASL versioned aether, so there's no real gap to talk about. I /wish/ there was some kind of change in the pipeline that I could say made the aether/maven split problematic. But there isn't, is there ? I am much more worried about change in maven at a higher level than interfaces. I somehow sense that pom version 5 is never going to happen; but that's not aether's fault..? Kristian - 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
