Re: Patent Commitments and Dead Ends

On 12/25/2016 11:37 PM, Michael Champion wrote:
> Jeff wrote:
>>    Well stated.  Thank you.
>
> Yes, thanks for the very detailed explanation!
>
>  A couple of points:
>
>> You're right that this is "enforced" mostly as a cultural norm,
>> whereas CGs have something more up-front. But that's a legal
>> side-effect of how the W3C has set things up, and not, imho, a
>> a fundamental consideration of process. If it's an issue, W3C
>> should address it for all WGs, as it's not specific to CSS.
>
> Yes, IMHO we should address the lack of patent promises in WGs
> for work that doesn’t get to FWPD and binding commitments for
> work that doesn’t get to Recommendation.  That, however, might
> require revising the Patent Policy, which very few people have
> much interest in.  It also might be possible to do this via
> the Process Document, I’m not sure, but it’s worth discussing
> with attorneys exactly what room to maneuver we have here.

I agree the lack of patent commitments for work that doesn't get
to REC is a problem, and probably needs resolution through revising
the Patent Policy. To the extent that companies are comfortable
making commitments to a CG, they should be comfortable making those
same commitments to a WG. So if revising the actual patent policy
is difficult, maybe adding an optional legal agreement along the
lines of the CG CLA's contribution clauses would be easier. Then
it's possible to get all of the relevant commitments even though
it's not a built-in part of the Process. The WG would be responsible
for soliciting those commitments, at least until the time that the
AC is prepared to amend the Patent Policy accordingly... at which
point, this little experiment could be used as evidence to the AC
of the viability of such a patent commitment system.

As for work that doesn't get to FPWD, the solution to that is easy:
publish early and publish often. :) I believe the W3C is fulfilling
its openness commitments best when all of its current work is
available through easy-to-find official channels--and for spec
output, this is /TR. We've historically had technical problems with
this being a workable system, but Echidna is solving those.

Fwiw, the CSSWG publishes proposals as FPWD so long as they represent,
roughly:
   * A problem the CSSWG agrees is in-scope and has interest
     from the community
   * An approach that the CSSWG agrees is viable, fits well within
     the CSS system, and adheres to our principles of design

We've rejected proposals that don't fit the above criteria, and sent
back for revision prior to FPWD some that seemed like a slightly
different approach would be possible and acceptable. But we don't
require that all the details be worked out or that the overall
design be finalized prior to FPWD: that's the role of the WD stage
of the Process.

> Likewise it would be good to figure out how the W3C WG process or
> the CSS culture could be tweaked to ensure that the w3.org/TR page
> doesn’t remain littered with supposed Rec-track specs that aren’t
> going anywhere because proponents lost interest, don’t solve a real
> world problem, or nobody plans to implement them.  That’s one of
> the problems WICG was intended to solve, by not putting specs on
> the Rec track until they had sustained interest, demonstrably solved
> a real problem, and had implementer buy in.  There’s surely other
> ways to solve that problem besides insisting on incubation in WICG,
> so let’s discuss.

The CSSWG has so far used the technique of "Republish the spec with
empty content and an obnoxious notice of obsoletion" for closing off
abandoned specs. This at least makes it clear that the spec is no
longer under development.

It would be *better* if the Process allowed for WDs and CRs to be
rescinded. Currently only RECs can be rescinded. :(

I guess that's a relatively easy fix; hadn't occurred to me to request it.
Chaals? :) :)

~fantasai

Received on Monday, 26 December 2016 13:02:16 UTC