GnuCOBOL 3.2 RC2 (11Feb2023) binaries for Windows

[Arnold Trembley]

With many thanks to Chuck Haatvedt and Simon Sobisch, you can now build
GnuCOBOL Release Candidate 2 for Windows in 32-bit and 64-bit versions
using MSYS2. These builds include gmplib 6.2.1, PDCursesMod 4.3.5,
Berkeley DataBase 18.1.40 (for ISAM), and GCSORT.exe. MSYS2 uses GCC
12.2.0 as the embedded C Compiler. These binaries also include XML
parsing, cJSON, code coverage testing, and debugging support. You can
download a binary compressed with 7-Zip and rename the file extension
from "7z" to "exe". Then you can run it as a self-installing archive.
See the STARTHERE.txt file, or open a cmd.exe window in the install
folder, and run "set_env.cmd" to set the environment variables. You can
also download the MSYS2-Build-Kit.7z archive which contains the Build
Guide in LibreOffice DOCX format and in PDF format.

https://www.arnoldtrembley.com/GC32M-BDB-x64-rc2-rename-7z-to-exe.7z

https://www.arnoldtrembley.com/GC32M-BDB-x32-rc2-rename-7z-to-exe.7z

https://www.arnoldtrembley.com/MSYS2-Build-Kit-v05.7z

https://sourceforge.net/p/gnucobol/discussion/help/thread/446042b769/


Kind regards,


--
https://www.arnoldtrembley.com/

[Arne Vajhøj]

I wonder if all GnuCOBOL users actually understand the
implications from BDB being under AGPL (while VBISAM being
under LGPL).

It is mentioned in the dist DEPENDENCIES.txt and in
the FAQ item 1.3 about licenses, but sometimes people
don't read that stuff.

And speaking of BDB. Has anyone considered switching
from latest Oracle BDB (under AGPL) to the Bloomberg
fork of the original Sleepycat code (under BSD like licenses)?

I think most are fine with GnuCOBOL itself being
under GPL, but the runtime is a different matter -
there is a reason why LGPL and GPL with linking
exception was invented.

Arne

[Arnold Trembley]

On 2/11/2023 9:57 AM, Arne Vajhøj wrote:
> On 2/11/2023 4:00 AM, Arnold Trembley wrote:

>> (snip)

>
> I wonder if all GnuCOBOL users actually understand the
> implications from BDB being under AGPL (while VBISAM being
> under LGPL).
>
> It is mentioned in the dist DEPENDENCIES.txt and in
> the FAQ item 1.3 about licenses, but sometimes people
> don't read that stuff.
>
> And speaking of BDB. Has anyone considered switching
> from latest Oracle BDB (under AGPL) to the Bloomberg
> fork of the original Sleepycat code (under BSD like licenses)?
>
> I think most are fine with GnuCOBOL itself being
> under GPL, but the runtime is a different matter -
> there is a reason why LGPL and GPL with linking
> exception was invented.
>
> Arne
>
>

This is an issue that has been discussed in the Sourceforge GnuCOBOL
forums. After Oracle bought BDB, any later releases have a more
restrictive license that makes it difficult to build commercial programs
that include Oracle BDB. The distributor must either provide full
source code (including GnuCOBOL programs) or else pay a license fee to
Oracle to keep their COBOL programs proprietary. At least that is my
understanding, but I am not a lawyer. The GnuCOBOL developers would
prefer that all components be compatible with GPL and LGPL licensing.

I haven't tried building GnuCOBOL with BDB (published 2013-09-09), but
it is something I will look into.

There is an interesting Wikipedia article on Berkeley Database:
https://en.wikipedia.org/wiki/Berkeley_DB

The GnuCOBOL developers are looking into replacing BDB with VBISAM,
which uses version 3 of GPL and LGPL licenses. But VBISAM is currently
not as robust as BDB and does not currently appear to support record
locking.

Current GnuCOBOL does have improved support for EXTFH (External File
Handlers), so it is possible to use alternate software for ISAM support.