This FAQ addresses questions related to the document license provisions of the HTML Working Group charter.
W3C, for the first time, is experimenting with a permissive copyright license for some Recommendation-track deliverables of a W3C Working Group.
A Dual License. Documents are available under two distinct licenses:
Not at this time.
The HTML Working Group described a set of use cases, including:
This experiment is intended to address those use cases.
W3C received a formal objection from Mozilla to a proposed HTML Working Group charter in March 2013.
The HTML Working Group Charter expires 30 June 2015.
The following conditions will be taken into account to monitor and evaluate the experiment:
When submitting an extension specification to the Working Group, individuals may propose that W3C publish the document under the Creative Commons Attribution 3.0 Unported License (CC-BY) as well as the W3C Document License. Extension specifications published under the Dual License may include materials that have been dropped from the HTML 5.0 and HTML 5.1 specifications but must not duplicate material included in these specifications. The DOM4 specification is also a candidate for the Dual License.
In May 2011, the W3C Advisory Committee rejected 3 options proposed by the PSIG for the document license applicable to the HTML 5.0 specification. In November 2011, the Director declared a lack of consensus and kept the W3C Document license as-is. However, as proven by the formal objection raised during the review of the HTML Charter, the matter is still an unresolved issue and the Director intends to conduct this experiment to allow developers to bring more specifications to W3C, without resulting in confusion in the Web ecosystem.
No. They are only licensed under the W3C Document License.
Yes (with the approval of the HTML Working Group).
When a submitter proposes to use the Dual License, the Working Group decides to adopt the proposal either:
If there is an objection the group must not adopt the Dual License for that document.
Yes. See the next question for attribution requirements related to the Dual License.
Derivative works based on these specifications must:
W3C promotes the five principles of cooperation, adherences to principles, collective empowerment, availability, and voluntary adoption to avoid fragmentation. This is achieved through industry consensus and encouraging an open forum for discussion within the W3C Working Groups. Therefore, we encourage individuals to work within the W3C Process and find common grounds with the community at large. Forking a specification imposes high costs, and is therefore not recommended.
No. The W3C Patent Policy requires Royalty Free licensing only of Essential Claims necessarily infringed by implementation of a W3C Recommendation. Working Group participants' patent commitments may be limited to implementations of the W3C Recommendation and to what is required by the Recommendation.
Per section 8 of the the HTML charter:
Extension specifications published under the Dual License may include materials that have been dropped from the HTML 5.0 and HTML 5.1 specifications but must not duplicate material included in these specifications.
Therefore, the extension specification must be abandoned once its material has been included in the HTML 5.0 or HTML 5.1 specifications, and further changes related to the extension will be available only under the W3C Document License.
Since the W3C Document License is applied to both Dual License extensions specifications and core HTML specifications, there shouldn't be complication. See also the answer on success criteria.
Legal opinions on GPL compatibility vary, and we believe that CC-BY should be sufficiently interoperable to permit the use case. Although some developers have stated that CC-BY is not sufficiently liberal due to the perceived incompatibility with GPL, the Director encourages developers to appreciate CC-BY as a forking-permitted license and intends the experiment to test its utility for the use case.
Per section 2.2.3 Extensibility of the HTML 5.0 specification:
When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification.
The conformance terminology for documents depends on the nature of the changes introduced by such applicable specifications, and on the content and intended interpretation of the document. Applicable specifications MAY define new document content (e.g. a foobar element), MAY prohibit certain otherwise conforming content (e.g. prohibit use of <table>s), or MAY change the semantics, DOM mappings, or other processing rules for content defined in this specification. Whether a document is or is not a conforming HTML5 document does not depend on the use of applicable specifications: if the syntax and semantics of a given conforming HTML5 document is unchanged by the use of applicable specification(s), then that document remains a conforming HTML5 document. If the semantics or processing of a given (otherwise conforming) document is changed by use of applicable specification(s), then it is not a conforming HTML5 document. For such cases, the applicable specifications SHOULD define conformance terminology.
The scope of the extension specifications in the HTML Working Group are therefore subject to the approval of the HTML Working Group, within the scope of the HTML Working Group charter.
The HTML Working Group encourages extension specifications as follows:
- Use modularity to manage the size and complexity of the specifications while reducing social conflict within a constrained timeline:
- Gain agreement that the remaining open issues can proceed via extension specifications at first. Provide an opportunity to merge extension specifications back into the baseline spec upon getting WG consensus and after the extension specifications meet their Candidate Recommendation exit criteria.
- Welcome the option of extension specifications that don't merge back at all and instead proceed at different paces and possibly even with different Candidate Recommendation exit criteria.