RE: Mozilla Proposal for HTML5 Spec Licence

Hi Gerv,

I hate being in this position of advocating for an imperfect license for W3C. My heart and mind are with the open source and Creative Commons philosophies, and so I have always supported the freedom to create *any* derivative works -- subject to license conditions. (But I don't like the public domain solution! [1]) Here in W3C I'm now arguing for a compromise that doesn't *guarantee* our right to fork. I'm torn between what I wish would happen and the present limitations of the real commercial IP world.

For the past few years I've been listening to the demands of many in W3C and PSIG that forking of HTML5 industry specifications (in a derivative works sense) should be restricted. I personally see no reason to impose such restrictions, noting that open source software has thrived without it. I've also argued that such restrictions are, as a matter of copyright law, essentially unenforceable anyway in the context of functional software standards. But convincing all W3C contributors and members of the inherent justice of that principle of freedom has proven impossible. Even our erstwhile friends (I name no names because of W3C confidentiality rules) are afraid of giving away too much; they praise open source and lock away their IP.

In real life, however, nobody important is actually trying to fork the W3C HTML5 specification. Indeed there are cooperative efforts to restrain the very desire to do so. So the argument for forking that you are raising is both an abstraction and a distraction. 

The reason I proposed Option 3 as a compromise is this: It does not require us to acknowledge that W3C can or will prevent the forking of its specifications by copyright. It leaves that battle for another day. It contains no explicit restrictions that are unacceptable features (to FSF) of Options 1 and (to me) of Option 2. By accepting the Option 3 license to create *any* software and its associated documentation -- even under the GPL and Apache licenses! -- we can avoid arguing about the hypothetical forking of specifications until someone comes along who actually wants to do so. It is a battle I will then be glad to join, as always, on the side of freedom.

/Larry

P.S. You also make this point: "....[The] specifications for software are (at least in this case) not software." That's also a distraction and an arguable contention, so I leave my response as a postscript. Take a look at https://softwaretechnews.thedacs.com/stn_view.php?stn_id=56&article_id=178. This is part of my legal argument against Option 2 and against the IETF solution that some praise.

[1] FWIW, here's an article I published in 2004 expressing my distaste for the public domain solution. http://rosenlaw.com/lj16.htm. I haven't changed my mind about this in the years since despite the eloquence of the Mozilla proposal. I'd rather have an enforceable license, thank you very much anyway.



> -----Original Message-----
> From: member-psig-request@w3.org [mailto:member-psig-request@w3.org] On
> Behalf Of Gervase Markham
> Sent: Tuesday, April 12, 2011 1:49 AM
> To: Lawrence Rosen
> Cc: 'HTML Working Group'; PSIG
> Subject: Re: Mozilla Proposal for HTML5 Spec Licence
> 
> On 12/04/11 03:14, Lawrence Rosen wrote:
> >>> Yes, CC0 is suitable for dedicating your copyright and related
> >>> rights in computer software to the public domain, to the fullest
> >>> extent possible under law.
> >
> > If you are suggesting a public domain dedication for the HTML5 specs,
> > don't get your hopes up. Why would W3C members allow that?
> 
> Well, at least two have said that they would (Mozilla and Google) so
> perhaps the argument from incredulity will not serve you well here.
> 
> > You expect
> > them to release their community-created specifications without any
> > conditions?
> 
> Because, perhaps, they want the community to be able to make wide use
> of it.
> 
> > No open source non-profit (including FSF and Apache)
> > allows that with their valuable copyrightable software. No
> > corporation (including Google and Mozilla) would release their own
> > software as public domain. Why should W3C tolerate that for its
> > specifications of software?
> 
> Because the specifications for software are (at least in this case) not
> software.
> 
> Quoting from http://www.w3.org/2011/03/html-license-options.html :
> "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."
> 
> Is your objection that with CC0 there is no disclaimer of warranty
> attached, as in e.g. the BSD licences? Those have effectively a similar
> degree of liberality to CC0. Google and Mozilla have certainly released
> software under BSD licences, and I suspect that if FSF people were
> contributing to projects so licensed, they would as well. If that is
> your objection, state it and we can discuss it.
> 
> It would help move the discussion forward if you were to give examples
> of the sort of bad thing that could happen if we use CC0 that could not
> happen if we used one of Options 2 or 3, why that thing is actually
> bad,
> and who it is bad for.
> 
> > Open Web Foundation just published its specification licenses, which
> > are already used by Google, Facebook, and others for publishing
> > software standards. There isn't even a hint of "public domain" in
> > that!
> 
> Mozilla is not arguing that CC0 is the only acceptable license for
> specifications in any context under any circumstances. We are arguing
> that CC0 is the most appropriate license for this document, given the
> circumstances in which it was created and the uses to which people wish
> to put it.
> 
> > If you focus your discussion on articulating some need for forking of
> > the HTML5 specification rather than introducing the public domain as
> > an alternative, you are more likely to influence events at W3C.
> 
> My previous message contained an attempt to articulate our rationale
> for
> requiring the ability to fork, and why we think attempting to prevent
> it
> would be both unwise and, likely, ineffective at achieving the purposes
> aimed at. Do you feel the need for forking is still insufficiently
> explained?
> 
> Gerv
>

Received on Tuesday, 12 April 2011 18:34:32 UTC