RE: Option 3

On Mon, 7 Mar 2011, Lawrence Rosen wrote:
> > 
> > As this is a new license, it further increases license proliferation, 
> > which Google finds objectionable.
> 
> 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.

The problem is with introducing new licenses, not whether those licenses 
are approved or not by some organisation or another.

   http://en.wikipedia.org/wiki/License_proliferation

The only way to not make the problem of license proliferation worse is to 
use an existing license unmodified.


> > 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).
> 
> That is not accurate.

That paragraph was written by one of our lawyers. If the intent of this 
license text is that it be compatible with the GPL, then I strongly 
recommend that the license text be reworded to make this completely 
unambiguous. Certainly Google would not be able to use spec text covered 
under this license in GPL'ed products.


> 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.

So is it your intent that someone should be able to take the 
specification, place it into a GPL'ed software product, and then take that 
software product, remove the software parts of it, and publish the 
remainder (namely the specification) as a specification under the GPL?

If the answer is no, then to my untrained eye it seems that you are 
clearly adding additional limitations or restrictions above and beyond the 
GPL's, which would imply it's not compatible.

If the answer is yes, then why go to all this trouble to not just allow 
forking directly? It seems pointless to require people to jump through 
legal hoops to do something, if they're not stopped from doing it.


> > 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.
> 
> 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.

Ok:

Finally, the terms do not seem to allow 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.


> 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.

That misses the point.


> 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.

I'm not sure how much higher a level I can take it... who's above Jeff?


> 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. :-)

It wasn't a problem in 1998 either. The goal isn't to solve a problem that 
exists today. The goal is to prevent the problem from ever existing.

Note that with HTML this is entirely moot, since the entire spec is 
available under a license even more liberal than the MIT license already. 


> > 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.
> 
> That's not as easy as it sounds.

Actually it really is.


> We must also incorporate the existing W3C Document License

Unnecessary, since anything the W3C Document License is allowed by the MIT 
license.


> the W3C Patent Policy and the W3C Trademark Policy

These do not apply, as we're talking about a copyright license here and 
not patent or trademark licenses.

You are making this more complicated than necessary.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 8 March 2011 01:25:59 UTC