* RE: Licensing of Guile code loaded by libguile.so
2024-06-13 13:56 ` Felix Lechner via Developers list for Guile, the GNU extensibility library
@ 2024-06-15 9:01 ` Maxime Devos
2024-06-15 9:06 ` Philip McGrath
1 sibling, 0 replies; 6+ messages in thread
From: Maxime Devos @ 2024-06-15 9:01 UTC (permalink / raw)
To: Felix Lechner, Dr. Arne Babenhauserheide,
Jonas Hahnfeld via Developers list for Guile,the GNU extensibility library
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Licensing of Guile code loaded by libguile.so
2024-06-13 13:56 ` Felix Lechner via Developers list for Guile, the GNU extensibility library
2024-06-15 9:01 ` Maxime Devos
@ 2024-06-15 9:06 ` Philip McGrath
2024-06-19 23:57 ` Felix Lechner via Developers list for Guile, the GNU extensibility library
1 sibling, 1 reply; 6+ messages in thread
From: Philip McGrath @ 2024-06-15 9:06 UTC (permalink / raw)
To: Felix Lechner, Dr. Arne Babenhauserheide,
Developers list for Guile, the GNU extensibility library
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
^ permalink raw reply [flat|nested] 6+ messages in thread