Licensing of Guile code loaded by libguile.so

Licensing of Guile code loaded by libguile.so

[Felix Lechner via Developers list for Guile, the GNU extensibility library]

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]

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..

May I publish my project under the GPL, or should I also choose the LGPL
like Guile?

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.

In other words, does libguile.so run code by calling the Guile
interpreter via an exec system call, or does the library run the Guile
code directly in the same, potentially proprietary, process?

Thanks!

Kind regards
Felix

P.S. I'm not subscribed to your list; please copy me on your replies.

[1] https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html

Re: Licensing of Guile code loaded by libguile.so

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Felix Lechner via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org> writes:
> 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]
>
> 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..
>
> May I publish my project under the GPL, or should I also choose the LGPL
> like Guile?

The rule of thumb is, if you want proprietary software to use your code,
you must choose LGPL.

> 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.

Since the license is LGPLv3 or later, and version 3 has a clearer
definition of the corresponding source: is there “intimate data
communication or control flow”?

See https://www.gnu.org/licenses/gpl-3.0 1. paragraph 4: Corresponding Source.

So I think your code would be part of the corresponding source of the
linked libguile, which would propagate the requirements of the GPL.

I’m not a lawyer, though, so better wait for the reply from FSF before
making a final decision.

> P.S. I'm not subscribed to your list; please copy me on your replies.
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Licensing of Guile code loaded by libguile.so

[Felix Lechner via Developers list for Guile, the GNU extensibility library]

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?

Kind regards
Felix

P.S. I'm not subscribed to your list; please copy me on your replies.

RE: Licensing of Guile code loaded by libguile.so

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]

(I haven’t figured out how to stop the autocorrupt of names of e-mail addresses yet – while Jonas Hahnfeld can read this, I don’t have them in mind.)

>> 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?

Let “L” be your LGPL library, “G” the Guile code under GPL and “P” the proprietary software.

AFAIK this hasn’t really been tested, but ...
IIUC, “L” can call “G” code just fine. But if “L” does this, then “P” can’t use “L” anymore, because “L” is in turn using GPL stuff (this could also be called “L is _effectively_ GPL”. I expect the same would hold if “L” is, say, Expat (AKA MIT though that’s ambiguous).

So, while AFAIK you can do this, it is pretty useless for the proprietary software “P”. As intended, otherwise you could just create LGPL wrappers – that’s also why I find the idea of “if you invoke GPL software as a separate process, then all is fine” too simplistic – invoking a new process isn’t all that different from invoking a procedure.

Conversely, there is the sort-of implication that linking proprietary and GPL software together would also be (legally) possible (but I know only of a single case where this true – almost attempts at this I have seen so far were pretty bogus).

An exception to this I have seen is the use of vDSO in Linux, where the kernel provides a shared library that userspace software links to (for some syscall things). (Not the best example since Linux has the syscall exception ...)

Another possible situation is where your LGPL software only conditionally uses GPL stuff. Then, if in some way the proprietary software tells the LGPL software to not do any of this GPL stuff, I don’t expect problems (except in the sense that proprietary software is always a problem in itself). Although, I recommend reading the LGPL and GPL license text closely to be sure, it has been a while since I read it.

> I am thinking specifically about the GNU Shepherd.

I don’t see any situation where proprietary software can call GNU Shepherd, whether directly or indirectly through a LGPL library, except for the proprietary software doing something basic like “herd start/stop/reload/whatever some-service”.

> 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..

Assuming this isn’t a money thing, a BSD-style “it’s not free unless non-free software can use it too” thing or for popularity. Or some other thing – in utilitarian terms, I don’t know your utility function, but I will try to make an argument of the form “you don’t actually want that because it is not good for the value function”, so the following argument might be non-applicable:

I think it would be simplest to not do this. With some rare exceptions, I haven’t seen much cases where adding the “L” to “GPL” appeared to lead to significant improvement that surpasses the cost of having more proprietary software. It’s not something I have carefully investigated, so take it with a full salt shaker.

Best regards,
Maxime Devos

[-- Attachment #2: Type: text/html, Size: 6878 bytes --]

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

Re: Licensing of Guile code loaded by libguile.so

[Felix Lechner via Developers list for Guile, the GNU extensibility library]

Hi Philip,

On Sat, Jun 15 2024, Philip McGrath wrote:

> Therefore, "the entire work, as a whole," would need to be under the
> GPL.

Thank you.  That's also the conclusion I came to from several different
angles.

For now, the work remains licensed under the GPL.  My work is
Guile-PAM. [1] It's kind of a big step, because one day Guile-PAM could
potentially strive to replace both Linux-PAM, which is licensed under
MIT/Expat and OpenPAM, which is licensed under BSD-3.

I effectively burden operating system distributors in that all programs
using Guile-PAM must be "compatible" with GPL, or rather be linkable
with a library released under the GPL. [2]

> if you really want to, you can still license part of the work that you
> write under the LGPL

That's what I did for now.  As a concession, the actual PAM module
(written in C) is currently available under the LGPL. [3] That's the
same license as libguile, which it calls.

I'm not sure it makes much of a difference for users and distributors,
however.  Maybe both parts of my project should be released under the
GPL.

Any further comment or advice would be welcome.

> 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.

I totally agree, but unfortunately PAM expects a shared object.

> 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.

I looked unsuccessfully for information online and would like to read
more about it, if you have time.  Thanks!

Kind regards
Felix

[1] https://codeberg.org/lechner/guile-pam
[2] https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
[3] https://codeberg.org/lechner/libpam-guile-c