You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2011/07/17 15:26:03 UTC
[DISCUSS] incorporate EPL Aether
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by John Casey <jd...@commonjava.org>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Kristian Rosenvold <kr...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Arnaud Héritier <ah...@gmail.com>.
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 <ma...@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
Posted by Mark Derricutt <ma...@talios.com>.
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
Posted by Benson Margulies <bi...@gmail.com>.
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
<kr...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jesse McConnell <je...@gmail.com>.
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.mcconnell@gmail.com
On Sun, Jul 17, 2011 at 09:15, Stephen Connolly
<st...@gmail.com> wrote:
> http://maven.apache.org/developers/dependency-policies
>
> On 17 July 2011 15:02, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>>
>>> From: Benson Margulies <bi...@gmail.com>
>>> Subject: [DISCUSS] incorporate EPL Aether
>>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
'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 <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: [DISCUSS] incorporate EPL Aether
> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by John Casey <jd...@commonjava.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
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 <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: [DISCUSS] incorporate EPL Aether
> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
>
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jul 30, 2011, at 11:58 AM, Benson Margulies wrote:
> On Sat, Jul 30, 2011 at 2:52 PM, Ralph Goers <ra...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Jul 30, 2011 at 2:52 PM, Ralph Goers <ra...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
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" <de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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
Posted by Ralph Goers <ra...@dslextreme.com>.
See below
Sent from my iPhone
On Jul 30, 2011, at 10:33 AM, Jason van Zyl <ja...@sonatype.com> wrote:
>
> On Jul 30, 2011, at 4:16 PM, Ralph Goers wrote:
>
>> See below.
>>
>> Sent from my iPhone
>>
>> On Jul 30, 2011, at 9:39 AM, Jason van Zyl <ja...@sonatype.com> wrote:
>>
>>>
>>> On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote:
>>>
>>>> The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary.
>>>
>>> Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it.
>>
>> We have been told by the VP of legal we cannot do this.
>>
>
> It can't be for legal reasons. They are telling you that you don't have the right to take a codebase and fork it for which the license allows? For which Apache 3rd party policies states you can consume as a binary? I'm not saying you want to do this but I can't see how you're legally not entitled to do this.
>
It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so.
>>
>>> How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse?
>>
>> We are not. My assumption has always been that what has been discussed is wrt something that Aether wouldn't accept - a purely hypothetical situation right now.
>
> You probably couldn't care less what the main body of Aether does and there are extension points which allow you to do pretty much anything you want. The maven-aether-connector is a good example.
>
>>
>>> The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it.
>>
>> Are you saying you would be willing to provide a software grant to allow us to do so? That would change the situation dramatically.
>
> No, I'm not saying that. I believe in the EPL and the function it serves. You don't have to agree with me but I ask you respect my choice. I don't think this adversely affects anything with respect to Maven. The same counter to the merit wall argument I'm willing to extend to anyone who wants it. If you wanted to be listed as a committer you can be. Would that make you feel more comfortable? Politics don't stand at Eclipse so there would be no way I could do anything to force you out of the project once you were part of it, if that concerned you. Mike would toss me out before he let me attempt to throw someone else out. Then if you chose to implement anything nothing would stop you.
>
> Additionally, I'm sure at some point in the future if you pointed at some harmful change in Aether the board would let you fork the project at Github and absorb the binary you produced. There is already precedent for absorbing EPL binaries so I can't see how that could legally be a problem.
>
>>
>>> The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back.
>>>
>>>> We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form.
>>>>
>>>> I don't believe anyone is concerned with Aether becoming "unusable" for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern.
>>>
>>> This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether.
>>>
>>>>
>>>> Ralph
>>>>
>>>> On Jul 30, 2011, at 10:31 AM, David Jencks wrote:
>>>>
>>>>> I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy.
>>>>>
>>>>> Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all.
>>>>>
>>>>> I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote:
>>>>>
>>>>>> The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote:
>>>>>>
>>>>>>> I'd like to to try to put a little oxygen into this thread now, given
>>>>>>> the rather clear results of the vote thread.
>>>>>>>
>>>>>>> Ralph posed the following question on Legal Discuss: 'Can the Maven
>>>>>>> PMC pull a dual-licensed version of AEther back into Apache without a
>>>>>>> grant from Sonatype?'
>>>>>>>
>>>>>>> The answer was, "legally yes, but it is counter to long-established
>>>>>>> policy, and strongly discouraged by a number of senior ASF people
>>>>>>> (including a board member or two)".
>>>>>>>
>>>>>>> So, the community has some choices. It seems to me that the viability
>>>>>>> of these different choices depends on the viability of walking away
>>>>>>> from AEther. In practical terms, the choices are:
>>>>>>>
>>>>>>> a) Use versions of AEther controlled by 'someone else'.
>>>>>>> b) Create our own 'someone else' at apache-extras or elsewhere.
>>>>>>> c) Go down the path of becoming an exception to the policy and take on
>>>>>>> reworking AEther from the last dual-licensed version.
>>>>>>> d) Start All Over Again from Maven 2.2.
>>>>>>>
>>>>>>> From the vote comments, it seemed to me that a plurality of people
>>>>>>> felt that EPL at Eclipse was tolerable. So that argues for sitting
>>>>>>> still for now. I offer only the observation that forking into
>>>>>>> apache-extras 'works' the same way today, or after the code appears in
>>>>>>> Eclipse. In other words, adopting what's out there today only makes
>>>>>>> choice (c) harder, it doesn't have any impact that I see on a, b, or
>>>>>>> d. However, a 'no' vote is a 'no' vote, so this is all just food for
>>>>>>> thought.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>>>
>>> -- Paul Graham
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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 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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>>
>> -- Paul Graham
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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 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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote:
> The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary.
Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse? The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it. The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back.
> We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form.
>
> I don't believe anyone is concerned with Aether becoming "unusable" for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern.
This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether.
>
> Ralph
>
> On Jul 30, 2011, at 10:31 AM, David Jencks wrote:
>
>> I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy.
>>
>> Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all.
>>
>> I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario.
>>
>> thanks
>> david jencks
>>
>> On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote:
>>
>>> The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary.
>>>
>>> Ralph
>>>
>>> On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote:
>>>
>>>> I'd like to to try to put a little oxygen into this thread now, given
>>>> the rather clear results of the vote thread.
>>>>
>>>> Ralph posed the following question on Legal Discuss: 'Can the Maven
>>>> PMC pull a dual-licensed version of AEther back into Apache without a
>>>> grant from Sonatype?'
>>>>
>>>> The answer was, "legally yes, but it is counter to long-established
>>>> policy, and strongly discouraged by a number of senior ASF people
>>>> (including a board member or two)".
>>>>
>>>> So, the community has some choices. It seems to me that the viability
>>>> of these different choices depends on the viability of walking away
>>>> from AEther. In practical terms, the choices are:
>>>>
>>>> a) Use versions of AEther controlled by 'someone else'.
>>>> b) Create our own 'someone else' at apache-extras or elsewhere.
>>>> c) Go down the path of becoming an exception to the policy and take on
>>>> reworking AEther from the last dual-licensed version.
>>>> d) Start All Over Again from Maven 2.2.
>>>>
>>>> From the vote comments, it seemed to me that a plurality of people
>>>> felt that EPL at Eclipse was tolerable. So that argues for sitting
>>>> still for now. I offer only the observation that forking into
>>>> apache-extras 'works' the same way today, or after the code appears in
>>>> Eclipse. In other words, adopting what's out there today only makes
>>>> choice (c) harder, it doesn't have any impact that I see on a, b, or
>>>> d. However, a 'no' vote is a 'no' vote, so this is all just food for
>>>> thought.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
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
<kr...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Kristian Rosenvold <kr...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
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
<st...@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" <da...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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" <da...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without
>> actually developing a running system is doomed to failure. No one
>> is that smart. A framework is a resuable design, so you develop it by
>> looking at the things it is supposed to be a design of. The more examples
>> you look at, the more general your framework will be.
>>
>> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>>
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: [DISCUSS] incorporate EPL Aether
Posted by Stephen Connolly <st...@gmail.com>.
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" <da...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
>
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
> 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" <de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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
Posted by Jason van Zyl <ja...@sonatype.com>.
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" <de...@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" <da...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> People develop abstractions by generalizing from concrete
>> examples.
>> Every attempt to determine the correct abstraction on paper
>> without
>> actually developing a running system is doomed to failure.
>> No one
>> is that smart. A framework is a resuable design, so you
>> develop it by
>> looking at the things it is supposed to be a design of. The
>> more examples
>> you look at, the more general your framework will be.
>>
>> -- Ralph Johnson & Don Roberts, Patterns for
>> Evolving Frameworks
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
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" <de...@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" <da...@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> People develop abstractions by generalizing from concrete
> examples.
> Every attempt to determine the correct abstraction on paper
> without
> actually developing a running system is doomed to failure.
> No one
> is that smart. A framework is a resuable design, so you
> develop it by
> looking at the things it is supposed to be a design of. The
> more examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for
> Evolving Frameworks
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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" <da...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Re: [DISCUSS] incorporate EPL Aether
Posted by Stephen Connolly <st...@gmail.com>.
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" <da...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] incorporate EPL Aether
Posted by David Jencks <da...@yahoo.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Stephen Connolly <st...@gmail.com>.
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" <st...@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 <st...@gmail.com>
wrote:
>
>> From: Stephen Connolly <st...@gmail.com>
>> Subject: Re: [DISCUSS] incorporate EPL Aether
>> To: "Maven Developers List" <de...@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" <bi...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] incorporate EPL Aether
Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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 Margulies"<bi...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by John Casey <jd...@commonjava.org>.
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 Margulies"<bi...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Jul 30, 2011 at 2:55 PM, Ralph Goers <ra...@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 <st...@gmail.com> wrote:
>>>
>>>> From: Stephen Connolly <st...@gmail.com>
>>>> Subject: Re: [DISCUSS] incorporate EPL Aether
>>>> To: "Maven Developers List" <de...@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" <bi...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <st...@gmail.com> wrote:
>>
>>> From: Stephen Connolly <st...@gmail.com>
>>> Subject: Re: [DISCUSS] incorporate EPL Aether
>>> To: "Maven Developers List" <de...@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" <bi...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <st...@gmail.com> wrote:
>
>> From: Stephen Connolly <st...@gmail.com>
>> Subject: Re: [DISCUSS] incorporate EPL Aether
>> To: "Maven Developers List" <de...@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" <bi...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
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 <st...@gmail.com> wrote:
> From: Stephen Connolly <st...@gmail.com>
> Subject: Re: [DISCUSS] incorporate EPL Aether
> To: "Maven Developers List" <de...@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" <bi...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Stephen Connolly <st...@gmail.com>.
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" <bi...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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" <de...@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 <ra...@dslextreme.com>
>> wrote:
>>>
>>>> From: Ralph Goers <ra...@dslextreme.com>
>>>> Subject: Re: [DISCUSS] incorporate EPL Aether
>>>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
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" <de...@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 <ra...@dslextreme.com>
> wrote:
> >
> >> From: Ralph Goers <ra...@dslextreme.com>
> >> Subject: Re: [DISCUSS] incorporate EPL Aether
> >> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Jason van Zyl <ja...@sonatype.com>.
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 <ra...@dslextreme.com> wrote:
>
>> From: Ralph Goers <ra...@dslextreme.com>
>> Subject: Re: [DISCUSS] incorporate EPL Aether
>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Mark Struberg <st...@yahoo.de>.
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 <ra...@dslextreme.com> wrote:
> From: Ralph Goers <ra...@dslextreme.com>
> Subject: Re: [DISCUSS] incorporate EPL Aether
> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Benson Margulies <bi...@gmail.com>.
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
<st...@gmail.com> wrote:
> http://maven.apache.org/developers/dependency-policies
>
> On 17 July 2011 15:02, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>>
>>> From: Benson Margulies <bi...@gmail.com>
>>> Subject: [DISCUSS] incorporate EPL Aether
>>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Stephen Connolly <st...@gmail.com>.
http://maven.apache.org/developers/dependency-policies
On 17 July 2011 15:02, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>
>> From: Benson Margulies <bi...@gmail.com>
>> Subject: [DISCUSS] incorporate EPL Aether
>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Posted by Mark Struberg <st...@yahoo.de>.
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 <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: [DISCUSS] incorporate EPL Aether
> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org