Thanks for the terms. I had used "apache license categories" and some other variations.
I assume you mean this: http://www.apache.org/legal/3party.html#criteriaandcategories If so, is there an accepted version, other than this merely proposed version? Fred. On Fri, Aug 2, 2013 at 7:39 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Google: Apache third party licenses > > Should work on lucky... Or look at the head revision where I added the > link. > > There is a 3rd category: Category X... Eg GPL, which we are not allowed to > use > > On Friday, 2 August 2013, Fred Cooke wrote: > > > Are definitions of cat A and B and others listed anywhere? I searched > but > > failed. > > > > I assume Cat A = permissive and Cat B = copyleft? or? > > > > On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > Correct. And it would be subject to the same CTR and potential veto if > > Cat > > > A. If Cat B and being added to core then you'd have a mandatory vote by > > the > > > PMC where the majority *of the whole PMC* are required to approve. > > > > > > The rational being, a Cat A licensed dependency can always be forked > into > > > Maven if we need to. > > > > > > On Friday, 2 August 2013, Igor Fedorenko wrote: > > > > > > > Is this really specific to PMC? Can't a regular developer like myself > > do > > > > the same, i.e. setup a project elsewhere, then commit <dependency> to > > > > maven core? > > > > > > > > -- > > > > Regards, > > > > Igor > > > > > > > > On 2013-08-02 8:29 PM, Paul Benedict wrote: > > > > > > > > I've stated from the beginning of this thread that it's impossible to > > > > prevent someone from developing outside of Apache. I stand by that > > still. > > > > That can't be prevented and any attempt will fail since it's not > > > practical. > > > > > > > > If my words today aren't clear, I'll try again. My stance isn't about > > > > halting developing elsewhere, but to halt what I (and maybe some > > others) > > > > perceive as a way of getting around the Apache community. > > > > > > > > I won't use your "ultra whizzbang high performance logging" :-) > example > > > > because it doesn't fit what my concern; but imagine an existing > > component > > > > (I won't name any) that is critical and Maven's existence and Maven > > can't > > > > function without it. It's very easy for any PMC member to go to > another > > > OSS > > > > community, develop it, and then kind of leave the other PMCs with no > > real > > > > "choice" but to use it because the code realizes the future of Maven. > > > Those > > > > other PMCs are really backed into a corner; they have no real > recourse > > to > > > > preventing this, lest Maven development is simply halted altogether. > > The > > > > other OSS community has other committers, other mailing lists, other > > > > deliberations, etc. Community work and input becomes marginalized > here. > > > > > > > > Does this make sense to you? That kind of community-splitting effort > > > needs > > > > to stop and that's what I am trying to address. > > > > > > > > Cheers, > > > > Paul > > > > > > > > > > > > > > > > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly < > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > > We cannot stop somebody from developing something outside of Apache. > > > > > > > > So I could go off and write a High Performance Logging API... now I > > could > > > > be doing that because I want to foist that Logging API on Maven... > or I > > > > could be doing it as an experiment that, if successful, I may offer > for > > > > Maven to consume... or I could be doing it because I need it for my > Day > > > > Job... > > > > > > > > We cannot know the reasons why somebody is doing something outside of > > > > Maven... we can ask, but we cannot *know* if the answer we are given > is > > > > truthful. > > > > > > > > So anyway, I now have this ultra whizzbang high performance logging > API > > > and > > > > I am aware of some deficit in the logging performance of Maven, so I > > spin > > > > up a private fork (it could be a hidden private fork, or it could be > a > > > > public one... doesn't matter) and integrate the logging API and low > and > > > > behold I see a whopping X% improvement... so I want to bring that > back > > to > > > > Maven... > > > > > > > > Is there anything wrong with the above? > > > > > > > > If the library I created is under a Category A license and open > source > > > and > > > > I go with CTR and nobody vetos my commit... we have consensus... why > do > > > we > > > > need to go all Iron Fist and require a vote? > > > > > > > > We already have established tools: review of commits, vetos on > commits, > > > > mandatory votes for Category B dependencies... > > > > > > > > Do we really need *more* processes and procedures to follow? > > > > > > > > On 2 August 2013 16:51, Paul Benedict <pbened...@apache.org> wrote: > > > > > > > > I don't under> > > > ------------------------------**------------------------------**--------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > <javascript:;> > > > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > > > > > > > > > > -- > > > Sent from my phone > > > > > > > > -- > Sent from my phone >
