TDB license (was: Re: tdb performance)

David Chappell David.Chappell at
Thu Jan 24 12:23:08 GMT 2002

> On Wed, Jan 23, 2002 at 04:05:07PM -0500, David Chappell wrote:
> > TDB looks very nice and is small while Sleepycat's and SQ Lite look like
> > overkill, but there is one problem that has so far made me hesitate to
> > use it.  My project (the PPR print spooler) is distributed under the BSD
> > license.  If I were to include TDB then, as I understand it, my whole
> > project would automatically come under the GPL.  Now I have nothing
> > against the GPL, but I have reasons for wanting to keep this particular
> > project BSD.
> > 
> > So I think it is a good thing that Samba as a whole is under the GPL,
> > but I also think it would be nice if TDB were licensed under the LGPL. 
> > That way, people from other projects who used TDB would still have to
> > contribute their fixes and improvements but they could still make their
> > own decisions about how to license their projects.
> > 
> > I understand that Richard Stallman disagrees with this reasoning,
> > basically because he sees GPL licensed libraries as an incentive to
> > choose the GPL for new projects.
On Wed, 2002-01-23 at 16:19, Jeremy Allison wrote:
> So do we. This is why tdb is GPL. We're not going to re-license tdb
> under the LGPL.
> However, we are thinking about allowing an "Open Source" exception
> that allows the use of tdb in Open Source projects only without
> forcing the rest of the project to be GPL also.
> We don't want tdb to be used in proprietary projects, so no LGPL.
> This has come up before (and no doubt will do so again) so I
> thought I'd clarify our position on it.
> Jeremy.

I see.  I was hoping that it was just that no one had ever raised this
point before.

As I said, I understand why the body of Samba is under the GPL and I
know that this has already served to prevent it from being hijacked at
least once.  I was hoping that permitting people to _use_ tdb without
their works effectively coming under the GPL would be compatible with
the goals of the Samba project.

Hey, its your code though.  If you want to use it as a carrot to draw
people to the GPL, that's your right.  (By "you" I mean the authors of

Michael Still <mikal at> wrote:
>My project is licensed under the GPL, so I can appreciate the
>requirement to have tdb GPL'ed, and have no problem with that.
>It was, however, my understanding that if I had say a BSD licensed
>project, then it was still cool to link to a GPL'ed library... So long
>as I was to distribute the tdb stuff separately, and not modify it
>without releasing those changes. Then again, I am willing to be wrong.

I am not sure it would even be necessary to distribute the library
separately.  (Any comments?)  The problem is that (according to the FSF)
linking to a GPL library is not "using it" or "referring to it" it but
"creating a derived work".  Thus, none of my files that so much as
called a TDB function could be used in a non-GPL compatible project. 
(Until they were re-written to call a different database library.)

It should also be pointed out that this is a controversial point. 
Trolltech at one point took considerable trouble to add GNU readline
support to Ghostscript.  But at the last minute, the FSF informed them
that they consider a version of Ghostscript that is linkable (even
optionally) with readline to be "derived" from readline.  Since Alladin
releases Ghostscript under a license more restrictive than the GPL (and
then releases it under the GPL about a year later), if this theory were
true, there would be a problem.  Alladin thought this was idiotic and
mean-spirited, but wasn't willing to fight them in court over it. 
Alladin believed (as far as I recall) that linking Ghostscript to the
public interface of readline simply created a collection, not a derived

It is 'interesting' that one may call a GPL program from a shell script
without the shell script being considered a derived work, but
dynamically linking to a GPL library is said to create a derived work. 
Some people have trouble understanding the distinction.  ;-)

Steve Lagasek <vorlon at> wrote:
>I think you will find that the decision to license all of Samba under 
>the GPL and only under the GPL is a quite deliberate one.
>However, the fact that the TDB code is released under the GPL doesn't 
>mean that you can't release your code under the BSD license; that is, 
>since the revised BSD license is GPL-compatible, you can continue to 
>release all files that are copyright you under the BSD license, while 
>still distributing them together with the TDB code.  The /combination/ 
>of your BSD code and the GPL'ed TDB code can only be distributed under
>the terms of the GPL, because this is the only license that satisfies 
>the requirements of both; but someone would still be free to create a 
>derived work that used your code with no TDB code and enjoy all the 
>freedoms that are granted by the BSD license.
>I realize you would probably still prefer to be able to distribute the 
>entire work under the BSD license; I'm merely offering an alternative 
>because past experience suggests to me that it isn't going 
>to happen. :)

I believe you are completely correct.  Unfortunately, for my project,
the distinction seems to be moot and the alternative non-viable.  I am
not looking for a database library some optional function which can be
excluded at build time, such as interfacing to Samba.  I need something
to do core things like index the list of installed fonts, the list of
character sets, and the mapping between Unicode ranges and character
sets.  If my code were sprinkled with calls to tdb, then, while my naked
source code would still be BSD licensed, anything linked with it (and
indirectly with tdb) would 'magically' come under the GPL.

This would defeat one of the principal purposes of my project.  That
purpose is to provide example code for post-processing of PostScript and
generation of good-quality PostScript output.  It has been my experience
that most PostScript-generating programs do a terrible job.

I would like to see developers, both open and closed source, liberally
borrow from my code to improve their own.  They will be discouraged from
doing that if they first had to re-write large parts of it to replace

This is not hypothetical.  The code to convert TrueType fonts to Type 3
and Type 42 PostScript fonts has been incorporated into version 3.0 of
the Qt toolkit.

Obviously, this list is not a forum for debating the merits of the GPL
vs. the LGPL.  The question is, to what extent can I call tdb without my
code coming _for_all_practical_purposes_ under the GPL?  For example, if
I include a program that links to tdb for the purposes of adding drivers
to the drivers database or filling in information about print jobs, how
much of my project can only be distributed under the GPL?  What if I
include the source code to tdb in the tar file and link it to this

And, if you will forgive an off-topic question, does anyone know of a
database which is small, can tolerate concurrent access, and has a
BSD-compatible license?  Failing that, maybe the tdb authors know where
I can read about the theory of this kind of database so I can write my

More information about the samba-technical mailing list