W3C

Site Navigation

Nearby

Results of Questionnaire HTML5 license: Which license should be used for the W3C HTML5 specifications? - Preference Poll

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-04-28 to 2011-05-05.

75 answers have been received.

Jump to results for question:

  1. W3C License Option 1
  2. W3C License Option 2
  3. W3C License Option 3
  4. Mozilla proposed CC0 license
  5. Mozilla proposed MIT license

1. W3C License Option 1

We have W3C License Option 1 for the W3C HTML5 specifications. Please provide your preference with respect to this license by choosing ONE of the options below.

If you have strong objections to adopting this License Option, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Summary

ChoiceAll responders
Results
This is my preferred license. 6
I can live with this license. 18
I cannot live with this license. 49

Details

Responder W3C License Option 1 Rationale
Kenneth Dahlstrøm I cannot live with this license.
Ian Hickson I cannot live with this license.
John Vernaleo I cannot live with this license.
Kyle Simpson I can live with this license.
Mike Taylor I cannot live with this license.
Gavin Sharp I cannot live with this license.
Shawn Medero I cannot live with this license.
Kornel Lesinski I cannot live with this license.
Jeremy Keith
Tab Atkins Jr. I cannot live with this license. This license is not compatible with the GPL.
Robert O'Callahan I cannot live with this license. I object to this license because it is not compatible with the MPL or GPL, and prevents specification forking.
Silvia Pfeiffer I cannot live with this license. "the publication of derivative works of this document for use as a technical specification is expressly prohibited" is no way to give back to the community that helped create the specification; W3C should be the point of reference for the specification because it is the "original author" and it cares about maintaining it, not because everyone else is prohibited to work on the specification
Mathias Bynens I cannot live with this license.
Philip Jägenstedt I cannot live with this license.
Henri Sivonen I cannot live with this license. I object to this license, because it prohibits specification forking.
Mark Pilgrim I cannot live with this license. Not compatible with open source
Mark Miller I cannot live with this license. "the publication of derivative works of this document for use as a technical specification is expressly prohibited" is too restrictive. I have actively argues that Ecma documentation licenses should have no such restrictions, and I feel as strongly about w3c licenses.
Matthew Turvey I cannot live with this license.
Doug Jones I can live with this license. The W3C License Option 1 explicitly prohibits forking the specification. I support this stance but realize it is an impracticable position to expect.

The HTML5 specification should be respected and not forked by others. Since HTML is used world-wide to communicate with many cultures and needs, only one world-wide HTML specification should be recognized as the method to use HTML.
David Baron I cannot live with this license.
Boris Zbarsky I cannot live with this license. This license is not GPL or MPL compatible and prevents forking.
David Bolter I cannot live with this license.
Dimitri Glazkov I cannot live with this license.
Wayne Carr This is my preferred license. W3C is the best place to develop html specs. It is an open and fair standards org. We do not want others to fork W3C specs. This option (with changes suggested below) enables uses in implementations and documentation, while clearly preventing forks.

The text “HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited. ” should be reworded as “Nothing in this license grants permission for the publication of derivative works of this document for use as a technical specification.” As is, some could read it as a prohibition they need to pass on and therefore may think it is incompatible with GPL. There is no need to explicitly prohibit. It is enough that the copyright holders themselves point out the license isn't granting that permission (regardless of whether anyone else chooses to repeat that or not).

Licensing code, pseudo-code, idl, etc found in specs for use in open source or proprietary code is a positive step. It is the most useful part of these options. Those parts under a well known license like 3-clause BSD would make it obvious without question they can be copied into open source implementations and also widely used in other ways (with none of the debates we've seen on whether compatible or not). This is what I see as the real value in the new proposed license.

However, licensing under MPL 1.1 would have W3C making claims that are not true. MPL 1.1 says “each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license" [deleted irrelevant clause] "b. under Patent Claims infringed by the making, using, or selling of Modifications made by that Contributor either alone and/or in combination with its Contributor Version”. W3C patent policy is about essential claims needed to implement specs for use in implementing those specs. How can W3C make that claim about Contributor patent grants for derivative uses that are not covered by W3C Member obligations? 3clause BSD does not include explicit patent language and is very well known and widely considered compatible with other open source licenses.

On GPL compatibility for a document license: Text licensed under the GNU Free Document License (GFDL from FSF) is incompatible with GPL [1], so it isn't unusual to have documentation that cannot be copied into GPL licensed works, even open source documentation from the FSF itself. In commentary on FSF's GFDL they note "Of course, if these scripts are generally useful for other tasks, it is a good idea to release them separately under the GNU GPL." [2] This option does something similar in licensing the types of things likely to be put into code with a separate license that is clearly compatible with GPL.[3]

[1] http://en.wikipedia.org/wiki/GNU_Free_Documentation_License#GPL_incompatible_in_both_directions
[2] http://www.gnu.org/licenses/fdl-howto.html
[3] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses
Tony Gentilcore I cannot live with this license.
Gavin Carothers I can live with this license.
Krijn Hoetmer I cannot live with this license.
Lawrence Rosen I can live with this license. Apache members have not expressed any desire to fork the W3C HTML5 specification. We are working comfortably and productively within W3C and under its consensus-based procedures. As such, the restriction in Option 1 on derivative works of the W3C specification itself is of no relevance to us. That is why we can live with this license.

We are, however, attentive to the express objections of FSF to this Option 1 license. That is the reason we prefer Option 3 to Option 1.
Steve Faulkner I can live with this license.
Jirka Kosek This is my preferred license.
Gervase Markham I cannot live with this license. Mozilla has been told Option 1 is considered by the FSF to be not compatible with the GPL (one of the licences used by Mozilla), and so we feel it is unacceptable and we have not considered it further.
Andrew Wilson I cannot live with this license. The prohibition of derivative works is too restrictive, and the possibility that the license is not compatible with GPL would mean that excerpting the specification in GPL'd code would be prohibited.
Matt Lee I cannot live with this license.
Bob Lund I cannot live with this license. It appears to preclude use case #9 which is important to me.
Jens Oliver Meiert I cannot live with this license.
Samuel Santos I cannot live with this license.
Michael Puls II
Simon Myers I cannot live with this license. It does not (explicitly) allow that another group could take over responsibility for the HTML5 spec and republish it, for example in the case that this working group is disbanded or loses credibility among those who implement HTML5.
Lachlan Hunt I cannot live with this license. To assist with making an informed decision, the following documents the facts relating to this licence with supporting rationale. The views expressed herein are my own and do not necessarily reflect those of Opera Software. The statements relating to use cases should not imply any claim regarding the desirability of meeting any particular use case.

Due to the explicit field of use restriction:

1) The FSF declared that this licence is incompatible with the GPL.

2) This licence is incompatible with the Open Source Definition and the Debian Free Software Guidelines (DFSG).
James Graham I cannot live with this license.
Daniel Schattenkirchner I cannot live with this license.
Matthew May This is my preferred license.
Christopher Bank This is my preferred license.
Roy Fielding I can live with this license. In general, my preference is for no changes to the W3C license unless a new license is adopted for all W3C recommendations and expected to be applied to all of them in accordance with W3C participation agreements.

I do not like the express prohibition of a specific form of derivative work. Prohibition is the default, by law. Licenses should always be worded as what permissions the owners have chosen to give, not as if they could take some away, since it interferes with providing more licenses at a later time.
Mayank Kumar This is my preferred license. I strongly believe that W3C should be the only organization that establishes and manages the HTML specification.

This option meets the reasonably strict requirements for expressly forbidding the creation of derivative specifications and creates the least confusion over what is allowed and what is not allowed.
John Foliot I can live with this license.
Cameron Jones I cannot live with this license. My preference if for the same license across the W3C, however until the ambiguity of GPL compatibility and forking is resolved the license is untenable.

Modifications to the license should be according to the letter and spirit of GPL in allowing forking to occur yet mandating license compatibility of a fork.

This would alleviate GPL compatibility, retain W3C rights and protect from nefarious forks by guaranteeing community ownership and allowing any deviations to be merged back to the authoritative source.

This would appear to be a similar to the current scenario, HTMLWG vs WHATWG.
Eric Eggert I cannot live with this license.
Adrian Bateman I can live with this license.
Aryeh Gregor I cannot live with this license. I've posted my response to www-archive, since it's too long to submit here (9.4 KB):

http://lists.w3.org/Archives/Public/www-archive/2011May/0008.html
Leif Halvard Silli I cannot live with this license.
Tantek Çelik I cannot live with this license. Per http://lists.w3.org/Archives/Public/public-html/2011Apr/0000.html

The time has come for W3C to abandon bespoke license(s).

There are no longer any substantial reasons why W3C should spend
time/money on bespoke licenses as it has historically done so.

The costs, both to W3C, and to anyone who wishes to use W3C
technologies are unnecessary: time/effort for W3C to develop/maintain
bespoke licenses vs simply re-use "standard" licenses, and time/effort
for users of W3C tech to read/evaluate W3C's bespoke licenses vs.
knowing they can trust previously known licenses/agreements such as
CC0 and OWFa.
Michael Cooper This is my preferred license.
Leonard Rosenthol I can live with this license.
David Carlisle I cannot live with this license. It would be actively harmful to give the W3C copy a more restrictive licence than is used elsewhere as that effectively just encourages people to use the whatwg version as the primary source, thus diluting the W3C as being the primary standards organization in this field.

Aryeh Gregor in his response also gives general arguments why a permissive licence is a good thing, I broadly agree with those points.

This rationale applies to the following questions as well, but is not repeated.
Kimberly Blessing I cannot live with this license.
Masataka Yakura I cannot live with this license.
Arne Johannessen I cannot live with this license.
Richard Schwerdtfeger I can live with this license.
Eliot Graff I can live with this license.
Kris Krueger I can live with this license.
Mounir Lamouri I cannot live with this license.
Frank Olivier I can live with this license.
Cynthia Shelly I can live with this license.
Arun Ranganathan I cannot live with this license. We believes that nothing but the right to fork, expressed in such a clear way that anyone reading the license agrees that the license does actually give the right to fork, will do. In other words, none of the W3C PSIG options 1 through 3 are OK, because they don't offer this right.

The right to fork is an important free software/open source value, and in this case particularly it ensures that if the W3C once again becomes a bad venue for HTML development, as happened before (leading to the creation of the WHATWG), work doesn't need to be started again from scratch. There can thus be a continuity of thought in successor specifications, should such successor specifications to HTML5 need to be developed outside of W3C's aegis.

The relevant "official Mozilla" public statements on the topic are:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0021.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0263.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0696.html

Both CC0 and MIT would achieve the forkability goal and, thus, align
with our values. CC0 was proposed first, but it's less familiar to
people, so MIT was proposed afterwards so that forkability doesn't get rejected just because some people are suspicious of CC0. See:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0689.html .
Travis Leithead I can live with this license.
Andi Snow-Weaver I can live with this license.
Matt Harris I cannot live with this license. "the publication of derivative works of this document for use as a technical specification is expressly prohibited."

This is not in the spirit of open source, nor does it encourage innovation. It does not encourage innovation as it prohibits forking on the specification for the purposes of implementation. To me that's unacceptable.
Jonathan Watt I cannot live with this license.
David Singer I cannot live with this license. Without consensus over the GPL-compatibility of this option, this license does not meet the use cases and potentially creates unacceptable risk for those who need GPL compatibility.
Jace Voracek I can live with this license.
Eihab Ibrahim I can live with this license.
Jonas Sicking I cannot live with this license. * Doesn't allow forking
* Isn't GPL compatible
* Doesn't allow copying text in the spec into GPL licensed source files
Theresa O'Connor I cannot live with this license.
Hadley Beeman I cannot live with this license. The W3C should provide validation and endorsement for specs as per the traditional process of consensus and iteration, not by preventing forks through copyright terms. The work done by these groups should be available to others for reuse and inspiration, and this reuse should not threaten the legitimacy of this group's work.

2. W3C License Option 2

We have W3C License Option 2 for the W3C HTML5 specifications. Please provide your preference with respect to this license by choosing ONE of the options below.

If you have strong objections to adopting this License Option, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Summary

ChoiceAll responders
Results
This is my preferred license. 11
I can live with this license. 15
I cannot live with this license. 47

Details

Responder W3C License Option 2Rationale
Kenneth Dahlstrøm I cannot live with this license.
Ian Hickson I cannot live with this license.
John Vernaleo I can live with this license.
Kyle Simpson I can live with this license.
Mike Taylor I can live with this license.
Gavin Sharp I cannot live with this license.
Shawn Medero I cannot live with this license.
Kornel Lesinski I can live with this license.
Jeremy Keith
Tab Atkins Jr. I cannot live with this license. This license is not compatible with the GPL.
Robert O'Callahan I cannot live with this license. I object to this license because it prevents specification forking, and because its field-of-use restrictions are not compatible with software freedom.
Silvia Pfeiffer I cannot live with this license. "other IPR commitments (e.g., for patents) that are associated with W3C Recommendations do not extend to your derivative specification" if somebody is contributing IPR to the open Web specifications, they should really mean it for the best of the open Web and thus to anyone creating open specifications for the Web, not just the W3C specifications
Mathias Bynens I cannot live with this license.
Philip Jägenstedt I cannot live with this license.
Henri Sivonen I cannot live with this license. I object to this license because it doesn't allow forking the spec as a whole ("reasonable portions" is not clearly defined but might be interpreted to mean something substantially less that the whole spec).
Mark Pilgrim I cannot live with this license. Not compatible with open source
Mark Miller I cannot live with this license. "It is not, however, intended to facilitate the publication of derivative works as a technical specification.". Again, this is too restrictive, and I have actively fought such restrictions within Ecma. The same considerations apply to w3c. Whether or not forking is good, the right to fork is.
Matthew Turvey I cannot live with this license.
Doug Jones I can live with this license. The W3C License Option 2 does not overtly prohibit forking, but forking should not be permitted.

The HTML5 specification should be respected and not forked by others. Since HTML is used world-wide to communicate with many cultures and needs, only one world-wide HTML specification should be recognized as the method to use HTML.
David Baron I cannot live with this license.
Boris Zbarsky I cannot live with this license. This license has field-of-use restrictions and purposefully creates ambiguity about whether forking is ok, which is highly undesirable.
David Bolter I cannot live with this license.
Dimitri Glazkov I cannot live with this license.
Wayne Carr I cannot live with this license. The notes that accompany this option sound like W3C is uncertain whether this option has licensed forks or not. This one just strongly requests in the notes that people don't fork if they think the license permits it. It should clearly say that nothing in the license grants permission to create a derivative work for use as a specification.

This option very narrowly focuses on use in software in the first two bullets: “in source code for implementation of the technical specifications ” or “in software such as, for example, in source code comments, commit messages, documentation of software, test materials, user-interface messages, and supporting materials accompanying software, all in accordance with good software engineering practices ”. Other licenses discuss programs but define it very broadly as any work distributed under the license (i.e. gpl), but these bullets in this option seem about use only in real software. Unlike the first 2 bullets, the third bullet which is more general does not say “modify”, but only “include”. Given the difference from the other 2 bullets, I assume that means include without modification.

Under this option, how could someone take pseudocode or code from a W3C spec, modify it and use it in an implementation of the W3C spec and then license that implementation under the GPL? While W3C grants them the right to use the text in their implementation (and they'd be fine if it was not open source), they have no right to grant a license to others that says the text in the source code can be used without use restrictions – the implementers have no right themselves to use that code without restrictions. An alternative approach of licensing code like parts of specs under a real open source license like the W3C Software License or 3-clause BSD would enable this use case.

Smaller point - the list for code, idl, etc. differs from options 1 and 3 by also including “header text” in the list of content from the spec that is covered in a special way. While it is clear what “header text” means in code, it is not clear what it means in the contents of a specification. Should be dropped from option 2.
Tony Gentilcore I cannot live with this license.
Gavin Carothers I can live with this license.
Krijn Hoetmer I cannot live with this license.
Lawrence Rosen I cannot live with this license. This license is limited to "reasonable portions" of the W3C HTML5 specifications. Apache members are not willing to let some judge or jury tell us what is reasonable for our software.

This license also attempts -- albeit both imprecisely and with an excess of technical jargon -- to distinguish derivative works of code and of prose. That distinction has no basis in copyright law or in development protocols for well-written and well-documented software. This is merely an opening for future quarrels about how much "stuff" may be copied from W3C HTML5 specifications. We want the freedom to copy as much stuff as we desire for our software and its documentation.

Finally, this license attempts to limit developers to "good software engineering practices". Some large software companies believe that they have special insight into what that term means; many of us in Apache beg to differ. We will decide for ourselves what engineering practices we want to follow, regardless of whether others think them good or bad, and we will be judged only by our software quality.
Steve Faulkner I can live with this license.
Jirka Kosek I can live with this license.
Gervase Markham I cannot live with this license. Mozilla has three requirements for the licensing of HTML Recommendations:

A) The license must meet the Open Source Definition and the Free Software Definition.

B) As a UA vendor, we want to be able to embed license text (e.g. IDL definitions) in our code, our developer documentation, etc. So the spec license needs to allow us to do that, given our existing licenses for code and documentation. This means, among other things, allowing relicensing to the MPL, LGPL or GPL (i.e. sticking it in the middle of a file which is under one, two or all three of those licenses without needing reams of additional legal text).

C) As an organization that cares about the future of the web, the spec needs to be effectively forkable as long as its made clear that the fork is not W3C-sanctioned in any way.

Our opinion is that Option 2 does not directly satisfy requirement A), because it does not allow one to make derivative works of the whole document.

Our opinion is that Option 2 does not satisfy requirement C), because it limits the ability to copy and redistribute to portions, not the whole. Either this stipulation is meaningless in practice and so should be removed, or is meaningful and is therefore unacceptable. A license where different parties interpret the same words different ways in order to make them and their constituency happy is also not reasonable, and may lead to conflict in the future.
Andrew Wilson I cannot live with this license. This option is fundamentally intended to discourage forking, which is an important potential use of the specification.
Matt Lee I can live with this license.
Bob Lund This is my preferred license.
Jens Oliver Meiert I cannot live with this license.
Samuel Santos I can live with this license.
Michael Puls II
Simon Myers I cannot live with this license. It does not (explicitly) allow that another group could take over responsibility for the HTML5 spec and republish it, for example in the case that this working group is disbanded or loses credibility among those who implement HTML5.
Lachlan Hunt I cannot live with this license. To assist with making an informed decision, the following documents the facts relating to this licence with supporting rationale. The views expressed herein are my own and do not necessarily reflect those of Opera Software. The statements relating to use cases should not imply any claim regarding the desirability of meeting any particular use case.

1) This licence is incompatible with the Open Source Definition (OSD) and the Debian Free Software Guidelines (DFSG), as well as the the GPL and similar licences.

The W3C Document licence states:

"No right to create modifications or derivatives of W3C documents is granted pursuant to this license."

Options 2 only provides limited exceptions granting the use of "reasonable portions" of the document within software and related materials, and within research materials and publications.

The OSD and DFSG [1] state that:

"The license must allow modifications and derived works"

and

"The license must not restrict anyone from making use of the program in a specific field of endeavor."

Additionally, the GPL v2 [2] states that:

"You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

The proposed licence does not meet these requirements due to the "reasonable portions" limitation imposed upon copying and modification in clauses 2 and 3, and because of the implied restrictions against the use of the document in any materials that are not covered by those limited exceptions.

In addition, this licence fails to address a number of use cases:

* Use cases #1 and #10:
2) Due to the GPL incompatibility, this licence does not satisfy these use cases for a book published and licensed under that licence.

3) A derived work reproducing the specification in full or in part along with annotations, commentary or otherwise, is not clearly permitted.

* The reproduction of the entire specification with modifications does not clearly meet the "reasonable portions" limitation.
* Such a document does not qualify as software, or any related materials, as listed in clause 2.
* It is not clear if such a document would qualify as "research materials and publications" in clause 3.

For example, the HTML5 spec for web developers which excludes implementation requirements, or something along the lines of the annotated specifications like Annotated ES5 spec.

http://developers.whatwg.org/
http://es5.github.com/

Producing such documents based on the W3C HTML5 specification, if licenced under Option 2, would likely require explicit permission from the W3C.

* Use cases #8 and #9:
4) Due to the GPL incompatibility, this licence does not satisfy these use cases for a specification published and licensed under that licence.

5) Due to the implicit field of use restriction, this licence does not satisfy these use cases because a specification does not qualify as "research materials and publications" from clause 3.

Use cases #2, #3, #4, #5, #6 and #7:
6) In relation to use of code-like portions from the document, this licence is compatible with the GPL due to the right to copy, modify and distribute those portions "without limitation".

7) In relation to prose, due to the GPL incompatibility, this licence does not satisfy these use cases for software distributed under the GPL.

Additional statements were obtained from debian-legal contributors in support of these views. The discussion thread is archived, beginning at [3]. The views and rationale expressed in [4] and [5] are of particular interest.

[1] http://www.opensource.org/osd.html and http://www.debian.org/social_contract
[2] http://www.gnu.org/licenses/gpl-2.0.html
[3] http://lists.debian.org/debian-legal/2011/04/msg00058.html
[4] http://lists.debian.org/debian-legal/2011/04/msg00061.html
[5] http://lists.debian.org/debian-legal/2011/04/msg00070.html

James Graham I cannot live with this license.
Daniel Schattenkirchner I cannot live with this license.
Matthew May I cannot live with this license.
Christopher Bank I cannot live with this license.
Roy Fielding I cannot live with this license. I object to Option 2 because it relies on undefined (and undefinable, short of litigation) terms such as "reasonable portions" and "good software engineering practices".
Mayank Kumar I cannot live with this license.
John Foliot I can live with this license.
Cameron Jones I cannot live with this license.
Eric Eggert I cannot live with this license.
Adrian Bateman This is my preferred license. Option 2 provides the best balance between the requirements of the working group as expressed in the use cases and the mandate expressed in the AC vote. We see Option 2 as the best way to support W3C in its fundamental mission as a source of stable, authoritative, consensus-based specifications that support cross-platform interoperability while respecting the role that external and open source communities play in innovating the specs and implementing the standards. In the end, users, implementers, and developers rely on W3C for a Web that works. This means stable specifications they can write to, embed in their products, and use in their homes and businesses. Option 2 supports that endeavor while addressing the wishes of the broadest possible span of communities.
Aryeh Gregor I cannot live with this license. I've posted my response to www-archive, since it's too long to submit here (9.4 KB):

http://lists.w3.org/Archives/Public/www-archive/2011May/0008.html
Leif Halvard Silli I cannot live with this license.
Tantek Çelik I cannot live with this license. Per http://lists.w3.org/Archives/Public/public-html/2011Apr/0000.html

The time has come for W3C to abandon bespoke license(s).

There are no longer any substantial reasons why W3C should spend
time/money on bespoke licenses as it has historically done so.

The costs, both to W3C, and to anyone who wishes to use W3C
technologies are unnecessary: time/effort for W3C to develop/maintain
bespoke licenses vs simply re-use "standard" licenses, and time/effort
for users of W3C tech to read/evaluate W3C's bespoke licenses vs.
knowing they can trust previously known licenses/agreements such as
CC0 and OWFa.
Michael Cooper I can live with this license.
Leonard Rosenthol I cannot live with this license. Adobe does not wish the specification to fork, since we believe that this would fragment the Web. Adobe strongly believes that W3C should be the only organization that establishes and manages the HTML specification.
David Carlisle I cannot live with this license.
Kimberly Blessing I can live with this license.
Masataka Yakura I cannot live with this license.
Arne Johannessen I can live with this license.
Richard Schwerdtfeger This is my preferred license.
Eliot Graff This is my preferred license.
Kris Krueger This is my preferred license.
Mounir Lamouri I cannot live with this license.
Frank Olivier This is my preferred license.
Cynthia Shelly This is my preferred license.
Arun Ranganathan I cannot live with this license. We believes that nothing but the right to fork, expressed in such a clear way that anyone reading the license agrees that the license does actually give the right to fork, will do. In other words, none of the W3C PSIG options 1 through 3 are OK, because they don't offer this right.

The right to fork is an important free software/open source value, and in this case particularly it ensures that if the W3C once again becomes a bad venue for HTML development, as happened before (leading to the creation of the WHATWG), work doesn't need to be started again from scratch. There can thus be a continuity of thought in successor specifications, should such successor specifications to HTML5 need to be developed outside of W3C's aegis.

The relevant "official Mozilla" public statements on the topic are:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0021.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0263.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0696.html

Both CC0 and MIT would achieve the forkability goal and, thus, align
with our values. CC0 was proposed first, but it's less familiar to
people, so MIT was proposed afterwards so that forkability doesn't get rejected just because some people are suspicious of CC0. See:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0689.html .
Travis Leithead This is my preferred license.
Andi Snow-Weaver This is my preferred license.
Matt Harris I cannot live with this license. "It is not, however, intended to facilitate the publication of derivative works as a technical specification"

The same reasons as previously stated as objections to option 1.
This is not in the spirit of open source, nor does it encourage innovation. It does not encourage innovation as it prohibits forking on the specification for the purposes of implementation. To me that's unacceptable.
Jonathan Watt I cannot live with this license.
David Singer This is my preferred license. This license is compatible with our intended uses, and is GPL compatible. We believe that the restrictions within the license, along with accompanying text that expresses 'social restrictions' creates sufficient practical barriers to forking.
Jace Voracek This is my preferred license.
Eihab Ibrahim I cannot live with this license.
Jonas Sicking I cannot live with this license. * Doesn't unambiguously allow forking
* It's unclear if it is GPL compatible.
* It's unclear if it allows copying parts of the document into GPL licensed software.

The reason for the last two bullet points is that while the license allows relicensing portions of the document, it's unclear if that is only as long as the restrictions set forth in "the terms set forth above" applies. I.e. if it's only allowed in any license that enforces the requirements set forth in the original license.
Theresa O'Connor I can live with this license. (This is a personal response.)

I believe this license allows for the copying of relevant spec text into open source software such as WebKit. But others disagree, and they may be disinclined to participate in projects incorporating spec text should we go with this option.
Hadley Beeman I cannot live with this license.

3. W3C License Option 3

We have W3C License Option 3 for the W3C HTML5 specifications. Please provide your preference with respect to this license by choosing ONE of the options below.

If you have strong objections to adopting this License Option, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Summary

ChoiceAll responders
Results
This is my preferred license. 7
I can live with this license. 25
I cannot live with this license. 41

Details

Responder W3C License Option 3Rationale
Kenneth Dahlstrøm I cannot live with this license.
Ian Hickson I cannot live with this license.
John Vernaleo I can live with this license.
Kyle Simpson I can live with this license.
Mike Taylor I cannot live with this license.
Gavin Sharp I cannot live with this license.
Shawn Medero I cannot live with this license. Option 3 claims GPL compatibility but doesn't clearly demonstrate the rational for this assumption. There's a bit of a "he said, she said" type assertion made, but there is not a document trail I can follow to understand the assertion. If there was a legal analysis supporting the GPL compatibility claim provided by an independent 3rd party entity knowledgeable of Free Software issues, then perhaps I could support this option.
Kornel Lesinski I can live with this license.
Jeremy Keith
Tab Atkins Jr. I cannot live with this license. This license does not appear to be compatible with the GPL. If it does turn out to be compatible, it is still a brand-new license for no good reason.
Robert O'Callahan I cannot live with this license. I object to this license because its field-of-use restrictions ("To facilitate implementation of the technical specifications set forth in this document") are not compatible with software freedom.
Silvia Pfeiffer I cannot live with this license. "Furthermore, all code, pseudo-code, schema, data tables, cascading style sheets, and interface definition language is licensed under the W3C Software License, LGPL 2.1, and MPL 1.1." why not put everything under a license that is easy to understand? In this way, it's not easy to meger it with specifications / code published under different licenses.
Mathias Bynens I cannot live with this license.
Philip Jägenstedt I cannot live with this license.
Henri Sivonen I cannot live with this license. I object to this license, because the qualifications on its permissive part make it unclear if it allows forking. The license should be unambiguous on its stance towards forking.
Mark Pilgrim I cannot live with this license. Not compatible with open source
Mark Miller I cannot live with this license. While a huge improvement, " It is still W3C policy to discourage unauthorized forks of its specifications, and nobody should read Option 3 as including any such authorization." still indicated too restrictive a stance.
Matthew Turvey I cannot live with this license.
Doug Jones This is my preferred license. The W3C License Option 3 neither explicitly permits or prohibits forking of the HTML5 specification, although it implies forking the specification is not permitted. It appears to rely on other law and its interpretation as to whether forking its allowed.

The HTML5 specification should be respected and not forked by others. Since HTML is used world-wide to communicate with many cultures and needs, only one world-wide HTML specification should be recognized as the method to use HTML.

I believe this proposed license allows for proposed HTML changes to be included within copies of the HTML5 specification for development purposes without having the resulting document called an HTML specification.
David Baron I cannot live with this license.
Boris Zbarsky I cannot live with this license. This license has field of use restrictions and purposefully creates ambiguity about whether forking is ok, which is highly undesirable.
David Bolter I cannot live with this license.
Dimitri Glazkov I cannot live with this license.
Wayne Carr I cannot live with this license. Should add “ Nothing in the license grants permission for the publication of derivative works of this document for use as a technical specification”. People seem to believe that is the case. Readers of the license shouldn't need to have lawyers to know that.

This option licenses snippets from specs under mpl 1.1 which has a patent grant from contributors. What in W3C patent policy provides for that patent grant from W3C Members other than for implementing the spec itself? This says there are patent grants from members for uses where there likely are none.
Tony Gentilcore I cannot live with this license.
Gavin Carothers This is my preferred license.
Krijn Hoetmer I cannot live with this license.
Lawrence Rosen This is my preferred license. Because this Option 3 eliminates the only objection that FSF has to the first option, this Option 3 is Apache's preferred license. We want FSF to be satisfied with the W3C HTML5 license.

In discussions on this HTML5 WG list comparing the effects of Options 1 and 3 on forking of the W3C HTML5 specification, some people noted that Option 3 merely replaces an express restriction in Option 1 with an implied restriction. As I said above in response to Option 1, Apache members are willing to continue under the W3C umbrella for the HTML5 specification and have no desire to fork the specification as a specification. Express or implied, W3C restrictions on forking the HTML5 specification don't matter to Apache.

As a lawyer, I don't concede that copyright law provides a legitimate way to prevent forking of functional specification; patent law yes, copyright law no. At some future distant time, when someone can demonstrate that the W3C consensus process harms the software world and that a forked HTML5 specification is the only remedy, I will probably argue as a lawyer that functional specifications can always be forked for functional reasons! But that's an argument for another day.

Option 3 allows the W3C HTML5 specification to be published under W3C's copyright and patent regime that is friendly to *ALL* open source licenses, including the Apache license, for software and its documentation. That's all that Apache members have insisted upon in our use cases.
Steve Faulkner This is my preferred license.
Jirka Kosek I can live with this license.
Gervase Markham I cannot live with this license. Please note the Mozilla requirements given above.

Our opinion is that Option 3 does not satisfy requirement A), because it contains field-of-use restrictions.

Our opinion is that Option 3 does not satisfy requirement C), because the W3C Document License does not permit forking, and the additional permission statement restricts it to portions "in/accompanying software". Either this stipulation is meaningless in practice and so should be removed, or is meaningful and is therefore unacceptable. A license where different parties interpret the same words different ways in order to make them and their constituency happy is also not reasonable, and may lead to conflict in the future.
Andrew Wilson I cannot live with this license. This option is also fundamentally intended to discourage forking, which is an important potential use of the specification, and the possible lack of GPL compatibility is another serious issue.
Matt Lee I can live with this license.
Bob Lund I can live with this license.
Jens Oliver Meiert I cannot live with this license.
Samuel Santos I can live with this license.
Michael Puls II
Simon Myers I cannot live with this license. It does not (explicitly) allow that another group could take over responsibility for the HTML5 spec and republish it, for example in the case that this working group is disbanded or loses credibility among those who implement HTML5.
Lachlan Hunt I cannot live with this license. To assist with making an informed decision, the following documents the facts relating to this licence with supporting rationale. The views expressed herein are my own and do not necessarily reflect those of Opera Software. The statements relating to use cases should not imply any claim regarding the desirability of meeting any particular use case.

1) This licence is incompatible with the Open Source Definition (OSD) and the Debian Free Software Guidelines (DFSG), as well as the the GPL and similar licences.

The W3C Document licence states:

"No right to create modifications or derivatives of W3C documents is granted pursuant to this license."

Options 3 only provides limited exceptions related to software, supporting materials accompanying software, and documentation of software.

The OSD and DFSF [1] states that:

"The license must not restrict anyone from making use of the program in a specific field of endeavor."

Additionally, the GPL v2 [2] states that:

"You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

The proposed licence does not meet these requirements due to the implied field of use restrictions against the use of the document in any materials that are not covered by those exceptions.

In addition, this licence fails to address a number of use cases:

* Use cases #1 and #10:
2) Due to the GPL incompatibility, this licence does not satisfy these use cases for a book published and licensed under that licence.

3) A derived work reproducing the specification in full or in part along with annotations, commentary or otherwise, is not permitted because the such a derivative work does not qualify as software, supporting materials accompanying software, nor documentation of software, as stated in clause 1.

For example, the HTML5 spec for web developers which excludes implementation requirements, or something along the lines of the annotated specifications like Annotated ES5 spec.

http://developers.whatwg.org/
http://es5.github.com/

Producing such documents based on the W3C HTML5 specification, if licenced under Option 3, would likely require explicit permission from the W3C.

4) The PSIG proposal document states within the table listed in the "How Licenses Meet HTML Working Group Use Cases" section states, in relation to Option 3, for those two use cases:

"Full: Yes. Portions: Yes, in supporting materials accompanying
software, and in documentation of software."

This indicates a known field of use restriction against the use of the document within a book that does not accompany software, and which does not reproduce the document in full without modification.

* Use cases #8 and #9:
5) Due to the GPL incompatibility, this licence does not satisfy these use cases for a specification published and licensed under that licence.

6) Due to the implicit field of use restriction, this licence does not satisfy these use cases because a specification does not qualify as "research materials and publications" from clause 3.

Use cases #2, #3, #4, #5, #6 and #7:
7) In relation to use of code-like portions from the document, this licence is compatible with the GPL due to those portions also being licensed under the W3C Software Licence and the LGPL 2.1.

8) In relation to prose, due to the GPL incompatibility, this licence does not satisfy these use cases for software distributed under the GPL.

Additional statements were obtained from debian-legal contributors in support of these view. The discussion thread is archived, beginning at [3]. The views and rationale expressed in [4], [5] and [6] are of particular interest.

[1] http://www.opensource.org/osd.html and http://www.debian.org/social_contract
[2] http://www.gnu.org/licenses/gpl-2.0.html
[3] http://lists.debian.org/debian-legal/2011/04/msg00058.html
[4] http://lists.debian.org/debian-legal/2011/04/msg00061.html
[5] http://lists.debian.org/debian-legal/2011/04/msg00062.html
[6] http://lists.debian.org/debian-legal/2011/04/msg00070.html
James Graham I cannot live with this license.
Daniel Schattenkirchner I cannot live with this license.
Matthew May I can live with this license.
Christopher Bank I can live with this license.
Roy Fielding I can live with this license. In general, my preference is for no changes to the W3C license unless a new license is adopted for all W3C recommendations and expected to be applied to all of them in accordance with W3C participation agreements.

If any change is found necessary, then I prefer Option 3 over all other options, though I see no reason for the three added licenses in the final bullet. The W3C software license already applies to such work products.
Mayank Kumar I can live with this license. This option will be OK only if there is a statement here that the license language clearly states that it is only a document use license (i.e., copyright license) and does not convey IPR rights (i.e., patents).
John Foliot This is my preferred license.
Cameron Jones I cannot live with this license. Does not resolve Option 1.
Eric Eggert I cannot live with this license.
Adrian Bateman I can live with this license. The premise of Option 3 is to allow use of the text "to facilitate implementation of the technical specifications set forth in this document" and allows that use broadly in software, supporting materials, and documentation. It satisfies the goals set by W3C in light of the AC vote, but Option 1 accomplishes the same end with text that is more readily understood by a wide range of parties. So while we would prefer a clearer statement of W3C's intentions, we can live with Option 3 so long as it is supported by a strong explanatory FAQ.
Aryeh Gregor I cannot live with this license. I've posted my response to www-archive, since it's too long to submit here (9.4 KB):

http://lists.w3.org/Archives/Public/www-archive/2011May/0008.html
Leif Halvard Silli This is my preferred license.
Tantek Çelik I cannot live with this license. While this is an improvement over options 1 and 2, it is still a bespoke license and thus has all the same problems mentioned in: http://lists.w3.org/Archives/Public/public-html/2011Apr/0000.html

There are no longer any substantial reasons why W3C should spend
time/money on bespoke licenses as it has historically done so.

The costs, both to W3C, and to anyone who wishes to use W3C
technologies are unnecessary: time/effort for W3C to develop/maintain
bespoke licenses vs simply re-use "standard" licenses, and time/effort
for users of W3C tech to read/evaluate W3C's bespoke licenses vs.
knowing they can trust previously known licenses/agreements such as
CC0 and OWFa.
Michael Cooper I can live with this license.
Leonard Rosenthol I can live with this license. This option will be OK only if there is a statement here that the license language clearly states that it is only a document use license (i.e., copyright license) and does not convey IPR rights (i.e., patents).
David Carlisle I cannot live with this license.
Kimberly Blessing I can live with this license.
Masataka Yakura I can live with this license.
Arne Johannessen I can live with this license.
Richard Schwerdtfeger I can live with this license.
Eliot Graff I can live with this license.
Kris Krueger I can live with this license.
Mounir Lamouri I cannot live with this license.
Frank Olivier I can live with this license.
Cynthia Shelly I can live with this license.
Arun Ranganathan I cannot live with this license. We believes that nothing but the right to fork, expressed in such a clear way that anyone reading the license agrees that the license does actually give the right to fork, will do. In other words, none of the W3C PSIG options 1 through 3 are OK, because they don't offer this right.

The right to fork is an important free software/open source value, and in this case particularly it ensures that if the W3C once again becomes a bad venue for HTML development, as happened before (leading to the creation of the WHATWG), work doesn't need to be started again from scratch. There can thus be a continuity of thought in successor specifications, should such successor specifications to HTML5 need to be developed outside of W3C's aegis.

The relevant "official Mozilla" public statements on the topic are:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0021.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0263.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0696.html

Both CC0 and MIT would achieve the forkability goal and, thus, align
with our values. CC0 was proposed first, but it's less familiar to
people, so MIT was proposed afterwards so that forkability doesn't get rejected just because some people are suspicious of CC0. See:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0689.html .
Travis Leithead I can live with this license.
Andi Snow-Weaver I can live with this license.
Matt Harris I cannot live with this license. Whilst this provides the ability to fork and publish derived technical specifications it seems redundant when a license to allow that already exists. Adjusting an existing license to allow it to work with the others seems unnecessary when the other license could be merely adopted.
Jonathan Watt I cannot live with this license.
David Singer I cannot live with this license. This license potentially leaves too many questions open to interpretation.
Jace Voracek I can live with this license.
Eihab Ibrahim This is my preferred license.
Jonas Sicking I cannot live with this license. * Doesn't allow forking
* Isn't unambigiously GPL compatible. I.e. even lawyers with expertise in the area disagree, this is enough that most people will be scared of treating it as GPL compatible for fear of at best getting sued, at worst loosing in court.
* Doesn't allow copying text in the spec into GPL licensed source files
Theresa O'Connor I cannot live with this license.
Hadley Beeman I cannot live with this license.

4. Mozilla proposed CC0 license

Although W3C staff are pursuing a license that does not permit forking, we are also interested in hearing from HTML Working Group participants about their opinion of the CC0 license as proposed by Mozilla for the W3C HTML5 specifications. Please provide your preference with respect to this license by choosing ONE of the options below.

If you have strong objections to adopting this License Option, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Summary

ChoiceAll responders
Results
This is my preferred license. 29
I can live with this license. 17
I cannot live with this license. 27

Details

Responder Mozilla proposed CC0 license Rationale
Kenneth Dahlstrøm I can live with this license.
Ian Hickson This is my preferred license. Google would be equally happy with CC0, MIT, BSD, or other similar licenses.
John Vernaleo I can live with this license.
Kyle Simpson I can live with this license.
Mike Taylor I can live with this license.
Gavin Sharp I can live with this license.
Shawn Medero I can live with this license.
Kornel Lesinski I can live with this license.
Jeremy Keith This is my preferred license.
Tab Atkins Jr. This is my preferred license. This license is compatible with the GPL, and is an existing wide-spread license.
Robert O'Callahan This is my preferred license.
Silvia Pfeiffer This is my preferred license. is the patent situation solved in this situation?
Mathias Bynens This is my preferred license.
Philip Jägenstedt This is my preferred license.
Henri Sivonen This is my preferred license.
Mark Pilgrim This is my preferred license.
Mark Miller This is my preferred license. Ideally non-restrictive.
Matthew Turvey This is my preferred license.
Doug Jones I cannot live with this license. The use of the CC0 license relinquishes anyone of any responsibility for the HTML5 specification and therefore reduces its integrity. Not only is forking permitted, but any attribution to the original holder does not appear to be required.

Multiple versions of the HTML5 specification (and its successors) must not be permitted so consistency and accessibility using HTML may be more easily maintained for the benefit of users, content providers, HTML authors, and user agents.

Individuals and user agents will continue to develop new technologies to improve HTML. In this process, new and experimental features will be added to UAs (as they have in the past) that will not be compatible across all user agents until officially accepted in a subsequent version of the HTML specification.

I believe another proposed license allows for proposed HTML changes to be included within copies of the HTML5 specification for development purposes without having the resulting document called an HTML specification.
David Baron This is my preferred license.
Boris Zbarsky This is my preferred license.
David Bolter This is my preferred license.
Dimitri Glazkov I can live with this license.
Wayne Carr I cannot live with this license. W3C is the best place to develop html specs. It is an open and fair standards org. We do not want others to fork W3C specs.

Hypothetical: Suppose this option was adopted. 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. Being permitted by W3C to modify the W3C spec would allow them to do that without openly ignoring copyright or without having to create separate specs that openly require disregarding the W3C spec. W3C would clearly have permitted their fork.

Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C or work in the proposed, new W3C Community Groups [1] than to splinter html. (At least at present, proposed copyright licensing for community groups is very open, so future new work from the wider community may have other avenues for contributing while allowing those contributions to be used broadly by others. That would not require changing how W3C specs are licensed).

[1] http://www.w3.org/QA/2011/04/coming_soon_w3c_community_grou.html
Tony Gentilcore I can live with this license.
Gavin Carothers I cannot live with this license.
Krijn Hoetmer This is my preferred license.
Lawrence Rosen I cannot live with this license. This is not a software license. It is compatible with software licenses merely because it purports to place the work in the public domain. The CC0 license includes nothing about patents. It does not incorporate the otherwise helpful provisions of the W3C Document License that we all have lived with for years.

The public domain offers no solution to W3C's legitimate efforts to make the forking of its specifications as difficult as possible. That is, in my opinion, a reasonable goal for a consensus-based standards organization dealing with important web software specifications. Forking is bad; avoid it through all available means except when absolutely necessary. The CC0 license doesn't do that.
Steve Faulkner I cannot live with this license.
Jirka Kosek I cannot live with this license. HTML5 spec should be one reference place. Even now there is some confusion because there are W3C and WHAT WG versions of spec. Allowing forking will make this situation even worse.
Gervase Markham This is my preferred license. This licence is a well-understood lawyer-checked internationalized licence from a respected player in the licensing space. Its terms and intent are completely clear, and do not suffer from the problem of being interpreted different ways by different people. And, examining the 11 use cases presented, by virtue of imposing no restrictions whatsoever we believe this licence meets all of them.
Andrew Wilson This is my preferred license.
Matt Lee This is my preferred license.
Bob Lund I can live with this license.
Jens Oliver Meiert This is my preferred license.
Samuel Santos I can live with this license.
Michael Puls II
Simon Myers This is my preferred license. This allows that another group could take over responsibility for the HTML5 spec and republish it, for example in the case that this working group is disbanded or loses credibility among those who implement HTML5. (Equal preference with MIT.)
Lachlan Hunt I can live with this license. To assist with making an informed decision, the following documents the facts relating to this licence with supporting rationale. The views expressed herein are my own and do not necessarily reflect those of Opera Software. The statements relating to use cases should not imply any claim regarding the desirability of meeting any particular use case.

1) This licence addresses all use cases.
James Graham I can live with this license.
Daniel Schattenkirchner I can live with this license.
Matthew May I cannot live with this license.
Christopher Bank I cannot live with this license.
Roy Fielding I cannot live with this license. CC0 is not a license. CC0 is a unilateral declaration of intent not to pursue exclusive rights. As stated on that page, CC0 is not suitable for works that have third-party copyrights, since the CC0 declaration is only made by one party. Absent that one party, each of the individual copyright owners can individually sue for their exclusive rights. In other words, CC0 is not in any way appropriate for a standards specification in which all the participants remain owners of their own copyright and have merely granted the SDO (the W3C) the right to distribute their contributed work as a joint or collective work.
Mayank Kumar I cannot live with this license.
John Foliot I cannot live with this license.
Cameron Jones I can live with this license.
Eric Eggert I can live with this license.
Adrian Bateman I cannot live with this license. This option is not consistent with the direction given by the AC vote. It is drafted as a complete waiver under copyright law, which is not appropriate for a W3C specification.
Aryeh Gregor This is my preferred license. I've posted my response to www-archive, since it's too long to submit here (9.4 KB):

http://lists.w3.org/Archives/Public/www-archive/2011May/0008.html
Leif Halvard Silli I cannot live with this license.
Tantek Çelik This is my preferred license. http://lists.w3.org/Archives/Public/public-html/2011Apr/0000.html

CC0 provides the maximum world-wide flexibility for both creators
of implementations and derivative materials from specifications.

Open standards should hold themselves to no less of a standard than that.

Over three years ago the microformats community switched to requiring all contributions be placed into the public domain (with CC0-compatible permissions) and the results have only been positive since.

Even the development of what could be considered "competing" microdata vCard and vEvent vocabularies based on microformats has provided valuable feedback for improving the hCard and hCalendar microformats as well as microformats as whole. The hCard microformat and microformats community errata/suggestions for vCard have also been used to improve IETF vCard4. All of this was made trivially possible by microformats community adoption of CC0-compatible public domain licensing.

http://microformats.org/2007/12/29/making-open-standards-as-open-as-possible

HTML5, like all web standards, deserves to be as open a standard as possible, and that means placing it as much as possible into the international public domain - which is what CC0 does.
Michael Cooper I cannot live with this license.
Leonard Rosenthol I cannot live with this license. Adobe does not wish the specification to fork, since we believe that this would fragment the Web. Adobe strongly believes that W3C should be the only organization that establishes and manages the HTML specification.
David Carlisle I can live with this license.
Kimberly Blessing I cannot live with this license.
Masataka Yakura This is my preferred license.
Arne Johannessen I cannot live with this license.
Richard Schwerdtfeger I cannot live with this license.
Eliot Graff I cannot live with this license.
Kris Krueger I cannot live with this license.
Mounir Lamouri This is my preferred license.
Frank Olivier I cannot live with this license.
Cynthia Shelly I cannot live with this license.
Arun Ranganathan This is my preferred license. We believes that nothing but the right to fork, expressed in such a clear way that anyone reading the license agrees that the license does actually give the right to fork, will do. In other words, none of the W3C PSIG options 1 through 3 are OK, because they don't offer this right.

The right to fork is an important free software/open source value, and in this case particularly it ensures that if the W3C once again becomes a bad venue for HTML development, as happened before (leading to the creation of the WHATWG), work doesn't need to be started again from scratch. There can thus be a continuity of thought in successor specifications, should such successor specifications to HTML5 need to be developed outside of W3C's aegis.

The relevant "official Mozilla" public statements on the topic are:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0021.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0263.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0696.html

Both CC0 and MIT would achieve the forkability goal and, thus, align
with our values. CC0 was proposed first, but it's less familiar to
people, so MIT was proposed afterwards so that forkability doesn't get rejected just because some people are suspicious of CC0. See:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0689.html .
Travis Leithead I cannot live with this license.
Andi Snow-Weaver I cannot live with this license.
Matt Harris This is my preferred license.
Jonathan Watt This is my preferred license.
David Singer I cannot live with this license. The CC0 is a mechanism for waiving copyright. Using the CC0 would essentially give the message "the W3C gives this away and walks away" which is not our stance and not the message the W3C should give. It is not clear that the W3C can even use the CC0 for this purpose; the material contributed was not placed into the public domain by the contributors, and the W3C cannot give away more than it received. This license does not require attribution, which is a common aspect of open-source licenses.
Jace Voracek I cannot live with this license.
Eihab Ibrahim I cannot live with this license.
Jonas Sicking This is my preferred license. CC0 or MIT is equally good to me.
Theresa O'Connor
Hadley Beeman This is my preferred license.

5. Mozilla proposed MIT license

Although W3C staff are pursuing a license that does not permit forking, we are also interested in hearing from HTML Working Group participants about their opinion of the MIT license as proposed by Mozilla for the W3C HTML5 specifications. Please provide your preference with respect to this license by choosing ONE of the options below.

If you have strong objections to adopting this License Option, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Summary

ChoiceAll responders
Results
This is my preferred license. 31
I can live with this license. 22
I cannot live with this license. 21

Details

Responder Mozilla proposed MIT license Rationale
Kenneth Dahlstrøm This is my preferred license.
Ian Hickson This is my preferred license. Google would be equally happy with CC0, MIT, BSD, or other similar licenses.
John Vernaleo This is my preferred license.
Kyle Simpson This is my preferred license.
Mike Taylor This is my preferred license.
Gavin Sharp This is my preferred license.
Shawn Medero This is my preferred license.
Kornel Lesinski This is my preferred license.
Jeremy Keith
Tab Atkins Jr. I can live with this license. This license is compatible with the GPL, and is an existing wide-spread license.
Robert O'Callahan This is my preferred license.
Silvia Pfeiffer This is my preferred license. is the patent situation solved in this situation? BSD would be equally good as this one.
Mathias Bynens This is my preferred license.
Philip Jägenstedt This is my preferred license.
Henri Sivonen This is my preferred license.
Mark Pilgrim I can live with this license.
Mark Miller I can live with this license. Adequately non-restrictive
Matthew Turvey This is my preferred license.
Doug Jones I cannot live with this license. The MIT license does require attribution of the copyright owner, but by allowing one to "modify" the Software, it also permits forking.

Multiple versions of the HTML5 specification (and its successors) must not be permitted so consistency and accessibility using HTML may be more easily maintained for the benefit of users, content providers, HTML authors, and user agents.

Individuals and user agents will continue to develop new technologies to improve HTML. In this process, new and experimental features will be added to UAs (as they have in the past) that will not be compatible across all user agents until officially accepted in a subsequent version of the HTML specification.

I believe another proposed license allows for proposed HTML changes to be included within copies of the HTML5 specification for development purposes without having the resulting document called an HTML specification.
David Baron I can live with this license.
Boris Zbarsky This is my preferred license.
David Bolter This is my preferred license.
Dimitri Glazkov I can live with this license.
Wayne Carr I cannot live with this license. same response as for CC0 above.

W3C is the best place to develop html specs. It is an open and fair standards org. We do not want others to fork W3C specs.

Hypothetical: Suppose this option was adopted. 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. Being permitted by W3C to modify the W3C spec would allow them to do that without openly ignoring copyright or without having to create separate specs that openly require disregarding the W3C spec. W3C would clearly have permitted their fork.

Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C or work in the proposed, new W3C Community Groups [1] than to splinter html. (At least at present, proposed copyright licensing for community groups is very open, so future new work from the wider community may have other avenues for contributing while allowing those contributions to be used broadly by others. That would not require changing how W3C specs are licensed).

[1] http://www.w3.org/QA/2011/04/coming_soon_w3c_community_grou.html
Tony Gentilcore This is my preferred license.
Gavin Carothers I can live with this license.
Krijn Hoetmer I can live with this license.
Lawrence Rosen I cannot live with this license. Only engineers like the MIT license. Lawyers laugh at it nowadays. Its ambiguities about implied licenses are a challenge to explain. It doesn't address patents in a meaningful way. I've written extensively elsewhere about how the FOSS community has now developed more rigorous licenses and the MIT and BSD licenses are not the best we have to offer; I won't repeat that diatribe here.

With Option 3 (and Option 1, for that matter), anyone who still believes that the MIT license is a useful way to distribute his or her HTML5 software may still do so. Options 1 and 3 are fully compatible with the MIT license.
Steve Faulkner I cannot live with this license.
Jirka Kosek I can live with this license. HTML5 spec should be one reference place. Even now there is some confusion because there are W3C and WHAT WG versions of spec. Allowing forking will make this situation even worse.

But at least MIT license somehow requires to keep reference to original spec in forks. Ideally this provision should be extended and all spec forks should be required to reference original HTML5 spec and list reasons for fork and all changes from W3C HTML5.
Gervase Markham This is my preferred license. This licence is a well-understood, familiar licence with a long track record in the software industry. Its terms and intent are completely clear, and do not suffer from the problem of being interpreted different ways by different people. And, examining the 11 use cases presented, we believe this licence meets all of them.
Andrew Wilson I can live with this license.
Matt Lee I can live with this license.
Bob Lund I can live with this license.
Jens Oliver Meiert I can live with this license.
Samuel Santos This is my preferred license.
Michael Puls II This is my preferred license.
Simon Myers This is my preferred license. This allows that another group could take over responsibility for the HTML5 spec and republish it, for example in the case that this working group is disbanded or loses credibility among those who implement HTML5. (Equal preference with CC0.)
Lachlan Hunt This is my preferred license. To assist with making an informed decision, the following documents the facts relating to this licence with supporting rationale. The views expressed herein are my own and do not necessarily reflect those of Opera Software. The statements relating to use cases should not imply any claim regarding the desirability of meeting any particular use case.

1) This licence is well established, widely compatible and widely recognised and supported among the software industry. This is also true for the 2- and 3- clause BSD licence.

2) This licence addresses all use cases.

3) This licence also has precedent. Since 2008, the XMPP Software Foundation has used an MIT-based license for its specifications:
http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ (See section 4)
James Graham This is my preferred license.
Daniel Schattenkirchner This is my preferred license.
Matthew May I cannot live with this license.
Christopher Bank I cannot live with this license.
Roy Fielding I cannot live with this license. The W3C Document License and Patent Policy work together to provide limited rights to implement and redistribute what we as the W3C membership have agreed to in the form of Recommendations. In particular, the rights that are described in the MIT license are not given by the contributors until after agreement on the document has been reached, and certainly not to arbitrary derived works. Therefore, the MIT license applied to this specification now would be misleading the public. In order for such a thing to be legitimate, we would first have to change the W3C policies and participation agreements to include the patent licenses upon public contribution, like the Apache License.
Mayank Kumar I cannot live with this license.
John Foliot I cannot live with this license.
Cameron Jones I can live with this license.
Eric Eggert This is my preferred license.
Adrian Bateman I cannot live with this license. This option is not consistent with the direction given by the AC vote. It is an exceedingly broad license that does not send the appropriate message that a W3C Recommendation is a stable, global reference point. This is necessary to maintain W3C as a trusted and reputable source of definitive technical specifications.
Aryeh Gregor This is my preferred license. I've posted my response to www-archive, since it's too long to submit here (9.4 KB):

http://lists.w3.org/Archives/Public/www-archive/2011May/0008.html
Leif Halvard Silli I cannot live with this license.
Tantek Çelik I can live with this license. As noted: http://lists.w3.org/Archives/Public/public-html/2011Apr/0581.html

I prefer CC0 over the MIT license due to the ambiguity of the latter and in particular the fact that CC0 has been written/checked/accepted by Creative Commons' lawyers explicitly taking into account international laws/jurisdictions regarding copyright.

Since W3C operates internationally, CC0 being more internationally-aware/applicable makes it strongly preferable to an "MIT-style" license.

I would encourage those at companies whose lawyers have evaluated and approved the MIT license to also please evaluate CC0 as I think (IANAL) that you will find it similarly acceptable at a minimum, and likely preferable per the reasoning above.
Michael Cooper I cannot live with this license.
Leonard Rosenthol I cannot live with this license. Adobe does not wish the specification to fork, since we believe that this would fragment the Web. Adobe strongly believes that W3C should be the only organization that establishes and manages the HTML specification.
David Carlisle I can live with this license.
Kimberly Blessing I can live with this license.
Masataka Yakura I can live with this license.
Arne Johannessen This is my preferred license.
Richard Schwerdtfeger I cannot live with this license.
Eliot Graff I cannot live with this license.
Kris Krueger I cannot live with this license.
Mounir Lamouri I can live with this license.
Frank Olivier I cannot live with this license.
Cynthia Shelly I cannot live with this license.
Arun Ranganathan This is my preferred license. We believes that nothing but the right to fork, expressed in such a clear way that anyone reading the license agrees that the license does actually give the right to fork, will do. In other words, none of the W3C PSIG options 1 through 3 are OK, because they don't offer this right.

The right to fork is an important free software/open source value, and in this case particularly it ensures that if the W3C once again becomes a bad venue for HTML development, as happened before (leading to the creation of the WHATWG), work doesn't need to be started again from scratch. There can thus be a continuity of thought in successor specifications, should such successor specifications to HTML5 need to be developed outside of W3C's aegis.

The relevant "official Mozilla" public statements on the topic are:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0021.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0263.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0696.html

Both CC0 and MIT would achieve the forkability goal and, thus, align
with our values. CC0 was proposed first, but it's less familiar to
people, so MIT was proposed afterwards so that forkability doesn't get rejected just because some people are suspicious of CC0. See:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0689.html .
Travis Leithead I cannot live with this license.
Andi Snow-Weaver I cannot live with this license.
Matt Harris I can live with this license.
Jonathan Watt This is my preferred license.
David Singer I can live with this license. This is not an ideal license. It is a software, not a documentation license. However, it does appear to allow what needs to be allowed, and retains what needs retaining (e.g. attribution).

If this license is used, some explanatory material, and 'social restrictions' text similar to option 2, may need to accompany it.
Jace Voracek I can live with this license.
Eihab Ibrahim I cannot live with this license.
Jonas Sicking This is my preferred license. CC0 or MIT is equally good to me.
Theresa O'Connor This is my preferred license.
Hadley Beeman I can live with this license.

More details on responses

  • Kenneth Dahlstrøm: last responded on 28, April 2011 at 17:45 (UTC)
  • Ian Hickson: last responded on 28, April 2011 at 17:51 (UTC)
  • John Vernaleo: last responded on 28, April 2011 at 17:52 (UTC)
  • Kyle Simpson: last responded on 28, April 2011 at 17:52 (UTC)
  • Mike Taylor: last responded on 28, April 2011 at 20:53 (UTC)
  • Gavin Sharp: last responded on 28, April 2011 at 21:34 (UTC)
  • Shawn Medero: last responded on 28, April 2011 at 21:35 (UTC)
  • Kornel Lesinski: last responded on 28, April 2011 at 21:44 (UTC)
  • Jeremy Keith: last responded on 28, April 2011 at 23:27 (UTC)
  • Tab Atkins Jr.: last responded on 29, April 2011 at 00:12 (UTC)
  • Robert O'Callahan: last responded on 29, April 2011 at 02:55 (UTC)
  • Silvia Pfeiffer: last responded on 29, April 2011 at 04:03 (UTC)
  • Mathias Bynens: last responded on 29, April 2011 at 05:47 (UTC)
  • Philip Jägenstedt: last responded on 29, April 2011 at 08:26 (UTC)
  • Henri Sivonen: last responded on 29, April 2011 at 10:15 (UTC)
  • Mark Pilgrim: last responded on 29, April 2011 at 13:10 (UTC)
  • Mark Miller: last responded on 29, April 2011 at 13:46 (UTC)
  • Matthew Turvey: last responded on 29, April 2011 at 13:54 (UTC)
  • Doug Jones: last responded on 29, April 2011 at 14:23 (UTC)
  • David Baron: last responded on 29, April 2011 at 15:44 (UTC)
  • Boris Zbarsky: last responded on 29, April 2011 at 16:37 (UTC)
  • David Bolter: last responded on 29, April 2011 at 19:57 (UTC)
  • Dimitri Glazkov: last responded on 29, April 2011 at 21:37 (UTC)
  • Wayne Carr: last responded on 30, April 2011 at 00:26 (UTC)
  • Tony Gentilcore: last responded on 30, April 2011 at 09:36 (UTC)
  • Gavin Carothers: last responded on 30, April 2011 at 18:50 (UTC)
  • Krijn Hoetmer: last responded on 1, May 2011 at 14:03 (UTC)
  • Lawrence Rosen: last responded on 1, May 2011 at 22:36 (UTC)
  • Steve Faulkner: last responded on 2, May 2011 at 07:28 (UTC)
  • Jirka Kosek: last responded on 2, May 2011 at 08:01 (UTC)
  • Gervase Markham: last responded on 2, May 2011 at 15:58 (UTC)
  • Andrew Wilson: last responded on 2, May 2011 at 16:14 (UTC)
  • Matt Lee: last responded on 2, May 2011 at 20:37 (UTC)
  • Bob Lund: last responded on 2, May 2011 at 22:20 (UTC)
  • Jens Oliver Meiert: last responded on 2, May 2011 at 23:28 (UTC)
  • Samuel Santos: last responded on 3, May 2011 at 00:16 (UTC)
  • Michael Puls II: last responded on 3, May 2011 at 03:47 (UTC)
  • Simon Myers: last responded on 3, May 2011 at 08:22 (UTC)
  • Lachlan Hunt: last responded on 3, May 2011 at 13:44 (UTC)
  • James Graham: last responded on 3, May 2011 at 14:32 (UTC)
  • Daniel Schattenkirchner: last responded on 3, May 2011 at 16:14 (UTC)
  • Matthew May: last responded on 3, May 2011 at 20:18 (UTC)
  • Christopher Bank: last responded on 3, May 2011 at 21:15 (UTC)
  • Roy Fielding: last responded on 3, May 2011 at 22:01 (UTC)
  • Mayank Kumar: last responded on 4, May 2011 at 01:43 (UTC)
  • John Foliot: last responded on 4, May 2011 at 06:53 (UTC)
  • Cameron Jones: last responded on 4, May 2011 at 10:26 (UTC)
  • Eric Eggert: last responded on 4, May 2011 at 13:02 (UTC)
  • Adrian Bateman: last responded on 4, May 2011 at 22:12 (UTC)
  • Aryeh Gregor: last responded on 4, May 2011 at 23:11 (UTC)
  • Leif Halvard Silli: last responded on 5, May 2011 at 00:10 (UTC)
  • Tantek Çelik: last responded on 5, May 2011 at 01:27 (UTC)
  • Michael Cooper: last responded on 5, May 2011 at 03:50 (UTC)
  • Leonard Rosenthol: last responded on 5, May 2011 at 13:42 (UTC)
  • David Carlisle: last responded on 5, May 2011 at 15:54 (UTC)
  • Kimberly Blessing: last responded on 5, May 2011 at 16:08 (UTC)
  • Masataka Yakura: last responded on 5, May 2011 at 17:22 (UTC)
  • Arne Johannessen: last responded on 5, May 2011 at 18:42 (UTC)
  • Richard Schwerdtfeger: last responded on 5, May 2011 at 18:52 (UTC)
  • Eliot Graff: last responded on 5, May 2011 at 19:03 (UTC)
  • Kris Krueger: last responded on 5, May 2011 at 20:10 (UTC)
  • Mounir Lamouri: last responded on 5, May 2011 at 20:42 (UTC)
  • Frank Olivier: last responded on 5, May 2011 at 21:35 (UTC)
  • Cynthia Shelly: last responded on 5, May 2011 at 21:39 (UTC)
  • Arun Ranganathan: last responded on 5, May 2011 at 21:43 (UTC)
  • Travis Leithead: last responded on 5, May 2011 at 22:06 (UTC)
  • Andi Snow-Weaver: last responded on 5, May 2011 at 22:34 (UTC)
  • Matt Harris: last responded on 5, May 2011 at 23:04 (UTC)
  • Jonathan Watt: last responded on 5, May 2011 at 23:27 (UTC)
  • David Singer: last responded on 5, May 2011 at 23:59 (UTC)
  • Jace Voracek: last responded on 6, May 2011 at 00:40 (UTC)
  • Eihab Ibrahim: last responded on 6, May 2011 at 01:20 (UTC)
  • Jonas Sicking: last responded on 6, May 2011 at 02:09 (UTC)
  • Theresa O'Connor: last responded on 6, May 2011 at 04:00 (UTC)
  • Hadley Beeman: last responded on 6, May 2011 at 04:39 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.