RE: Option 3

Ian, please allow me to correct a few points in your email. See below.

> -----Original Message-----
> From: [] On
> Behalf Of Ian Hickson
> Sent: Monday, March 07, 2011 3:15 PM
> To: Lawrence Rosen
> Cc:; PSIG
> Subject: Re: Option 3
> As this is a new license, it further increases license proliferation,
> which Google finds objectionable.

[LR: ] Option 3 is better viewed as a Specification permission slip for
implementations distributed under any other FOSS and proprietary software
licenses, not a new software license. But if you expect us to seek OSI
approval of this simple license, I have no doubts whatsoever that it would
qualify. You will soon be presented with Options 1 and 2, and I will note my
belief that Option 1 would also qualify for OSI approval (but not FSF
approval), but I personally don't believe Option 2 would qualify for
approval by either group. Any meaningful proposal from PSIG would increase
license proliferation in the sense that you describe it, so if that's the
constraint we might as well give up now. 

> Secondly, this license does not appear to be GPL-compatible, because it
> applies additional constraints (e.g. it does not allow the content to
> be merged into a non-software product).

[LR: ] That is not accurate. What a license allows is not the opposite of
what it prohibits; this license only affirmatively allows what it allows and
says nothing whatsoever about the right to do other things. Option 3 does
not prohibit anyone from merging the content of the spec into a non-software
product; it simply doesn't authorize it. All of our licenses are based on
affirmative but limited and conditional grants, not limitless grants. If you
examine the patent grants in almost all FOSS licenses, for example, you will
note that they do not *allow* the content to be merged into lots of things.
That's how open source has always worked. 

As for the mandates of the GPL, the only thing that the GPL prohibits is
"further restrictions" [1] and Option 3 has no such. There are no
limitations or restrictions that would have to be passed on to downstream

> Finally, the terms seem to disallow forking, which misses one of the main
> reasons for a liberal license, namely, to allow spec forking so as to
> encourage us to do a good job.

[LR: ] Option 3 doesn't disallow anything. It is the existing W3C Document
License that prohibits forking. This Option 3 does not prohibit forking or
anything else; it merely does not authorize it. The same rules will apply as
currently: Anyone who wants to fork a W3C specification *as a specification*
needs to ask permission to do so. If you don't like that policy, please take
it up at a higher level rather than demanding it as a requirement for a
software implementation license.

As for encouraging you to do a good job, I'm new to this WG but I gather
that's not much of a problem nowadays. :-)

> In conclusion, it's not clear that this really solve the problem of the
> W3C HTML spec being under an overly-restrictive license. I highly
> suggest we simply choose an existing liberal open source license (such as 
> the MIT license) rather than try to create a a new license.

[LR: ] That's not as easy as it sounds. We must also incorporate the
existing W3C Document License, the W3C Patent Policy and the W3C Trademark
Policy, and that requires a different way of saying things than MIT wrote so
many long years ago. The MIT license by itself is useless for us. Hence the
"license proliferation" quandary. 


[1] From GPLv3: "All other non-permissive additional terms are considered
"further restrictions" within the meaning of section 10. If the Program as
you received it, or any part of it, contains a notice stating that it is
governed by this License *along with a term that is a further restriction,*
you may remove that term. If a license document contains a further
restriction but permits relicensing or conveying under this License, you may
add to a covered work material governed by the terms of that license
document, provided that the further restriction does not survive such
relicensing or conveying." [Emphasis between * * is added]

Received on Tuesday, 8 March 2011 00:28:43 UTC