[ On Thu, September 17, 1998 at 20:22:24 (-0400), Todd Vierling wrote: ]
> Subject: Re: Sleepycat Software DB 2.x library licensing vs. NetBSD
>
> On Thu, 17 Sep 1998, Greg A. Woods wrote:
> 
> :  * 3. Redistributions in any form must be accompanied by information on
> :  *    how to obtain complete source code for the DB software and any
> :  *    accompanying software that uses the DB software.  The source code
> 
> This doesn't work for libc, which may be derived into an environment free of
> GPL'd software.

Whether DB 2.x is in libc or not is irrelevant according to the full
terms of that section I only partly quoted.

/*
 * Copyright (c) 1990, 1993, 1994, 1995, 1996, 1997
 *      Sleepycat Software.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions  
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Redistributions in any form must be accompanied by information on      
 *    how to obtain complete source code for the DB software and any
 *    accompanying software that uses the DB software.  The source code
 *    must either be included in the distribution or be available for no
 *    more than the cost of distribution plus a nominal fee, and must be    
 *    freely redistributable under reasonable conditions.  For an
 *    executable file, complete source code means the source code for all
 *    modules it contains.  It does not mean source code for modules or
 *    files that typically accompany the operating system on which the
 *    executable file runs, e.g., standard library modules or system
 *    header files.
 * 
[[.... and then follows a fairly standard warranty disclaimer that's not
       really part of a copyright license ....]]

Since the code is derrived from a previous work, further copyrights from
UCB and Harvard are appended as well

Of course if this copyright license were more careful at defining its
terms and limitations, as the GNU LGPL is, then it would be easier to
convince folks that it is irrelevant whether or not the library is
actually included in some other library or not.  All that matters is
whether there's a copy of the object code in the "proprietary"
application, or not.

Wait a minute.....

NetBSD has a shared libc (and could have a shared libdb if it were
disentangled).  That implies that a proprietary application does not
contain a copy of the library in any fashion.  Given the exact wording
of the terms above there is no redistribution of the library when a
proprietary application using the library is copied.

Of course if some attempt was made to copyright the interfaces, or apply
patents to the algorithms, etc. then this would be a different story.

> You're free to install DB 2.x yourself;

Of course.  But that's not the point.

> however, we have DB 1.85 in libc,

Which could probably be upgraded to 1.86, the interim DB 2.0 release
which is supposed to have locking, etc.  It's supposedly available
without the new copyright license.

> and rather need to keep it now for binary compatibility.

That's never really stopped any other change in NetBSD.  The old
routines can be added to a compatibility library, if necessary (1.86
already includes a compatibility interface for 1.85, but it may be
source compatibility only).

BTW, I hope you mean binary API compatability, and not file format
compatability.  So far as I can see there are no static .db and all .db
files are easily re-built on demand.

(of course even upgrading to 1.86 will break file format compatability.

> Now, adding a "libdb" to the source tree may be feasible later in the
> future, if it seems gainful....

I've always wondered why libdb (i.e. the 1.85 version) is in fact
integrated into libc.  It seems to me that when you have to do version
management with things like shared libraries it's a whole lot better to
have more objects (so long as they are truely independent, and not
interdependent) than to have one big blob where internal changes can
cause many incompatible interdependencies with the applications that use
it.

But that's another story....  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>