[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 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 > review > 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, > patrick.gannon@oasis-open.org > > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]