Summary of HTML WG license survey results

The following summary (which includes a link to the full poll results) will be submitted to Ian Jacobs. The chairs will ask him to convey this information as input to the Advisory Committee, the W3C Team and the Director as input for further licensing discussions.

= Summary of HTML WG License Survey Results =

Based on a request from the W3C Team, the Chairs of the HTML Working Group surveyed the group regarding three proposed licenses that have resulted from discussions by the W3C PSIG. These licenses all attempt to meet many of the HTML WG's use cases for a more liberal license, but at the same time prevent forking. The licenses are collected here:

http://www.w3.org/2011/03/html-license-options.html

In addition, Working Group members proposed two additional licenses during mailing list discussion. These two licenses, the MIT license and the CC0 license, allow for forking of the specification. The Chairs agreed to include any license advocated by at least one WG member in the HTML WG survey.

The full results of the survey are here:
http://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results

= Numbers =

75 out of 419 HTML WG members participated in the survey. Vote counts are presented for reference. Caution should be exercised in interpreting these numbers. This was a survey of individuals, not Member organizations, and in many cases many individuals affiliated with the same Member organization replied. In addition, the HTML WG has a very large number of Invited Experts, and their influence may be greater in this survey than is typical in the W3C. With those caveats, here are the survey results based on counting individual WG member preferences:

Option 1:
49 cannot live with this license. 18 can live with this license. 6 prefer this license. 2 gave no reply.

Option 2:
47 cannot live with this license. 15 can live with this license. 11 prefer this license. 2 gave no reply.

Option 3:
41 cannot live with this license. 25 can live with this license. 7 prefer this license. 2 gave no reply.

CC0:
27 cannot live with this license. 17 can live with this license. 29 prefer this license. 2 gave no reply.

MIT:
21 cannot live with this license. 22 can live with this license. 31 prefer this license. 1 no reply.

In addition, the following summary breaks down the results by organizational affiliation or individual contributor status:
http://intertwingly.net/stories/2011/05/08/html5-license-poll-by-org.html

= Common Arguments For/Against All Non-Forking Licenses =

The survey allowed space for WG members to give rationale for their responses. Most of the arguments presented for and against the Option 1, Option 2 and Option 3 licenses were identical. The common aruguments for/against the non-forking licenses are collected together below.  Subsequent sub-sections provide the comments unique to each non-forking license

Against:
- Incompatible with the MPL and GPL, therefore fails to meet many HTML WG use cases, including ons regarding reuse in open source.

- Does not allow specification forking.
- Does not allow another group to take over if the HTML WG is disbanded or ceases to be effective.
- W3C has abandoned HTML in the past, so the possible need to fork in such a case is not just theoretical.
- Not compatible with open source (e.g. guides such as the Open Source Definition or the Debian Free Software Guidelines).
- HTML has been forked many times in the past, including ISO HTML, WML, XHTML-MP, WTVML, WHATWG HTML, CE-HTML, EPUB, and HTML 4.1. These forks were done as delta specs or from scratch. Therefore, copyright restrictions are not effective at preventing forking.
- Fails to meet HTLM WG use cases #1 and #10, for publication as a book under a range of licenses.
- Would prevent publication of useful annotated versions of the spec.
- The W3C version of HTML should not have a more restrictive license than the WHATWG copy, since that would encourage use of the WHATWG copy as the primary source.
- The W3C should re-use well-known "standard" licenses instead of new custom licenses.
- Prohibiting forking discourages innovation.

In favor:
- The HTML5 specification should be respected and not forked by others.

= Unique Arguments For/Against Option 1 =

In addition to the common arguments for/against non-forking licenses, the following arguments uniquely applied to Option 1:

Against:
- Do not like the express prohibition of a specific form of derivative work. Prohibition is the default, by law.

In favor:
- GFDL is incompatible with GPL so it's ok for a W3C spec license to be incompatible with GPL.
- Creates the least confusion over what is and is not allowed.

= Unique Arguments For/Against Option 2 =

In addition to the common arguments for/against non-forking licenses, the following arguments uniquely applied to Option 2:

Against:
- Limitation to "reasonable portions" leaves key points of interpretation to the coursts.
- Distinction between code and prose is untenable.
- Limitation to "good software engineering practices" is unacceptably vague.
- The debian-legal group has stated that they do not believe the license to be GPL-compatible.
- GPL compatibility is uncertain and disputed.

In favor:
- 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.
- 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.

= Unique Arguments For/Against Option 3 =

In addition to the common arguments for/against non-forking licenses, the following arguments uniquely applied to Option 3:

Against:
- Although this license is claimed to be GPL-compatible, no legal analysis is provided in support of this claim.
- Deliberately creates ambiguity about whether forking is allowed.
- License is hard to understand.
- The fact that restrictions on forking are implicit makes it hard to know what is allowed.
- 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.
- The debian-legal group has stated that they do not believe the license to be GPL-compatible.
- Does not explicitly clarify that no patent rights are granted.
- Isn't unambiguously 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.

In favor:
- 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.

= Common Arguments For/Against All Forking Licenses =

The survey allowed space for WG members to give rationale for their responses. Most of the arguments presented for and against the MIT and CC0 licenses were identical. The common arguments for/against the two forking licenses are collected together below.  Subsequent sub-sections provide the comments unique to each forking license.

Against:
- Allowing divergent versions of the HTML specification results in inconsistency and fragmentation of the Web.
- W3C is the best place to develop html specs. It is an open and fair standards org.
- A national government could prevent access to the Web by making a forked HTML spec.
- Device-speciic variants of HTML could be created, causing splintering of HTML.
- Does not include anything about patents.
- Inconsistent with direction from the AC to prevent forking.

In favor:
- This license is compatible with the GPL, and is an existing wide-spread license.
- Fully meets all HTML WG use cases.
- Allows another group to take over responsibility for HTML, if the HTML WG is disbanded or becomes ineffective.
- HTML has been forked many times in the past, including ISO HTML, WML, XHTML-MP, WTVML, WHATWG HTML, CE-HTML, EPUB, and HTML 4.1. These forks were done as delta specs or from scratch. Therefore, copyright restrictions are not effective at preventing forking. So forbidding it has little benefit, but does have some costs.
- Allowing another organization to pick up the slack on HTML, as the W3C did 1998-2007, is crucial. Otherwise, an opening is created for proprietary technologies to take over the Web.
- While some are concerned about device-specific forks of HTML, these have in fact already happened and have not been prevented by copyright restrictions.
- Creation of competing forked specs can provide valuable feedback, as in the case of hCard and hCalendar.
- License terms are completely clear.

= Arguments For/Against CC0 =

In addition to the common arguments for/against forking licenses, the following arguments uniquely applied to CC0:

Against:
- Lacks even a basic attribution requirement.
- Not a software license.
- CC0 is not appropriate because contributions to W3C specifications have third-party copyrights. Contributors only give non-exclusive copyright grants, therefore the W3C cannot actually put specifications into the public domain unilaterally.
- 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.

In favor:
- Ideally non-restrictive.
- This license is a well-understood lawyer-checked internationalized license from a respected player in the licensing space.
- CC0 provides the maximum world-wide flexibility for both creators of implementations and derivative materials from specifications.

= Arguments For/Against MIT License =

In addition to the common arguments for/against forking licenses, the following arguments uniquely applied to MIT License:

Against:
- The MIT license has ambiguities that are a challenge to explain.
- Software license, not a documentation license.

In favor:
- Adequately non-restrictive.
- This license includes an appropriate attribution requirement.
- This license is a well-understood, familiar license 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.

Received on Monday, 9 May 2011 04:38:11 UTC