Proposed HTML5 Document License Options

1. Introduction
2. Licenses
3. Use Cases

Introduction

Background

In 2009, participants of the HTML Working Group requested a new document license for HTML based on a number of use cases. This request led to extensive discussions within the W3C Membership, W3C Advisory Board, and Patents and Standards Interest Group (PSIG) about license changes. Based on feedback from the Membership, and because of the merits of the use cases, in March 2010, the W3C Director asked the PSIG to find a license that would 'satisfy all the use cases except for forking.'

Since then, the PSIG has sought to fulfill the Director's request. Over the last year, the PSIG has had discussions of how a license might be designed to enable as many of these use cases as possible, while not allowing outright forking of the specification. Information from that discussion, and, in particular, the text of and discussion of three candidate licenses is provided below.

The W3C staff now seeks feedback from participants in the HTML WG on their understanding of which of the three licenses best satisfies the Director's request.

About the Licenses

To understand how the PSIG arrived at these licenses, it is useful to review the use cases (listed below) and the Director's request to the PSIG:

• Two use cases (8,9) explicitly request the ability to create derivative specifications: to be able to fork a W3C specification.
• Several (2, 3, 4, 5, 6, 7) require that portions of a specification be licensed without use restrictions.

The Director asked the PSIG to solve both sets of requirements simultaneously: in essence, to find a solution that imposes a restriction (against the creation of derivative specifications) while allowing developers to use any downstream software license they choose (including, but not limited to, GPL). "GPL" is used here as convenient shorthand for "any open source software license that allows no additional usage restrictions." Because of the approaches taken, views differ on how and whether the licenses address various use cases. Therefore, additional materials (such as FAQ entries) are used to clarify the intent of the licenses.

Differing views on GPL-compatibility

Views differ on the GPL-compatibility of the proposed licenses. Anticipating that some are likely to turn to the Free Software Foundation (FSF) for views on the GPL-compatibility of license, the PSIG consulted Eben Moglen. His input is reflected below, along with the differing views within the PSIG about the same licenses.

Prose v. Code

All of the candidate licenses are designed to allow liberal use of any code-like portions included in the specification; as a result, they allow more reuse than the current W3C Document License. In addition, because several of the use cases distinguish code-like portions from "prose," the licenses make similar distinctions:

• Use cases 5 and 6 distinguish code and code-like portions
• Use cases 2, 3, and 7 refer to prose
• Use cases 1, 4, and 10 refer to both.

W3C already makes it a practice to license IDL portions of a specification under the W3C Software License; policies of other organizations such as the IETF also distinguish code from prose.

Two approaches to GPL-compatibility

The PSIG took two approaches to achieving GPL-compatibility:

1. Allow liberal use of specification text but specifically disallow republication of derivative works as technical specifications.
2. Restrict how much material may be used by the first user ("reasonable portions, consistent with good engineering practices, to implement the specification"), with no downstream field of use restriction thereafter.

Options 1 and 3 adopt two variations to the first approach:

• Option 1 explicitly imposes the field of use restriction.
• Option 3 omits any explicit grant to use material for derivative specifications, and under copyright law (generally) a license provides rights only to what is explicitly granted, and nothing more.

Summary

With this as background, the three licenses can be summarized as follows:

• Option 1 Broad reuse in software and software documentation to implement the specification, with an explicit field of use restriction.
• Option 2 Reuse of reasonable portions in software and software documentation to implement the specification consistent with good engineering practices, with no field of use restriction thereafter.
• Option 3 Broad reuse in software and software documentation to implement the specification, with an implicit field of use restriction.

In addition, note:

• All enable reuse of code portions under any open source license.
• All address the use cases related to the full specification through a reference to the existing W3C Document License.
• All benefit from accompanying text clarifying the intent of the license.
• All allow use of the text to facilitate implementations of the specification.

Note: The expectation is that the license could be adopted for any specification published by the HTML Working Group, or any specification split off from the original HTML5 draft. The complete list is: HTML 5; HTML+RDFa; HTML Microdata; HTML Canvas 2D Context; HTML: The Markup Language; HTML/XHTML Compatibility Authoring Guidelines; HTML5: Techniques for providing useful text alternatives; HTML5 differences from HTML4; HTML5 Web Messaging; Web Storage; The Web Sockets API, Server-Sent Events. W3C expects to gain experience with any new license before deploying it more broadly.

How Licenses Meet HTML Working Group Use Cases

Views within the PSIG differ on how each license satisfies each use cases. The primary sources of disagreement relate to one's view of the following:

• the GPL-compatibility of a license. Note: Eben Moglen has stated that he considers Options 2 and 3 to be GPL-compatible.
• whether a particular GPL-compatible solution (namely, a stand-alone text file) satisfies the use case as stated.
• whether license text — on its own without supplementary material — is clear enough regarding whether it licenses the creation of derivative specifications.
• the meaning of the use case (at times, unclear on certain points).

The table below says "No consensus" where there is clear disagreement on any of the above points.

Licenses

Option 1

Notes on Option 1

The PSIG intends this license to be compatible with open source software licenses, including GPL, LGPL, Apache, and MPL (all listed in the use cases). This license does not impose a limitation on the republication of all or part of the specification in software. The W3C makes no representations or warranties as to whether the license is in fact compatible with any particular open source software license.

Within the PSIG, there are differing views as to whether the phrase in the license "the publication of derivative works of this document for use as a technical specification is expressly prohibited" is a restriction that adversely affects these use cases.

Views suggesting that this license is not "GPL-compatible" include the following:

• The restriction related to derivative specifications is not compatible with the GPL's requirement that no further restrictions be placed on the creation of derivative works.

Views suggesting that this license is "GPL-compatible" include the following:

• The license prohibits only the publication of derivative works "for use as a technical specification," which does not restrict the development of open source software.

The PSIG has asked the following organizations to provide their views on compatibility with specific licenses:

• Representatives of the Apache Software Foundation have expressed non-binding views that this proposed license is compatible with Apache requirements.
• Representatives of The Free Software Foundation (FSF) have expressed non-binding views that the proposed license is not compatible with GPL.
• Representatives of The Mozilla Foundation have expressed non-binding views that the proposed license is not compatible with MPL.

The FSF and Mozilla representatives cited the restriction related to derivative specifications as the source of incompatibility.

Option 2

Notes on Option 2

Option 2 permits a wide variety of uses of the text and code contained therein. It is not, however, intended to facilitate the publication of derivative works as a technical specification. Even if you believe that such an action might be permitted under some reading of the license terms, W3C strongly requests that, in the interests of industry convergence and clarity that you not republish any part of this document as a technical specification. W3C exists as a forum for building consensus around specifications, and seeks to create an environment where people remain at the table to work out their differences. "Forking" (as distinguished from experimentation with various proposals within a group) is discouraged as it tends to increases everyone's costs and creates confusion.

If you are working with the specification, it is better to refer to it than copy it. Please consider that other IPR commitments (e.g., for patents) that are associated with W3C Recommendations do not extend to your derivative specification; see the W3C Patent Policy for authoritative information. Finally, there are marks, names, and other properties (e.g. the name "W3C") that are not part of this specification; W3C does not license its marks for use in derivative works, and the license(s) for this specification do not apply to them.

W3C encourages experimentation based on W3C specifications, but asks that (1) the experiments be clearly identified as such, and (2) that they do not harm interoperability with other W3C specifications.

Eben Moglen has stated that he considers Option 2 to be GPL-compatible.

Option 3

Notes on Option 3

Option 3 is identical to Option 1 with the removal of the following sentence: "HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited." As a result of this change, Eben Moglen has stated that Option 3 is compatible with all GPLv2 and GPLv3 licenses. Others in the community see the lack of express permission as incompatible with the GPL.

As with all three licenses, Option 3 seeks to balance the requirement for complete freedom to write and distribute software embodying W3C specifications, with the agreed principle that forking of those specifications to create incompatible implementations should be resisted. Option 3 does not expressly forbid the creation of derivative specifications, NOR DOES IT AUTHORIZE SUCH ACTIVITIES. It is still W3C policy to discourage unauthorized forks of its specifications, and nobody should read Option 3 as including any such authorization.

Use Cases

These are the eleven HTML Working Group use cases, recorded here using a PSIG transcription. Note: In the use cases, "I" refers to Henri Sivonen, who submitted a real-world use case to the group.

1. Publishing the full or parts of a specification in a book to be sold.
2. Include prose of the specification in software from proprietary to complete open source
3. Copying the prose defining an algorithm, pasting it verbatim or with modifications into source code of a program as comments and writing an implementation of the algorithm (possibly making creative optimizations) so that the spec text and the statements of the programming language intermingle. The resulting program should be licensable under the MIT license without additional terms. (For algorithms contained in "HTML 5", this use case is addressed by the WHATWG license, but relying on that means that the W3C instance of HTML5 can't be treated as the canonical instance. I'm already exercising this option on the source code of the Validator.nu HTML Parser under the WHATWG spec license.)
4. Extracting parts of a spec and showing the extracts verbatim or with modifications in the user interface of a validator. The validator as a whole including its UI strings should be Open Source and should be suitable for packaging in popular GNU system distributions including Debian. Both distributing a copy of the spec text and a program for extracting pieces of it at runtime and distributing preprocessed extracts should be permitted. Showing a copyright notice on in the documentation of the validator is acceptable, but showing a copyright notice or other legal legends in the UI whenever a spec extract appears would not be acceptable. (I'm already doing this in Validator.nu under the WHATWG spec license. However, I'd be interested in having the option to do this with the authoring guide/reference deliverables of the WG and with the SVG and MathML specs.)
5. Extracting the WebIDL parts of the spec and incorporating them verbatim or with modifications into the source code trees of implementations of the spec. Such inclusion should not interfere with LGPLv2.1 or later (Gecko, WebKit), GPLv2 or later (Gecko), MPL 1.1 or later (Gecko), Apache Software License 2.0 (Batik) or the licensing models of Opera and IE.
6. Extracting the CSS parts of the spec and incorporating them verbatim or with modifications into the source code trees of implementations of the spec. Such inclusion should not interfere with LGPLv2.1 or later (Gecko, WebKit), GPLv2 or later (Gecko), MPL 1.1 or later (Gecko), Apache Software License 2.0 (Batik) or the licensing models of Opera and IE.
7. Copying prose from the spec and pasting it verbatim or with modifications into comments or accompanying documentation of a test case and checking the test case into the source tree of any of the above-mentioned software projects plus html5lib without interfering with their licensing or choice of project hosting.
8. Continuing the development of the WG deliverables in a non-W3C venue if the W3C or the HTML WG cease operations. Note: It is likely that other policies specific to the W3C bylaws/formation documents may play a part in addressing this question.
9. Forking some or all of the WG deliverables and pursuing an alternative development path outside the W3C even without the W3C or the HTML WG ceasing operations. (That is, I think what Rob Burns is doing on the HTML4All wiki should be allowed.)
10. Taking WG deliverables in whole or part and repurposing content into a book that is given gratis or sold on paper or as a digital file.
11. Using extracts from WG deliverables in documentation published on developer.mozilla.org. (See terms)

Ian Jacobs <ij@w3.org>.
$Id: html-license-options.html,v 1.3 2011/03/30 23:04:10 ijacobs Exp $