[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Re: Deprecating db1

From: Keisuke Nishida
Subject: Re: [open-cobol-list] Re: Deprecating db1
Date: Tue Apr 5 11:22:32 2005
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hi Roger,

The reason I made DB/DB1 support optional is because their
licenses add more restrictions over LGPL.  You MUST follow
the Berkeley DB license (or original BSD license if you use
libdb1) when you enabled --with-db1 or --with-db.  By making
these flags optional, I wanted the user of open-cobol to know
what they mean exactly.

Roger While wrote:
Bernard, I do not think the second part is true.
Here is an excerpt from the product licensing :
Do I have to pay for a Berkeley DB license to use it in my Perl or Python scripts?
No, you may use the Berkeley DB open source license at no cost.
The Berkeley DB open source license requires that software that uses
Berkeley DB be freely redistributable. In the case of Perl or Python,
that software is Perl or Python, and not your scripts. Any scripts you write
are your property, including scripts that make use of Berkeley DB.
None of the Perl, Python or Berkeley DB licenses place any restrictions
on what you may do with them.

COBOL is not a scripting language.  cobc compiles your
COBOL code into a binary, which will eventually be
linked with libcob and libdb.  In this case, your
software uses Berkeley DB, I guess.

Which is a very clear statement.
So, we just have to make sure that OC license is OK.
At the moment the library is under LGPL.
Keisuke, do we have any problem relaxing it to GPL ?

If libcob was GPL, you would have to distribute your
COBOL programs under GPL.  Is that what you want?



One big problem I see with deprecating DB1,
is the License issue:
If you use anything beyond 1.85, you have to follow
the GPL license pour DB, which means you have to
provide the OC RTL under GPL (which may be fine),
BUT you ALSO have to provide anything which uses the
OC RTL under GPL, in particular your COBOL code,
which precludes to use OC for any COBOL software
you would like to keep the source non public.
And in this case, the potential for OC would be much

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
open-cobol-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]