RE: Option 3

Hi Ian,

Your email prompts me to address two popular misconceptions about FOSS
licensing that may be infecting the HTML WG:

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) 

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

But you mostly worry about a more interesting problem, and I want to address
it:

> 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. 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. My advice to a client seeking
to fork the HTML spec would probably be, don't waste your time reverse
engineering the GPL code, just specify the preferred functionality you want
to implement and publish it; copyright law won't prevent you from doing
that. [See 17 USC 102(b)] 

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.

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

> > > 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. In any event, as I said
above, if Google is right in its response to the Oracle complaint, you can
fork any spec for functional reasons no matter what the copyright license
says.

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.

> You are making this more complicated than necessary.

I don't really think so. Copyright and other laws relating to software
standards are complicated. Take a look at
https://softwaretechnews.thedacs.com/stn_view.php?stn_id=56&article_id=178.


/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 5:25 PM
> To: Lawrence Rosen
> Cc: public-html@w3.org; 'PSIG'
> Subject: 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 06:14:44 UTC