[legal] Feedback on OpenID IPR Policy and Process

Mike Jones Michael.Jones at microsoft.com
Sun Oct 28 19:33:15 UTC 2007


Continuing my responses to Dick's comments (now that I'm back in the U.S.) ...

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.

I would be OK with copying the voting procedures from the Bylaws into the process doc.

Why is the Board responsible for closing a WG?

I believe that this is symmetric with its power to approve the establishment of a working group.

It is not clear that a Draft is approved by the WG, and only the WG. Is this true?

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?

True.  This seems fine with me because if there's sufficient opposition to a spec as to block consensus, by definition, it's not a consensus spec.

So the implication of this is that the Board is the Final arbitrator and can do whatever it wants?

Yes, the board is the final arbitrator.  There has to be one and this seemed like the logical choice.  No, it can't do whatever it wants because there are guidelines laying out what grounds under which a working group decision can be over-ruled (such as exceeding scope, creating undue legal risk for the foundation or a specification, etc.)

Essentially the Board can make the specifications with this clause, as anything can be changed by the Board.

Yes, there has to be a final arbiter and this was the arbiter we chose.  Unless there's a concrete counter-proposal, this seems like the best choice available.  The check-and-balance on this for most organizations is that board members must periodically stand for election.  Not sure whether this really applies here or not...

Where are written documents sent?

Good question

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

It could either be a cause for concern or an indication that the community believes we are headed in the right direction.  I don't think that this community has shown itself to be reluctant to speak up before, so I would take it as the latter.

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?

Yes, it's becoming a standards body.  I wasn't involved in the creation of the foundation so I can't speak to whether this was in scope for its charter or not.  (Can someone point us to the posted copy of the Foundation charter and other related documents?)  It *does* seem like something like a standards body is needed exactly to be able to collect the IPR commitments for all of the specs and to ensure that working groups are operating within their scope.

Whether this was the original intent of the creating the foundation or not, it *is* a necessary function for putting OpenID specifications on a sound IPR footing, and therefore, having it fill this role seems like a good thing to me.

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.

This doesn't seem like a serious problem to me.  Those who want the benefits that OpenID brings will use it.  Those who don't won't.  On the other hand, cleaning up the IPR status of the OpenID specs does solve a serious adoption problem -- one that we're on the verge of completing the solution to, once the IPR policy and associated procedures are approved.

I'll also comment that, if this is perceived as a problem, I *know* that OASIS (and probably other standards bodies as well) would be glad to take an approved OpenID spec and adopt it as an OASIS spec as-is.  Charters can be written to be so tightly scoped as to just allow an up-down vote by the OASIS committees, but no modifications.  This would solve the "recognized standards body" problem, should we decide that it's an actual problem.

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.

OASIS comes with its own sets of problems.  Developing specs in open committee has a track record of producing bloated, inferior specifications.  XML Schema (a W3C effort) was one such result in recent memory.  Far better to develop specifications that are first vetted through the existence of multiple implementations based upon implementers drafts, then have them stamped final by the OpenID process, and possibly then sent as-is to an "official" standards body.

Dick's questions do bring up one of my own.  How can we enshrine the notion that specifications should only be approved when there are multiple independent interoperable implementations of them?  The IETF has such a policy.  I believe that the OpenID process should as well.

Thanks again for the thoughtful comments Dick.

                                                Cheers,
                                                -- Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-legal/attachments/20071028/637d5bbf/attachment-0002.htm>


More information about the legal mailing list