Re: Licensing of Guile code loaded by libguile.so

[Philip McGrath]

Hi Felix,

On 6/13/24 09:56, Felix Lechner wrote:
> Hi Arne,
>
> On Thu, Jun 13 2024, Arne Babenhauserheide wrote:
>
> > The rule of thumb is, if you want proprietary software to use your
> > code, you must choose LGPL.
>
> > So I think your code would be part of the corresponding source of the
> > linked libguile, which would propagate the requirements of the GPL.
>
> Okay, but does that also mean my code--when licensed under the LGPL and
> loaded by a proprietary program via libguile.so---may not call any Guile
> code released under the GPL?
>
> I am thinking specifically about the GNU Shepherd.
>
> For context, my software aims to replace a common system facility.  The
> current license is GPL, although the C piece that starts Guile via
> libguile.so is available under the LGPL.  Likewise releasing the
> remainder under the LGPL, however, logically implies that no interpreted
> GPL code may be called by my software.  Is that right?

(As typical, I am not a lawyer, etc.)

Scheme code that uses e.g. `(use-modules (shepherd comm))` probably "is 
specifically designed to require" the Shepherd, "such as by intimate 
data communication or control flow." Therefore, "the entire work, as a 
whole," would need to be under the GPL.

However, if you really want to, you can still license part of the work 
that you write under the LGPL or any other GPL-compatible license. That 
would give people the permission later to modify the LGPL code you 
wrote: if they create a modified version that no longer uses anything 
covered by the GPL, the result would only be covered by the LGPL. (You 
might decide that this small amount of extra permissiveness is not worth 
making the licensing situation more complex, though!)


On 6/13/24 01:49, Felix Lechner wrote:
> Hi,
>
> I would like to release some code under the GPL.  libguile.so calls it
> from C.  The setup is similar to the code in the Tortoise tutorial. [1]
>
> ...
>
> [1] https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html
>

On 6/13/24 09:56, Felix Lechner wrote:
> For context, my software aims to replace a common system facility. The
> current license is GPL, although the C piece that starts Guile via
> libguile.so is available under the LGPL.

It's not related to licensing, but, in most cases, I would not recommend 
designing your program like this. Instead of writing a C program that 
uses libguile.so, you can write a Guile program that accesses 
C-implemented functionality through the Foreign Function Interface. If 
necessary, you can write new C code designed to be accessed via the FFI; 
you can even write Foreign Extensions that use the Guile C API. Code 
structured as a Guile program that uses the FFI is often more flexible 
than a C program that embeds Guile. Usually it also requires writing 
less new C code, which is good for all the reasons we'd rather write 
Scheme than C.


On 6/13/24 01:49, Felix Lechner wrote:
>
> Guile is licensed under the LGPL, so it is possible for proprietary
> programs to use libguile.so.  I would now like to ensure that those
> proprietary programs may also legally run my code..
>
> ...
>
> I am in contact with the licensing folks at FSF, but hope to collect
> some input here, as well.
> The technical question is, I think, whether libguile executes Guile code
> in a manner that is considered being "run" or being "linked."  The
> answer could potentially be different for compiled or uncompiled code.

As I wrote above, your concrete situation sounds reasonably clear 
(though IANAL), but there do exist subtle cases where it is unclear how 
exactly the LGPL's linking requirements should apply to Scheme, 
especially with the combination of macros and modules. To provide more 
clarity, Racket was relicensed away from the LGPL in 2019 (after almost 
three years of work) with the help of the Software Freedom Conservancy.

I'm much more familiar with Racket's internals than Guile's, but I think 
some of the factors that made the LGPL complex for Racket are less 
applicable to Guile: for example, I think Guile currently compiles code 
in a way that links less intimately to imported modules than Racket's 
compiler does. Until recently, contributions to Guile required copyright 
assignment to the FSF, which was thus in a very strong position to 
clarify if necessary by granting additional permissions, relicensing, or 
even publishing a new version of the LGPL. Indeed, `info '(guile)Guile 
License'` currently says:

> Scheme level code written to be run by Guile (but not derived from
> Guile itself) is not restricted in any way, and may be published on any
> terms.  We encourage authors to publish on Free terms.

If it would be useful to anyone, I'd be happy to write more about the 
ways in which applying the LGPL to Racket seemed problematic. To be 
clear, I had no involvement in the decision-making other than agreeing 
to relicense my own contributions, but, from my perspective as a free 
software and copyleft advocate, I think the concerns were legitimate 
(though not necessarily insurmountable).

Philip