Subject: Re: Do I owe you money?
Date: Sun, 19 Mar 2000 20:23:35 -0500

Keith Bostic wrote:
> > From:
> >
> > But there is a simple solution if this is a problem.  What you can do
> > build a stand alone open source application on top of the open source
> > library, and then connect to that.  For instance the application can be
> > a server with a well-defined API that you communicate to with a socket.
> It's always risky to make a technical end-run around the license wording.
> If it's clear that the copyright holder intends the software not be used
> commercially, it's best to abide by their wishes.  If you've
> your way around their copyright, a court can still decide to nail you.
> Besides, even if you're successful, you've pissed them off, not a good
> idea if their software is integral to your product, and their next
> will almost certainly block the loophole.

I agree that it is morally better to use software as it is intended,
but I do not see a good block for the above work-around.  For instance
suppose that you write a nice dbm-style database, someone incorporates
that into a popular email server, and then Joe Bloe e-commerce wannabe
uses it to send emails as part of their order confirmation system.  In
fact, as we both know, this is not a very hypothetical example at all!
(Others may not realize that Keith works for Sleepycat, which produces
the Berkeley DB database.  Berkeley DB has found its way into many
applications, including Sendmail.  And many e-commerce systems do use
Sendmail for order confirmation.)

Now is there reasonably anything that you can do to allow the kinds of
uses that you want of your excellent software, while blocking these
slimy e-commerce people?

> Also, some licenses explicitly disallow this kind of end-run, with phrases
> like "uses the software" rather than "links to the software".

True.  And I hope that people developing applications for public
servers (eg websites) are careful to not use such software!  For
instance if I used your dbm in a search engine, and then Apple added
my search engine to Sherlock, someone could get into trouble and it
will probably not be Apple...

Also the workaround may not be much of a workaround.  Taking again
your Berkeley DB (and yes, I do need to get back to that documentation
project) as we discussed* a CGI script that needed to use the various
transactional features you have would be very ill-advised to link to
the library directly, but instead should go through a dedicated RPC
server.  So even for an apparently simple library, a special-purpose
server may make technical sense and be of independent interest.


* This is from a long private conversation some months ago.  The
problem is that CGI programs are run frequently and uncontrollably.
In the event of the sorts of failure (eg disk) that make transactional
features useful, various checks must be done and if necessary repairs
to the database from your logs.  Some of this must be done in a
single-threaded manner.  (For instance it would be bad if a new
instance tried to connect while you were recovering data.)  The only
reasonable way to do this with CGI programs is to have the CGI programs
connect to a dedicated server, and have the server do the necessary
checks and repair if needed when it starts.