Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <5270EE36.4070800@intertwingly.net>
Date: Wed, 30 Oct 2013 07:32:06 -0400
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: legal-discuss@apache.org
Subject: The facts concerning the W3C CC-BY experiment as I understand them
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The following are based on my discussions with the members of the W3C 
PSIG (many of which are lawyers representing W3C member organizations), 
W3C management, and reading of the announcement and accompanying FAQ. 
Links will be provided on request.

For starters, CC-BY was not picked by the lawyers of the W3C PSIG. In 
fact, the PSIG recommendation was set aside by W3C Management in favor 
of a license choice that they were lead to believe would be more 
palatable by the WHATWG.  It turns out that they were incorrect.

The WHATWG considered a number of factors.  For starters CC-BY is not 
listed as an open source license by the OSI.  It is not recommended by 
the authors of that license for source code.  Both the FSF and the 
Mozilla foundation have publicly stated that they don't consider CC-BY 
to be compatible with licenses that they created.  In the end, they 
decided that CC-BY does not meet their needs.

In any case, HTML5, HTML5.1, and any specification which includes text 
present in those specifications are specifically excluded from the 
experiment that the W3C has authorized.

It is indeed true that Larry Masinter has expressed concerns about Ian 
Hickson's style of specification writing, particularly as it applies to 
HTML5.  In particular, Larry Masinter expressed a concern about 
specification text phrased as algorithms.  Here is what the HTML5 
specification says about such:

Conformance requirements phrased as algorithms or specific steps may be 
implemented in any manner, so long as the end result is equivalent. (In 
particular, the algorithms defined in this specification are intended to 
be easy to follow, and not intended to be performant.)

Ian Hickson's style of specification writing is uncommon.  It generally 
is not the case that other W3C specifications are written using this style.

It is not the case that the W3C would consider implementation of W3C 
specifications to run afoul of the W3C document license.

Any specification text that Ian Hickson writes and makes available for 
inclusion in HTML5 is also made available via the WHATWG separately 
using the following license:

> /*
>  * Copyright 2004-2010 Apple Computer, Inc., Mozilla Foundation, and Opera
>  * Software ASA.
>  *
>  * You are granted a license to use, reproduce and create derivative works of
>  * this document.
>  */

Drafts of the W3C HTML specification include, and have included, the 
following text for a number of years:

The bulk of the text of this specification is also available in the 
WHATWG HTML Living Standard, under a license that permits reuse of the 
specification text.

No current W3C Recommendation contains the HTML requirements phrased as 
algorithms provided by Ian Hickson.  No planned future W3C 
Recommendation made available using CC-BY will contain such.

The above is based on discussions with others.  The below is my conclusions.

It seems to me that code bases that implement HTML4 will not be affected 
by the planned release of HTML5 in 2014.  Code bases preceded the 
development of HTML5 would not be considered copies of HTML5.  Code 
bases that implement parts of HTML5 that are not expressed as pseudo 
code would not be considered copies of HTML5.  Being familiar with that 
specification, the algorithms are primarily present to deal with 
sometimes tricky parts dealing with the consumption of HTML5.  Code 
bases that produce HTML would not be considered copies of those portions 
of the specification.

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org