as an option, eclipse has allowed dual licensed code before, namely jetty so there is precedent for aether to be dual licensed if they so desire..
http://www.eclipse.org/jetty/licenses.php cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sun, Jul 17, 2011 at 09:15, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > http://maven.apache.org/developers/dependency-policies > > On 17 July 2011 15:02, Mark Struberg <strub...@yahoo.de> wrote: >> Actually the discussions I remember have explicitly favoured (3) (forking >> the last ALv2 version) if no ALv2 licensed version is available anymore. >> There are 2 arguments for that: it's not only aether, it's also sisu and the >> other guice stuff. >> >> Aether and likes are core maven parts which are utterly important if we like >> to maintain maven itself. Just check how deep aether is anchored in >> DefaultMaven.java! The original decision was to introduce a 'pluggable >> repository layer' which in my opinion would have meant to introduce a series >> of interfaces and data holder classes in form of a SPI. But this very part >> has not been implemented this way. Instead lots of internal details needs to >> be addressed/controlled directly from inside Maven. >> >> I tried to introduce such an interface layer for a few days but failed due >> to the deep integration... >> >> So I'd definitely -1 a EPL core dependency which once was part of maven core >> as long as there is no ALv2 alternative which we can bugfix ourselfs! >> >> LieGrue, >> strub >> >> --- On Sun, 7/17/11, Benson Margulies <bimargul...@gmail.com> wrote: >> >>> From: Benson Margulies <bimargul...@gmail.com> >>> Subject: [DISCUSS] incorporate EPL Aether >>> To: "Maven Developers List" <dev@maven.apache.org> >>> Date: Sunday, July 17, 2011, 1:26 PM >>> After re-reading the ASF legal >>> licensing policy, I'm starting this >>> thread to formally propose that the Maven incorporate >>> versions of >>> Aether that are EPL without an AL dual-license. As per >>> convention, >>> someone can make a VOTE thread once voices have been heard >>> here. >>> >>> EPL is 'Category B'. Binary redistribution with a notice is >>> acceptable. >>> >>> Maven incorporated many plexus components, and at least >>> some of them >>> have IP question marks hanging over them (c.f. the >>> discussion of the >>> plexus-utils replacement). I, therefore, don't see any real >>> impact on >>> the users of Maven in adopting EPL copies of Aether. To the >>> extent >>> that Maven is a development tool, the user impact of >>> category B >>> components is lighter than with something that is >>> routinely >>> incorporated in larger systems. To the extent, on the other >>> hand, that >>> Maven is embeddable, this could be a problem for someone. >>> However, >>> that argument would make a lot more sense if every other >>> scrap of the >>> ecosystem were fully-vetted category A. >>> >>> Someone might wonder, 'Why has Benson decided to tilt at >>> this >>> particular windmill?' >>> >>> Well, some itches of mine have led into Aether, and I'd >>> feel fairly >>> silly investing a lot of time and energy in Aether patches >>> that will >>> never see the light of day in Maven. So, I'm inclined to >>> push the >>> community to choose a course of action. I see three >>> possibilities: >>> >>> 1) Just make the notice arrangements to use Aether under >>> EPL. >>> 2) Actively see if Sonatype will put the dual license >>> back. >>> 3) Fork the last dual version. >>> >>> My sense, without reading private archives, is that the >>> community >>> decided not to adopt the overall course of action of which >>> (3) would >>> be a part, so I believe that it's not a serious option at >>> this point. >>> (2) is possible, but my view is that the value to the >>> community of the >>> dual license is not worth the trouble. Thus, I'm proposing >>> (1), but >>> I'm certainly not going to complain if some PMC member >>> decides to take >>> a run at (2). A positive decision to allow incorporation of >>> EPL Aether >>> would give us flexibility, and if (2) happened later that >>> would be a >>> good thing. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
