RE: Option 3

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