- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 9 Mar 2011 10:48:50 +0000 (UTC)
- To: Lawrence Rosen <lrosen@rosenlaw.com>
- cc: public-html@w3.org, 'PSIG' <member-psig@w3.org>
On Mon, 7 Mar 2011, Lawrence Rosen wrote: > > 1. The MIT license, despite its apparent generosity and compatibility > virtues, is an antiquated, poorly written license that does not serve > modern software needs. I won't bother rehashing those concerns here > since I wrote about them extensively in the final pages of chapter 5 of > my book. (http://rosenlaw.com/Rosen_Ch05.pdf) I read that chapter, but could not find the concerns to which you refer. Could you elaborate as to exactly what I should be reading? The chapter seemed to be rather positive about the MIT license, describing many ways in which it is superior to the BSD license. > 2. License proliferation is not as serious a problem as some perceive it > to be. I appreciate the arguments posted at Wikipedia (apparently > written by some of our mutual friends at Google whose opinions I > recognize), but I beg to differ. Whether you agree with those opinions or not, it is Google's position that we should not be increasing license proliferation, and the proposal here would do so. As such, Google objects to this proposal. > I also addressed the license proliferation issue in a somewhat different > way with somewhat different conclusions in an article I published. > (http://rosenlaw.com/LicenseProliferation.pdf) You can Google "license > proliferation rosen" to read what I and others say about this so-called > FOSS problem of license proliferation. Your essay starts with a simple question: | Which licenses would you have us remove, Majesty, so that | the symphony will be more pleasant to you? The answer is equally simple: let us start with the license you are proposing here. > > 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? > > Yes, but not for the reasons you may think important. I don't think the > copyright license has anything to do with it. As Google itself is > arguing in its defense of the copyright lawsuit by Oracle, the > functional parts of specifications like the HTML5 (and Java) > recommendations are not strongly copyrightable (if at all) in the first > place. Well if the entire discussion is moot, why are we bothering to come up with a restrictive copyright license in the first place? Let's just have a license that allows any normally copyright-restricted behaviour with respect to the specs. > If Google is right about that aspect of copyright law -- and I earnestly > believe they are -- then you have nothing to worry about doing such odd > things as reverse engineering a GPL program merely to fork the HTML > specification. We would much rather have a situation where it is unambiguous what the rights are than a situation where the W3C claims that it is reserving certain rights that it may not be able to reserve. > So W3C probably can't actually use copyright law to prevent the forking > of a specification no matter how desperately some W3C members want to do > that. But don't demand that W3C give you explicit permission to do so. > That is demanding too much of a standards organization that also has its > trademarks to protect. Trademarks have nothing to do with this. Why would it be demanding too much? It's demanding nothing at all, if, as you suggest, the law is such that we are already allowed to do all this. > Note also that you get no benefit your way from the W3C Patent Policy. > So you ought not to believe this: > > > 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. > > The MIT license from people doesn't give you any meaningful patent > rights; read Chapter 5 of my book. Without clear patent rights, you > probably ain't got shit. Patents are a separate issue as well. The W3C doesn't have any patents to grant, so it couldn't be granting patent rights anyway. (The patent policy takes care of this issue separately.) You are correct that a forked specification would not have patent grants. However, specifications are still valuable even without patent grants. The IETF, for example, has been prolifically operating for decades with no meaningful patent policy in place. Should a fork of a W3C specification truly be necessary, it is likely that the patent situation would eventually be resolved, as it has was with the HTML specification when we forked that. (In the case of HTML, it was resolved by the W3C changing direction and once again working on HTML.) > > > > 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). > > I addressed in my previous email to this list why there are no "further > restrictions" in Option 3 to harm the GPL distribution model. I was on > the drafting committee for GPLv3; I've read that license carefully many > times. I believe that courts will take the GPLv3 license at its plain > wording and conclude that a failure to explicitly license the forking of > a specification is in no way a "further restriction" on doing so. >From the GPL FAQ: | What does it mean to say a license is "compatible with the GPL?" It | means that the other license and the GNU GPL are compatible; you can | combine code released under the other license with code released | under the GNU GPL in one larger program. | | All GNU GPL versions permit such combinations privately; they also | permit distribution of such combinations provided the combination is | released under the same GNU GPL version. The other license is | compatible with the GPL if it permits this too." So can we combine code released under the GPL with a work released under this license into one larger program? Not in all cases, hence, it is not compatible. What cases? Let's start simple. The proposed license here only authorizes derivative work creation in software. What if my code is used in hardware? GPLv3 doesn't even limit itself to software and code, like that FAQ definition talks about: | "The Program" refers to any copyrightable work licensed under this | License. Can I combine this spec with a GPLv3 document? No: the document license does not allow it, and the permission grant does not change that. > So don't reject Option 3 (or the other options you will be presented by > PSIG) out of hand. You may want to ask again if your insistence on the > MIT license is actually solving your problem in any meaningful way. There is no insistence on the MIT license; it's merely an example of something that would indeed solve the problem meaningfully. Any other solution that solves the problem would be equally fine. The W3C Software License is close; its requirement that changes be documented makes it impractical for the HTML spec, which is approaching its 6000th revision over 5 years, but other than that it would work fine. The problem is that we cannot take W3C specs, modify them, and republish them without the W3C's involvement. This makes the W3C the weak link in the chain. We've already seen the effect of this: when the W3C dropped the ball on HTML, instead of being able to take the HTML4 spec and fix it, we had to rewrite the entire HTML specification from scratch. In the future, if the W3C drops the ball on HTML again, will the next group of people who try to save it have to start from scratch? Or will they be able to start with our work? Currently the only thing that ensures they won't have to duplicate our effort of the past 7 years is that the WHATWG also publishes the HTML spec and does so under a liberal license. But that's just the HTML spec, what about XML? CSS? XForms? DOM? > You are making this more complicated than necessary. > > I don't really think so. I beg to differ. This could all be resolved simply by not reserving any rights on the specification text. This should be especially trivial given that you don't think that the W3C has the authority to reserve any copyright rights on these works in the first place. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 March 2011 10:49:18 UTC