Spec license (was: Re: Discussions with plh)

On Feb 2, 2009, at 23:53, Sam Ruby wrote:

> = Topic 1: License =
>
> We started with the license.  In my discussions with Ian and at  
> Mozilla, I gathered that it was a shared understanding that by  
> October that the license for the W3C license would be somehow open  
> source friendly, and specifically that a Creative Commons  
> Attribution license was something that was of common and general  
> interest.

This is great news!

I have some observations/questions:

  * Currently, most (all?) HTML5 parsers are licensed under the MIT  
license for maximum open source licensing compatibility. Particularly  
in the case of the tokenizer, including the whole tokenizing spec in  
the source code of the tokenizer intermingled almost line-by-line with  
the code is good for tracking that the spec and the code are in sync.  
CC-by alone (without exceptions) would interfere with this use case.  
(To be clear, I think it is much more valuable to have the spec  
available under *a* free culture license than to address this use case  
specifically, but I thought it was still worthwhile to point out this  
actual non-speculative use case.)

  * When a sufficient number of open sourcy pieces are mashed up, at  
some point the issue of GPL-compatibility comes up. For example, in  
order to explain why Validator.nu as a whole (excluding the IANA  
language subtag registry file) is Free in the sense of the Debian Free  
Software Guidelines, I explain how each runtime dependency is GPLv3- 
compatible. The FSF says that CC-by 2.0 is not GPL-compatible (http://www.fsf.org/licensing/licenses/index_html#ccby 
). (I haven't seen a compatibility analysis for CC-by 3.0.) Would the  
W3C be willing to explicitly permit relicensing under "GPLv2 or later"  
or "GPLv3 or later" to make sure that the spec is licensed in a GPL- 
compatible way?

  * Is the intent to use "or later" when specifying the version of CC- 
by? (Particularly, using a version prior to 3.0 without "or later"  
would for sure create the kind of problem that now exists with copying  
RFC text into Debian packages.)

  * Is the intent to license the IDL pieces also under a software- 
oriented license that has previously been found suitable for licensing  
software interfaces in a way that doesn't unduly interfere with the  
licenses of downstream projects using the interface definitions?  
(Consider the recent W3C interface licensing discussion in connection  
to use in Batik.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 3 February 2009 07:48:03 UTC