Christian Huitema | 4 Dec 19:58 2002
Picon

RE: History of IPR in IP Storage WG and Questions It Raises

One thing is to require that all patents be licensed for free, another
is to require disclosure. In one case there is loss of property, in the
other there is the inconvenience of having to disclose the existence of
an application. Compare that inconvenience to the symmetric
inconvenience of the working group members who work on a technology for
12-24 month only to discover then that "you won't license it cheap". I
would say that your inconvenience of early disclosure is less than their
inconvenience of having to rework the standard. 

> -----Original Message-----
> From: Eric Burger [mailto:eburger <at> snowshore.com]
> Sent: Wednesday, December 04, 2002 10:11 AM
> To: Elizabeth Rodriguez; ipr-wg <at> ietf.org
> Subject: RE: History of IPR in IP Storage WG and Questions It Raises
> 
> The problem is not with the RFC 2026, but with the patent system.
> 
> I will speak for myself, not for Lucent.
> 
> When I file for a utility patent, I have no idea what the patent
office
> will allow.  For example, I may file a patent that claims everything
you
> need to do Protocol X, namely technologies A, B, and C.  However, two
> years from now *if* the patent issues, the patent office may pare down
my
> claims to only C.  Moreover, technology C may not be applicable to
> Protocol X.  Thus I cannot say if my application does or does not
cover
> Protocol X.
> 
> Why can't I disclose what my application is?  I can't do that because
it
> opens myself to some expensive flack from competitors.  I won't
disclose
> unless I have to, which occurs when the patent office publishes the
> application.  That is why the EPO publishes applications immediately,
and
> the USPTO publishes patents after 12-24 months (depending on
> circumstances).
> 
> Why doesn't my "What I submit is RAND/RF" statement cover things that
> others submit?  This should be quite obvious.  I spend $Blns on a
> technology.  My competitor sees it is a good thing, but knows that I
won't
> license it cheap (because I need to get my money back somehow).
Rather
> than licensing it from me, *they* submit it to a standards body that
> requires me to license it for free.  Last I looked there is another
word
> for that.  We call that "theft."
> 
> 
> > -----Original Message-----
> > From: Elizabeth Rodriguez [mailto:ElizabethRodriguez <at> ieee.org]
> > Sent: Monday, November 18, 2002 2:38 AM
> > To: ipr-wg <at> ietf.org
> > Subject: History of IPR in IP Storage WG and Questions It Raises
> >
> >
> > All,
> >
> > Below is a history of IPR issues that were faced in the IPS working
> > group.
> > Some of these issues were mentioned at the IPR meeting in Yokohoma.
> > I plan on discussing some of these issues again at the IPR meeting
> > Monday.
> >
> > Elizabeth Rodriguez
> > IPS co-chair
> > -----
> >
> > The IPS working group has encountered several issues in relation to
> > IPR in the course of deciding which security algorithms and
protocols
> > to specify for their drafts. The case in this email shows
disclosures
> > that were done in ways that were problems for the working group.
> >
> > In the IPR meeting in Yokohoma, Elizabeth Rodriguez and David Black,
> > co-chairs of the IPS WG, briefly discussed some of these issues that
> > were faced by IPS WG with respect to IPR.  This message is intended
to
> > briefly expand that report, and raise detailed problems, to see if
> > the policy and Note Well need some tuning to support better
practice.
> >
> > For the most part, the situation in the IPS WG centered around a
> > specific technology -- SRP.  SRP is the Secure Remote Password
> > protocol, specified in RFC 2945.
> >
> > SRP was contributed by Thomas Wu of Stanford University.  Stanford
> > University has offered a royalty free license for SRP.  Stanford has
> > also indicated that they believe that SRP is free of other IPR.
> >
> > (http://www.ietf.org/ietf/IPR/WU-SRP;
> > http://www-cs-students.stanford.edu/~tjw/srp/license.txt;
> > http://www-cs-students.stanford.edu/~tjw/srp/whatisit.html)
> >
> > But it came to the attention of the IPS WG that two other companies,
> > Lucent Technologies and Phoenix Technologies, might have IPR related
> > to SRP.  Through the security area, it was noted that EKE (Lucent)
and
> > SPEKE (Phoenix) might be related to SRP, despite the Stanford
> > disclaimer.  The Security Area had been struggling with EKE and
SPEKE
> > claims against SRP for a while. It should be noted that the security
> > area of the IETF has an unwritten policy against the use of
> > cryptographic algorithms and protocols that have IPR claims against
> > them in all but the most extreme/demanding circumstances.
> >
> > SRP was not a work item in any WG of the IETF. Lucent has a
> > general IPR
> > statement (Statement available at:
> > http://www.ietf.org/ietf/IPR/LUCENT-Patents)indicates states that:
> >
> >      If part(s) of a submission by Lucent is(are) included in a
> >      standard and Lucent has patents and/or pending application(s)
> >      that are essential to implementation of such included part(s)
in
> >      said standard, Lucent is prepared to grant - on the basis of
> >      reciprocity (grantback) - a license on such included part(s) on
> >      reasonable, non-discriminatory terms and conditions.
> >
> > Since Lucent did not contribute to the development of SRP, Lucent
> > indicated that the above statement did not apply.
> >
> > Issue: Does the general IPR statement above satisfy the IETF policy
on
> > IPR submission?  Essentially, if read in the most strict sense, the
> > above indicates that if Lucent did not formally contribute to a
> > technology, in written form, the above does not apply. (This seems
to
> > be the manner in which Lucent intended this statement, see Lucent
> > letter of Nov 30, 2001 (bottom of
> >   http://www.ietf.org/ietf/IPR/LUCENT-SRP disclosure)
> >
> >     As you are aware, RFC 2945 was neither submitted or proposed
> >     by Lucent.  Therefore, Lucent's general patent statement
> > to IETF in
> >     1999 does not cover RFC 2945.
> >
> > One interpretation of the Note Well is that a general IPR statement
> > meets the requirements of the Note Well, and thus no further IPR
> > disclosure from a company is required when they have IPR on a
specific
> > technology, and participants in a Working Group.  If the general IPR
> > statement had applied in this case, disclosure of IPR in a specific
> > technology such as SRP might not have had to be made to the WG.
> >
> > This is problematic, in that while it may or may not satisfy a legal
> > requirement (e.g. Dell VL-Bus suit), it would not satisfy the
> > spirit of
> > the request.  That is, in order for a WG to make an intelligent
> > decision on a technology, they need to know about any IPR that any
of
> > their contributors (where contributions is defined as attendance,
> > verbal or written comment or formal submission) might possess about
a
> > technology when it is being discussed.  While the general statement
> > may allow anyone to license adopted IPR on reasonable terms and
> > conditions, it does not meet the IETF's technical need.  The working
> > group needs to have some information to make its determination about
> > the decision on the technology (it is understood that
> > companies will not
> >
> > always be willing or able to give pointers to the specific location
of
> > the
> > claim, or the claim may still be pending, so the information
> > cannot be
> > expected to be perfect).
> >
> > As previously stated, Lucent determined the 1999 general IPR
statement
> > did
> > not apply to SRP. At first, Lucent indicated that they would make a
> > disclosure to the IPS WG, and then changed their minds. After much
> > delay,
> > (and some negative press -- see
> > http://www.byteandswitch.com/document.asp?doc_id=11764) they
> > finally did
> > give a statement to the IETF on IPR related to SRP.  That statement:
> >
> >      Lucent has not conducted and has no current plans to conduct a
> >      search of its patent portfolio with respect to SRP.  In
addition,
> >      Lucent has not studied and has no current plans to study its
> >      patents with respect to SRP.  However, in the event that any
> >      Lucent patents are determined to be essential to the
> >      implementation of SRP as an IETF standards track specification,
> >      Lucent is prepared to grant - on the basis of reciprocity
> >      (grantback) - a license to those patents on reasonable and
> >      non-discriminatory terms.
> >
> > (Full statement available at:
> > http://www.ietf.org/ietf/IPR/LUCENT-SRP)
> >
> > This statement seems evasive of the working group's needs in that it
> > neither claims or denies rights in SRP. In essence, a conditional
> > disclosure. Such a statement is probably worse than no disclosure at
> > all, in
> > that it implies IPR in SRP without explicitly stating a claim.
> >
> >
> > The Phoenix Technologies statement on the SRP is found at
> > http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt.  This
statement:
> >
> >      This is to advise the IETF that Phoenix Technologies Ltd.
> >      ("Phoenix") has U.S. Patent Number 6,226,383 that may
> >      relate to the IETF document RFC 2945 titled "The SRP
> >      Authentication and Key Exchange System".
> >
> >      To the extent that this patent assigned to Phoenix is
> >      necessary for implementation of RFC 2945 or any related
> >      IETF standard, Phoenix will provide, upon written request,
> >      to implementers of the relevant standard, a non-exclusive
> >      license under reasonable and non-discriminatory terms.
> >
> > This statement is clearer than Lucent's in that it at least
> > identified a
> > specific patent, though it is still provisional.  There may not be
> > issues
> > to raise with respect to the policy and the Phoenix disclosure.  But
> > its presence should not distract from the issues raised by the
Lucent
> > case.
> > Other disclosures emulate Lucent's language now.
> >
> > The SRP issue caused major problems for the IPS working group,
> > delaying the decision on the mandatory to implement authentication
> > method
> > for some 7 months or more.  A majority of the people actively
> > participating
> > in IPS wanted SRP to be the mandatory to implement authentication
> > method.
> > Technical analysis convinced this group that it was by far the best
> > choice.
> > But, a group of people were very concerned with SRP being mandatory
to
> > implement -- especially members of the open source community
> > and smaller
> > companies who did not necessarily have the monetary funds, IP
> > portfolios
> > or
> > legal resources to undertake a patent search and license the
> > technology
> > from
> > multiple companies.
> >
> > The outcome of this whole issue basically boiled down to the
submitter
> > the
> > following:
> >   - The SRP protocol, Tom Wu backed by Stanford University, granted
a
> >     royalty free license to SRP.
> >   - The legal department at Stanford had performed IPR searches, and
> >     felt that SRP was free of other IPR.
> >   - Even with this assurance, the IETF IPR policy allowed others to
> > state
> >     they might have claims, without definitively claiming
> > IPR.  At least
> > one
> >     claim can be argued to be poorly formed in terms of RFC
> > 2026 and the
> >     Note Well policy, but the presence of both claims cast much
doubt.
> >   - The same techniques as were used by Lucent might hypothetically
be
> >     used to bias against a technology in a working group setting.
> >
> > Is this case enough of an example to suggest strengthening the IETF
> > policy?
> > We can offer recommendations if the case seems compelling -
> > the changes
> > need not be large.
> >
> >
> >
> >
> > ------- End of Forwarded Message
> >
> > _______________________________________________
> > Ipr-wg mailing list
> > Ipr-wg <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipr-wg
> >
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipr-wg

Gmane