Re: Spec license

On Feb 3, 2009, at 6:38 AM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Feb 2, 2009, at 11:47 PM, Henri Sivonen wrote:
>>> * 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.)
>> For IDL, it would be helpful if open source browser engines such as  
>> Gecko or WebKit could incorporate it directly, so a license known  
>> to be compatible with the LGPL (for WebKit) and with MPL/LGPL/GPL  
>> tri-license (for Gecko) would be best. I believe an MIT style  
>> license fits the bill. This would also allow proprietary browser  
>> engines to incorporate spec IDL if they choose to.
>
> I would love for this working group to present a set of acceptable  
> options and/or use cases to W3C management to consider.

Here are some use cases that I think are important as to the IDL:

- Direct use in open source projects, including those under LGPL-style  
licenses.
- Direct use in proprietary software projects.

I am confident that an MIT license (or BSD without advertising clause,  
or anything along those lines) will satisfy both of these use cases.

> Meanwhile, I'm looking for show-stoppers.  Options that people  
> "can't live with", and therefore must be excluded.  Do you have a  
> specific reason to believe that cc-by 3.0 would be unacceptable to  
> WebKit or Gecko?

I don't know of any evaluation specifically citing cc-by 3.0 as in  
conflict with the LGPL, but since the FSF cites cc-by 2.0 as in  
conflict, and since no analysis says otherwise as to 3.0, we would err  
on the side of caution, and not incorporate code under that license.

That being said, there really aren't any options that the WebKit  
project "can't live with", since we can always copy IDL from the  
WHATWG copy of the spec, which has an extremely permissive license.  
However, it would be my preference that the W3C copy could be used as  
the canonical reference.

> The ASF considers cc-by 2.5 to be compatible with the Apache License  
> 2.0[1].  The FSF considers the Apache license 2.0 to be compatible  
> with the LGPLv3.[2].

License compatibility is not necessarily transitive. For example, the  
MPL/GPL/LGPL tri-license that Mozilla uses is compatible with the MPL  
or with the GPL, but that doesn't mean the MPL and the GPL are  
compatible. My understanding of the matter is as follows: GPL and LGPL  
both severely restrict the kinds of additional conditions that can be  
placed on works covered by the license. This is the reason why some  
open source licenses are incompatible.

I should also note that WebKit uses LGPL v2.1, not v3, and Mozilla  
uses v2.1 "or any higher version".

>  I already mentioned that GNU FDL 1.3 was modified[3] to permit some  
> (presumably wikipedia) to "escape" to cc-by-sa, which I view as some  
> form of endorsement, albeit indirect.

I don't think this really says anything about license compatibility  
with the LGPL. The FSF's list of licenses says this about cc-by 2.0:

"This is a non-copyleft free license that is good for art and  
entertainment works, and educational works. Please don't use it for  
software or documentation, since it is incompatible with the GNU GPL  
and with the GNU FDL."

So clearly they can endorse a license that they believe to be  
incompatible with the GPL or LGPL.

> Nothing in the preceding paragraph is conclusive, but it does make  
> for a plausible case that cc-by might be acceptable.

We could ask for an expert opinion.

> Meanwhile, I have no problem operating under the assumption that a  
> MIT license would satisfy this working group's needs.  I'd even be  
> willing to go so far as to say it is the preferred option.  But I  
> would hate to have plh go into the AC meeting with just one option  
> and have it excluded for whatever reason when there might be other  
> options that he cuold work with.


I studied the FSF's list of GPL-compatible licenses - a number of  
these, but not all, are likely to be compatible with the LGPL. So far  
as I can tell, they fall into these four categories:

- BSD-like licenses - 3-clause BSD, 2-clause BSD, X11/MIT or similar
- The GPL, LGPL, and related FSF licenses
- Exotic licenses (those that are used b only one or only a few  
projects)
- Public Domain (not technically a license)

I believe all of the options besides BSD-like licenses have issues:

- Using GPL, LGPL or a related license creates problems for open  
source projects with different license terms, due to the viral nature  
and tendency to conflict of GPL-related licenses.
- Exotic licenses create "license proliferation" which is widely seen  
as undesirable.
- Public Domain retains no legal rights at all and so may be seen as  
problematic in case of conflict.

Rather than limiting the options presented to the AC, we could list  
pros and cons of different options, even if some have downsides we may  
consider to be quite serious.

Hope this helps,
Maciej

Received on Tuesday, 3 February 2009 16:26:18 UTC