OpenLDAP license

Frank Hecker frank at
Wed Apr 11 23:46:42 UTC 2001

"Karsten M. Self" wrote:
> For the second time today:
>     The program must include source code, and must allow distribution
>     in source code as well as compiled information about form.
> Again, the initial (OSD-compliant) distribution must include source.
> The licensing terms must allow for distribution of source.  The license
> need not *compel* distribution of source.  Following an OSD-compliant
> distribution, downstream distributions may either be OSD-compliant or
> not.

Not to stick my nose in the middle of this heated topic :-), but I think
I see (at least a bit) what Ryan Dancey is concerned about. In fact, I'm
beginning to think that he may have exposed an ambiguity in the way OSI
handles certification of software as "OSI Certified Open Source

I think the underlying source of confusion is whether the OSD is
intended to place requirements on a software license considered in
isolation (i.e., as a stand-alone legal document), or rather is intended
to place requirements on "distribution terms" considered in the context
of a specific program and the exact manner in which it happens to be
distributed. This confusion is IMO compounded by the way OSI specifies
its requirements for use of the OSI certification mark.

The OSD itself says that "Open source doesn't just mean access to the
source code. The distribution terms of an open source program must
comply with the following criteria: ..." IMO that could be interpreted
either as saying that the OSD places requirements simply on the
software's license (which specifies the terms under which it may be
distributed) _or_ as saying that the OSD places requirements on
"distribution terms" considered generally, i.e., on the manner in which
a particular program (which is claimed to be "open source") is
distributed. This "manner in which a program is distributed" would
include the actual license terms associated with the program as
distributed, but could also cover additional aspects of distribution as
well, such as what is actually included in the distribution.

When OSD section 2 then states "The program must include source code,
..." that to me strengthens the conclusion that the OSD is placing
requirements on "distribution terms" considered generally as previously
discussed, and not simply placing requirements on the software license

However, whether this was and is its intention or not, IMO the OSI is
seen as primarily certifying _licenses_ as OSD-compliant, not
"distribution terms" in this larger sense. Thus, given that the OSI has
certified the BSD and MIT licenses (among others) as "approved
licenses", Ryan Dancey is apparently looking to those licenses
themselves to provide some guarantee that the requirements of OSD
section 2 are fulfilled. Since the BSD and MIT licenses in and of
themselves do not provide this guarantee, he has apparently concluded
that either a) the BSD and MIT licenses are not really "OSD-compliant";
or b) the OSD is flawed in some way.

I agree that this is confusing, but I also agree with your (Karsten's)
implied argument: Neither (a) or (b) above is true; the seeming
contradiction can be resolved by abandoning the idea that a license is
"OSD-compliant" in and of itself. By "approving" a license what the OSI
means to state (IMO) is that if you distribute a particular piece of
software under the approved license _and_ if you take any other actions
that are necessary to meet the requirements of the OSD (actions which
may not be explicitly referenced by the license itself), then your
"distribution terms" as a whole satisfy the OSD, and you have earned the
right to call your software (as distributed by you) "open source".

Thus, to return to your example, if a software product is licensed under
the BSD or MIT licenses and is distributed with source code (or with an
indication of how and where source can be obtained), then the
"distribution terms" for that software are OSD-compliant, and the
software as distributed can be referred to as open source software.

On the other hand, if the same software were to be licensed under the
same BSD or MIT license, but the software were distributed in binary
form only, without source code and without any information on where
source could obtained, then the "distribution terms" for that software
would not be OSD-compliant, and the software as distributed could not be
referred to as open source software.

More specifically, since the OSI is not really enforcing use of the term
"open source" itself but rather use of its "OSI Certified" mark, if a
company were to distribute software in this manner and use the OSI
certification mark in promoting the software, then presumably the action
of distributing BSD- or MIT-licensed software in binary-only form would
be in violation of the terms under which OSI permits people to use its

However I note that the web site is not at all clear
about this. For example, the "Approved Licenses" page says "If you
distribute your software under one of these licenses, you are permitted
to say that your software is 'OSI Certified Open Source Software.'" It
contains no mention of any explicit requirement to include source code. 

More seriously, the page describing the "OSI
Certification Mark and Program"

says "You may use the OSI Certified mark on any software distribution
that contains, and meets the requirements of, any license on the
approved list below, or on software whose source code is explicitly
identified as having been placed in the public domain." Again, the
emphasis is on licenses only, and not on the manner of distribution as a
whole. In fact, this whole page never once mentions an explicit
requirement to include source code, nor does it mention any requirement
that your overall "distribution terms" (including the license but not
confined to the license) must satisfy the OSD.

So here's a hypothetical: Let's forget what we all "know to be the
case", and let's also ignore arguments that something "violates the
spirit of the OSD" (or "open source", or whatever). Let's suppose the

1. I distribute a software product in binary-only form, without source
code of any kind and without any notice that source code could be

2. The only license notice included with my software is the MIT license,
which happens to be included on the OSI's approved list. To make this
concrete, let's say that the MIT license notice is displayed by the
(binary-only) installation program, is displayed as part of an "about
box", is included as a text file installed with the program, and so on.

3. Following the OSI-provided instructions available at the URL
referenced above, I include the following notice with the software "This
software is OSI Certified Open Source Software. OSI Certified is a
certification mark of the Open Source Initiative." (Per the
instructions, I include this notice in a README file with the electronic
form of the software, or in the printed matter if I ship printed
documentation, and/or on the CD if I provide a CD.)

So here's my question: On what grounds could OSI prevent me from using
the OSI certification mark in this manner? Would I have not followed to
the letter the requirements that the OSI has outlined for use of that
mark, as contained in the URL referenced above? Certainly my "software
distribution" "contains" a license on the OSI-approved list (as required
by the OSI-provided language quoted earlier) -- I've included the
license in the distribution as noted above. Also, my "software
distribution" "meets the requirements of" the license I have chosen from
the list -- What "requirement" of the MIT license does it not meet?

In fact, just for fun, let's say that if anyone asks me "where's the
source code", I reply "Oh, you can get that. All you need to do is to
send me $1M and a self-addressed envelope, and I'll send you a copy of
the source." Again, were I to do this, on what grounds could OSI prevent
me from continuing to use its certification mark to promote my software?

Clearly my behavior would violate the Open Source Definition. But from
my reading of the OSI certification requirements, compliance with the
OSD is not a condition of using the OSI mark. It seems to me that, at
least at present, the only real requirement for use of the mark is that
I use as my license one of the licenses on the list which OSI has
helpfully provided.


Frank Hecker            work:
frank at        home:

More information about the License-discuss mailing list