Re: Spec license

On Feb 3, 2009, at 10:12, Sam Ruby wrote:

> Henri Sivonen wrote:
>> 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.)
>
> While I have some background in licenses, it is not clear to me why  
> the above is true.  Can you provide more reasons why you believe  
> this to be so?  Better yet, a pointer?

I'm not saying that the MIT license and CC-by were incompatible. I'm  
saying that CC-by would add some terms in comparison to the MIT  
license. This would defeat the point of using the MIT license. (The  
point being enabling maximal use in software projects be they GPL, non- 
GPL Open Source or proprietary and doing so in a well recognized way  
that people are known to be used to and comfortable with.) Thus, for  
projects that use the MIT license the choice of adding nice-to-have  
spec extracts and taking on additional terms vs. not adding nice-to- 
have spec extracts while not taking on additional terms would probably  
fall on the side of not taking on additional terms.

>> * 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?
>
> This isn't direct evidence, but the GNU FDL 1.3 was explicitly  
> changed to allow certain sites to relicense information covered by  
> this license to the cc-by-sa license for a limited time.  I  
> interpret that as some form of endorsement, and an acknowledgement  
> that cc-by is a better fit for at least some use cases.

The exception was added for the Wikipedia use case. So far, the FSF  
hasn't changed their advice on licensing software documentation.  
Moreover, it wasn't a proper endorsement. It was more like an  
acknowledgement of GFDL failing in the mindshare competition against  
CC-by-sa in terms of the network of compatible non-software-related  
works.

> In FSF-terms, cc-by would be a more "permissive" license than cc-by- 
> sa.  As a general rule, being more permissive does not present a  
> compatibility issue:
>
> http://www.fsf.org/licensing/licenses/quick-guide-gplv3-compatibility.png

Right, but there's (to my knowledge) no clear FSF opinion stating the  
compatibility of CC-by 3.0 and GPLv3 available.

Note that there's (again to my knowledge) also no FSF opinion stating  
that CC-by-sa 3.0 were GPLv3-compatible. It seems that they can't be,  
since both are strong copyleft but aren't the same license.

>> * 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.)
>
> I don't have any intent here other than to capture and convey the  
> desires of the working group.  If you have concrete suggestions, by  
> all means make them.

  1) I suggest the CC-by version be specified with "or, at your  
option, any later version" language.

  2a) The simplest way to deal with the GPL compatibility concern, the  
IDL concern and the HTML5 parser source code annotation concern all at  
once would be dual-licensing the deliverables under the MIT license (http://www.opensource.org/licenses/mit-license.php 
), so I suggest doing that.

  2b) Failing 2a, I suggest dual-licensing spec text in general under  
version 2 or 3 of the GPL with "or, at your option, any later version"  
language and the IDL pieces under the W3C Software License or the MIT  
license.

> I had suggested that we start a one week period of soliciting  
> objections on Thursday.

None of my points are objections.

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

Received on Tuesday, 3 February 2009 09:34:57 UTC