- From: Lawrence Rosen <lrosen@rosenlaw.com>
- Date: Mon, 7 Mar 2011 16:28:15 -0800
- To: <public-html@w3.org>, "'PSIG'" <member-psig@w3.org>
Ian, please allow me to correct a few points in your email. See below. /Larry > -----Original Message----- > From: public-html-request@w3.org [mailto:public-html-request@w3.org] On > Behalf Of Ian Hickson > Sent: Monday, March 07, 2011 3:15 PM > To: Lawrence Rosen > Cc: public-html@w3.org; PSIG > Subject: Re: Option 3 <snip> > > 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 licensees. > 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. /Larry [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