The Guile license and the use of LGPL libs (like GMP).

The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

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

>> I haven't checked yet, but can we use GMP's IO routines?
>
> I don't know, I haven't looked...

After posting this question, I ended up in a good discussion with Greg
Troxel about using GMP and the resultant licensing issues.  Now it may
be that the two of us are misunderstanding things, but it looks like
if we migrate to require GMP then we may be changing the licensing
requirements for apps that use Guile.  In particular, any app that
wants to link against Guile will have to respect the provisions of the
LGPL which is at least a bit more restrictive than Guile's license.  I
think Greg put the possible issues fairly clearly:

> I'm not sure how I feel personally.  It has been guile project
> policy that guile has the guile exception in order to encourage use
> of guile absolutely everywhere.  Meeting LGPL terms isn't
> necessarily hard, but it requires thought and possibly legal
> department review, whereas the guile exception is easier to read and
> get on with life.

and then in response to a question I had about whether or not dynamic
linking avoided the problem (at least for apps that didn't need to
-static link):

> Dynamic linking is not entirely sufficient to comply with LGPL;
> rights to modify for own use and reverse engineer to debug that use
> must also be granted (see section 6 of LGPL).  It may be that given
> where guile is, and perl/python/tcl, that this is really not
> important strategically to guile and the FSF as a whole.  But I
> maintain that departing from the guile exception is a substantial
> philosophical shift.  Only free software weenies seem to use guile
> as it is, so a change probably wouldn't hurt much.  And I only write
> code mostly on platforms with shlibs, but what about palmos?  What
> if cisco wanted to put guile into IOS?  LGPL compliance would not
> perhaps be intellectually problematic, but it would be a lot of
> work, so they wouldn't want to do this.

If the analysis is correct, then it seems like we have a few choices:

  1) Use (and require) GMP anyway and expect people to accomodate the
     licensing changes.

  2) Use GMP, but have a configure switch that allows you to omit it,
     either with fallback non-GMP bignum support, or perhaps no
     bignums at all.

  3) Ask the relevant parties whether or not they might be willing to
     extend the guile exception to GMP, i.e. add a special Guile
     clause to the GMP license.

  4) Abandon GMP and continue to do things ourselves.

Thoughts?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Greg Troxel]

  1) Use (and require) GMP anyway and expect people to accomodate the
     licensing changes.

This is a lose; it makes guile harder to use in proprietary software,
and that doesn't serve the project's goals now.  For example, I put
guile into gated, and gated's licensing is painful enough as is
without having to figure out if it is really LGPL compatible.

  2) Use GMP, but have a configure switch that allows you to omit it,
     either with fallback non-GMP bignum support, or perhaps no
     bignums at all.

This is reasonable.  I'd fall back to no bignum support, so that the
code doesn't have to be maintained.  I suspect people in embedded
environments (the target audience for whom LGPL is problematic) don't
care about bignums.  (I've never particularly cared in the places I've
embedded guile (a home-grown emulator and gated), because the
underlying programs don't really support them, so this strategy would
not have actually caused me any grief.)

  3) Ask the relevant parties whether or not they might be willing to
     extend the guile exception to GMP, i.e. add a special Guile
     clause to the GMP license.

I'd ask, and see what happens - I can imagine people saying no, but
not reasonably getting really upset at being asked.  The exception
could apply to GMP as used by guile, and not extend to using the GMP
api directly in derived works.  Something like the following, heavily
ripped off from the guile exception:

 * As a special exception, the Free Software Foundation gives permission
 * for additional uses of the text contained in its release of GMP.
 *
 * The exception is that, if you link the GMP library with other files
 * to produce an executable solely because GMP is required for GUILE,
 * and the resulting work does not call any GMP routines except
 * indirectly as a result of using GUILE, this does not by itself
 * cause the resulting executable to be covered by the GNU General
 * Public License.  Your use of that executable is in no way
 * restricted on account of linking the GMP and GUILE library code
 * into it.
 * 
 * This exception does not however invalidate any other reasons why
 * the executable file might be covered by the GNU General Public License.
 *
 * This exception applies only to the code released by the Free
 * Software Foundation under the name GMP when used as a component of
 * GUILE.  If you copy code from other Free Software Foundation
 * releases into a copy of GMP, as the General Public License permits,
 * the exception does not apply to the code that you add in this way.
 * To avoid misleading anyone as to the status of such modified files,
 * you must delete this exception notice from them.
 *
 * If you write modifications of your own for GMP, it is your choice
 * whether to permit this exception to apply to your modifications.
 * If you do not wish that, delete this exception notice.  */

  4) Abandon GMP and continue to do things ourselves.

This is a lose, too - it seems like wasted effort to maintain multiple
copies of similar code, and it really seems the GMP code is better.

        Greg Troxel <gdt@ir.bbn.com>

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Rob Browning wrote:
> > Dynamic linking is not entirely sufficient to comply with LGPL;
> > rights to modify for own use and reverse engineer to debug that use
> > must also be granted [[...]].  But I
> > maintain that departing from the guile exception is a substantial
> > philosophical shift.  Only free software weenies seem to use guile
> > as it is, so a change probably wouldn't hurt much.

I use guile.  My stuff *is* used in commercial environments
that is hostile to LGPL.  If you change and leave me with no
migration path, I'll wind up locked into a frozen version.
I suppose I could change to a Perl extension engine, but
that's real work....

> If the analysis is correct, then it seems like we have a few choices:
> 
>   1) Use (and require) GMP anyway and expect people to accomodate the
>      licensing changes.

No, please.

>   2) Use GMP, but have a configure switch that allows you to omit it,
>      either with fallback non-GMP bignum support, or perhaps no
>      bignums at all.

If this bypasses the licensing issue, great.

>   3) Ask the relevant parties whether or not they might be willing to
>      extend the guile exception to GMP, i.e. add a special Guile
>      clause to the GMP license.

Murky.  Probably legally okay, but businesses want to focus on
business and not wrestle with murky issues.

>   4) Abandon GMP and continue to do things ourselves.

Better than #1 or #3.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

Bruce Korb <bkorb@pacbell.net> writes:

>>   2) Use GMP, but have a configure switch that allows you to omit it,
>>      either with fallback non-GMP bignum support, or perhaps no
>>      bignums at all.
>
> If this bypasses the licensing issue, great.

It should.

>>   3) Ask the relevant parties whether or not they might be willing to
>>      extend the guile exception to GMP, i.e. add a special Guile
>>      clause to the GMP license.
>
> Murky.  Probably legally okay, but businesses want to focus on
> business and not wrestle with murky issues.

Hmm.  If the GMP license could be changed to have a Guile exception
(identical to the one in the current Guile license), then I don't see
how it's really any murkier on this front than the status quo.

>>   4) Abandon GMP and continue to do things ourselves.
>
> Better than #1 or #3.

Not for all purposes -- depends on what your goals are -- if we want a
full numeric tower that's *fast* on multiple platforms, my impression
is we may be better leaving that to numeric experts like the people
working on GMP.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Carl R. Witty]

Rob Browning <rlb@defaultvalue.org> writes:

> Not for all purposes -- depends on what your goals are -- if we want a
> full numeric tower that's *fast* on multiple platforms, my impression
> is we may be better leaving that to numeric experts like the people
> working on GMP.

You might want to run some benchmarks before you decide on GMP.  My
impression (from the last time I looked at the issue, maybe a couple
of years ago) is that GMP is intended to be asymptotically fast on
large numbers, but that it's not particularly fast on smaller
numbers.  (For instance, you certainly wouldn't want to get rid of
fixnums and use GMP numbers for all numbers; when I looked at it, GMP
had no optimization for small numbers at all, so computing something
like 2*2 would take about 6 function calls and several loops.)

Does anybody have any idea what distribution of numbers is typical in
programs with bignums?  For instance, are most numbers that are bigger
than 32 bits in the 32 to 64 bit range, or are there lots of numbers
with hundreds of bits?  (I don't suppose anybody really knows the
answer to this question, but you'll have to make a guess before you
can decide whether one implementation is faster than another.)

Carl Witty

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

cwitty@newtonlabs.com (Carl R. Witty) writes:

> You might want to run some benchmarks before you decide on GMP.

Yeah, thanks.  I'm working on trying to get some together.  I was
planning to try to do some benchmarking before I actually proposed
committing the GMP bignums.  In the future I'd like to make it so that
we can benchmark guile fairly easily, so people can evaluate (in at
least some sense) various changes.  Of course it's hard to develop a
"really good" set of benchmarks, heck it's hard to even define what
"really good" means, but it would be nice to be able to get some sense
that you haven't made things terribly, obviously worse...

> My impression (from the last time I looked at the issue, maybe a
> couple of years ago) is that GMP is intended to be asymptotically
> fast on large numbers, but that it's not particularly fast on
> smaller numbers.  (For instance, you certainly wouldn't want to get
> rid of fixnums and use GMP numbers for all numbers;

Definitely not.  The GMP integration I'd done so far was only for
bignums, fixnums are untouched.

> it, GMP had no optimization for small numbers at all, so computing
> something like 2*2 would take about 6 function calls and several
> loops.

Right, I'm not planning on going there :>

> Does anybody have any idea what distribution of numbers is typical
> in programs with bignums?  For instance, are most numbers that are
> bigger than 32 bits in the 32 to 64 bit range, or are there lots of
> numbers with hundreds of bits?  (I don't suppose anybody really
> knows the answer to this question, but you'll have to make a guess
> before you can decide whether one implementation is faster than
> another.)

Probably entirely application specific.  I doubt the most common users
of guile (one of which is gnucash) use bignums all that often... or do
they? :> Come to think of it, in gnucash the dates are stored as a
cons pair (secs-since-epoch-utc . ns), so these days, the secs are
well over fixnum size.  Of course on 64-bit machines, if you have 6X
bit fixnums, bignums would be rare.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Jeff Read]

On Thu, May 16, 2002 at 10:35:44AM -0500, Rob Browning wrote:
> 
> If the analysis is correct, then it seems like we have a few choices:
> 
>   1) Use (and require) GMP anyway and expect people to accomodate the
>      licensing changes.
> 
>   2) Use GMP, but have a configure switch that allows you to omit it,
>      either with fallback non-GMP bignum support, or perhaps no
>      bignums at all.
> 
>   3) Ask the relevant parties whether or not they might be willing to
>      extend the guile exception to GMP, i.e. add a special Guile
>      clause to the GMP license.
> 
>   4) Abandon GMP and continue to do things ourselves.
> 
> Thoughts?

I don't think option 1 is a good idea, both from a licensing standpoint (because changing licenses, especially from less restrictive ones to more restrictive ones, is tricky) and from a more pragmatic standpoint concerning Guile's deployment.

I rather like the notion of Guile as "SIOD on steroids". Basically a relatively lightweight, self-contained, but very powerful and RnRS-compliant Scheme with strengths in extension and integration. For this purpose, anyway, options 2 and 4 are best. Option 3 is a possibility if we bundle in GMP with Guile.

Right now I'm compiling Guile out-of-the-box (out-of-the-tarball?) on a stock OpenBSD system, which doesn't come all tricked out like a lot of popular GNU/Linux distros do. I'd like to continue to be able to do this, and not sweat too much about libraries that Guile depends on for its very existence.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

"Jeff Read" <bitwize@snet.net> writes:

> I rather like the notion of Guile as "SIOD on steroids". Basically a
> relatively lightweight, self-contained, but very powerful and
> RnRS-compliant Scheme with strengths in extension and
> integration. For this purpose, anyway, options 2 and 4 are
> best. Option 3 is a possibility if we bundle in GMP with Guile.

Option 3 could be possible even if we don't bundle.  It kinda depends
on how RMS, the GMP people, etc. feel about the issue.  I suspect
there may not be any serious technical reasons preventing a Guile
exception from being added to the mainstream GMP license, but that
doesn't mean they'd think it was a good idea :>

> Right now I'm compiling Guile out-of-the-box (out-of-the-tarball?)
> on a stock OpenBSD system, which doesn't come all tricked out like a
> lot of popular GNU/Linux distros do. I'd like to continue to be able
> to do this, and not sweat too much about libraries that Guile
> depends on for its very existence.

So in your opinion, would requiring GMP, even if the licensing issues
were worked out be too big a hassle?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Robert Uhl <ruhl@4dv.net>]

Rob Browning <rlb@defaultvalue.org> writes:
> 
> So in your opinion, would requiring GMP, even if the licensing
> issues were worked out be too big a hassle?

IMHO using GMP is a near-must.  The issue, I think, is what needs to
be done to make it practical, not whether it should be done at all.

It would not bother me to need to install some other software to use
guile.  This is easily enough done when free software is involved.

-- 
Robert Uhl <ruhl@4dv.net>
Hristus A Inviat!  Adeverat a Inviat!

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Jeff Read]

On Thu, May 16, 2002 at 12:22:08PM -0500, Rob Browning wrote:
> 
> So in your opinion, would requiring GMP, even if the licensing issues
> were worked out be too big a hassle?

It would be something of a hassle, yes. My main use for Guile is as a scripting workhorse. Wherever I go, I'd like Guile to go with me (inasmuch as my movement is restricted to vaguely unixoid systems) with a minimum of fuss. Depending on another external lib complicates that. Guile depends on qthreads as it is, but that is essentially resolved by bundling qthreads with Guile. Which is why I mentioned bundling GMP.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

"Jeff Read" <bitwize@snet.net> writes:

> It would be something of a hassle, yes. My main use for Guile is as
> a scripting workhorse. Wherever I go, I'd like Guile to go with me
> (inasmuch as my movement is restricted to vaguely unixoid systems)
> with a minimum of fuss. Depending on another external lib
> complicates that. Guile depends on qthreads as it is, but that is
> essentially resolved by bundling qthreads with Guile. Which is why I
> mentioned bundling GMP.

OK, well we should keep that in mind, though as long as GMP supports
the target architecture, and we arrange guile to handle a
--with-gmp=/some/prefix argument, I'm not sure that keeping a copy of
GMP's source tree inside ours buys much over just making sure the GMP
tarfile is handy, and that we have good docs about any required
configure args, etc.

This is all presuming we were in a situation where you had to have
GMP, i.e we didn't take the route allowing --without-gmp, or similar.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Jeff Read]

On Thu, May 16, 2002 at 06:17:07PM -0500, Rob Browning wrote:
> 
> OK, well we should keep that in mind, though as long as GMP supports
> the target architecture, and we arrange guile to handle a
> --with-gmp=/some/prefix argument, I'm not sure that keeping a copy of
> GMP's source tree inside ours buys much over just making sure the GMP
> tarfile is handy, and that we have good docs about any required
> configure args, etc.
> 
> This is all presuming we were in a situation where you had to have
> GMP, i.e we didn't take the route allowing --without-gmp, or similar.
> 

This is acceptable. My main concern is that Guile not exhibit "creeping DLL hell". I once heard a statistic that said the Gnucash project, for instance, has some 60 lib dependencies. Most of these are probably due to interlocking GNOME dependencies... but that factors into why I don't touch GNOME with a ten-foot pole.

Ideally, as you said, we'd provide an option to allow the user to opt out of GMP usage, hopefully with no loss in functionality.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Robert Uhl <ruhl@4dv.net>]

"Jeff Read" <bitwize@snet.net> writes:
> 
> I once heard a statistic that said the Gnucash project, for
> instance, has some 60 lib dependencies.

It is pretty nasty, but I believe a major reason is that it uses later
versions of various libraries than are common, _and_ that said
libraries are under heavy development, and thus the APIs change.
Hence it requires a slew of downloads to work.

OTOH, programming against the older libraries would be hell.  That's
why I use guile 1.4 for travtrack.  The unfortunate side effect is
that this means that it will not compile for most folks.

> Ideally, as you said, we'd provide an option to allow the user to
> opt out of GMP usage, hopefully with no loss in functionality.

Well, they'd have to lose some functionality--or else what's the point
of GMP in the first place?

-- 
Robert Uhl <ruhl@4dv.net>
Christ is Risen!  Truly He is Risen!

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Thien-Thi Nguyen]

   From: ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>)
   Date: 16 May 2002 17:38:47 -0600

   Well, they'd have to lose some functionality--or else what's the
   point of GMP in the first place?

perhaps GMP can provide better behavior (speed/accuracy/etc) in support
for a previous interface (if implementors can separate interface from
implementation).

here are some concise notes on good interface design:

 http://swissnet.ai.mit.edu/~jaffer/CORSI.html

(see you in orbit... :-)

thi

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

"Jeff Read" <bitwize@snet.net> writes:

> This is acceptable. My main concern is that Guile not exhibit
> "creeping DLL hell".

Well I'd fight that too.  I agree that it's important, *especially*
given Guile's intent, to remain fairly self-contained, but I also
think that GMP may be a fairly special case.  It appears to do a hard
job pretty well, and probably isn't something where it's easy to roll
your own and get it right.

>I once heard a statistic that said the Gnucash project, for instance,
>has some 60 lib dependencies. Most of these are probably due to
>interlocking GNOME dependencies... but that factors into why I don't
>touch GNOME with a ten-foot pole.

I suspect it's over 60, but you're also right that it's mostly stuff
that's pulled in via GNOME.  The "lots of tiny libraries" doesn't
really cause me all that much trouble, but it's hard to evaluate what
it would be like if I weren't using Debian or some other distribution
that handles the packaging issues well.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> OK, well we should keep that in mind, though as long as GMP supports
> the target architecture, and we arrange guile to handle a
> --with-gmp=/some/prefix argument, I'm not sure that keeping a copy of
> GMP's source tree inside ours buys much over just making sure the GMP
> tarfile is handy, and that we have good docs about any required
> configure args, etc.

Technically, I think we should not have a copy of GMP in our sources.
The libltdl thing is already somewhat confusing: when you first
configure Guile without a libltdl in your system, it will install it.
When you configure a new version of Guile, it will find the old
libltdl and will use it, while it should probably replace it with the
new version from Guile.

I'd say the user should explicitely state that he/she doesn't want to
use GMP.  When --without-gmp is not given, configure should abort when
GMP is not found.  Otherwise people might be tricked into building a
Guile with inferior number support without noticing it.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Bill Schottstaedt]

> I suspect people in embedded
> environments (the target audience for whom LGPL is problematic) don't
> care about bignums.

I do, or I'm confused about what "embedded" refers to -- I need the
Scheme-side equivalent of "off_t" (long long -- 64 bit ints) in a
context where file sizes go over 2^31 bytes.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> If the analysis is correct,

I think it is, on every point.  I should have caught the license
problem earlier, sorry.[1]

> then it seems like we have a few choices:
> 
>   1) Use (and require) GMP anyway and expect people to accomodate the
>      licensing changes.

Personally, I would be happy to see Guile use the LGPL or even the
unmodified GPL.  It makes things easier (as shown by this very issue),
but relicensing towards more restrictions should not be done lightly.
People have said that they do make use of the exception, and taking
that choice away from them would be bad.

>   2) Use GMP, but have a configure switch that allows you to omit it,
>      either with fallback non-GMP bignum support, or perhaps no
>      bignums at all.

I think this is acceptable.  A not-GMP-using libguile would be
technically inferior to the default libguile, but that can only be
expected.  If you want the good stuff, agree to our terms.

If it is not too much hassle, we should keep our current bignum
implementation as the fall-back.  We might have a thin interface layer
between libguile and GMP (as some SCM_I_BIGNUM_ macros say).  That
interface could be tuned to be efficiently implemented by GMP, and
straightforwardly but not necessarily efficiently implemented with the
current stuff.  What I'm trying to say is that we should not make
ourselves a lot of work to keep the fall back be efficient.

>   3) Ask the relevant parties whether or not they might be willing to
>      extend the guile exception to GMP, i.e. add a special Guile
>      clause to the GMP license.

That would be a solution, but somehow, I don't like it very much.  It
can't hurt to ask.  I am a bit unsure about my own position here, so I
would have to think about this a bit more.  I would ask RMS what he
thinks about removing the exception from libguile and about adding the
restriction to GMP. But I don't know yet in what direction I would
argue myself...

>   4) Abandon GMP and continue to do things ourselves.

That would not be good.  GMP is the technically Right Thing to use,
and it would be strange to refuse our 'own' software for its
restrictive license terms, wouldn't it?



[1] Somehow, it escaped me that the exception was not equivalent to
LGPL.  I had this image in my head where the FSF were trying a new
strategy since they didn't really seem to like the LGPL any more.  But
I also _knew_ that the exception did not turn the GPL into the LGPL.
If someone had asked me directly... :-/

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Marius Vollmer wrote:

> >   2) Use GMP, but have a configure switch...
> 
> I think this is acceptable.  A not-GMP-using libguile would be
> technically inferior to the default libguile, but that can only be
> expected.  If you want the good stuff, agree to our terms.

Then you cannot complain if a proprietary product uses a GMP-using
libguile.  The problem is that the person installing libguile is
not necessarily the installer of the proprietary produce.  e.g.,
SuSE distributes Linux with a pre-packaged libguile.  The proprietary
product installation should do what?  Check for GMP-enablement in
libguile and choke, or just install?

> If it is not too much hassle,

Methinks it is.  I also doubt any of my "clients" use big nums,
but I put no constraints on their Scheme code, either.

> What I'm trying to say is that we should not make
> ourselves a lot of work to keep the fall back be efficient.

Fallback isn't the issue.  You're talking about a new
library with new usage restrictions.  Think:  new name, too.

> >   3) Ask the relevant parties whether or not they might be willing to
> >      extend the guile exception to GMP, i.e. add a special Guile
> >      clause to the GMP license.
> 
> That would be a solution,

It would preclude needing to rename.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Bill Gribble]

On Tue, 2002-05-28 at 13:28, Marius Vollmer wrote:
> Personally, I would be happy to see Guile use the LGPL or even the
> unmodified GPL.  It makes things easier (as shown by this very issue),
> but relicensing towards more restrictions should not be done lightly.
> People have said that they do make use of the exception, and taking
> that choice away from them would be bad.

I use the exception.  Were the guile-1.6 license to become strictly GPL,
I would have to stick with guile-1.4 for my own code. 

I'm not sure exactly what the difference is between the Guile license
currently and the LGPL.  If I could continue to write programs that use
libguile but can have licenses more restrictive than the GPL, I don't
really care which license guile uses. 

> That would not be good.  GMP is the technically Right Thing to use,
> and it would be strange to refuse our 'own' software for its
> restrictive license terms, wouldn't it?

License issues are part of the criteria one has to use to evaluate the
alternatives.  If the licenses of GMP and Guile aren't compatible, it's
not that strange to have to forego use of GMP. 

b.g.




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

Re: The Guile license and the use of LGPL libs (like GMP).

[Greg Troxel]

For the record, I have used guile in non-free code, and others at BBN
are on the verge of doing so as well.  This is generally stuff done
for a customer.  While this isn't free software (some of it might
later be, but that's very different from committing up front), it has
resulted in bug fixes being sent back to guile.  It has helped in a
very small way the advancement of the notion that it is reasonable to
use guile - which really is an uphill battle outside of the pro-guile
crowd.  So I'd really hate to see the exception abandoned - it would
essentially mean the end of guile use in my workplace, or at least a
great diminishment.

        Greg Troxel <gdt@ir.bbn.com>

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

> So I'd really hate to see the exception abandoned - it would
> essentially mean the end of guile use in my workplace, or at least a
> great diminishment.

What would prohibit you from using Guile if it would be licensed under
the Lesser GPL?  (I guess it might be section 6 of the LGPL that
requires you to enable all recipients of your "work that uses the
library" to replace libguile with a suitably modified version of
libguile.)

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Greg Troxel]

  What would prohibit you from using Guile if it would be licensed under
  the Lesser GPL?  (I guess it might be section 6 of the LGPL that
  requires you to enable all recipients of your "work that uses the
  library" to replace libguile with a suitably modified version of
  libguile.)

That would likely be workable.  That would leave two issues:

  a question of people's comfort that they really understand the terms
  - with the 'guile exception' it is very easy to be sure that one
  understands it correctly.  The LGPL doesn't require much, but it's
  not so obvious.  It additionally requires that reverse engineering
  be permitted.  Right now, there is resistance to using guile due to
  scheme.  So, for the sake of widespread guile adoption (with the
  goal of guile becoming mainstream), I think we should keep all
  barriers as low as possible.

  Static linking --  What if cisco wanted to put guile in IOS?  The
  current strategy of record says that this (rather than, say, tcl :-)
  would be a good thing.  Overall, the FSF strategy seems to be

    library that can't be had elsewhere -> GPL

    library that has lots of non-free competition -> LGPL

    library that we really want to have used and be mainstream (eg
    guile, and afaik the only one of these) -> Guile exception

All that said, a --without-gmp that basically makes integers turn to
inexact on overflow (using double) rather than into exact bignums
should be a good compromise.  I don't know if Rob is up for this,
though, or if his work-in-progress already supports it.

Probably someone from the guile maintainer group should talk to RMS or
any other FSF policy folks - this issue really goes a bit beyond just
the guile project.

Sorry if I'm being redundant...

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

>   What would prohibit you from using Guile if it would be licensed under
>   the Lesser GPL?  (I guess it might be section 6 of the LGPL that
>   requires you to enable all recipients of your "work that uses the
>   library" to replace libguile with a suitably modified version of
>   libguile.)
> 
> That would likely be workable.  That would leave two issues:

Oops, I wasn't clear enough.  I wanted to say that probably section 6
of the LGPL is giving you problems.

>   a question of people's comfort that they really understand the terms
>   - with the 'guile exception' it is very easy to be sure that one
>   understands it correctly.  The LGPL doesn't require much, but it's
>   not so obvious.

That should not be a substantial problem, I hope.  The LGPL is a
established license, as opposed to the Guile exception which is
probably more unfamiliar.  Having to educating people about the LGPL
should not keep us from using it...

>   It additionally requires that reverse engineering be permitted.

Would that be a problem, in your specific case?  I'm trying to also
learn from actual cases, not only from speculating.

>   Right now, there is resistance to using guile due to scheme.  So,
>   for the sake of widespread guile adoption (with the goal of guile
>   becoming mainstream), I think we should keep all barriers as low
>   as possible.

Yes, but will people who don't like Scheme still pick Guile because of
its license?  I can imagine that people who like Scheme could refuse
Guile if it hadn't the weak license, tho.

>   Static linking --  What if cisco wanted to put guile in IOS?

I don't know what IOS is, so I can't say whether we would lose
anything when Cisco doesn't use Guile.  (We would probably lose
eyeballs and contributors...)  But maybe they would want Guile so bad
that they would go along with the LGPL.  In that case, we would gain
by having a slightly more 'open' IOS.  Well.

> All that said, a --without-gmp that basically makes integers turn to
> inexact on overflow (using double) rather than into exact bignums
> should be a good compromise.

Yes, I think so too.

> Probably someone from the guile maintainer group should talk to RMS or
> any other FSF policy folks - this issue really goes a bit beyond just
> the guile project.

Yes, we are doing that already.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

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

> If it is not too much hassle, we should keep our current bignum
> implementation as the fall-back.  We might have a thin interface layer
> between libguile and GMP (as some SCM_I_BIGNUM_ macros say).  That
> interface could be tuned to be efficiently implemented by GMP, and
> straightforwardly but not necessarily efficiently implemented with the
> current stuff.  What I'm trying to say is that we should not make
> ourselves a lot of work to keep the fall back be efficient.

I think I can do this without too much trouble.  I'll go ahead and see
after I get the next beta out and start working on 1.7 again.

> That would be a solution, but somehow, I don't like it very much.  It
> can't hurt to ask.  I am a bit unsure about my own position here, so I
> would have to think about this a bit more.  I would ask RMS what he
> thinks about removing the exception from libguile and about adding the
> restriction to GMP. But I don't know yet in what direction I would
> argue myself...

I don't really like this option too much either, unless the FSF really
does consider Guile a Very Special Case.

> That would not be good.  GMP is the technically Right Thing to use,
> and it would be strange to refuse our 'own' software for its
> restrictive license terms, wouldn't it?

Agreed.

> [1] Somehow, it escaped me that the exception was not equivalent to
> LGPL.  I had this image in my head where the FSF were trying a new
> strategy since they didn't really seem to like the LGPL any more.  But
> I also _knew_ that the exception did not turn the GPL into the LGPL.
> If someone had asked me directly... :-/

Well, my recollecion is that Guile was intended to have a somewhat
special status.  Since the FSF kinda hoped for World Domination on the
extension language front, the goal was to make sure the license didn't
get in the way, but only with respect to that particular issue --
hence the exception.  I can see the point, but it does make things a
little more complicated when Guile wants to depend (at the direct
linking level) on anything else.

Lets see how hard it is for me to get a --without-gmp fallback
working.  If I can, then we can probably just put a note in LICENSE
and forget about it for now.  I'll have to see how to best arrange
this.

Anyone here familiar enough with goops to know if we might be able to
handle bignums via goops with sufficient efficiency?  I kinda doubt
it, but I was wondering.  In any case I want to see if there's a way
to refactor the numerics so that the bignum code is less tangled with
the rest.  I'm not sure it's possible without too much loss of
efficiency, but I'll check.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Bruce Korb <bkorb@pacbell.net> writes:

> Marius Vollmer wrote:
> 
> > >   2) Use GMP, but have a configure switch...
> > 
> > I think this is acceptable.  A not-GMP-using libguile would be
> > technically inferior to the default libguile, but that can only be
> > expected.  If you want the good stuff, agree to our terms.
> 
> Then you cannot complain if a proprietary product uses a GMP-using
> libguile.

I could complain... but I understand that it would look like a scam to
the other side.

> The problem is that the person installing libguile is not
> necessarily the installer of the proprietary produce.  e.g., SuSE
> distributes Linux with a pre-packaged libguile.  The proprietary
> product installation should do what?  Check for GMP-enablement in
> libguile and choke, or just install?

As you say, we can handle this with giving distinct names to libguile,
depending on its license.

> > If it is not too much hassle,
> 
> Methinks it is.  I also doubt any of my "clients" use big nums,
> but I put no constraints on their Scheme code, either.

Without bignums, fixnums would overflow into floats.  So we would have
to have two versions of 'bignums' anyway, whether they are implemented
with floats or with our current bignum code.  Assuming that our
current bignum code is correct, it wouldn't need much maintainance
itself.

> > What I'm trying to say is that we should not make
> > ourselves a lot of work to keep the fall back be efficient.
> 
> Fallback isn't the issue.  You're talking about a new
> library with new usage restrictions.  Think:  new name, too.

Yep, this occured to me... but which one should be plain "libguile"?
The one with GMP or the one without?  Also, we already have API
variants: with or without threads, with or without heavy-weight
debugging support.  Maybe we should give distinct names to them also?

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Marius Vollmer wrote:

> Without bignums, fixnums would overflow into floats.  ...
> Assuming that our current bignum code is correct,
> it wouldn't need much maintainance itself.

Works for me.  :-)

> > > What I'm trying to say is that we should not make
> > > ourselves a lot of work to keep the fall back be efficient.
> >
> > Fallback isn't the issue.  You're talking about a new
> > library with new usage restrictions.  Think:  new name, too.
> 
> Yep, this occured to me... but which one should be plain "libguile"?

The one without new restrictions.

> The one with GMP or the one without?  Also, we already have API
> variants: with or without threads, with or without heavy-weight
> debugging support.  Maybe we should give distinct names to them also?

If there are usage constraints, yes.  Otherwise, it's a config
issue.  "Does the library support function X?" is a fundamentally
different question than, "Am I allowed to link with the library at all?"

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Bruce Korb <bkorb@pacbell.net> writes:

> > Yep, this occured to me... but which one should be plain "libguile"?
> 
> The one without new restrictions.

Yes that seems to be the best choice.  (Although I was hoping that we
could find an argument that let's us use the nicer "libguile" for the
'best' library.)  We would also need to add an option to guile-config,
no?

Anyway, I'm sure we can find a good solution that doesn't turn
libguile into a trap for people that want the exception.

> > The one with GMP or the one without?  Also, we already have API
> > variants: with or without threads, with or without heavy-weight
> > debugging support.  Maybe we should give distinct names to them also?
> 
> If there are usage constraints, yes.  Otherwise, it's a config
> issue.  "Does the library support function X?" is a fundamentally
> different question than, "Am I allowed to link with the library at all?"

Yes, agreed.  Good point.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Robert Uhl <ruhl@4dv.net>]

Bruce Korb <bkorb@pacbell.net> writes:
>
> > Yep, this occured to me... but which one should be plain "libguile"?
> 
> The one without new restrictions.

The one which causes the least trouble.  How many folks are using
libguile with proprietary software?  How many with free software?  I
daresay that former group is much smaller than the latter, but I could
be wrong.  Seems to me that the smaller group should be
inconvenienced, not the larger.

I'm still not certain why guile doesn't simply use the LGPL.  And I
still don't buy that dynamic linking produces a derived work; nor am I
convinced that static linking really does in any meaningful sense.

-- 
Robert Uhl <ruhl@4dv.net>
Christos Voskrese iz mertvych
Smertiju smert' poprav
I suscim vo hrobich zi
Vot darovav!

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Marius Vollmer wrote:
> We would also need to add an option to guile-config, no?

Probably:

  LDOPTS=`guile-config --license=gpl link`

Yes?

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Bruce Korb <bkorb@pacbell.net> writes:

> Marius Vollmer wrote:
> > We would also need to add an option to guile-config, no?
> 
> Probably:
> 
>   LDOPTS=`guile-config --license=gpl link`
> 
> Yes?

Yes, or rather "--license=lgpl".

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Robert Uhl <ruhl@4dv.net>]

Marius Vollmer <mvo@zagadka.ping.de> writes:
>
> >   LDOPTS=`guile-config --license=gpl link`
> 
> Yes, or rather "--license=lgpl".

Yuck.  Most guile-using software will be gpl-compatible.  Make the
developers of proprietary software use the ugly option.

-- 
Robert Uhl <ruhl@4dv.net>
Ha Mashiyach qam!  Ken hu qam!

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> >
> > >   LDOPTS=`guile-config --license=gpl link`
> > 
> > Yes, or rather "--license=lgpl".
> 
> Yuck.  Most guile-using software will be gpl-compatible.  Make the
> developers of proprietary software use the ugly option.

Yes, I'm considering that.  I would like this much better myself.

As far as I see right now (I am currently being educated behind the
scenes about licensing details), the risk for a developer to
accidentally violate the license of Guile will be very small.  Such a
violation can only happen when (parts of) Guile are distributed
together with the non-free software and we can expect the developers
to know what they are distributing.  When Guile is not distributed
with the non-free software (i.e. the non-free software uses dynamic
linking or comes as non-free source), the author of the non-free
software is not affected by Guile's license, whatever it is.

So, it would probably be OK to prominently announce the change of the
default license of Guile, and simply ask people who want to use the
weak license to take care to distribute a properly configured Guile.


All this will effectively allow non-free software to use a free
software library (GMP), albeit indirectly.

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

Re: The Guile license and the use of LGPL libs (like GMP).

[Robert Uhl <ruhl@4dv.net>]

Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> So, it would probably be OK to prominently announce the change of
> the default license of Guile, and simply ask people who want to use
> the weak license to take care to distribute a properly configured
> Guile.

Cool.  I do love guile:-)

My own project travtrack <http://travtrack.sf.net/> is coming along
slowly but surely.

-- 
Robert Uhl <ruhl@4dv.net>
Christos Voskrese iz mertvych
Smertiju smert' poprav
I suscim vo hrobich zi
Vot darovav!

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