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