W3C home > Mailing lists > Public > public-html@w3.org > April 2011

W3C should drop bespoke licenses, adopt CC0 + OWFa instead (was Re: HTML License Options for Discussion)

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Fri, 1 Apr 2011 03:13:21 +0000
Message-ID: <AANLkTinQH0pz-SgBTUncAh2e+enDNXEz=QbfGhXg6LYg@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "public-html@w3.org WG" <public-html@w3.org>, PSIG Group <member-psig@w3.org>
tldr version:

The time has come for W3C to abandon bespoke license(s) and re-use
common licenses/agreements instead, in particular CC0[1] for
copyright, and OWFa/CLA 1.0[2] for patent concerns. Since license(s)
are an issue in the HTMLWG, this is a good place to start for W3C to
make this transition.

[1] http://creativecommons.org/choose/zero/
[2] http://www.openwebfoundation.org/announcements/owfaandcla10agreementspublished

Disclosure: I am on the board of the Open Web Foundation, but this
proposal/suggestion is my own as an open web standards advocate, and I
do not speak for the OWF.


longer:

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.

Related:

There is the widely propagated illusion / poor framing that W3C's
limited licenses provide some degree of "protection" against
"forking". This is wrong on several counts.

1. "forking" is not actually a bad thing. As well known from open
source, the development of independent ideas, which may eventually be
reincorporated, often benefits open efforts. The burden of proof is on
those against forking, to provide *any* real world examples where a
fork of a *web* standard resulting in a bad outcome (due to the fork).

2. no company has the leverage to fork a standard and succeed. One of
common excuses to "protect" against forking is that otherwise some
company could make their own version of a standard and take control of
it. While this may have been true with a one or two large browser
companies when W3C was founded, it is no longer true for open web
technologies (W3C's focus). There is both sufficient diversity in the
browser market that no one company could deviate a standard, as well
as a huge realtime public feedback mechanism (AKA the Web) which would
harshly criticize any company for attempting to do so. Again the
burden of proof is on the anti-forking advocates to provide *any* real
world examples where a company has successfully forked and taken over
a web standard.

3. the alleged "protection" offered by W3C's licenses is toothless and
self-defeating. W3C has never taken legal action for someone forking a
W3C specification. And even if they did, the expected result would be
a chilling effect on the use of that standard and on the W3C efforts
in general. That is, any legal action taken to "protect" a W3C
standard would actually likely have the opposite effect, that is, to
slow, hurt, or even kill that standard in terms its usage/adoption in
the marketplace. Witness the chilling effects of Java-related
litigation for example. Or, technology companies simply treat such
legal action as an obstacle and route around it, reverse engineering /
clean-rooming as necessary. And once again, the burden of proof is on
the "protection" advocates to provide even a *single* example where
legal action taken to "protect" a *web* standard actually *helped* its
adoption (rather than hurt).


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

OWFa[2] has been created to fill the need of a re-usable agreement
regarding patent/IP concerns for open web standards.

The adoption of the two of these in combination are "good enough" (and
in many ways superior) IMHO IANAL for W3C to drop its bespoke
license(s)/agreements.

Thanks for your consideration,

Tantek


On Thu, Mar 31, 2011 at 16:38, Maciej Stachowiak <mjs@apple.com> wrote:
>
> In 2009, the HTML Working Group generated a number of use cases for a more
> liberal license for the HTML5 specification than the usual W3C Document
> License, and submitted these to the W3C Team. Since then, there have been
> discussions in the W3C PSIG (Patents and Standards Interest Group) 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 license text and additional
> commentary for three candidate licenses can be found here:
>
> http://www.w3.org/2011/03/html-license-options.html
>
> Since the HTML WG made the original request, at this time, W3C Management
> would like feedback on these licenses. This feedback will be input to the
> W3C Advisory Committee and to W3C Management, who will be responsible for
> the final decision.
>
> We will use the following schedule for gathering feedback from the WG:
>
>    * 31 Marc: HTML Working Group Chairs introduce materials to WG.
>    * 28 April: HTML Working Group Chairs will open survey for feedback on
> several document license options, to run for one week.
>    * 5 May: HTML Working Group Chairs summarize feedback and send to W3C
> staff.
>    * Soon after: W3C staff opens survey of W3C Membership on same options,
> with this material and HTML WG feedback as input.
>    * 15-17 May: W3C Membership discuss during Advisory Committee Meeting.
>
> The discussion period is now open. Please feel free to discuss these
> candidate licenses. At the end of the month, there will be a final
> opportunity to formally record feedback that will be delivered to the AC and
> W3C Management.
>
> Regards,
> Maciej



-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Friday, 1 April 2011 03:14:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC