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
Description: PGP signature
