Subject: Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
From: "Matthew C. Weigel" <>
Date: Tue, 25 Sep 2001 17:59:51 -0400 (EDT)

On Tue, 25 Sep 2001, Greg London wrote:

> is it possible to take GPL'ed code,
> modify it, relicense it under
> a proprietary license, and distribute
> it only in binary form?
> my understanding is it is not possible.
> but MIT'ed code would allow this.

Irrelevant.  Is it possible to take APSL'ed code, modify it, and not
provide Apple with information on your changes?  My understanding is it
is not possible.  But MIT'ed code would allow this.

> The 'bar' to meet GPL is pretty high.
> The bar to satisfy the MIT license is on the ground.
> The OSD is somewhere in between.

No.  First, understand that the OSI certifies *software*, in part
because of the license under which it is distributed, and in part based
upon what is distributed.  So, as Bruce indicated, if software is made
available under the BSD license and includes source code, it is OSI
approved.  If not, then not.  OSD #2 applies to the software, and not
the license.

> one can argue about RMS's definition
> of free software, but his implementation
> (the GPL license) set the bar a LOT
> higher than MIT.


> One could also argue that RMS's definition
> is moot to OSI, since OSI has it's own
> definition to follow.

No, even working from the FSF definition, the BSD/MIT license is free.

> > and to change the OSD to exclude them
> > would be a travesty.
> travesty smavesty.
> I'm not saying exclude GPL. Never did.

Please read what he wrote - excluding the BSD or MIT licenses would be
a travesty.

> I am saying the MIT license does not meet OSD #2.

That's correct.  Because, strictly speaking, #2 applies to software,
and not licenses.  A license may preemptively *require* #2 to be met,
but it need not - so long as it is met.

> Since OSD #2 says
> "the program MUST include source code"
> There is nothing in the MIT license to
> guarantee OSD#2, so it fails to meet the
> definition.

Go back to the part you had so much difficulty with before - the OSI
approves software, based in part upon software licenses.  It certifies
licenses as being compatible with the OSD.

> And OSD#2 requires this, because it uses
> the word "MUST". I didn't put it there,
> OSI did.

So, were you to distribute a derivative of a BSD kernel in binary form
without source, you would not be distributing free software (unless you
let people know where they could get the source).

> It isn't about it being a "travesty".
> It's about whether or not OSI followed
> its own definition.

No, it's a question of reading comprehension.  The OSD does not require
"the license must guarantee access in source code form," "the license
must provide a public location from which to download the source," etc.

It says the software must either include source, or have a
well-publicized location from which to get source.  Now, if you wanted
the source to the FreeBSD kernel, included in binary form on your
installation floppy... you know where to get it-

> If OSI certification gives absolutely
> no guarantees about code licensed with
> an OSI approved license, then OSI is
> moot.

Disregarding my own opinions on this, your analysis and the logic that
leads to your conclusion are founded upon a misunderstanding.

I also think that the OSD contributes to this misunderstanding - I
think the wording of the introduction should be rewritten to not
suggest the distribution terms have to meet the OSD, but the
distribution terms or the distribution itself.
 Matthew Weigel
 Research Systems Programmer ne

license-discuss archive is at