<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 25-Apr-07, at 2:31 AM, Drummond Reed wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"> <DIV class="Section1"><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy">Dick,<O:P></O:P></SPAN></FONT></P><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy"><O:P> </O:P></SPAN></FONT></P><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy">RE the IPR Policy, Blanket Reciprocity term, I don’t think you give a license for anything other than the Necessary Claims you contribute. The issue is that if you sue another Contributor for ANYTHING – even something totally unrelated to OpenID – you lose the license they have provided to any Necessary Claims they contributed.</SPAN></FONT></P><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy">See the suggestion in the Blanket Reciprocity open issue section for a simple way to fix that.</SPAN></FONT></P></DIV></BLOCKQUOTE><DIV>If I can't sue, I can't enforce, and I effectively have granted a license. Even with the suggested change, If someone's implementation infringes on a patent that is NOT required to implement OpenID, then if I sue, then they can counter sue for infringing on any OpenID related patent. Effectively I have granted a right to any patent used in their implementation.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type="cite"><DIV class="Section1"><P class="MsoNormal"><FONT class="Apple-style-span" color="#000080" face="Arial" size="4"><SPAN class="Apple-style-span" style="font-size: 13.3333px;"><BR class="khtml-block-placeholder"></SPAN></FONT></P><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy">RE the formal process, I agree that essentially it’s a very lightweight standards process. Call it a community process. But if you read Gabe’s proposal closely, the full skeleton is there. Voting (which would take place directly on the lists), membership (which involves only membership on the lists), governance (which is this process doc itself) is all covered – it’s all just very lightweight.<BR></SPAN></FONT></P></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Given the IP significance of this, the voting process is too loose. This is not open source software where there is a right to fork and on-going support of a core group is needed to move forward. The dynamics around a standard are quite different, and my experience with voting on the OpenID list has been very disappointing and inconclusive.</DIV><BR><BLOCKQUOTE type="cite"><DIV class="Section1"><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy"> <O:P></O:P></SPAN></FONT></P><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy"><O:P> </O:P></SPAN></FONT></P><P class="MsoNormal"><FONT size="2" color="navy" face="Arial"><SPAN style="font-size: 10.0pt;font-family:Arial;color:navy">Overall, if the choice at this point in time comes down to putting in place “just enough process” for the OpenID community to have its own lightweight process vs. being forced to move the specs to a full-blown SDO, I’d prefer the former.</SPAN></FONT></P></DIV></BLOCKQUOTE><BR></DIV><DIV>IMHO: Given the progress of the community to date, I think we would be able to produce a better spec faster in an existing standards organization. :-)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-- Dick</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>