(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
