Relationship between OSOA body & Apache

[Ken Tam <ke...@gmail.com>]

I urge anyone with an interest in Tuscany and who is associated with
the OSOA body to read this rather lengthy mail forwarded from
general@incubator.

It's becoming increasingly likely (and appropriately so, IMO) that
coming up with a very concrete description of the relationship between
the OSOA body and Apache (that is established as mutually satisfactory
for both organizations) is going to be a pre-condition for graduation
from the incubator.

---------- Forwarded message ----------
From: Cliff Schmidt <cl...@gmail.com>
Date: Jul 20, 2006 1:33 AM
Subject: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
To: general@incubator.apache.org
Cc: cctrieloff@redhat.com


On 7/19/06, Henri Yandell <fl...@gmail.com> wrote:
> I was assuming that standard bodies dictate the license to a large
> extent, and given that those have caused trouble in the past the idea
> of a new project with that still undefined is a worry. The term
> "standards body" is a mental flag :)
>
> I asked Cliff as champion about this bit and he said he'd reply here
> in a few hours.

First of all, let me apologize for the longest email I've written in
some time.  I've obviously had too many of these thoughts built up in
my head over the last couple years, and it's all apparently spilling
out now...

But before I begin to ramble, let me give a brief response to Henri's
comment above:
The major concern we've had around standards bodies lately was with
OASIS's WS-Security.  That Technical Committee's IPR mode (IP rights
licensing) does not conform to any of the three options of the new
OASIS IP policy.  Instead it is called legacy, meaning that it could
be anything, and we were unhappy with the particular terms that the
vendors picked (which are now being considered for revision based on
our feedback).  That was probably the reason for your mental flag.

Regarding whether a standards body would dictate the IPR terms is that
it is not their IP to dictate.  They body either has an IPR policy (or
at least an IPR option) that is compatible with the license the
authors have chosen (and have agreed to keep in force in future
versions) or they don't.  If they don't, the contract that they
authors signed to keep the spec under RF terms doesn't allow the spec
to be submitted to such a standards body.  But, the thing is that the
W3C, OASIS, and many others do, in fact, have Apache-friendly options
if the authors choose to pick them when forming the TC.

now on to my big-picture thoughts about this proposal...

The cool thing is that several people (Brian, Dims, Paul, and others)
have been asking the exact same questions I asked when I was
approached to champion and mentor this project.  The answers I got
from Carl sounded equal to or an improvement over other projects we've
accepted for incubation in the past.  Based on these answers, I had
two thoughts:
 - It's difficult to reject a proposal when we've accepted others that
are based on less-open specifications (unless we've declared such
projects as failures, not to be repeated), and
  - If the Blaze committers are willing to accept the fact that they
will not graduate from the Incubator until the AMQP process meets our
standards for specification openness, I'd like to spend my time using
this project to help get ASF folks to reach a consensus on exactly
what we mean by open specifications implemented at Apache.

In short, Blaze is more open than Tuscany; but we might want a higher
bar.  I'd like us to document exactly what that bar is and hold all
podlings to it before we let them graduate.


on to some specific issues...

1. Licensing of the specification.
a. Copyright licensing
Carl had told me that the specification license would allow for
royalty-free (RF) distribution of the specification itself.  I think
(and would like others to confirm) that it might be important to be
able to include a copy of the spec within source code distributions of
any release.  We would clearly need the distribution right for this.
And, even if we didn't need to do this, we might want to check the
spec into subversion or possibly post the whole or parts of the spec
on an ASF website.  We would need a distribution right for this as
well (some specification licenses reference the right to display, but
this is not enough).  Some people might even claim that an
implementation of the spec copies and eventually distributes parts of
the specification in its source and/or binaries.  I'm actually not too
worried about this argument, although it might be another reason to
want to see the word "distribute" in the RF grant for the spec.

 * The bad news on this is that the spec license appears only to grant
copy, display, and implement rights, not distribution.
 * The good news is that I asked Carl about this today, and he says
he's surprised at that as well and expects it is only an
administrative hassle to get it fixed, but that it will happen.
  * The ugly news is that the SCA spec that Tuscany is based upon
seems to have the same problem.

b. Patent licensing
 * The good news is that there is an RF license for all patent claims
required for  implementation, and there is no contract required to be
signed, nor is there any requirement for cross-licensing, instead just
a patent-retaliation clause not too far different than that in the
Apache License.
 * The bad news is that it's a whole lot of text to accomplish
something nearly identical to many shorter versions that make people
more comfortable and don't require as much lawyer time.


2. Application of the non-public specification drafts.
If a project is chartered to implement a specification (whether in a
standards body or not), I don't ever want to see code committed to its
/trunk that is fulfilling the implementation of a private version of a
specification.  Most of the "standards" that we base our
implementations on have stages between drafts that are not public.
However, if a committer is privy to the private drafts, they should
not be using those drafts in their code contributions.

  * The good news is that Carl has assured me that this will never
happen, and I will be there with other mentors to make sure no one
slips.  I hope all our projects in this situation are careful about
this.  One allowance might be to let any committer experiment with
ideas in a sandbox or experimental branch if that helps provide
feedback to the specification group.

3. Openness of participation in the specification.
This has recently become one of my top concerns at Apache.  Brian,
Paul, and others have mentioned this same concern on this thread.
Here's how I would phrase the problem:

      "If an Apache project is based on a specification that is driven
       by a closed set of authors, including some, but not all committers,
       how can the technical decisions of the project truly be based on
       an open meritocracy?"

This was the most important issue for me since I saw the Blaze
proposal.  This is also another place where I think Tuscany has a
problem (sorry to keep picking on this project -- I have nothing
against any of the Tuscany committers, many of whom are friends of
mine, but I do think we think carefully about the right process before
they graduate from incubation).

There are a lots of ways one could deal with this; here are a few:
  (a) Let only the Apache committers write the spec
  (b) Allow the ASF to join the specification group and send whomever
we like as our representative(s)
  (c) Allow individuals to join the specification group as equal
partners simply based on their status as a project committer and/or
PPMC member
  (d) Ensure the specification group is selected based on a similarly
meritocratic process as Apache.

I personally think all of these are reasonable options, although that
might not turn out to be the consensus view (or even my view after
hearing others' thoughts).

- Option (a) is nice, but I recognize that vendors sometimes prefer to
work out specifications in  a working group separate from/parallel to
the implementation work.

- Option (b) is the JCP-style option.  Carl has already welcomed this
option; I've also heard Tuscany folks ponder it.  I think it's not a
terrible idea, but I have one concern: having the ASF join is a pretty
big public endorsement of the group.  Even though the JCP was
well-established and somewhat understood (about as much as it's ever
really been understood) when we joined, it was still a big endorsement
for them.  So, my concern is that we might not yet be comfortable with
understanding how these guys operate to offer up the headline, "Apache
Joins AMQP".  That time might come, possibly before the spec is
submitted to a formal standards org; but IMHO, it is too soon to do so
now.

- Option (c) is basically building on the results of Apache's
meritocratic process without requiring a formal ASF relationship with
the standards org/vendor consortium/set of authors.  This is just a
random thought I had recently; not sure how well it would work.

- Option (d) is establishing a parallel meritocracy.  It's not our
system, but it matches our principles and allows all committers an
equal opportunity to be involved.

  * The good news is that AMQP has agreed to option (d).
  * The bad news is that, unlike the ASF (although very similar to the
Eclipse Foundation), they insist on the individual's employer to play
a role due to concerns over who owns work-for-hire IP.  See more on
this below.
  * The ugly news is that (correct me, if I'm wrong), the SCA
specification group, which Tuscany is based upon, does not currently
offer any of these options -- nor did it when we accepted their
proposal.
  * More ugly news is that the OASIS and W3C specifications that we
implement today do not offer any of these options.  They are both
pay-to-play, and the W3C doesn't even allow individuals to join (other
than as invited experts, which is rare and often related to previous
relationships).  The JCP allows and doesn't charge individuals, and we
also have membership with them; but the Spec Lead has significantly
more control of the specification than the other members of the Expert
Group.  While the Executive Committee (which the ASF is a part of) can
reject the entire spec, the role of Spec Lead turns is closer to the
benevolent dictator model than the consensus-driven development we're
used to.

So, back to the details behind AMQP's option (d):
Carl has stated that individuals cannot join the group because of IP
concerns.  I believe (based on past conversations...and please correct
me if I'm wrong here, Carl) that he means that, should an individual
be interested in participating as an equal member of the specification
group, that opportunity will be based on exactly two factors: 1) the
judgement of the group as to the merit of that individual's past
contributions to the specification, and 2) the consent of their
employer to enter the contract with the specification group *when it
is reasonable to assume that the employer has claims on the IP
submitted by the individual* (which would be most cases).  As I
mentioned before, this sort of check is not far from what the Eclipse
Foundation requires to ensure that employees don't inadvertently grant
their employer's rights without proper authority to do so.  However,
should a self-employed individual want to join the group, the only
pertinent factor would be merit.


If anyone has actually read this far, thanks for indulging my thoughts
on this.  I believe that the Blaze proposal clearly meets the
precedent we have set to *enter* incubation (obviously, or I wouldn't
have championed it).  I also believe that the committers intend to
cooperate with us as we come up with exactly what it means to meet
Apache's standards for "openness of specifications", and that they
will meet these standards before graduation.

Cliff

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org