y question came down to this; if someone offers a patch, which then suggests
an improvement to the spec, does the ASL (which covers -everything- that is
offered to the ASF) adequately correspond to the RLA terms to satisfy the
spec committee? If so there's no issue; in fact it would be sufficient to
continue to accept contributions from ASF committers who have signed a CLA
to the effect that everything they offer is covered.
Now that I understand what you are getting at - I really like the idea.
no idea if it
is possible, but worth looking into - seems like it might work. We can
work this with
Cliff and see what we can come up during incubator
Carl
William A. Rowe, Jr. wrote:
Carl Trieloff wrote:
William A. Rowe, Jr. wrote:
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.
Actually, no, that doesn't follow from my question.
My question came down to this; if someone offers a patch, which then suggests
an improvement to the spec, does the ASL (which covers -everything- that is
offered to the ASF) adequately correspond to the RLA terms to satisfy the
spec committee? If so there's no issue; in fact it would be sufficient to
continue to accept contributions from ASF committers who have signed a CLA
to the effect that everything they offer is covered.
This is slightly distinct from a non-committer without a CLA which is also
contributing under the ASL, but without quite as strong a paper trail that
they contributed knowingly under that license.
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
This would generally be true even if they were both under the ASF umbrella,
I don't necessarily think they have to be one. E.g. even if the spec
committee were an ASF committee, they would answer to all implementors, not
only one implementation by the ASF...
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.
Sure, that sounds like a good thing, although it still doesn't go to the
questions
* project contributors must all sign two agreements?
* the spec committee is or isn't sufficently protected by the ASL terms?
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.
Well the ASL is the binding license of ASF work, so if that's a presumptuous
assertion, perhaps this project belongs elsewhere?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
