RE: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL

[Mike Thomas]

Hi Camm.

| Greetings!  The BFD library linking is a recent addition, and could be
| removed if necessary, though it would force us back to
| dlopen/non-permanent object loading on all but two of the 6 platforms
| which we thus support at present.

That would be a shame, I think.

My understanding is that we would only need to dump BFD linking in cases
where a particular GNU Common Lisp binary distribution was to be licenced
under LGPL.

Such a binary would presumably give the author of new third-party software
developed with that GCL binary the option of not releasing the source code
to their new software.

So for example, a developer might build a GCL with custom relocation rather
than BFD, no readline and assuming that the Emacs code is subject to a
waiver, that particular build of GCL could be licenced under LGPL.  That
person could then write a spreadsheet with that LGPL GCL and sell it without
making the source code to that spreadsheet available.

By my understanding, such an example was OK within the scope of historical
GCL releases before references to BFD and readline (and possibly Emacs
unexec) entered the source tree.

If not, then I see no advantage in licencing GNU Common Lisp under LGPL and
it would save us all a lot of trouble just to go with full GPL.


| If need be I suppose we could
| expand on the custom reloc code already in the tree. Richard
| is of course right here that static or dynamic linking is not
| relevant.

I had been under the impression that a dispute existed over the issue of
dynamic linking at one time and I never found out what the outcome was,
which is why I used the phrase "grey area".  From an ethical point of view I
agree, incidentally, with yourself and Richard and on that basis I would
hope that the point of view of the courts would be so constrained.


| The unexec routines from emacs were definitely in place when GCL was
| maintained by Dr. Schelter.  Surely the license issues must have been
| worked out at that time?

My understanding also, but I felt that while we were sorting licencing out
it would be appropriate to ensure that an overall view be formed - I had
forgotten in previous discussions that these other relevant licencing
factors existed.  I am also concerned that the unexec stuff might have crept
in, historically speaking, without sufficient consideration.  I don't know
the timeline or facts of these matters myself, but I would like to know.


| To my understanding, the only function
| needed from emacs is unexec -- the files listed my Mike are those
| needed to support this function on several architectures.
|
| How much of an issue is it really if we just place GCL under the GPL?
| Do we know of anyone who would be inconvenienced by this?

As far as I know, only potential users of GCL who might one day like to
protect their software ventures by means of source code secrecy; an issue
which goes to the heart of the existence of the FSF.  It seems also,
however, that there is a moral imperative at play in terms of the intentions
of Bill Schelter who preserved the LGPL status of GCL while keeping it
alive.

In the end, I bow to the decision of yourself and the relevant FSF experts
as I am sure that you will all proceed on the merits of the project in terms
of it's potential for doing some good in this world.

Cheers

Mike Thomas.