[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary
+1 to Jeff's comments. And we should be very precise with terminology in these discussions... as the OASIS IPR Policy, per se, applies to all of us.
Outside of the copyright provisions, the IPR Policy is essentially a way to insure that the ultimate implementer has the right/ability to get needed licenses from Obligated TC Members when the specification is implemented - as our goal is to get multiple implementations of the spec into the marketplace. And the obligations don't spring until there's actually the final specification approved. OK, that's shorthand, as there are lots of details in the IPR Policy!
Jim
-----Original Message-----
From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
Sent: Friday, January 22, 2010 2:19 PM
To: Patrick Durusau
Cc: Jim Hughes (LCA); chairs@lists.oasis-open.org
Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
On Jan 22, 2010, at 2:02 PM, Patrick Durusau wrote:
> Jim,
>
> Sorry, I have been watching this discussion and have a fairly basic
> question. When you say:
>
>> It's the assertion that "you have lots of protection because the IPR
>> Policy applies to Committee Notes" that is the issue. If this is what
>> we really mean, then we need to assure that the Committee Notes get
>> all the due diligence we put into Committee Specifications - and
>> understand that patent licensing obligations might arise because of
>> things someone else in the TC put into a White Paper.
> Isn't it true IPR rules apply at the point of contribution to a TC?
>
> That is to say that once IP is contributed under a particular IP mode
> for a TC, that governs the IP within that TC, whatever use, if any,
> the TC makes of it.
>
> To do otherwise, would require machinery to track IP into various TC
> documents, emails, minutes, presentations, white papers, drafts,
> standards, etc., a task that is obviously insupportable.
Essential Claims (which what you are "on the hook for" so to speak) only apply to material that winds up in an OASIS Final Deliverable. So if the TC decides not to make use of a contribution, then the there is no licensing obligation. There is only the "potential" for one.
hth,
jeff
>
> Hope you are looking forward to a great weekend!
>
> Patrick
>
>
> Jim Hughes (LCA) wrote:
>> I'm not questioning the presence of Conformance Clauses, if you have
>> a specification - the point is that when we start talking about them
>> in the context of *non-specifications* it becomes much murkier. The
>> intro to "Guidelines to Writing Conformance Clauses"
>> (http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuideline
>> s.html
>> ) is pretty clear that these things "need to be observed... to claim
>> successful use of a *specification*".
>>
>> If we will have Conformance Clauses in Committee Notes, I think we
>> need to be clearer - should the Committee Note say "this is
>> implementable, and these Conformance Clauses apply", or should the
>> reader think "I think I might be able to implement this stuff in the
>> white paper - maybe the examples - so these clauses tell me when I'm
>> allowed to assert 'successful use' of the White Paper examples"?
>> Absent a template or guidance, it looks like this is open for TC
>> interpretation.
>>
>> Very similar "conformance" language appears in the IPR Policy about
>> Normative Portions - you have to implement these things in order to
>> comply with the document... and it gets even more complicated because
>> you have to consider Essential Claims, Licensed Product, etc. if you
>> (the implementer) want to make sure you'll get all the patent
>> licenses you might need. Relating this to non-specifications is a
>> concern.
>>
>> It's the assertion that "you have lots of protection because the IPR
>> Policy applies to Committee Notes" that is the issue. If this is what
>> we really mean, then we need to assure that the Committee Notes get
>> all the due diligence we put into Committee Specifications - and
>> understand that patent licensing obligations might arise because of
>> things someone else in the TC put into a White Paper.
>>
>> I'm in favor of the tighter process we're proposing in Committee
>> Notes - it's just these pesky details about conformance and the IPR
>> Policy that need closure. Plus clarity on whether TCs are allowed to
>> create more deliverables than CNs or CS/OASIS Standard; is there some
>> sense that if the non-standard is supposed to "carry the stamp of the
>> TC", it must be a CN? Or could the TC create things without public
>> review? (obvious, non-interesting cases are minutes and the like...).
>>
>> Jim
>>
>>
>> -----Original Message-----
>> From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
>> Sent: Thursday, January 21, 2010 10:24 PM
>> To: chairs@lists.oasis-open.org
>> Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
>>
>>
>> On Jan 19, 2010, at 4:43 PM, Jim Hughes (LCA) wrote:
>>
>>
>>> If we don’t have Conformance Clauses (and Normative Portions,
>>> etc.) in
>>> a Committee Note, then it’s very difficult to understand just how an
>>> “implementer” of the Committee Note is supposed to claim needed
>>> patent licenses (if any) from some Obligated Party in the TC. Or, to
>>> get to a finer point better left up to the legal community, what
>>> exactly it means to have “no non-infringing alternatives” when
>>> thinking about Essential Claims in a Committee Note… so I agree with
>>> Abbie and Marc below, and we shouldn’t be going down this path.
>>>
>>
>> I think the Conformance Clauses issue is a red herring. Conformance
>> clauses have nothing to do with Essential Claims and patent licenses.
>> They tell you what you have to do in order to make legimate claims
>> about your product, not how hard it is for you to do so, or who's
>> permission you may or may not need to get in order to ship an
>> implementation (legally).
>>
>> Evidence for this is:
>>
>> a. The requirement for mandatory Conformance Clauses is more recent
>> than the IPR policy. The IPR policy went into effect in 2005. The
>> requirement that conformance clauses must be present went into effect
>> in June 2007. The requirement was added to increase quality (that's
>> why its in section 2.18), to help customers better evaluate products
>> with conformance claims, and so that vendors would be able to more
>> clearly know what was expected of their products.
>>
>> b. A conformance clause can in effect say everything is optional or
>> say "there are no conformance requirements". In both of these
>> instances there may or may be Normative Portions which may be
>> encumbered by Essential Claims.
>>
>> Almost all documents approved before June 2007 did not have
>> conformance clauses. So from an IPR perspective, with the exception
>> of the Cover Page/status, they pretty much look like what's being
>> proposed for CNs.
>>
>> Another point, which Mary and others have tried to make, is that
>> today, when TC's want to approve something that they would really
>> prefer to call a CN, they simply call it a spec, with a spec template
>> and approve it. All the Normative bits are covered by the IPR Policy.
>> That's the status quo. All the this proposed change really does is
>> let TC's engage in "truth in advertising" about the intent of what
>> the adopted material is.
>>
>>
>> cheers,
>> jeff
>>
>>
>>
>>
>>> While I can understand that some might find comfort in generally
>>> saying “the IPR Policy applies to CNs”, I think there are rather
>>> fundamental issues over understanding what this means – and our TCs
>>> are better off making sure that we use Committee Specifications for
>>> documents we expect the world to implement, and reserving Committee
>>> Notes for things we don’t expect the world to implement… or at least
>>> make it clear that if someone wants to “implement” the slide
>>> presentation, they don’t think it’s what we’ve traditionally called
>>> a “specification”.
>>>
>>> I support just about all the changes coming forward in this revision
>>> to the TC Process – but this issue (which may mean both IPR Policy
>>> changes as well as clarification in the TC Process) is something I
>>> will ask the board to consider.
>>>
>>> jim
>>> Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary
>>>
>>> • From: "abbie barbir" <abarbir@live.ca>
>>> • To: "'Marc Goodner'" <mgoodner@microsoft.com>,"'Patil,
>>> Sanjay'"
>>> <sanjay.patil@sap.com
>>>
>>>> ,"'Peter F Brown \(Pensive\)'" <Peter@pensive.eu>,"'Jon Bosak'"
>>>> <bosak@pinax.com ,"'Mary McRae'" <mary.mcrae@oasis-open.org>
>>>>
>>> • Date: Mon, 11 Jan 2010 16:51:56 -0500
>>> +1
>>> abbie
>>>
>>> -----Original Message-----
>>> From: Marc Goodner [mailto:mgoodner@microsoft.com]
>>> Sent: January-11-10 3:56 PM
>>> To: Patil, Sanjay; Peter F Brown (Pensive); Jon Bosak; Mary McRae
>>> Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org
>>> Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary
>>>
>>> These draft changes include conformance clauses as allowed work
>>> product for committee notes. If these are truly informative
>>> materials conformance clauses don't have a place in them and they
>>> should not be listed as an allowed work product.
>>>
>>> -----Original Message-----
>>> From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
>>> Sent: Monday, January 11, 2010 12:37 PM
>>> To: Peter F Brown (Pensive); Jon Bosak; Mary McRae
>>> Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org
>>> Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary
>>>
>>>
>>> +1
>>> I think the debate and decision of what qualifies as a normative
>>> specification vs. other/informative material should be left up to
>>> the TCs.
>>>
>>> I would also like to voice an opinion in favor of the TC process
>>> changes for supporting creation of Committee Notes. I think the
>>> Service Component Architecture TCs potentially could use this option
>>> for publishing the material related to testing of the
>>> specifications.
>>>
>>> -- Sanjay
>>>
>>>
>>>> -----Original Message-----
>>>> From: Peter F Brown (Pensive) [mailto:Peter@pensive.eu]
>>>> Sent: Sunday, Jan 10, 2010 19:01 PM
>>>> To: Jon Bosak; Mary McRae
>>>> Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org
>>>> Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary
>>>>
>>>> I think that we avoid should semantic discussions about the
>>>>
>>> meaning of
>>>
>>>> "spec", "information note", "guidelines", etc and concentrate on
>>>> establishing a clear distinction between what a TC *intends* to be
>>>> normative (and thus establish a legitimate expectation on the part
>>>>
>>> of
>>>
>>>> "consumers") and what a TC intends *not* to be normative (and thus
>>>> effectively issuing a caveat emptor).
>>>>
>>>> What the current discussion seems to boil down to is thus a matter
>>>>
>>> of
>>>
>>>> intent.
>>>>
>>>> The only thing "we" (any OASIS TC or authority, as the "producer"
>>>>
>>> of a
>>>
>>>> work) can have any control over is whether a work is intended as a
>>>> normative work or an informative (or any other purpose) sort of
>>>>
>>> work.
>>>
>>>> I agree with Jon that there will be many authorities who will wish
>>>>
>>> to
>>>
>>>> make normative use of potentially *any* OASIS TC work but we can
>>>>
>>> never
>>>
>>>> predict, manage or control that. No TC, nor OASIS itself, will be
>>>>
>>> able
>>>
>>>> to address the issue of intent on the part of the "consumer".
>>>>
>>>> Best regards,
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: Jon Bosak [mailto:bosak@pinax.com]
>>>> Sent: 10 January 2010 11:21
>>>> To: Mary McRae
>>>> Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org
>>>> Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
>>>>
>>>> Mary McRae wrote:
>>>>
>>>>> Hi Jon,
>>>>> A Committe Note does not replace Committee Specification. That is
>>>>> still a very viable category, and there is no requirement that all
>>>>> Committee Specifications be submitted for OASIS Standard ballot.
>>>>>
>>> If
>>>
>>>>> what you're working on is a specification, then by all means it
>>>>>
>>> can
>>>
>>>>> stay in the Standards Track. The new Non-Standards Track is to
>>>>> support a formal process for approval of work products / documents
>>>>> that aren't specifications. The Non-Standards Track defines the
>>>>> approval level post public review as a Committee Note
>>>>> - the equivalent in TC approval terms to a Committee
>>>>>
>>> Specification.
>>>
>>>>> I hope that clarifies and alleviates your concerns.
>>>>>
>>>> Actually, I got that. Sorry if it sounded like I didn't.
>>>>
>>>> What I meant was that the ordinary English meaning of the word
>>>> "specification," viz., "a specific, explicit, or detailed mention,
>>>> enumeration, or statement of something," applies to a lot of things
>>>> that we're going to be calling Notes. For example, the UBL
>>>>
>>> Guidelines
>>>
>>>> for Customization constitute "a specific, explicit, detailed
>>>>
>>> mention,
>>>
>>>> enumeration, and statement" of our guidelines for customization.
>>>>
>>> The
>>>
>>>> document is a specification of our guidelines. The new use of
>>>> Committee Specification now limits the universe of things called
>>>> specifications to those specifications whose possible end point is
>>>>
>>> an
>>>
>>>> OASIS Standard. That's OK, but it is a limitation on the plain
>>>> English meaning of the word.
>>>>
>>>> This is just a terminological observation -- not worth quibbling
>>>> about.
>>>>
>>>> Jon
>>>>
>>>>
>>>>> On Jan 10, 2010, at 11:35 AM, Jon Bosak wrote:
>>>>>
>>>>>
>>>>>> I don't have the energy to review the actual process language in
>>>>>> detail -- I'm willing to trust that the Board and Staff have done
>>>>>> the right thing -- so this comment is based on the summary.
>>>>>>
>>>>>> As Ken Holman has observed, some of the UBL deliverables are not
>>>>>> intended for promotion to OASIS Standards. For two recent
>>>>>> examples, see:
>>>>>>
>>>>>> UBL 2 Guidelines for Customization, First Edition
>>>>>> http://docs.oasis-open.org/ubl/guidelines/UBL2-
>>>>>>
>>>> Customization1prd03.doc
>>>>
>>>>>> UBL 2.0 International Data Dictionary, Volume 1:
>>>>>> Japanese, Italian, and Spanish
>>>>>> http://docs.oasis-open.org/ubl/idd/UBL-2.0-idd.html
>>>>>>
>>>>>> These have both been approved as Committee Specifications,
>>>>>>
>>> which in
>>>
>>>>>> each case was the intended end state. Under the revised process
>>>>>> (if I understand it correctly), these documents will in the
>>>>>>
>>> future
>>>
>>>>>> undergo the same approval process but be known as Committee
>>>>>>
>>> Notes.
>>>
>>>>>> (I rather liked "Committee Specification"
>>>>>> because documents such as these are, in fact, specifications, and
>>>>>> the TC process as designed explicitly recognized a role for
>>>>>> Committee Specification as an end state; but if the Board feels
>>>>>>
>>> the
>>>
>>>>>> need to specially identify specifications that are not intended
>>>>>>
>>> to
>>>
>>>>>> be made OASIS Standards, I can certainly live with Committee
>>>>>>
>>> Note.)
>>>
>>>>>> Anthony Nadalin wrote:
>>>>>>
>>>>>>> Why not have a new document type below specification, I see this
>>>>>>> as trying to force fit and will open TCs up to all sorts of
>>>>>>> strange things that may not be appropriate
>>>>>>>
>>>>>> The category of Committee Specification was created in the first
>>>>>> place to allow TCs to issue documents that represented their
>>>>>> consensus effort as technical experts but were not necessarily
>>>>>> intended to be endorsed by OASIS as an organization. A new
>>>>>> category below CS would be redundant.
>>>>>>
>>>>>> Mason, Howard (UK) wrote:
>>>>>>
>>>>>>> I think this lower form of deliverable is exactly what
>>>>>>>
>>> "Committee
>>>
>>>>>>> Note" is about. It has no normative content, but provides
>>>>>>>
>>> useful
>>>
>>>>>>> explanatory information about the implementation of a
>>>>>>> specification or standard, and needs some form of agreement
>>>>>>> process. "Guideline" is too specific - "note" is OK. I guess
>>>>>>>
>>> the
>>>
>>>>>>> ISO equivalent would be a Technical Report.
>>>>>>>
>>>>>> I agree with almost all of this (and in fact would have preferred
>>>>>> "Technical Report" because that's already a known ISO label for
>>>>>> roughly the same thing, though I'm not passionate about it). But
>>>>>> it should be understood that a specification that is not an OASIS
>>>>>> Standard can be normative if someone wants to declare it as such
>>>>>> within some particular context. For example, the UBL Guidelines
>>>>>> for Customization could be declared to be normative if some
>>>>>> organization wished to use them in that way. As noted in the
>>>>>> summary contained in the message that began this thread:
>>>>>>
>>>>>> Committee Notes ... are not intended to be normatively
>>>>>> referenced by other standards (either inside or outside of
>>>>>> OASIS), though of course there is no way to actually stop
>>>>>> someone from doing so (hence the IPR safeguards and rigorous
>>>>>> review/approval process).
>>>>>>
>>>>>> The standards landscape is littered with specifications that were
>>>>>> never declared Standards but are used normatively. Some IETF
>>>>>> Requests for Comment are good examples. A particularly egregious
>>>>>> case is European Legislation Regulation M/715 2007 (Euro 5),
>>>>>>
>>> which
>>>
>>>>>> mandates the implementation of a failed OASIS Committee Draft!
>>>>>> You never know the use to which these documents will be put, so
>>>>>> it's wise to require the same IPR policy and approval processes
>>>>>>
>>> to
>>>
>>>>>> CNs that are applied to CSs.
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>> --
>> Jeff Mischkinsky jeff.mischkinsky@oracle.com
>> Director, Oracle Fusion Middleware
>> +1(650)506-1975
>> and Web Services Standards 500
>> Oracle Parkway, M/S 2OP9
>> Oracle
>> Redwood Shores, CA 94065
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC
> (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1,
> 13250-5 (Topic Maps)
>
--
Jeff Mischkinsky jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]