Re: [Feature Request/Postmortem] Adding a way to compile GNU Guile scripts to a standalone executable

"Dr. Arne Babenhauserheide" <[email protected]> Wed, 13 Aug 2025 08:16:38 +0200
Newsgroups	gmane.lisp.guile.devel
Message-ID	<[email protected]>
Matt Wette <[email protected]> writes:

> Two issues:
> 1) Guile is LPGL so I don't see how one can distribute standalone
> executables w/o distributing
>     all the means to re-build.  For example, including
> ice-9/boot-9.go.   Do people want to do this?

AFAIK distributing the LGPL code alongside your code is legal as long as
you did not modify Guile itself (so the upstream repo is the complete
source) and either provide the code of Guile from your website or
include a written offer (valid for 3 years) to provide the code. The
latter should be trivial to realize.

You then also have to allow users to modify your program for their own
use (so they can replace Guile with a modified version -- no preventing
of modification of the LGPL part through the backdoor) and provide the
build tooling so they can get that working.

If you did modify Guile, you have to provide the modified sourcecode in
the same location as the proglem or -- again -- a written offer for
that. I’d always opt to just providing the download, otherwise if too
many people ask you could get overwhelmed by that.

Qt suggests dynamic linking:
https://www.qt.io/licensing/open-source-lgpl-obligations

And appimage seems to be compatible with that (it basically ships the
full filesystem -- similar to docker images that are also not static
linking, but just a collection in which users can replace Guile).

This has been solved for Qt, which is used a lot in commercial projects,
so you can use the same approach for Guile.

There’s also an entry in the FAQ:
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

> Does the LGPL have different requirements for statically vs
> dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
> 
>     For the purpose of complying with the LGPL (any extant version:
>     v2, v2.1 or v3):
> 
>         (1) If you statically link against an LGPLed library, you must
>         also provide your application in an object (not necessarily
>         source) format, so that a user has the opportunity to modify
>         the library and relink the application.
> 
>         (2) If you dynamically link against an LGPLed library already
>         present on the user's computer, you need not convey the
>         library's source. On the other hand, if you yourself convey
>         the executable LGPLed library along with your application,
>         whether linked with statically or dynamically, you must also
>         convey the library's sources, in one of the ways for which the
>         LGPL provides.

I’m not sure how cross-module inlining would play into this, because
then parts of the LGPL code might not be modifyable by replacing the
Guile *.go files.
https://wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile

So build your own *.go files with:
guild compile -Ono-cross-module-inlining

(see guild comple -Ohelp for the list of optimizations)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
signature.asc (application/pgp-signature, 1.1 KB)