Roger,
The short answer to your question is, we'd normally consider the
use you outline below to require a proprietary license for Berkeley
DB. If a third party writes an application that links the COBOL
ISAM library, then that app is using Berkeley DB; it would have
to be available in open source form, or would need a paid
proprietary license.
However, there is not much business advantage to Sleepycat in
requiring that this specific case adhere to the terms of our
public license. The amount of money we'd make from users building
COBOL ISAM apps would be small. Most likely, we'd simply drive
people away from our software.
As a result, Sleepycat is willing to permit use of these COBOL
libraries, including Berkeley DB, in proprietary or open source
apps at no charge. We're able to write you a variance letter
that makes that explicit if you like.
Let me know.
mike
> -----Original Message-----
> From: Roger While [mailto:address@hidden
> Sent: Wednesday, April 27, 2005 11:23 PM
> To: Michael A. Olson
> Subject: Re: COBOL libraries
>
> Hi Mike,
> Thanks for the prompt reply.
> COBOL has an ISAM syntax and a SORT verb.
> The open source COBOL libraries therefore
> use DB as an ISAM handler. (Nothing more, nothing less)
>
> During the normal "configure/make/make install" of the
> open source COBOL projects, the (shared) library
> ("lib<whatevercob>.so") would be linked against (shared) Berkeley DB
> ( "-ldb" ).
> (A note here, both projects are quite capable of working with Berkeley
> DB 1.85 - "-ldb1" - which of course does not have licensing issues;
> however; there are known deficiencies in 1.85).
>
> User COBOL programs are passed through the COBOL compiler(s).
> One project generates assembler code, one project generates "C" code.
> The COBOL compiler then compiles (as,gcc) the generated code
> and links it
> ( with "-l<whatevercob>" )
> This is done typically such (not using the actual compiler names) :
> cobcompiler MYPROGRAM.CBL
> This would produce an executable "MYPROGRAM".
>
> Note this is only one variation. There is the possibility to
> compile the COBOL program as a module (eg. "MYPROGRAM.so")
> whereby final linking does not take place. Of course in this
> case there still
> has to be a "driver" program that you execute. One of the
> projects does supply
> a driver program. In this case I would assume that there is
> no licensing issue as
> the COBOL programs are freestanding shared objects with only
> references to
> the COBOL libararies. Typically this looks like this (not
> using actual names) :
> cobcompiler -module PROG1.CBL PROG2.CBL ...
> This produces PROG1.so, PROG2.so, ...
> Run it with :
> runcobol PROG1
>
> I hope this clarifies the situation.
>
> Thanks for your help.
>
> Regards
>
> Roger While
>
>
> At 06:49 27.04.2005 -0700, you wrote:
>
>
> Roger,
>
> You asked:
>
> > Over at sourceforge.net, there
> > are a couple of projects (specifically COBOL compilers) that
> optionally
> > use Berkeley DB. These projects are fully GPL/LGPL.
> These compilers
> > produce executable code from COBOL source. The
> executable code does
> NOT
> > contain any reference to Berkeley DB. The executable
> code links
> against
> > the respective COBOL library. It is this COBOL
> library that has been
> > pre-linked with Berkeley DB. What is the situation
> as regards my
> COBOL
> > source code ? I would assume this is similar to the
> statement made as
>
> > regarding Perl.
>
> This isn't the same as the situation with Perl; in the
> case of Perl,
> there
> is an open source interpreter that executes scripts.
> The COBOL compiler
> emits machine code, which is eventually linked into an
> executable that
> includes Berkeley DB.
>
> However, this may be the equivalent to the use of
> Berkeley DB in glibc,
> which does qualify for use under the open source license.
>
> Can you tell me more about the libraries that use
> Berkeley DB? What
> do they do, and how do they use the database code?
>
> mike
>
>