What if Guile changed its license to be LGPL?

What if Guile changed its license to be LGPL?

[Marius Vollmer]

Guile currently has a license that consists of the GPL plus a special
exception that gives blanket permission to link Guile with non-free
software without putting restrictions on that non-free software.

This is different from the Lesser GPL, which would require the
non-free software to enable users of that software to modify Guile and
get the non-free software to use the modified Guile.  (This can be
simply done by linking to libguile dynamically, say.)

The special license of Guile means that we can't use other LGPLed
software for it without putting the whole of Guile under the LGPL,
effectively.  For example, we want to GMP for our bignum
implementation, and GMP is LGPL.

So, here comes the hypothetical questions: If we would change the
license of Guile to be the Lesser GPL, would you stop using it?
(Please reply only when your answer is "yes".)

What specifically would make you stop using it?  (I.e., "LGPL would
require me to distribute a link-kit, and I can't do that.")

Thanks!

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Per Bothner]

Marius Vollmer wrote:
> The special license of Guile means that we can't use other LGPLed
> software for it without putting the whole of Guile under the LGPL,
> effectively.

I don't believe that is the case.  There is no conflict between
the LGPL and the Guile GPL+exception license.

The real problem is that it makes it difficult to distribute a
a proprietary executable that includes a statically linked
copy of GMP.  In contrast, the existing Guile license allows
you to distribute a proprietary executable that includes a statically
linked copy of Guile.

For most people this is not an issue:  They can link against
a shared library version of libgmp.  (I see that Red Hat 7.3
comes with such a shared library.)  The main problem is for
people on embedded systems.  They are unlikely to be using
Guile, or if they use Guile, they are unlikely to want bignums.

So I don't think it's a real problem.  My suggestion:
(1) Keep the Guile license as is.
(2) Add a --with-gmp configure option.  It defaults to true if
it finds a shared library version of libgmp; false otherwise.
(3) If --with-gmp is "no", use floating-point numbers instead
of bignums.  (Actually, embedded systems might not want floating
point either, but that is a separate issue.)

You might (if you haven't already) ask RMS about modifying the GMP
license to GPL+exception, at least in the context of Guile.  (I would
also love to be able to use GMP for libgcj, the GCJ Java urn-time
library, when implementing java.lang.math.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Marius Vollmer]

Per Bothner <per@bothner.com> writes:

> Marius Vollmer wrote:
> > The special license of Guile means that we can't use other LGPLed
> > software for it without putting the whole of Guile under the LGPL,
> > effectively.
> 
> I don't believe that is the case.  There is no conflict between
> the LGPL and the Guile GPL+exception license.

No, there is no conflict, but unconditionally linking libguile to
libgmp would mean that all users of libguile would also have to obey
the license terms of libgmp.

We wouldn't need to change the license of Guile to the LGPL, but if
Guile's license would be effectively the LGPL, there would be little
point of keeping the current, 'non-standard' license.

> [...] For most people this is not an issue: They can link against a
> shared library version of libgmp.  (I see that Red Hat 7.3 comes
> with such a shared library.)  The main problem is for people on
> embedded systems.  They are unlikely to be using Guile, or if they
> use Guile, they are unlikely to want bignums.
> 
> So I don't think it's a real problem.  My suggestion:
> (1) Keep the Guile license as is.
> (2) Add a --with-gmp configure option.  It defaults to true if
> it finds a shared library version of libgmp; false otherwise.

I would like to make it fail when no libgmp can be found (shared or
non-shared) so that people don't accidentally build a inferior Guile
but take it for the real stuff and are disappointed.

> You might (if you haven't already) ask RMS about modifying the GMP
> license to GPL+exception, at least in the context of Guile.

I haven't asked, and I don't really like to go that route.  I
(personally) don't want to weaken the license of other peoples
software.

> (I would also love to be able to use GMP for libgcj, the GCJ Java
> run-time library, when implementing java.lang.math.)

What about creating a library that is reasonably compatible to GMP but
is simple minded and comes with a very unrestrictive license.  It's
sole purpose would be to make use of the permissive license of
libguile (and of libgcj, if I understand your intention right).

This will work, but it certainly feels quite strange to me to provide
a tool to eclipse GNU MP from within the GNU project itself.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Per Bothner]

Marius Vollmer wrote:
 > I haven't asked, and I don't really like to go that route.  I
 > (personally) don't want to weaken the license of other peoples
 > software.

That means you shoudl perhaps ask the actual author of GMP (Torbjörn
Granlund) *as well as* RMS.

More importantly, if this complicates Guile and possibly lessens
the "marketing power" of Guile, if may be in the FSF's interested
to work out some kind of exception for Guile.  They don't have to
change the license for GMP in general.  You can add some kind of
exception where as long as an Guile application does not use the
GMP C API directly, but only indirectly via Scheme code or other
public Guile APIs, then the application is still covered by the
Guile license, with exception.

Stallman (and Torbjörn) may be favorably inclined to such as
exception; as Guile maintainer I think you should at least bring up
the issue with RMS.

> What about creating a library that is reasonably compatible to GMP but
> is simple minded and comes with a very unrestrictive license.  It's
> sole purpose would be to make use of the permissive license of
> libguile (and of libgcj, if I understand your intention right).

Somebody wrote such a library.  Some years ago there were problems
with some use of GMP for encryption.  I don't remember the details,
but part of the problem was that since they were linking explicitly
against the GMP API, the FSF argued they were effectivly linking
with the GMP, even if they were separate.  That was resolved by
somebody writing an API-compatible very of GMP.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[tomas]

On Tue, Jun 04, 2002 at 02:55:41PM -0700, Per Bothner wrote:

[...]

> More importantly, if this complicates Guile and possibly lessens
> the "marketing power" of Guile, if may be in the FSF's interested
> to work out some kind of exception for Guile.  They don't have to
> change the license for GMP in general.  You can add some kind of
> exception where as long as an Guile application does not use the
> GMP C API directly, but only indirectly via Scheme code or other
> public Guile APIs, then the application is still covered by the
> Guile license, with exception.

IMHO: Please, don't. Complicated licenses also lessen the `marketing
power' of a product. I'd tend to Marius' approach of moving towards
LGPL and away from Guile exception, as long as there are no issues
with current users/uses. And if there are, I think it'd be worthwile
to try to resolve them.

[answering `yes' although Marius said only to answer in `no'
case, but I think the point of `license simplicity' is very
important: we have more and more small variations of open-ish
licenses these days]

Regards
-- tomas

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Marius Vollmer]

Per Bothner <per@bothner.com> writes:

[ extending the license exception of Guile to GMP ]
> Stallman (and Torbjörn) may be favorably inclined to such as
> exception; as Guile maintainer I think you should at least bring up
> the issue with RMS.

Yes, I will.  I'll wait a bit to see whether any other arguments
surface in favor of weakening the license of GMP.

> > What about creating a library that is reasonably compatible to GMP but
> > is simple minded and comes with a very unrestrictive license.  It's
> > sole purpose would be to make use of the permissive license of
> > libguile (and of libgcj, if I understand your intention right).
> 
> Somebody wrote such a library.  Some years ago there were problems
> with some use of GMP for encryption.  I don't remember the details,
> but part of the problem was that since they were linking explicitly
> against the GMP API, the FSF argued they were effectivly linking
> with the GMP, even if they were separate.  That was resolved by
> somebody writing an API-compatible very of GMP.

Yes, I thought I remembered something like that but couldn't
immediately find more details.  If such a library exists, we are
settled and can use GMP exclusively, no?  Anyone wanting to invoke the
exception in Guile's license can use the unrestricted substitute-GMP,
right?

Do you know more about this library?  Where could I find it?

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Per Bothner]

Marius Vollmer wrote:
>>Somebody wrote such a library.  Some years ago there were problems
>>with some use of GMP for encryption.  I don't remember the details,
>>but part of the problem was that since they were linking explicitly
>>against the GMP API, the FSF argued they were effectivly linking
>>with the GMP, even if they were separate.  That was resolved by
>>somebody writing an API-compatible very of GMP.
> 
> Yes, I thought I remembered something like that but couldn't
> immediately find more details.  If such a library exists, we are
> settled and can use GMP exclusively, no?  Anyone wanting to invoke the
> exception in Guile's license can use the unrestricted substitute-GMP,
> right?

However, the alternative implementation is probably not something
the FSF wants to promote or even mention.

Again, I suggest you check with RMS and Torbjörn to see what their
positions are on the issue.

> Do you know more about this library?  Where could I find it?

I don't remember.  I'm sure Torbjörn (tege@swox.com) remembers.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Marius Vollmer]

Per Bothner <per@bothner.com> writes:

> > If such a library exists, we are settled and can use GMP
> > exclusively, no?  Anyone wanting to invoke the exception in
> > Guile's license can use the unrestricted substitute-GMP, right?
> 
> However, the alternative implementation is probably not something
> the FSF wants to promote or even mention.

Heh, but they would consider letting anyone use GMP indirectly without
honoring the LGPL?

> Again, I suggest you check with RMS and Torbjörn to see what their
> positions are on the issue.

Yes, will do so tomorrow.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Panagiotis Vossos]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Per Bothner <per@bothner.com> writes:
> 
> [ extending the license exception of Guile to GMP ]
> > Stallman (and Torbjörn) may be favorably inclined to such as
> > exception; as Guile maintainer I think you should at least bring up
> > the issue with RMS.
> 
> Yes, I will.  I'll wait a bit to see whether any other arguments
> surface in favor of weakening the license of GMP.

I feel that adding an exception for guile in the GMP license is a bad
idea.  What if another scheme implementation with a free, but
incompatible license wants to use GMP?  The FSF would treat guile
differently and that would be unfair to all other implementors.

I think that the other suggestions are way better.

Just my 0.02 euros,
panagiotis.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Marius Vollmer]

Per Bothner <per@bothner.com> writes:

> > What about creating a library that is reasonably compatible to GMP but
> > is simple minded and comes with a very unrestrictive license.  It's
> > sole purpose would be to make use of the permissive license of
> > libguile (and of libgcj, if I understand your intention right).
> 
> Somebody wrote such a library.

Ok, I found it.  It's called fgmp and for example available from

    http://www-inst.eecs.berkeley.edu/~scheme/source/stk/Mp/fgmp-1.0b5/

We could include it in guile-core and use it when the user doesn't
want the LGPLed GMP.


Soooo, that's it, right?  Given that fgmp is complete enough (but Stk
uses it, so it should be), we don't need to do anything special
license wise, right?

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> What about creating a library that is reasonably compatible to GMP but
> is simple minded and comes with a very unrestrictive license.  It's
> sole purpose would be to make use of the permissive license of
> libguile (and of libgcj, if I understand your intention right).

Sorry, the words doesn't sense.  Let me try again:

What about creating a library that is reasonably compatible to GMP but
is simple minded and comes with a very unrestrictive license.  Its
sole purpose would be to enable the users of Guile to make use of the
permissive license of libguile by linking libguile to the
ersatz-libgmp.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Guile currently has a license [...] If we would change the
    Marius> license of Guile to be the Lesser GPL, would you stop
    Marius> using it?

I think this whole discussion is barking up the wrong tree.

We had a similar problem before with readline -- and solved it -- and
no doubt we will have similar problems in future with other packages
whose licences may be subtly incompatible with Guile's.

The solution is to arrange things so that it becomes a runtime problem
rather than a distribution problem.

In fact, "problem" is too negative.  I'd say this is an opportunity to
get a number of things right:

- a consistent approach to factoring non-core functionality out of
  core libguile

- a consistent approach to linking in such optional functionality and
  handling any runtime licence implications that result

- a consistent approach to coping with the non-existence of optical
  functionality

- consistent usage of `features' and/or `cond-expand' to permit
  programs to discover what optional functionality is present.

My guess is that bignums are non-core for the majority of Scheme
applications, so I think it would be acceptable, and would improve the
core libguile code, to remove Guile's homebaked bignum code and rely
only on GMP -- surely a "bugridden, poorly specified implementation of
half of GMP" is just as bad as a "bugridden, poorly specified
implementation of half of Common Lisp" :-)

Hoping this helps ...

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
>     Marius> Guile currently has a license [...] If we would change the
>     Marius> license of Guile to be the Lesser GPL, would you stop
>     Marius> using it?
> 
> I think this whole discussion is barking up the wrong tree.
>
> We had a similar problem before with readline -- and solved it -- and
> no doubt we will have similar problems in future with other packages
> whose licences may be subtly incompatible with Guile's.
> 
> The solution is to arrange things so that it becomes a runtime problem
> rather than a distribution problem.

That is one solution, but not the only one.  It's also not the best
for all possible variations of the 'problem'.

Making it a compile-time problem would also work, i.e., fixing the
license of libguile at configure time, and I am now convinced that the
legal consequences are tolerable for people who want the weak license.

A compile-time configuration switch is mostly inferior to a run-time
switch, agreed.  But I would like to keep the possibility of deciding
between the two based on technical reasons, not on legal ones.  For
example, removing bignums from Guile but having the possibility to
re-add them at run-time via GOOPS would be elegant, but maybe it would
simply be too slow.

In my view, bignums are very essential to Guile, on par with proper
tail-call handling, say, and they deserve to be deeply integrated.
(They also deserve to be present even without GMP...)

Other issues have other parameters.  The readline library does not
need to be deeply integrated into Guile (IMO), and its license is GPL
instead of LGPL.  This changes enough, I think, to choose the run-time
switch option for libreadline.

Back to GMP, possible solution would also be to change the license of
GMP, or the license of Guile, so that the two would be equal.  This
thread was meant to explore the possibility of changing the license of
Guile, and at the same time produce arguments for changing the license
of GMP.

You say we shouldn't bother since we can 'just' make this a run-time
issue.  I think we should explore a license change anyway, and I also
think that shifting the problem to run-time (and thereby out of the
licenses' reach) would not be really satisfactory.

> In fact, "problem" is too negative.  I'd say this is an opportunity to
> get a number of things right:

That opportunity still exists, even if we find a different solution
for GMP. ;-)

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 06 Jun 2002 00:45:22 +0200

   But I would like to keep the possibility of deciding
   between the two based on technical reasons, not on legal ones.

that is not a proper stance when dealing w/ legal issues.  (if i were a
lawyer raised by even the gentlest of wolves i would be salivating by
now.)

in any case, run-time solution for the more constrained external library
(readline) works w/ the less constrained one.  no worries.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 05 Jun 2002 16:45:47 +0100

   - a consistent approach to factoring non-core functionality out of
     core libguile

   - a consistent approach to linking in such optional functionality and
     handling any runtime licence implications that result

   - a consistent approach to coping with the non-existence of optical
     functionality

all these are part of build methodology.  see below for 1.4.x ROADMAP
(under $w/build/dist-files locally) -- critique welcome.

   - consistent usage of `features' and/or `cond-expand' to permit
     programs to discover what optional functionality is present.

how do these interact w/ each other?  are there weird corner cases?

thi


_________________________________________________________
This file explains the general direction of Guile.



1.4.x Goals

	- No breakage for current usage.
	- Build methodology evolved into architecture/implementation.
	- Build methodology documented and exported.
	- Scheme compilation to native code supported by build methodology.

	By the end of 1.4.x, we want to be able to use guile maximally
	from a "scheme world" point of view, reaching out from that
	centrality to the hardware and everything in between, and do so
	w/o forgetting how we did things before.

	The key task here is to understand what the hell we're doing.
	Then we put a name on it, put in place general machinery to
	handle that case and any historic cases, and lastly re-work
	these methodologies into scripts w/ parameters specific to Guile
	and documentation explaining how to specialize the scripts.
	Scripts then go under "guile-tools".


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: What if Guile changed its license to be LGPL?

[Dale P. Smith]

On 04 Jun 2002 21:36:31 +0200
Marius Vollmer <mvo@zagadka.ping.de> wrote:

> 
> So, here comes the hypothetical questions: If we would change the
> license of Guile to be the Lesser GPL, would you stop using it?
> (Please reply only when your answer is "yes".)
> 
> What specifically would make you stop using it?  (I.e., "LGPL would
> require me to distribute a link-kit, and I can't do that.")


The (soon to be released) mod_guile will be using the Guile license
because (so I'm told) that the Apache license and the GPL are
incompatible.  I'm not sure if the LGPL will be able to serve.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user