W3C home > Mailing lists > Public > public-w3process@w3.org > December 2016

Re: Requested addition to section 7.1

From: Michael Champion <Michael.Champion@microsoft.com>
Date: Fri, 23 Dec 2016 18:49:02 +0000
To: fantasai <fantasai.lists@inkedblade.net>, Jeff Jaffe <jeff@w3.org>, "public-w3process@w3.org" <public-w3process@w3.org>
Message-ID: <0BFD4C89-E466-4A9C-9B21-D4FC19703C45@microsoft.com>
> The CSSWG can pick up anything that is in scope for the charter and is
> presented for its adoption (and is not patent-encumbered), regardless
> of the source

How does the CSS WG determine whether something is patent encumbered?  One strength of incubating in WICG or any CG that all contributions are made under a Contributor License Agreement that offers a perpetual royalty-free license to any patents necessary to implement the proposal.  As best I understand, work that incubates in CSS or any other WG doesn’t get any kind of patent protection until a promise to make RF commitments is implicitly offered once the exclusion period on the First Public Working Draft expires, and those promises don’t become concrete until a spec gets to Recommendation.  I suspect this is more of a cultural norm in the CSS WG – don’t contribute anything you’re not prepared to make a patent commitment on at some point – than anything legally binding.  Do I have this about right?

If so, it would be good to spend some thought before the next CSS rechartering to see if there is a way to get binding patent commitments up front without asking the WG to change its mode of operations too much.  Perhaps some incubating in a parallel CSS CG that is for all intents and purposes the CSS WG but has the CG IPR policy in place?  It would be totally up to the WG when to propose specs for the standards track.  I’m not sure if that would be legally sound, but something along these lines might be a way forward.

> The MAY appears to give special consideration to work prepared in the
> WICG, and can be read (and has been read) as being a substitute for
>  review and development within the context of the CSSWG. 

Thanks for that explanation of something that seemed like a very minor point to me until this thread clarified it.  As an advocate of incubation in WICG or other CGS, I had thought of incubation as  NECESSARY condition for going on the Rec Track – solid proposal with buy in from implementers and users – and not a SUFFICIENT condition.  It’s apparently not clear enough that WGs make the decision to accept the output of WICG, not the WICG itself.  In practice, they will usually be the same people, but in case they are not, there should be no doubt that WICG incubation is not shortcut around the WP or CSS WG’s review proess.


-----Original Message-----
From: fantasai <fantasai.lists@inkedblade.net>
Date: Thursday, December 22, 2016 at 1:12 PM
To: "jeff@w3.org" <jeff@w3.org>, "public-w3process@w3.org" <public-w3process@w3.org>
Subject: Re: Requested addition to section 7.1
Resent-From: <public-w3process@w3.org>
Resent-Date: Thursday, December 22, 2016 at 1:13 PM

    On 12/22/2016 04:44 PM, Jeff Jaffe wrote:
    >
    > I just want to make sure that I understand the use case.  Are you saying
    > that without the MAY statement (that work may be incubated in WICG), that
    > it would have been prohibited for CSS to pick up anything that was
    > incubated in WICG?
    
    The CSSWG can pick up anything that is in scope for the charter and is
    presented for its adoption (and is not patent-encumbered), regardless
    of the source. However, any such proposal is subject to the CSSWG's
    review and evaluation, and the expectation is that it may be accepted,
    rejected, or adopted with the provision that it needs significant rework
    before being officially accepted.
    
    The MAY appears to give special consideration to work prepared in the
    WICG, and can be read (and has been read) as being a substitute for
    review and development within the context of the CSSWG.
    
    ~fantasai
    
    

Received on Friday, 23 December 2016 18:49:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 23 December 2016 18:49:34 UTC