• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Formal Process

Page history last edited by Chris Messina 13 years, 10 months ago

Introduction and Goals

There are the (conflicting) goals of an OpenID IPR policy:

  1. Produce specifications which are free from patent and copyright encumbrances.
  2. Minimize process imposed on participants, i.e., keep as “lightweight” as possible, especially in terms of executing licenses
  3. Facilitate free-wheeling, open-ended discussion in the current modes (a small handful of email lists consisting primarily of individuals who detest process and who have no IPR to protect).
  4. Maximize participation from IPR holders who would like to contribute IPR.
    1. Make contribution "safe" in terms of being well-scoped and well-defined.
  5. Maximize clarity on the IPR encumbrances around specs produced by the community for the purposes of 3rd parties who may want to adopt the specifications

Taking the proposed Formal IPR Policy as a base, this page proposes a layer of process that should be a workable solution to meeting these goals. Though not perfect, like most open source the intent is to be "good enough".

Licensing Commitments

As a participant, you have to agree to the Formal IPR Policy in one of two modes:

Blanket Licensing

You agree to licensing/non-action for anything produced and finally voted on in the openid discussion lists.

Specific Licensing

You state your intent to license only with respect to certain documents from a list that are currently on the table (discussed below).

You are a Specific Licensing Participant if you are operating under specific licensing, otherwise you are a Blanket Licensing Participant.

The point of this bifurcated IPR mode is to make today’s modal case (ie non-assertion on any IPR) the simplest case and the default case. We believe this will cover the vast majority of today's participants. Obviously organizations like Microsoft (and we've heard this from others as well) need to operate under the other mode whereby they commit to licensing/non-action for only specific specs (whose scope and associated mailing list(s) are well defined and agreed-to by the community).

"On The Table" Documents

This new process layer consists of having a list of specifications that are on the table at any given time. A spec is officially On The Table after a community discussion and vote. A spec may be proposed before it is officially On The Table, but it may not proceed to formal voting without first being voted On The Table.

The On The Table vote is based on (at least) a clearly defined scope statement that bounds the spec (i.e., bounds the commitment for licensing for the Specific Licensing participants). It is expected that Specific Licensing Participants will execute the IPR license for each of the On The Table specs, but they are under no obligation to do so. The fact that there are any Specific Licensing Participants that have NOT in fact executed Specific Licenses for a spec may be influential in the final vote on that spec. There’s lots of self-incentivizing community pressure set up by this transparent, open community process that we hope reduces the need for more complex rules.

The process to put a spec On The Table should start with a proposed specification scope statement and a proposal to make the spec On The Table. After community discussion it should be decided by community vote. Discussion about the specification scope should elucidate any pushback or resistance from IPR holders who are Specific Licensing Participants, i.e., the goal should be for the community to understand whether a license will or will not be forthcoming. Additionally, Specific License Participants will have an opportunity to influence the scope at this point – and the community may in turn influence a Specific License Participant. Note that at no point is anyone ever committed to license during this discussion process (or at any time, unless they committed to a license and didn't withdraw before the final vote on the spec).

Notes on Withdrawal

  • Participants can switch between Blanket and Specific Licensing modes at any time (until a spec becomes final).
  • Participants can withdraw licenses (or references to specific documents) at any time until a spec becomes final (as voted by the community).
  • One a spec is voted final, a Participant cannot withdraw license. 

Other Notes

  • When a person subscribes to the list (any list?), they are asked what licensing mode they are operating under. They must commit to Specific Licensing or Blanket Licensing. (It is possible to commit to Specific Licensing without listing a specific spec, however). Obviously, this needs to be managed on an employer-by-employer basis if the person is participating on behalf of their employer.
  • All Specific Licenses are publicly visible, including full dated revision history. This is critical for 3rd parties to ensure clean IPR hygiene.
  • Blanket Licensing parties will not be required to affirmatively submit a license - their subscription indicates commitment to the Blanket License. Thus, the full list of subscribers at any given time is required to be publicly available (and probably full dated revision history). It is understood that if you are a Blanket Licensing subscriber at the time of formal spec passage, then you are committing to a Blanket License.
  • A footer on each email to the list(s) must have a link to the IPR policy, a link to the list of specific licensing participant list, and perhaps a list of the current specs that are On The Table (that reminder is important!).
  • This will require minimal policing by the community – probably just period reminders, notification at votes, etc. Discussion outside the specs On The Table is fine, but that there is a risk that such a spec may be covered by IPR claims of Specific Licensing participants who have no interest in executing a Specific License. Some education will be needed here, and perhaps someone (the OpenID Foundation ED?) should have the role of making sure everyone is playing by the rules (or at least understanding the implications of what they are doing w/r/t discussions and licensing, etc).

ISSUES/TODO

#1 – Specification Voting

How are specs "voted final"? By majority vote of the companies/individuals who are confirmed Participants under either Blanket Licensing or Specific Licensing? By 2/3 or 3/4 majority of the same? When they make their IP commitment, is the company required to publicly declare who its voting representative is? A clear definition of this process should also be part of the Formal Process.

from Mike Jones

#2 – Evaluation Period

In the voting process there needs to have an evaluation period built-in during which a participant can decide whether to withdraw their IP commitment to a particular specification. The suggestion is 30 days. This would prevent, for instance, a hypothetical On The Table spec being changed in a way that was unacceptable to a Specific Licensing Participant and then immediately voted final. With a reasonable evaluation period, a Specific Licensing Participant would have adequate time to evaluate the final result and decide whether to commit their IP to the spec as voted upon or whether to withdraw their commitment.

from Mike Jones

Blame and Discussion

This process was proposed by Gabe Wachob with feedback from Mike Jones. An email list for discussion of this process and the underlying IPR policy is being setup.

Comments (0)

You don't have permission to comment on this page.