The right to (easily) fork

Ian Hickson wrote:

> 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.

 

 

Hi Ian, 

 

I understand what you want. But that wasn't a requirement in any of the use
cases presented by the HTML WG to PSIG. Nothing was said about a requirement
to make it easy to take a spec out of W3C and develop it elsewhere.

 

It isn't me you have to convince; it is the membership of W3C that voted
overwhelmingly in a survey that such a generous permission slip would be
harmful to W3C and to standards generally. They don't want to encourage
forking....

 

As for my personal opinion and my guess at what Apache members would
probably prefer, I agree with you completely about the importance of the
freedom to fork. That is an essential aspect of FOSS and of innovation
generally. That is why the Open Web Foundation, where I DO have some
influence, has just approved a new set of specification licenses that
preserve everyone's right to fork a specification (from a copyright
perspective) conditioned only on a simple attribution notice to the original
specification itself. [1] If you like the MIT license, then I'm hopeful
you'll like our mature grandson of the MIT license that OWF has created for
software specifications. PSIG is currently discussing how that IPR model
might be adapted/adopted into the new W3C Community Groups. So by no means
is this issue you raise dead in W3C. 

 

But we've been on a treadmill around here over a new W3C HTML document
license. Adding a new use case at this late date which requires that W3C
bless the forking of its specifications will, at the very least, delay any
resolution. Obstinacy, even when you're right, can sometimes delay progress.

 

All that said, I'll step back and let those who want to discourage forking
speak for themselves. This is, after all, a fundamental issue in the
standards community and lots of people have opinions about this.

 

/Larry 

 

[1] A description of the new OWF agreements is at DRAFT FAQ for OWFa/CLA 1.0
<https://docs.google.com/document/d/16xb_3pzHRqiWZZmzY_-4PYZ_6Ux4dmrAJh3DNWK
vvsI/edit?authkey=CK_y8qQD> . This is off-topic for the HTML WG list, so
please direct questions about this privately to me. 

 

 

 

> -----Original Message-----

> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On

> Behalf Of Ian Hickson

> Sent: Wednesday, March 09, 2011 9:24 PM

> To: Lawrence Rosen

> Cc: 'HTML WG Public List'; PSIG

> Subject: 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:

> 

>    http://lists.w3.org/Archives/Public/public-html/2009Feb/0093.html

> 

> 

> > 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

> basis.

> 

> 

> > 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:

> 

>    http://lists.w3.org/Archives/Public/public-html/2011Mar/0209.html

> 

> 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

> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._

> ,.

> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-

> .;.'

 

Received on Thursday, 10 March 2011 17:46:32 UTC