Re: [chairs] reminder to chairs: OASIS IPR Policy member review

[David RR Webber <david@drrw.info>]

Robert,

Thanks for all these notes.

It is still very unclear to me - which of the three IPR choices 
currently on the table is intended to function as an 'IPR free-zone'. Eg 
- the TC is operating without any IPR licensing, and all participants 
are agreeing to contribute entirely unburdened submissions to the TC, 
and not attempt to gain future IPR on TC work

We have TCs that currently exist explicitly because work was proceeding 
under that basis - particularly government sponsored TC work, and 
clearly we need to retain that ability for TCs that operate under those 
constriants.

It would be good to know which of the three IPR choices matches this so 
those TCs gain reference that for their government sponsors accordingly.

We may also want to ask government legal departments involved to comment 
further.

Thanks, DW
=======================
Philpott, Robert wrote:

> Rats – I made a cut and paste error and dropped one of the comments. 
> I’ve embedded it below…
>
> ------------------------------------------------------------------------
>
> *From:* Philpott, Robert [mailto:rphilpott@rsasecurity.com]
> *Sent:* Friday, September 10, 2004 1:16 AM
> *To:* karl.best@oasis-open.org; chairs@lists.oasis-open.org
> *Cc:* patrick.gannon@oasis-open.org
> *Subject:* RE: [chairs] reminder to chairs: OASIS IPR Policy member review
>
> Karl, et al,
>
> RSA Security performed an internal review with our legal department to 
> evaluate the proposed OASIS IPR Policy. I've included our relevant 
> comments and questions below.
>
> The points we feel most strongly about are:
>
>     * Lines 73-79, 82-87: Defines the terms “OASIS Committee Draft”,
>       “OASIS Committee Specification”, “OASIS Specification”, and
>       “OASIS Standard”. In the recent revision of the TC process, the
>       term “Committee Specification” was eliminated and replaced with
>       “Committee Draft”. So it appears that this IPR Policy is
>       introducing a 3^rd level of specification (CD, CS, and Standard)
>       and uses the term “OASIS Specification” to meaneither an “OASIS
>       Committee Specification” or an “OASIS Standard” (depending on
>       context). Is this true? The use of the term “OASIS
>       Specification” in the policy makes it VERY difficult to keep
>       straight which level of spec is actually being referred to. This
>       gets WAY too confusing and is easily misinterpreted. We
>       recommend dropping the definition and use of this term. Wherever
>       the policy uses “OASIS Specification”, it should just use the
>       “OASIS Committee Specification” or “OASIS Standard” terms or both.
>     * Lines 103-105: The definition of “Products” only includes
>       “specific portions of products . . . that implement and are
>       compliant with */_all_/*_ _Normative Portions of an OASIS
>       Specification.” [emphasis added] However, “Normative Portions”
>       are defined to include portions of optional parts that must be
>       implemented. We suggest that the Normative Portions of optional
>       parts be excluded from the word “all”.
>     * Lines 311-312: There appears to be a choice between the terms
>       “that Obligated Party” and “all implementers of such OASIS
>       specification”. We prefer the term “Obligated Party”. The
>       license agreement is between the Licensee and the Obligated
>       Party. The Licensee is only getting rights to that particular
>       Obligated Party’s IP. It only seems reasonable that the
>       reciprocal grant be to the Obligated Party and not to ALL
>       implementers. If the grant back is to all implementers, the
>       Licensee may have no leverage to negotiate licenses with other
>       Obligated Parties, as those Parties will already have a license.
>
> · */[RSP] Lines 313-314: There is a choice between the terms 
> “Obligated Party” and “any implementer”. Again, we prefer the term 
> “Obligated Party”. Assume that Licensee enters into an agreement with 
> an Obligated Party, but does not come to agreement with another 
> implementer. If the term “any implementer” is used, the Licensee 
> cannot sue the implementer without worrying that Obligated Party would 
> terminate its agreement with the Licensee. The Licensee could not 
> enforce its IP against any other implementer. Every implementer would 
> effectively have a license without giving any consideration to that 
> Licensee, including reciprocal rights. The phrase “for infringement of 
> claims essential to implement such OASIS Specification” should be 
> replaced with “for infringement of Essential Claims”. What makes a 
> claim “essential” has already been defined. Using the defined term 
> will help prevent confusion. The provision in lines 312-315 also seems 
> one-sided. The Licensee should be able to suspend the license to the 
> Obligated Party if the Obligated Party sues the Licensee./***
>
>     * Lines 336-337: We prefer the term “that Obligated Party” for the
>       reasons described above for lines 311-312.
>     * Lines 338-339: We prefer the term “the Obligated Party” for the
>       reasons described above for lines 313-314.
>     * Regarding all of the licensing modes: The FAQ states in section
>       4.4 that the IPR Policy defines particular licensing baselines,
>       and that other terms more favorable to the Licensee may be
>       offered instead. We believe that the IPR Policy should
>       affirmatively state that the licensing terms apply unless a
>       separate agreement is reached. What is “more favorable” is
>       subjective, but we’re comfortable with this term. If, for
>       example, a licensee did not wish to provide reciprocal rights,
>       separate terms could be negotiated. The IP licensing modes
>       should not prevent companies from doing deals that make sense
>       for both parties.
>
> In addition we have a few other comments/questions:
>
>     * Line 45: The clause “in effect at the time such OASIS
>       specification was developed” is used. This is an odd sentence.
>       It is not clear from the sentence whether this clause modifies
>       the TC charter or “the claims in any patent or patent
>       application”. We suggest that the claims should include future
>       claims. Here’s a potential scenario. A patent application is
>       pending while a spec is being developed. The claims as filed do
>       not apply to the spec. After the spec is completed the claims
>       are amended to now cover the spec. It seems reasonable that
>       these claims should be included in the “Essential Claims.”
>     * Lines 46-49: As written, the definition of Essential Claims
>       includes Normative Portions of optional parts. I understand that
>       there may be several ways to implement a feature of a spec. We
>       would be concerned if one of our technologies was described as
>       an “option” and then we were forced to license. If there are
>       non-infringing “options”, our IP should not become an Essential
>       Claim.
>     * Lines 41-51: We suggest that the definition of Essential Claims
>       be clarified to state that the claims are “claims owned or
>       controlled by a party.” We further suggest that there be a
>       carve-out for claims “that if licensed, would require a payment
>       of royalties by the licensor to unaffiliated third parties.” In
>       the licensing requirements section (section 10), the Obligated
>       Party’s claims are referred to as “its Essential Claims.” Our
>       reasoning for the first suggestion is that the definition of
>       Essential Claims would then encompass both claims that are owned
>       by a company as well as claims for which a company is the
>       exclusive licensee with rights to sublicense. In certain
>       situations, patents are exclusively licensed rather than
>       assigned. The exclusive licensee basically controls the patent.
>       My reasoning for the carve-out is that if a TC selects a RF
>       mode, it would not be fair to force the Obligated Party to
>       sublicense for free and then have to pay fees to a third party.
>     * Lines 185-186: Refers to “implementations of draft versions of
>       an OASIS Committee Specification”. Is this the same as an “OASIS
>       Committee Draft” by the new definitions? Or is it referring to
>       rev’s (i.e. drafts) of the specs that have not been voted on by
>       the TC?
>     * Lines 279-281: This clause doesn’t seem quite correct. It says
>       that the obligation kicks in when an “OASIS Specification”
>       (which as mentioned earlier is either an OASIS Committee
>       Specification or an OASIS Standard) is approved that
>       incorporates “such OASIS Committee Draft, either in whole or in
>       part”. We can see how the “OASIS Standard” type of OASIS
>       Specification might incorporate the “OASIS Committee
>       Specification”, but it doesn’t make sense to talk about an
>       “OASIS Committee Specification” incorporating the “OASIS
>       Committee Specification”. This is very difficult to interpret
>       the intent of the clause. Also, the use of “in whole or in part”
>       seems to kick in the obligation even if the part that might be
>       included no longer deals with the claims.
>
> *Rob Philpott*
> /Senior Consulting Engineer/
> *RSA Security Inc.*
> *Tel: 781-515-7115*
> *Mobile**: 617-510-0893*
> *Fax: 781-515-7020*
> mailto:rphilpott@rsasecurity.com
>
>> -----Original Message-----
>
>> From: Karl F. Best [mailto:karl.best@oasis-open.org]
>
>> Sent: Friday, July 30, 2004 2:55 PM
>
>> To: chairs@lists.oasis-open.org
>
>> Subject: [chairs] reminder to chairs: OASIS IPR Policy member review
>
>>
>
>> TC chairs:
>
>>
>
>> On 9 July OASIS announced to its membership a draft IPR Policy that has
>
>> been developed by our Board, and requested that members review and
>
>> provide comment on this draft. (See
>
>> http://lists.oasis-open.org/archives/members/200407/msg00002.html)
>
>>
>
>> One of the documents in this review is the proposed Transition Policy,
>
>> which describes how TCs will transition to the new IPR Policy by
>
>> selecting an IPR mode to operate under, after which the OASIS members
>
>> (organizations and individuals) represented in the TC will vote to
>
>> ratify that selection.
>
>>
>
>> In addition to the other issues in the IPR Policy that you individually
>
>> and your companies may be interested in, I would also appreciate your
>
>> TCs looking at, discussing, and commenting on the transition to the new
>
>> IPR Policy, as well as any other parts of the Policy that will affect
>
>> the day-to-day operations of the TC.
>
>>
>
>> -Karl
>
>>
>
>> =================================================================
>
>> Karl F. Best
>
>> Vice President, OASIS
>
>> office +1 978.667.5115 x206 mobile +1 978.761.1648
>
>> karl.best@oasis-open.org http://www.oasis-open.org
>