Re: HTML.next and Rechartering

(I don't know if this is off-topic for public-html.  If it is, someone
please say so and I'll stop.)

On Mon, Sep 12, 2011 at 1:52 PM, Carr, Wayne <wayne.carr@intel.com> wrote:
> But companies don't want to commit their intellectual property based on "arbitrary Editor's Drafts".   The current process has a step for opting out patent claims after the first (formal) public draft when there is some idea what the spec is about.  And another at Last Call when it is supposed to be feature complete and when the requirements of the charter were satisfied.  This is always after the last substantive change (because Last Call repeats if necessary).  The actual commitment is only on contents of the final specification.

But there is no final specification.  Even with versioned specs, any
spec of importance will be maintained in future versions.  HTML5 will
be a snapshot, for instance, while work will presumably continue in
HTML6.  Then eventually that will be snapshotted, and work will
presumably continue in HTML7.  And so on.  (Assuming no changes to
Process.)  Likewise we have DOM4 as the new version of DOM 3 Core,
which will presumably be followed by DOM5.  And so on.

So whatever happens, companies will be making patent commitments on
some kind of snapshot.  The snapshot will never be complete or final
because the web will continue to evolve.  In many cases, the snapshot
will be technically obsolete by the time it reaches REC.  Why does the
snapshot used for patent commitments also have to be interoperably
implemented?  This seems very bad, actually: it forces implementers to
create their implementations with no patent protection.  Surely we
want them to have patent protection *before* they begin
implementation, if possible.

> There isn't a separation between technical contents and legal stages - they are necessarily in synch.

Why?

> Those are very reasonable places in the process to have this apply.  First draft, last substantive change, final spec.  There can't be a continuous legal review or commitment to random features that come and go - that would be prohibitively expensive.

Of course not.  We have to have some kind of stable snapshots.
However, we could just take a snapshot of the latest Editor's Draft at
fixed intervals, perhaps one to three years.  Then there would only
need to be patent review once every one to three years.  Of course, a
shorter interval means more patent protection but also more expense on
legal review, so the tradeoff would have to be weighed carefully.  But
I don't see any reason to tie patent commitments to multiple
interoperable implementations, which is the status quo.  Companies can
do legal review and make patent commitments on features that don't
have full test suites, have only partial or experimental
implementations, etc.  But such features cannot be in a W3C REC.

Received on Monday, 12 September 2011 18:36:40 UTC