Forking

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit forking. For our purposes, forking means the ability for a third party to redistribute modified versions of the specification without the permission of the copyright holders. Standard licenses that permit forking include CC0, the MIT license, and the BSD licenses.

More specifically, this page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

Existing forks of HTML

(based on IRC comment by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

W3C-hosted forks

• XHTML Basic
• HTML 4 Mobile
• XHTML 2
• XHTML-Print

W3C-published but disavowed forks

• HDML
• XHTML+SMIL
• CHTML

Other forks

• ISO HTML
• XHTML-MP
• WML (apparently no free download)
• WTVML (apparently no free download)
• WHATWG HTML
• CE-HTML (apparently only a preview available for free)
• EPUB
• HTML 4.1

Organizational forks

One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

W3C competing with IETF

The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, Weaving the Web (pp. 62-3):

Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.

In practice, the W3C has wound up cooperating with the IETF more than competing.

WHATWG competing with W3C

After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

Supposed risks of forking

• "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
  • A national government would not be bound by copyright anyway. Even the US government does not consider itself bound by copyright law.
  • A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
  • In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (c.f. China).
  • Whether the W3C allows forking or not, and even if we grant that a license could stop this, this scenario could already happen because the entire HTML spec is already under a liberal license at the WHATWG.

• "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.

Advantages of allowing forking

• It encourages the W3C to do a good job, because of the risk that if the W3C does not do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

Reasons preventing forking is not necessary

• If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.