W3C home > Mailing lists > Public > public-w3process@w3.org > March 2015

Re: [Issue-152] Note for Draft Process Document

From: David Singer <singer@apple.com>
Date: Mon, 02 Mar 2015 12:40:42 -0800
Cc: Stephen Zilles <szilles@adobe.com>, "public-w3process@w3.org" <public-w3process@w3.org>
Message-id: <0FCEE9BD-CAB1-40C5-BC29-EA37DAABE332@apple.com>
To: Wayne Carr <wayne.carr@linux.intel.com>
I think that trying to define what is editorial or give examples, beyond saying “an editorial change does not change either implementations or the applicable IPR” is probably dangerous, as you say.

On your notes, we have had patents that applied or not based on what a techie would think silly reasons (the order of two bits, because the patent used the word “preceded”).  But this is a rat-hole..

> On Mar 2, 2015, at 11:57 , Wayne Carr <wayne.carr@linux.intel.com> wrote:
> 
> There is still the problem of stating (incorrect) conclusions about infringement in the examples. We're not the right group to be stating opinions about actual possible instances of infringement.  I also think both examples are irrelevant.  Both would require changes to implementations so clearly are not editorial changes (Editorial changes or clarifications that do not change the technical content of the specification.).
> 
> Here is a hypothetical example to indicate why there shouldn't be text like what is proposed.
> 
> Suppose a patent claim requires 10 conditions that have to be true in order to infringe and one of them is that the thing is "blue".  Suppose a spec being considered has nothing in it about being blue.  So, it is decided that the claim would not be infringed because the condition about being blue doesn't apply.  That doesn't mean that if it was "blue" that it would infringe.  It means they didn't have to bother looking at the other 9 conditions.   
> 
> "doesn't require the thing to be blue (thus avoiding a patent infringement)" is wrong in this hypothetical.  That language is in the note about a real example.  Similarly, a PAG could advise changing the name of a method, not to avoid infringement as the suggested note says, but just to avoid confusion if the name is causing people to think some technology is involved that isn't. 
> 
> 
> I would hope that neither of the examples would be considered editorial changes. Changing using a point into using an ellipse or changing the name of a method would cause everyone to re-implement.  Those aren't editorial changes.  I'd suggest dropping the examples.
> 
> 
> 
> 
> 
> On 2015-03-01 19:14, Stephen Zilles wrote:
>> Wayne,
>> Thank you for pointing out that I forgot to say that the note is to explain an open issue (152) and would be removed as soon as the issue is resolved. Hence, it would go in the next draft, but would disappear before the final draft of Process2015.
>>  
>> Steve Z
>>  
>> From: Wayne Carr [mailto:wayne.carr@linux.intel.com] 
>> Sent: Sunday, March 01, 2015 3:15 PM
>> To: Stephen Zilles; public-w3process@w3.org
>> Subject: Re: [Issue-152] Note for Draft Process Document
>>  
>> I'm not sure I understand what is meant by "attachment".  Is it to put all that text in the Note below in the Process Document?  If so, that doesn't seem good.  Way too much text for a fairly obscure subject. 
>> 
>> Wherever that Note would be published, I think there's a problem with the text.  The proposed Note seems to be stating conclusions about whether there would have been infringement in the examples.  We shouldn't have a note implying whether anything  would have infringed or not.  i.e. don't have text like "patent infringement was avoid" or "thus avoiding a patent infringement".    There can be multiple different reasons why something isn't a concern.  Sometimes there is a trivial change that makes it so you don't have to bother explaining the dozen other reasons it isn't a concern. Changes like the examples don't necessarily mean anything infringed - they could be just the simplest reason it isn't a problem.  Future versions of specs may want to go back in the same area so Notes shouldn't be stating conclusions about infringement. 
>> 
>> Another approach to the Note could be: "The purpose of returning to Proposed Recommendation and an Advisory Committee Review is to draw attention to the proposed changes before they become part of the Recommendation. A particular focus of that review would be to detect instances where changes were misclassified as not affecting conformance, in which case the result of AC Review should be to return it to Candidate Review and a patent exclusion period."
>> 
>> 
>> 
>> On 2015-02-28 15:58, Stephen Zilles wrote:
>> Per the request of the Advisory Board, the following note is proposed for attachment to the second paragraph of section 7.7.2 Revising a Recommendation to explain the only open issue on the current draft of Process2015. [The proposed text has been hyperlinked inline to make it easier to copy.]
>>  
>> Steve Z
>>  
>> ======NOTE=======
>> Note: It has been asserted that Process2014 has made the publication of Edited Recommendations more difficult in the case when they only have corrections that do not affect conformance and that this change was un-intended. This is Issue-152 on the Revising the W3C Process Community Group Tracker. For this kind of change, Process2005 does not require any “technical review of the proposed changes.” This also holds for Process2014, but an additional step, publication as a Proposed Recommendation, has been added.
>>  
>> The essence of the discussion has been around whether it is possible to reliably identify “corrections that do not affect conformance.” It seems that a Working Group should be able to perform this assessment (and has been responsible for doing so in the past). However, several recent Patent Advisory Groups (PAGs) have shown that subtle changes in a text can have significant Patent implications. The Touch Events Specification PAG noted that the Touch Events Specification does not fit an ellipse (as required by the patent considered) to touched pixels, relying only on a single coordinate point (thus avoiding a patent infringement). In a similar analysis, a patent infringement was avoid by changing the name of a method being used. These examples show the slippery slope of editorial changes.
>>  
>> Based on these examples, a number of people felt that any textual changes should have an associated exclusion announcement on the changed text. That puts the onus of checking whether any of the changes might trigger a patent problem on owner of the possibly infringed patents.  Any reviewer other than the patent holder may not have sufficient information to recognize the problem. If the 60 day review period passes without any exclusions that is good, and, if an exclusion occurred, then the change could certainly affect conformance. The essence of the argument is that getting a better Patent assessment prior to re-publishing a Recommendation is worth the added delay of an Exclusion period.
>>  
>> This does, however, elongate the process of updating a Recommendation with purely editorial changes. It has been suggested that it would suffice to have the Team Contact (as a disinterested expert in the group) review the changes prior to re-publication as a Recommendation, thus speeding up editorial updates.
>>  
>> No clear consensus position between these two positions has yet emerged.
>> =====END NOTE========
>>  
> 
> 

David Singer
Manager, Software Standards, Apple Inc.
Received on Monday, 2 March 2015 20:41:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 March 2015 20:41:13 UTC