RE: Option 3

On Wed, 9 Mar 2011, Lawrence Rosen wrote:
> Comment (a) regarding Use Cases 6 and 7: Nothing in W3C policy would 
> prevent you from referencing the official W3C HTML5 specifications as an 
> external specification in any venue and posting descriptions of 
> functional modifications to it that you intend to implement

That isn't what I am asking.

I want to be able to take the exact bytes the W3C publishes on its site, 
edit them, change the title so it doesn't say it's a W3C spec, then 
republish the specification as a formal standard on my own site. I further 
want there to be absolutely no doubt that the W3C authorises me to do 
that in all jurisdictions.

I don't know how much clearer I can make that.

(I hope that I will never have to exercise this right. My desire is about 
making it possible for other people to build on our work in the future, 
not about anything I personally want to do currently. It's about making 
sure that as a working group, it is our excellence that ensures we are the 
authority on the subject -- and that we are not enforcing that authority 
by putting up a high barrier to entry to compete with us.)

> Comment (b) regarding Use Case 6: If W3C or the HTML WG ceases 
> operations, why do you doubt that you'd be allowed to continue in a 
> non-W3C venue?

Because W3C staff has explicitly said I'm not on many occasions.

> Who will stop you from forking by reference?

There are three ways to fork.

Forking by reference: That's what we did with Web Forms 2.0 in 2003. It's 
not a viable long-term strategy for something with the scope of HTML.

Forking by rewrite: That's what we did with HTML5 in 2005. It's an 
extremely expensive strategy.

Forking by copying and editing: That's what I want to ensure people can do 
with our work.

Only the latter provides a suitably low barrier to entry to enable other 
groups to compete with us.

> There is an apparent paranoia here about W3C that predates me, and makes 
> it difficult to nail down the use cases. If you don't trust W3C to honor 
> its licenses, why are we bothering?

Search for the word "paranoid" in this e-mail for an anecdote explaining 
why we are asking for the W3C to explicitly authorise any and all re-use:

> As to whether you could publish *derivative works* of the official W3C 
> HTML5 specifications *as a specification*, ask your own lawyer.

I did. My lawyer said in no uncertain terms that what you propose as 
"option 3" would not let people publish derivative works of these 
specifications as specifications. Thus, it is in our opinion unacceptable 
as a solution to the problem of how to enable people to publish derivative 
works of these specifications as specifications.

> But I'm aware that W3C Members don't want you to do so without obtaining 
> express permission from W3C. Option 3 does not give you that express 
> permission

Exactly. That's why it's not a solution to the problem of getting that 
express permission without having to ask each time on a case-by-case 

> neither does it expressly forbid it, which gets around the GPL "further 
> restrictions" problem.

This is incorrect (per our lawyer), as described in my previous e-mail:

In the section starting "From the GPL FAQ".

> You can "fork" as long as you don't distribute a "derivative work" *as a 
> specification*.

That's a restriction, which is why it's not GPL compatible.

The GPL would allow me to distribute a derivative work as a specification. 
Your license does not. Ergo, your license imposes additional restrictions 
beyond those of the GPL and is not GPL compatible.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 10 March 2011 05:24:20 UTC