incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <>
Subject Re: Too many licenses? Was: [vote] Accept Glasgow
Date Thu, 03 Aug 2006 23:13:25 GMT
William A. Rowe, Jr. wrote:
> Garrett Rooney wrote:
>> AMQP seems to be moving in this
>> direction, they've got some sort of agreement you can sign in order to
>> provide them feedback
> I have a question, can anyone summarize how contributions under the ASL
> would be weaker or stronger than contributions under this RLA?
Legally they are most likely much the same - I think the questions you 
ask implies something
which should be the question to ask....
 -> Is Apache in the business of writing and publishing specifications? <-
 From precedence and from what I know it is not.

As long as Apache is not in the business of also creating 
specifications, there will be by definition
some separation between code and spec processes, and I would like to 
work with the ASF to
try improve this. The way the group is setup I believe the ASF can have 
a strong influence while
we are in incubator, and the ASF can "keep" us in incubator until the 
spec meets ASF standards as
Brian said before we went to vote. Thus being in incubator seems the 
perfect place to work this.

> I'd like to have those quantified.  If there's no difference, and the spec
> implementors are requesting this become an ASF project, then why not accept
> spec feedback/contributions under the ASL?  These may be relicensed under
> the RLA for their publishing purposes, the ASL doesn't inhibit that, IIUC.
I think this is one of the options we can look at to have any member of 
the project
 provide feedback to the spec working group - however it seems 
presumptuous to use the
ASL or work out details like this before we are accepted in incubator.


> Clarifications welcomed.
> Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message