You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2006/08/04 00:05:24 UTC
Too many licenses? Was: [vote] Accept Glasgow
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?
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.
Clarifications welcomed.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects (was RE: Too many licenses?
Was: [vote] Accept Glasgow)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Alan Conway wrote:
> Idiotic question from complete Apache newbie: is the proposal that
> Apache should start hosting specs but would still host projects
> implementing foreign specs, or that Apache should stop hosting projects
> implementing non-Apache specs?
Twofold answer IMHO...
if we host a spec, it shouldn't be the same as the implementation project,
but an independent 'project' that is implementation neutral.
and there is no reason to expect to host every spec. Many have very logical
umbrellas today that are acceptable. There are some spec umbrellas that are
not acceptable due to the control / nda / ip considerations and those sorts
of implementations wouldn't be appropriate for the open dialog of an ASF
hosted project. Open/transparent/freely licenseable specs are really not
an issue for the ASF to host one implementation, no matter what umbrella
hosts such a spec.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects (was RE: Too many
licenses? Was: [vote] Accept Glasgow)
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 15, 2006, at 6:57 AM, Alan Conway wrote:
> Idiotic question from complete Apache newbie: is the proposal that
> Apache should start hosting specs but would still host projects
> implementing foreign specs, or that Apache should stop hosting
> projects
> implementing non-Apache specs?
I haven't read anything as meaning that Apache would stop hosting
projects implementing external specs. We would have to cancel most of
the existing projects.
And we're circling around the idea of hosting spec-writing projects
but haven't come close to understanding the implications. And it's
not clear to me that the project that stimulated the discussion even
wants to have a spec-writing component.
Craig
>
> On Mon, 2006-08-14 at 08:34 +0100, James Strachan wrote:
>> On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
>>> Carl Trieloff wrote:
>>>
>>>> -> Is Apache in the business of writing and publishing
>>>> specifications? <-
>>>
>>>> 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.
>>>
>>> Wait ... why can't a specification be a releasable, just like a
>>> codebase? The only issue, as I see it, would be enforcement of
>>> compliance. And Roy even put forward a proposed license
>>> amendment for such things.
>>>
>>> As you saying that if the ASF would host the specification, that
>>> you and the rest of the AMQP IP holders would be willing to
>>> contribute and manage the specification here under ASF practices?
>>>
>>> I would be in favor of such an approach. Honestly, I would
>>> vastly prefer to have Open Specifications managed under ASF
>>> processes than under the JCP, OASIS, etc.
>>
>> +1
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Specifications as (part of) ASF projects (was RE: Too many
licenses? Was: [vote] Accept Glasgow)
Posted by Alan Conway <ac...@redhat.com>.
Idiotic question from complete Apache newbie: is the proposal that
Apache should start hosting specs but would still host projects
implementing foreign specs, or that Apache should stop hosting projects
implementing non-Apache specs?
On Mon, 2006-08-14 at 08:34 +0100, James Strachan wrote:
> On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
> > Carl Trieloff wrote:
> >
> > > -> Is Apache in the business of writing and publishing specifications? <-
> >
> > > 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.
> >
> > Wait ... why can't a specification be a releasable, just like a codebase? The only issue, as I see it, would be enforcement of compliance. And Roy even put forward a proposed license amendment for such things.
> >
> > As you saying that if the ASF would host the specification, that you and the rest of the AMQP IP holders would be willing to contribute and manage the specification here under ASF practices?
> >
> > I would be in favor of such an approach. Honestly, I would vastly prefer to have Open Specifications managed under ASF processes than under the JCP, OASIS, etc.
>
> +1
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)
Posted by James Strachan <ja...@gmail.com>.
On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
> Carl Trieloff wrote:
>
> > -> Is Apache in the business of writing and publishing specifications? <-
>
> > 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.
>
> Wait ... why can't a specification be a releasable, just like a codebase? The only issue, as I see it, would be enforcement of compliance. And Roy even put forward a proposed license amendment for such things.
>
> As you saying that if the ASF would host the specification, that you and the rest of the AMQP IP holders would be willing to contribute and manage the specification here under ASF practices?
>
> I would be in favor of such an approach. Honestly, I would vastly prefer to have Open Specifications managed under ASF processes than under the JCP, OASIS, etc.
+1
--
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> SOP effective when? http://wiki.apache.org/incubator/WicketProposal surely
> doesn't. Citations please, or are you just being inventive ;-?
Look at most of the prior proposals - they have affiliations listed.
It's especially more important when they are originating from a
corporate sponsor (or rather a 'coalition') instead of another
open-source community. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> It's not complicated, folks. ASF projects consist of individuals.
>> Adding company affiliations after each of the initial committers names
>> suggests, to some, that the day they move on to another company their
>> contribution to the project ends.
>
> No, including the affiliations is standard practice.
SOP effective when? http://wiki.apache.org/incubator/WicketProposal surely
doesn't. Citations please, or are you just being inventive ;-?
> This is the only
> way we can judge the diversity of the proposal. If it's just names of
> folks off the street and everyone works at the same company (and that
> isn't disclosed), we have no way of estimating the true diversity of
> the project. -- justin
Quit worrying about sense-of-community and diversity on entry into incubation.
Incubation is about growing community. Our only goal at this phase is to
determine that community and meritocracy can be established, moving forwards,
with the group of initial contributors, and that the project's appeal would
increase the diversity.
But, once again, nobody's answering the crux of the question, only blowing
more wind. Can the proposal be modified to be less employer-centric, or
does it need a different home to achieve the goals of the contributors?
Do the initial contributors/participants understand they are participating
on behalf of the project before their employer? Do they plan to be around
when they move on? If so they will make great participants in the project's
PMC. For those that don't, ethical considerations suggest they should plan
to remain committer / contributors.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Carl Trieloff <cc...@redhat.com>.
I placed company names after names, as the last proposal to get voted on
did not
have company names on it and was requested to add company names. Nothing
more than that.
Carl.
Justin Erenkrantz wrote:
> On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> It's not complicated, folks. ASF projects consist of individuals.
>> Adding
>> company affiliations after each of the initial committers names
>> suggests, to
>> some, that the day they move on to another company their contribution
>> to the
>> project ends. We understand why Cliff did so for himself (so that
>> there would
>> be no misunderstanding that he has a vested interest, bravo), but
>> that this
>> was propagated to the entire initial list of committers is very
>> troubling.
>
> No, including the affiliations is standard practice. This is the only
> way we can judge the diversity of the proposal. If it's just names of
> folks off the street and everyone works at the same company (and that
> isn't disclosed), we have no way of estimating the true diversity of
> the project. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/7/06, Cliff Schmidt <cl...@gmail.com> wrote:
<snip>
> Yep -- it's been fun for me to watch us go back and forth on this as I
> try to advise people outside the ASF on what the best thing to do is
> (since every proposer I've run into really actually wants to do the
> most acceptable thing).
not so much herding cats as ballet dancing with a hurd of rogue elephants ;-)
> Robert actually touched on this issue here:
> http://incubator.apache.org/guides/proposal.html#template-affiliations,
> which ends with, "It's probably best to do this in a separate section
> away from the committers list."
just to let every one know that it's just a draft. my plan is to try
to edit the drafts until they seem ready (to those working on the
documentation) and then put them up for community review. if anyone
wants to lend a hand, they'd be more than welcome :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Cliff Schmidt <cl...@gmail.com>.
On 8/7/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > It's not complicated, folks. ASF projects consist of individuals. Adding
> > company affiliations after each of the initial committers names suggests, to
> > some, that the day they move on to another company their contribution to the
> > project ends. We understand why Cliff did so for himself (so that there would
> > be no misunderstanding that he has a vested interest, bravo), but that this
> > was propagated to the entire initial list of committers is very troubling.
>
> No, including the affiliations is standard practice. This is the only
> way we can judge the diversity of the proposal. If it's just names of
> folks off the street and everyone works at the same company (and that
> isn't disclosed), we have no way of estimating the true diversity of
> the project. -- justin
Yep -- it's been fun for me to watch us go back and forth on this as I
try to advise people outside the ASF on what the best thing to do is
(since every proposer I've run into really actually wants to do the
most acceptable thing).
Robert actually touched on this issue here:
http://incubator.apache.org/guides/proposal.html#template-affiliations,
which ends with, "It's probably best to do this in a separate section
away from the committers list."
The funny thing is that I thought that was a good approach too, until
Justin and Yoav asked for the more explicit version (the way these
folks did things) in
http://mail-archives.apache.org/mod_mbox/incubator-general/200606.mbox/%3c5c902b9e0606210718k1cd8f394idf424dc085c0ff2e@mail.gmail.com%3e.
I understand as much as anyone that we have lots of different opinions
on these kinds of things and sometimes, some of us (including me)
think that there has been a consensus...and it's on our side. All
that is fine, but let's all try to be a little more careful with
making value juidgements against new folks who show up and think that
one of the options used in the past is a reasonable approach.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> It's not complicated, folks. ASF projects consist of individuals. Adding
> company affiliations after each of the initial committers names suggests, to
> some, that the day they move on to another company their contribution to the
> project ends. We understand why Cliff did so for himself (so that there would
> be no misunderstanding that he has a vested interest, bravo), but that this
> was propagated to the entire initial list of committers is very troubling.
No, including the affiliations is standard practice. This is the only
way we can judge the diversity of the proposal. If it's just names of
folks off the street and everyone works at the same company (and that
isn't disclosed), we have no way of estimating the true diversity of
the project. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
>> William,
>>
>> I have made some edits to the wiki on the Mechanisms for feedback[...]
>
> Although the objectionable language still appears on the spec parties' web
> sites[...]
Whoa - my bad; I got this wrong and the web sites beat us both...
> I have one last suggestion on your choice of words...
>
>>>From the proposal, "On such acceptance the employer is required to sign an
> agreement to make sure that employer also grants the ongoing and consistent
> licenses to the work as posted in specifications."
>
> could be more simply put "On such acceptance, the employer must also sign
> the [RLA? ] agreement [or is this Specifications Party Contract?] to ensure
> that all necessary licenses are clearly granted." - which makes perfect sense.
"In the same spirit of an Apache-style process, if an individual has shown
understanding of the project and substantive contribution to the specification,
based on technical merit and understanding of the goals of the work an
invitation may be extended to have that member join the specification Working
Group. On such acceptance the Party is required to sign an agreement that makes
sure they also grant ongoing and consistent licenses to the work."
Done. The language on the sites is perfect. The Party in this case is the
individual, and anyone else who lays claim to the IP they produce, so I don't
see any reason not to use the web site language off Envoy & IONA (the two I
just reread.)
Still looking for just the answer to my very last question about the Spec
participation contract, public or private status.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [vote] Accept Glasgow (revised vote)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Carl Trieloff wrote:
> William A. Rowe, Jr. wrote:
>> Last and final objection, I want to make sure I am not missing
>> something...
>> the contract between the spec participants is or is not public? If
>> public,
>> was there a link I missed? If so, can it be added to the proposal for
>> completeness sake?
>
> I have to say partially public.
With your very detailed explanation, I grok the dynamics at work. Although
I can't support the proposal until I understand all of the NDA's at work,
the extent to which the project will be 'controlled' by private traffic, and
by traffic they may or may not successfully influence ...
... I'm very pleased with all of the efforts to resolve entirely reasonable
confusion on the part of the submittors, and fully believe the project can
succeed as it addresses the remaining issues ...
... my vote is retracted, count me +/- 0 until we determine the rules by which
the spec committee is playing, at which point I would likely support the
proposal. But please don't let my earlier negative vote impede your progress
if there's sufficient support for the proposal as-is, the -1 is reverted.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Carl Trieloff <cc...@redhat.com>.
William A. Rowe, Jr. wrote:
> Last and final objection, I want to make sure I am not missing something...
> the contract between the spec participants is or is not public? If public,
> was there a link I missed? If so, can it be added to the proposal for
> completeness sake?
>
> Bill
>
>
>
William, to this last point that has not been covered in a previous posting
I have to say partially public.
Short explanation, about two weeks ago a similar question was asked and
based on
what was asked, I had requested from the working group to be able to publish
the "joint objectives" and the license that the working group will
provide to the standards
body once selected and submitted to. This has been added to the wiki.
The 'Joint Objectives'
is copied below.
The agreement is a non-NDA document, and the working group provides it
to anyone
who requests it that said I would prefer to discuss any publication of
the agreement on open
web sites or mailing lists with the working group prior to doing so. As
this group is
is new, it is still working out many policies internally. Out of respect
for those members
of the group who are out on summer vacations it seems best to wait for
the majority of the
other members to have returned before I make such a request.
I think it is good to clarify that I have two hats, one as a proposer of
project to incubator
and one as a part of the spec working group, and the hat I have to wear
for this issue
is as a representative of the working group and not as a committer on
this proposal
Regards
Carl.
Joint Objectives (from AMQP Participant agreement)
A. Members wish to work together to collectively create a Specification
for an open and interoperable messaging protocol, to enable the
development and industry-wide use and for widespread deployment.
B. The goal is to have the protocol generally used for messaging,
capable of servicing the industries' most complex and demanding
environments. However, it is intended to be simple to use and relatively
easy to implement.
C. It is not the first objective of this group to drive the creation of
middleware APIs complimentary to the AMQ Protocol even though an API
might be specified along with protocol for the express purpose to
understand and test the protocol itself. This is important as the
protocol will be general purpose and usable from any language, and any
platform without prejudice and bindings for many languages and platforms
will need to exist once the protocol is specified.
D. Members are encouraged to provide open (OSI) licensed implementations
of the AMQP Specification. Prototype implementations of Draft revisions
of the AMQP Specification may also be produced by a member for
demonstration, proof-of-concept, or market development purposes provided
prior approval to such a prototype implementation has been given. The
aim being that the unity and cohesion of the AMQP Specification is not
weakened by forking or manipulation of the market by early release of
non-conformant implementations.
E. The group will promote the use of the protocol and conformance with
the published AMQP Specification.
F. The protocol will not specify payload formats, but rather concentrate
on interoperability of the messaging "envelope" and all the related
components including but not limited to areas such as
security,transactions, persistence, synchrony, bridging, tunneling,
queuing semantics, reliable multicast and distribution optimizations to
name a few.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Carl Trieloff wrote:
>
> William,
>
> I have made some edits to the wiki on the Mechanisms for feedback
> section to clean up the language, based on some of the misunderstanding
> and to reflect the discussion from the list onto the wiki. Tried to keep
> it short, but can edit more in if required.
Although the objectionable language still appears on the spec parties' web
sites, and I still consider it an abuse of the phrase "In the same spirit
of an Apache-style process" until the rest of the language changes...
I have one last suggestion on your choice of words...
>From the proposal, "On such acceptance the employer is required to sign an
agreement to make sure that employer also grants the ongoing and consistent
licenses to the work as posted in specifications."
could be more simply put "On such acceptance, the employer must also sign
the [RLA? ] agreement [or is this Specifications Party Contract?] to ensure
that all necessary licenses are clearly granted." - which makes perfect sense.
I still find two points in the RLA (which, w.r.t. employment *wasn't* at all
objectionable(!) and entirely contributor-focused, individual or corporate)
to be odd;
"for the purpose of developing and promoting the Specification and in connection
with any product that implements and complies with the Specification"
which is a bit too fuzzy for many to agree too (usually it would be constrained
to "necessary to implement the proposed Feedback to the Specification" or some
similarly narrow language - but if this works for all involved), and...
"information shall be considered “Confidential Information” when, [...] (ii)
non-tangible disclosures are identified as confidential prior to disclosure and
reduced to writing, marked as provided above, and delivered to the receiving
party within thirty (30) days of the original date of disclosure."
which from a mailing-list centered activity is entirely a cat out of the bag
scenario. It's important that the project understand that the infra team
has a -strict- policy about not redacting project mailing list history for
any purpose whatsoever.
I am confident that at least three of the initial committers are clear
in their company hat / project hat deliniation and that any confusion
about this, in practice, will be cleared up in the project pre-committee.
Last and final objection, I want to make sure I am not missing something...
the contract between the spec participants is or is not public? If public,
was there a link I missed? If so, can it be added to the proposal for
completeness sake?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Carl Trieloff <cc...@redhat.com>.
William,
I have made some edits to the wiki on the Mechanisms for feedback
section to clean up the
language, based on some of the misunderstanding and to reflect the
discussion from the list
onto the wiki. Tried to keep it short, but can edit more in if required.
Carl.
William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
>
>>> But to the extent that ASF contributors offer productive growth and
>>> formative input into the specification, the way this section is phrased
>>> is not acceptable. If the contributor wish[es], and if under these terms
>>> their contributions merits participation, that contributor should either
>>> lead the ASF's direct involvement as the ASF spec liason (much as we've
>>> done within the JCP) or as an individual contributor.
>>>
>>>
>> I would love this.
>>
>
> Glad to hear that, but until the proposal is revised it is simply a platitude.
>
> I phrased that as an either-or or both, but we need to know from the spec
> committee what would be acceptable.
>
> I'm very concerned, though, that not one mentor has spoken up and added any
> feedback on this objection...
>
>
> Carl Trieloff wrote:
>
>>> 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.
>>>
>> 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
>>
>
> I'm a bit concerned about the project's apparent attitude "accept us and then
> we'll work out the wrinkles, or not". Even copyrights are already assigned
> as Apache Software Foundation when they are, in fact, not the ASF's yet. And
> FWIW - copyright will become much simpler under the new practice; no more
> individual file copyright notices, one collective NOTICE, one LICENSE file.
>
> Most important, so I'll say this for the third time;
>
>
>>> The specific statement "In the same spirit of Apache, if an individual has
>>> shown understanding of the project and substantive contribution to the
>>> specification, a vote based on technical merit and understanding of the goals
>>> of the work can be initiated to have that parties Employer join the
>>> specification working group."
>>>
>
> has put off this effort on the wrong foot. I hope this is addressed now, and
> not put off with some fuzzy "then we'll work out the details during incubation".
>
> It's not complicated, folks. ASF projects consist of individuals. Adding
> company affiliations after each of the initial committers names suggests, to
> some, that the day they move on to another company their contribution to the
> project ends. We understand why Cliff did so for himself (so that there would
> be no misunderstanding that he has a vested interest, bravo), but that this
> was propagated to the entire initial list of committers is very troubling.
>
> The effort seems entirely too eager to brand the project as Apache, entirely
> ready to defend the status quo or try to cite ASF policy back at any objectors,
> and entirely uninterested in addressing a couple of things; how to start off
> on the right foot as a collaboration of willing developers (not employers)
> at the ASF. That's the sense of what I'm reading - I'm not saying it's so.
> The enthusiasm is admirable, but the core issues need to be addressed before
> incubation begins.
>
> Address the crux of this please, the language of the spec feedback cycle and
> the spec body, and then let's all move *forward* to incubating the effort?
> The silence of the mentors on this makea me very concerned about their ability
> to adequately shape the evolution of this community.
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Carl Trieloff wrote:
>
>> But to the extent that ASF contributors offer productive growth and
>> formative input into the specification, the way this section is phrased
>> is not acceptable. If the contributor wish[es], and if under these terms
>> their contributions merits participation, that contributor should either
>> lead the ASF's direct involvement as the ASF spec liason (much as we've
>> done within the JCP) or as an individual contributor.
>>
> I would love this.
Glad to hear that, but until the proposal is revised it is simply a platitude.
I phrased that as an either-or or both, but we need to know from the spec
committee what would be acceptable.
I'm very concerned, though, that not one mentor has spoken up and added any
feedback on this objection...
Carl Trieloff wrote:
>
>> 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.
>
> 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
I'm a bit concerned about the project's apparent attitude "accept us and then
we'll work out the wrinkles, or not". Even copyrights are already assigned
as Apache Software Foundation when they are, in fact, not the ASF's yet. And
FWIW - copyright will become much simpler under the new practice; no more
individual file copyright notices, one collective NOTICE, one LICENSE file.
Most important, so I'll say this for the third time;
>> The specific statement "In the same spirit of Apache, if an individual has
>> shown understanding of the project and substantive contribution to the
>> specification, a vote based on technical merit and understanding of the goals
>> of the work can be initiated to have that parties Employer join the
>> specification working group."
has put off this effort on the wrong foot. I hope this is addressed now, and
not put off with some fuzzy "then we'll work out the details during incubation".
It's not complicated, folks. ASF projects consist of individuals. Adding
company affiliations after each of the initial committers names suggests, to
some, that the day they move on to another company their contribution to the
project ends. We understand why Cliff did so for himself (so that there would
be no misunderstanding that he has a vested interest, bravo), but that this
was propagated to the entire initial list of committers is very troubling.
The effort seems entirely too eager to brand the project as Apache, entirely
ready to defend the status quo or try to cite ASF policy back at any objectors,
and entirely uninterested in addressing a couple of things; how to start off
on the right foot as a collaboration of willing developers (not employers)
at the ASF. That's the sense of what I'm reading - I'm not saying it's so.
The enthusiasm is admirable, but the core issues need to be addressed before
incubation begins.
Address the crux of this please, the language of the spec feedback cycle and
the spec body, and then let's all move *forward* to incubating the effort?
The silence of the mentors on this makea me very concerned about their ability
to adequately shape the evolution of this community.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Carl Trieloff <cc...@redhat.com>.
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Carl Trieloff <cc...@redhat.com>.
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>
>> Carl Trieloff wrote:
>>
>>
>>> 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 presumpesuesume tuous
>> assertion, perhaps this project belongs elsewhere?
>>
The code is already under ASL, no issues with that. comment was to spec
feedback, sorry if that
was not clear.
>
> Oh - to the first half of your statement, I don't think it's a bad idea to
> filter the suggestions through a few key mentors who can track proposals
> through the spec committee. The bottom line is that the fruits of these
> ideas come from an ASL licensed code base by 'some member' who contributed
> to the implementation. So ... it's very important to know that dev@ spec
> discussion will be usable by the spec committee when pushed that direction
> by the spec liasons, from the ASF or any participating company.
>
> That's not necessarily something to postpone until incubation; from the day
> the dev@ list is created, you will begin to collect ideas on the dev@ list.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
>
>> 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?
Oh - to the first half of your statement, I don't think it's a bad idea to
filter the suggestions through a few key mentors who can track proposals
through the spec committee. The bottom line is that the fruits of these
ideas come from an ASL licensed code base by 'some member' who contributed
to the implementation. So ... it's very important to know that dev@ spec
discussion will be usable by the spec committee when pushed that direction
by the spec liasons, from the ASF or any participating company.
That's not necessarily something to postpone until incubation; from the day
the dev@ list is created, you will begin to collect ideas on the dev@ list.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Specifications as (part of) ASF projects
Posted by "Noel J. Bergman" <no...@devtech.com>.
Geir Magnusson Jr wrote:
> Noel J. Bergman wrote:
>> Geir Magnusson Jr wrote:
>>> Noel J. Bergman wrote:
>>>> Wait ... why can't a specification be a releasable, just like a
>>>> codebase? The only issue, as I see it, would be enforcement of
>>>> compliance. And Roy even put forward a proposed license amendment
>>>> for such things.
>>> Which license amendment? The license amendment that I'm thinking of was
>>> specific to JCP TCKs and how derivative works of a TCK can't be used for
>>> compatibility - it had nothing to do w/ enforcement of compliance with a
>>> spec.
> <grrr mail client changed?>
Not for the past 6 years. Would love the chance, and still waiting for someone to get clueful about migrating Outlook in its entirety, and not just a piece here and there. I've got >4.5GB of mail to migrate, plus 1000s of contact and calendar entries.
> > The JSR licemse, not the TCK license.
> I don't remember a JSR license.
I was referring to http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt, which could be adapted for the purpose.
> > what else would you call the clauses forbidding the use of the
> > trademark names, references to the specification, and restricted
> > name space unless the code passed the TCK?
> Dunno, but different than enforced compliance.
Denying implementers the ability to use the specification's restricted name space, which effects the use of the API; make any reference to the specification; or use the trademark(s) is probably about right when dealing with Open Source.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Noel J. Bergman wrote:
> Geir Magnusson Jr wrote:
>> Noel J. Bergman wrote:
>>> Wait ... why can't a specification be a releasable, just like a
>>> codebase? The only issue, as I see it, would be enforcement of
>>> compliance. And Roy even put forward a proposed license amendment
>>> for such things.
>> Which license amendment? The license amendment that I'm thinking of was
>> specific to JCP TCKs and how derivative works of a TCK can't be used for
>> compatibility - it had nothing to do w/ enforcement of compliance with a
>> spec.
>
<grrr mail client changed?>
> The JSR licemse, not the TCK license.
I don't remember a JSR license. I remember an addendum for an RI, and
an addendum for a TCK.
> Not that it can't be modified,
> but what else would you call the clauses forbidding the use of the
> trademark names, references to the specification, and restricted
> name space unless the code passed the TCK?
Dunno, but different than enforced compliance.
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Specifications as (part of) ASF projects
Posted by "Noel J. Bergman" <no...@devtech.com>.
Geir Magnusson Jr wrote:
> Noel J. Bergman wrote:
>> Wait ... why can't a specification be a releasable, just like a
>> codebase? The only issue, as I see it, would be enforcement of
>> compliance. And Roy even put forward a proposed license amendment
>> for such things.
> Which license amendment? The license amendment that I'm thinking of was
> specific to JCP TCKs and how derivative works of a TCK can't be used for
> compatibility - it had nothing to do w/ enforcement of compliance with a
> spec.
The JSR licemse, not the TCK license. Not that it can't be modified, but what else would you call the clauses forbidding the use of the trademark names, references to the specification, and restricted name space unless the code passed the TCK?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects (was RE: Too many licenses?
Was: [vote] Accept Glasgow)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
What broken mail client are you using?
inline...
Noel J. Bergman wrote:
> Carl Trieloff wrote:
>
>> -> Is Apache in the business of writing and publishing specifications? <-
>
>> 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.
>
> Wait ... why can't a specification be a releasable, just like a codebase? The only issue, as I see it, would be enforcement of compliance. And Roy even put forward a proposed license amendment for such things.
Which license amendment? The license amendment that I'm thinking of was
specific to JCP TCKs and how derivative works of a TCK can't be used for
compatibility - it had nothing to do w/ enforcement of compliance with a
spec.
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)
Posted by Brian McCallister <br...@apache.org>.
On Aug 13, 2006, at 10:49 AM, Noel J. Bergman wrote:
> Carl Trieloff wrote:
>
>> -> Is Apache in the business of writing and publishing
>> specifications? <-
>
>> 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.
>
> Wait ... why can't a specification be a releasable, just like a
> codebase? The only issue, as I see it, would be enforcement of
> compliance. And Roy even put forward a proposed license amendment
> for such things.
>
> As you saying that if the ASF would host the specification, that
> you and the rest of the AMQP IP holders would be willing to
> contribute and manage the specification here under ASF practices?
>
> I would be in favor of such an approach. Honestly, I would vastly
> prefer to have Open Specifications managed under ASF processes than
> under the JCP, OASIS, etc.
I very much agree.
-Brian
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Carl Trieloff wrote:
> -> Is Apache in the business of writing and publishing specifications? <-
> 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.
Wait ... why can't a specification be a releasable, just like a codebase? The only issue, as I see it, would be enforcement of compliance. And Roy even put forward a proposed license amendment for such things.
As you saying that if the ASF would host the specification, that you and the rest of the AMQP IP holders would be willing to contribute and manage the specification here under ASF practices?
I would be in favor of such an approach. Honestly, I would vastly prefer to have Open Specifications managed under ASF processes than under the JCP, OASIS, etc.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Too many licenses? Was: [vote] Accept Glasgow
Posted by Carl Trieloff <cc...@redhat.com>.
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.
Regards
Carl.
> Clarifications welcomed.
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>