OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


I'm not so sure this is quite as simple. I think we need something explictly upfront.

The ITEF has learned the hard way on this over the SenderID SNAFU - where
something that appeared to be progressing into the foundation of the Internet is then
found to have IPR associated with it. The Apache Project then baulked at using it,
and the IETF had to backtrack.

See - Google on "SenderID IPR" or http://xml.coverpages.org/ni2004-09-03-a.html

Clearly you have to know what rules you are playing by upfront - and not have a
situation (as happened with ebXML CPA) where a vendor comes back later
and says - sorry we changed our minds - and now the trip-wire you referred to is

Right now I'm not seeing that clear distinction with what is on the table. I have no
problem with TC efforts that want to be IPR bound - that is their choice - and
presumably they have specific reasoning for wanting to do that - but I cannot see
that being transferred to everyone else as the only modus operandi.

Thanks, DW
John Messing wrote:
I am not an expert in this field but it seems to me that the "IPR-free"
zone to which you refer is automatically excluded from the IPR policy
because only claims or potential claims of IPR involving work of a TC
can trigger provisions of the IPR policy in the first place. So perhaps
one way of looking at it is that the "IPR-free" zone is outside the
scope of the IPR policy but continues to co-exist nonetheless in a
robust environment.

Best regards.

John Messing
American Bar Association representative to OASIS
Member, LegalXML Steering Committee

-------- Original Message --------
Subject: Re: [chairs] reminder to chairs: OASIS IPR Policy member
From: "David RR Webber" <david@drrw.info>
Date: Fri, September 10, 2004 6:13 am
To: "Philpott, Robert" <rphilpott@rsasecurity.com>
Cc: karl.best@oasis-open.org, chairs@lists.oasis-open.org,


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 

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 

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
    * 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*

-----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
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 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]