OpenLDAP license

Thu Apr 12 21:30:06 UTC 2001

on Wed, Apr 11, 2001 at 07:46:42PM -0400, Frank Hecker (frank at collab.net) wrote:
> "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
> Software".
> 
> 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.

This is a distinction I've pointed out elsewhere (my O'Reilly Open
Source licensing presentation and various list mails):  the Open Source
Definition and the FSF's classification of Free Software are differently
formed.

Specifically, the FSF is concerned with the program itself, by
reflecting back to the license and how its rules effect distribution.
The OSD is applied to licenses, which project onto software.  The net
mapping onto software is largely similar (though certain categories of
free software wouldn't be considered for OSD certification, "public
domain" and US Federal Government works are two that come to mind.  In
the case of PD (either the more rigorously defined lapsed copyright
term, or the commonly accepted term for software that's been liberalized
of all copyright protections by its author), there is no license.  In
the case of US Government works, copyright protections are expressly
waived by statute.

The language of the OSD is somewhat confusing in that it speaks largely
to software but governs licensing.  This could be a problem.

<...>

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

s/primarily/expressly/

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

I suspect this becomes rather more difficult to do cleanly than a
license certification.  You've just scaled the task from approving terms
from a set of licenses to monitoring a projection of these licenses
against software projects.  More nodes, and changing state.  OSI is
barely able to keep up with the flow of licenses as it is, the extended
case would be infeasible with current resources, and probably with
several orders of magnitude more.

What the OSD *does* currently do is say that, if you have software, and
source, under a certified license, you're ensured of a minimum set of
rights defined under the OSD.  

    OSD rights == Software + source + license

> 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
> mark.
> 
> However I note that the opensource.org 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 opensource.org page describing the "OSI
> Certification Mark and Program"
> 
> http://www.opensource.org/docs/certification_mark.html
> 
> 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
> following:
> 
> 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
> obtained.
> 
> 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.
> 
> Comments?

Damn you, Frank.

Good conundrum.

-- 
Karsten M. Self <kmself at ix.netcom.com>    http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?       There is no K5 cabal
  http://gestalt-system.sourceforge.net/         http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20010412/78dda481/attachment.sig>