[legal] Feedback on OpenID IPR Policy and Process

Mike Jones Michael.Jones at microsoft.com
Fri Oct 26 23:20:21 UTC 2007

Thanks for the careful read, Dick.  I agree with you that many of the issues you raise deserve clarification in the text.  Here's my take on most of the points you raised...

For instance, "participation in OpenID" should probably become "participation in the OpenID Specification Development Process".  And I suspect that you're right that should look for other unqualified uses of the term "OpenID" and qualify them.

Does anyone want to suggest any clarifying text around Dick's example of whether a blog post from a contributor about a spec is a contribution?  I suspect that it should be unless it is explicitly called out as not being a contribution.  Or should the default be the other way around, so that contributions are defined as stuff sent to the spec list plus other materials explicitly contributed via other channels?

There's a draft contributor agreement nearing publication but it's not out yet, hence the confusion about the agreement.  The last version I'm aware of is attached.

For retroactive effect, I suspect that yes, any content posted to any OpenID list that was incorporated into a specification requiring retroactive effect must be considered a contribution.  However, I suspect that, in the spirit of the rest of the process document, anything not incorporated into a spec requires no IPR declaration because we're only asking people to issue non-asserts for stuff actually in specs -- not stuff that in theory could have been included in the specs.

I agree with you that if we are borrowing definitions from the Bylaws we should be aware that we are doing this and consider moving them into the primary documents, as you suggest.  Group, what terms are we incorporating from the Bylaws by reference?

Some of the "Editor" and "Specifications Council" comments you'd made were already brought up by others are and being addressed.  For instance, it seemed overly heavy-handed to allow the specifications counsel to do things like remove editors.  The specs council should communicate and coordinate, not dictate or have official powers.

The rationale for supermajority is as a proxy for consensus, which is actually the desired outcome.

I agree that needing a specs council member to convene is unnecessary.  Instead, a liaison from the specs council should be sufficient.  Also, committees of 3 should fine -- 5 unnecessary.

Once again, I agree with Dick that the specifications council would be better limited to an advisory role, not a final-arbiter role.  Input is good, but introducing a second layer of bureaucracy between submission of a WP proposal and its approval by the board seems unnecessary.

The consensus language I believe was lifted wholesale from the W3C, for better or worse.  It's probably better than calling for votes and letting slim majorities rule, in any event.

Oops -- have to board a flight on the way back from Catalyst now.  Not done but wanted to get this much out now.  I'll write more on the plane.

Once reactions to these are out I believe we should schedule another IPR call that includes Dick.

                                                -- Mike

From: legal-bounces at openid.net [mailto:legal-bounces at openid.net] On Behalf Of Dick Hardt
Sent: Wednesday, October 24, 2007 11:35 PM
To: legal at openid.net
Subject: [legal] Feedback on OpenID IPR Policy and Process

Feedback on OpenID IPR Policy

2. "Contributions" mean any communication to or through a particular Specification Mailing
List, or other textual materials, that are provided by a Contributor and are intended for
inclusion in an OpenID Specification.

This is a little vague on the intention. If I post on my blog about OpenID about where I think it should go, is that a Contribution? Who determines if it was intended for inclusion?

3. "Contributor" means, with regard to a particular Work Group, any person (individual,
entity, or otherwise) who has signed the applicable agreement in accordance with Section II.
1(b) and has joined such Work Group by requesting access to the applicable Specification
Mailing List and, if such person is an individual, includes such person's employer or other
person or entity to whom that person owes a duty with respect to activities such as his or her
participation in OpenID.

Who or what is OpenID? "OpenID" is referenced a number of times. It is not defined. Is it the community, the spec, the foundation? The term is used in a number of different ways. I would suggest it only be used as an adjective and each use be defined in the definitions.

(b) OpenID Contribution Agreement.

Is this document the agreement? Is there a separate agreement? What is to be signed and returned? I don't see any signature blocks.
Who is the agreement with? There is the Contributor and ???
What jurisdiction is the agreement made in? Who enforces the agreement? What happens if a Contributor breaks the agreement?

1. Becoming a Contributor.

(d) Retroactive Effect.  In consideration of OpenID allowing any individual or entity to
become a Contributor, such individual or entity acknowledges that Section V and VI of this
Policy apply to any Contributions made before signing the OpenID contribution agreement
or otherwise agreeing to the terms of this Policy.

How would these Contributions be determined?  Would a post on ANY OpenID mailing list be considered a Contribution?


OpenID Process Document

1               Definitions.  Each of the following initially capitalized terms has the respective meaning stated below.  All other initially capitalized terms have the meanings assigned in this OpenID Process Document ("Processes"), in the OpenID Foundation's IPR Policy ("IPR Policy"), or in the Bylaws.

Is this not the OpenID Process Document? Is that not the same as the terms below?
Referring to the OpenID Foundation Bylaws as a source of definitions I think is troublesome as the Bylaws can be modified, causing a potential change in this document. I'd prefer to have all definitions in this document so that it is complete. Is there a reason for spreading the definitions around?

1.3"Bylaws" means the then-current bylaws of the OpenID Foundation, as may be modified from time
to time as provided therein.

I could not find the Bylaws for the Foundation online. A URL for the Bylaws should be included (as well as getting them online!)

1.5                "Editor(s)" means, for a particular Specification to be developed by a particular WG, the individual Contributor(s) selected to coordinate development of, and transcription of the work of the WG for, such Specification, as well as (together with any other Editors for that WG) to administer WG operation.
How are Editors selected? What stops all Contributors from being Editors?

1.6                "Specifications Council" means a group comprised of: (a) all past Editors of Final Specifications who are still actively contributing to the OpenID community; (b) two representatives from the Board (one of whom is the OpenID Foundation Executive Director; and (c) all Editors from current WGs.  Each Editor will participate as a non-voting member of the Specifications Council until he or she has published a Final Specification, at which time such Editor will become a voting member.

What makes an Editor an actively contributing member? When is an Editor removed? What is the rational for the OpenID Foundation to be involved in the Specifications Council? Are those voting positions?

1.7                "Supermajority" means at least two-thirds of those entitled to vote on an issue.
What is the rational for needing a Supermajority?

1.8                "Minimum Membership" means, five Contributors.  For a new WG to be formed, at least one such Contributor should optimally be a member of the Specifications Council.
What happens if there are no Contributors in a WG? Will it more likely be rejected? What is the rational that there should be a member of the Specifications Council?

2               Work Groups.

2.1                Proposal.  Any group of at least Minimum Membership may form a WG by submitting a proposal via the mailing list specs at openid.net<mailto:specs at openid.net>; such proposal will include the following items, will be written in English, and will be provided in a plain text electronic form:

(a)   Charter.  The proposal will include the WG Charter, which will include:

(i)          a WG name, which will not include trademarks not owned by the OpenID Foundation or content that is infringing, harmful, or inappropriate, and any acronym or abbreviation for that name;

(ii)        a clear statement of purpose;

(iii)       an initial Scope, which must be related to the purpose of the OpenID community and which will include a definition of what is and is not the envisioned "work" of the WG;

(iv)       a proposed list of Specifications, including working titles, to be produced (and any other deliverables) and projected completion dates;

(v)        anticipated audience or users of the work;

(vi)       the language in which the WG will conduct business;

(vii)     the method of work including any virtual or planned face-to-face meetings;

(viii)     a basis for determining when the work of the WG is completed.

(b)   Background Information.  The proposal will also include the following:

(i)          any related work being done in other WGs or organizations, why the proposed new WG is necessary, and any proposed liaison with any such other WGs or organizations;

(ii)        the names, email addresses, and any Constituent affiliations of at least the Minimum Membership who support forming the WG ("Proposers") and the proposed Editor(s); and

(iii)       optionally, a list of Contributions that the Proposers anticipate will be made to the WG.

2.2                Review.  The Specifications Council will review proposals within 15 days after receipt and promptly provide notice to specs at openid.net<mailto:specs at openid.net>, either accepting it or explaining the reason for rejection.  If a proposal is rejected, it may be modified and resubmitted.  The reasons for rejection will be limited to:

(a)   an incomplete Proposal (i.e., failure to comply with §2.1);

(b)   a Supermajority decision that the proposal contravenes the OpenID community's purpose;
This seems potentially arbitrary. What if there is a proposal that the Specifications Council does not like? This looks to be a source of politics. Why not let WGs get started and put more judgement on the output?

(c)    a Supermajority determination that the proposed WG does not have sufficient support to succeed or to deliver proposed deliverables within projected completion dates; or

Another potentially arbitrary decision point. Why not let the WG start and see if it can complete?

(d)   a good-faith determination that the proposal is likely to cause legal liability for the OpenID Foundation or others (in which case, the Specifications Council may seek Board review of the proposal).

2.3                After Acceptance.  Promptly after acceptance, a mailing list will be created for the WG and one or more of the Proposers should notify general at openid.net<mailto:general at openid.net> of the new WG.  This notice will announce the formation of a new WG, invite participation, and describe the WG's proposed work, including any planned meetings (as based on the approved Charter).  The first obligation of a new WG is to establish and approve its Scope, which should broadly describe the outer limits of the WG's work.

2.4                Contributors.  Only persons or entities that have properly agreed to the IPR Policy may become Contributors to (or participate in) a WG.  A WG may, however, make copies of its Specification Mailing List, drafts, and other documents available for review by non-members.  A WG will not review or acknowledge comments by, or accept Contributions from, anyone other than Contributors.  The Specifications Council may close a WG at any time that the WG has not had Minimum Membership for six consecutive months.
How is Minimum Membership determined? Addresses susbcribed to the mailing list? Or is it via a formal withdrawal.

2.7                Editors.  A WG's work is coordinated by one or more Editors, and each WG must have at least one Editor and additional Editors may be selected at any time.  Different Editors in a WG may, however, be associated with different Specifications.  If an Editor takes emergency leave, or is otherwise unavailable, an additional Editor will be selected.  If a WG does not have an Editor, it will suspend work until an Editor is selected.  The Specifications Council may close a WG at any time that it has not had an Editor for the immediately prior 30 days.  An Editor may also be removed at any time by the Contributors to the applicable WG, under §2.16; or by the Specifications Council, on its own initiative or in response to a complaint.
Per above, how are Editors selected?

2.16             Decisions.

(a)   General.  All decisions are either Core Decisions or Non-Core Decisions, and all decisions may be made in meetings (e.g., face-to-face, telephonic, or otherwise) or by email or other electronic means.  Any decision that is not clearly a Non-Core Decision will be treated as a Core Decision.  "Core Decision" means a decision relating directly to the WG's substantive work, including those related directly to Specification content, Charter, or Scope; to approve an Implementers Draft or a Final Specification, or to adopt Errata (defined in §3.6); and to amend the Charter or to re-charter the WG.  "Non-Core Decision" means any decision other than a Core Decision, including decisions on date, time, place, and method(s) of attending meetings and other administrative details regarding WG operation or governance.
Moving Core Decision and Non-Core Decision definitions to the Definitions section would make the document cleaner.
Is there a format for how decisions are presented? Who is responsible for determining the results of a decision? If removing or adding an Editor a Core decision or a Non-Core Decision? (S 2.6)

(b)   Consensus.  Consensus is a core value.  To promote consensus, Editors should encourage consideration and resolution of all legitimate comments of Contributors.  All WG decisions will optimally be made by determining consensus, without formal vote.  Editor(s) will assess consensus without a formal vote and, when a proposal is pending, may interpret silence of those who have received proper notice (or who are present) as assent.  Consensus does not imply unanimity, although there should be substantial support for consensus decisions.  For Core Decisions, consensus should reasonably reflect the opinion of a Supermajority of Contributors to the applicable WG, after reasonable inquiry by the Editors.  For Non-Core Decisions, consensus should reflect the opinion of a majority of Contributors actually expressing an opinion.
How is consensus determined? Is silence consent? Does one negative vote mean there is no consensus?

(c)    Formal Vote.  If a decision cannot be made by consensus, the WG should defer decision until consensus can be reached.  If deferral would prejudice a WG's work, however, the Editor(s) may call a formal vote.  Any such vote will otherwise be in accordance with §§4.6-4.9 of the Bylaws, as applied to all Contributors (even if not OpenID Foundation members), except as otherwise provided in this §2.16(c).
I would be much more comfortable if the Voting Process was defined in this document. A change in the Bylaws voting which has to do with the Foundation will now impact Voting in the IPR Process.

2.17             Closing a WG.  A WG may be closed at any time by majority vote of all of its then-current Contributors (or by Board resolution, for the reasons stated in these Processes or otherwise if deemed necessary by the OpenID Foundation to avoid or mitigate legal risk).  The Board may also close a WG that has completed all deliverables in its Charter and has not agreed to develop new deliverables within the 180 days before closure; or that has not reasonably progressed to achieve its purpose, as defined by its Charter.
Why is the Board responsible for closing a WG?

3.4                WG Decision.  Approval of a draft as an Implementers Draft or the then-current Implementers Draft as a Final Specification should be based on consensus.  If the WG cannot reach consensus, then the decision may be made by formal vote.  The WG Editor(s) will notify the WG of a determination that consensus has been reached or of a call for (and results of) a formal vote.  Any Implementers Draft or Final Specification approved by the WG will include a list of Contributors who participated in its development.
It is not clear that a Draft is approved by the WG, and only the WG. Is this true?
So if a bunch of people that oppose a spec join as contributors, then a spec will never be approved unless the Board steps in?

4               Board Involvement.

4.1                Delegation.  The Board may delegate any of its obligations under these Processes (other than creating subcommittees) to a subcommittee of Board members, OpenID Foundation members, or both, and applicable terms in these Processes will then be deemed to refer to the subcommittee instead of the Board.

4.2                Complaints; Appeals.

(a)   General.  On proper notice from a Contributor, the Board will consider any complaint related to, or appeal of, any action taken (or alleged failure to act) related to these Processes.  The Board has authority to take any action it deems necessary to remedy a complaint or appeal.
So the implication of this is that the Board is the Final arbitrator and can do whatever it wants?

4.4                Amendment.  The Board may amend these Processes from time to time, in its sole discretion.
Essentially the Board can make the specifications with this clause, as anything can be changed by the Board.

4.5                Decisions.  All Boards decisions under this §4 will be made in accordance with the Bylaws.

5               Miscellaneous.  All notices and correspondence under these Processes will be by email.  Unless stated, or context requires, otherwise: (1) "written" or "in writing" refers to a non-electronic document only, manually signed by authorized representatives of the writing party(ies); (2) all internal references are to these Processes; (3) "days" means "calendar days"; (4) "may" means that the applicable actor has a right, but not a concomitant duty; and (5) all decisions of the Board (or an Editor) under these Processes are in the Board's (or such Editor's) reasonable discretion.  Examples following "including" or "e.g." are not exhaustive (i.e., are interpreted to include the words "without limitation"), unless qualified by words such as "only" or "solely."  These Processes will be interpreted according to the plain meaning of their terms.  Section headings are for convenience only and will not affect the meaning of any provision.
Where are written documents sent?


General Feedback

1) Looking over the archives for Legal [1], I see nominal feedback from the OpenID Community at large. This should cause concern.

2) The OpenID Foundation is becoming a Standards Body. This is contrary to the Charter of the Foundation. The Governance of the Foundation did not anticipate being a Standards Body and the political implications of being a Standards Body. As a participant in the formation of the Foundation, it was very clear that we did NOT want the Foundation to be Standards Body. Will the Foundation be responsible and liable for enforcing the IPR of all the specs?

3) Many organizations will NOT use a standard that has not been endorsed by a recognized Standards Body. While the OpenID Foundation could lobby to be recognized, that will take time and fractures the market as alternative standards must be selected where OpenID would be appropriate.


The IPR for OpenID 2.0 needs to be cleaned up. Why not simply have the Contributors to the existing specs that are almost final make non-assertion statements and assign copyright, then move all further OpenID standards work to, dare I say it, OASIS?  The Foundation could join OASIS which would allow any individual contributor that is a member of OASIS to participate. As holder of the OpenID trademark, the Foundation would have an effective veto on a standard being able to use the OpenID trademark -- but no control on the development of specifications.

- Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-legal/attachments/20071026/54c62dbb/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Online Contribution Agr (Internal Circulation Draft 20071017).doc
Type: application/msword
Size: 65536 bytes
Desc: Online Contribution Agr (Internal Circulation Draft 20071017).doc
URL: <http://lists.openid.net/pipermail/openid-legal/attachments/20071026/54c62dbb/attachment-0002.doc>

More information about the legal mailing list