[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Re: GCL compliance and Bill Schelter
Re: [Axiom-developer] Re: GCL compliance and Bill Schelter
Fri, 25 Jul 2003 09:55:16 +0100
Licensing issues seem to develop into religous wars and since releasing
Axiom under the BSD I've spent more time justifying that decision to
free-software advocates than helping people try to undrstand and use the
code. I can't help thinking the free software community needs to get a
better perspective. Its a simple fact that for all sorts of practical
reasons it is unlikely that we could have released the code under the
GPL. I don't agree with your point about axiom being "better served" by
a GPL license since I don't agree that building commercial products on
top of Axiom would be a bad thing (this is the model that MuPad have
tried to adopt, although with limited success as far as I can see - a
free kernel with proprietory user interfaces, help systems, IDEs etc.).
However we should agree to differ on this.
As far as your point about building a GPL'd product using BSD code, I
believe that you are correct although I have heard opinions to the
contrary. The broad principles should be OK, it seems that the devil is
in the detail and that making sure that the correct notices, disclaimers
etc. appear in the right places is a little tricky.
As for your specific question (6) about Axiom users saving custom
images, the fact is that as far as I know nobody outside IBM and NAG
ever did this when Axiom was built on AKCL and while its would have been
possible with the CCL version the procedure was never documented so I'm
confident that it didn't happen! The only significant advantage to a
user of doing this would be to save an image with their favourite
libraries pre-loaded, which these days isn't a big time saving.
Kind regards, Mike.
On Thu, Jul 24, 2003 at 05:24:52PM -0400, Camm Maguire wrote:
> Greetings, gentle people!
> I must confess that I don't even have time now to adequately ponder
> the flurry of latest emails. I'd like to make the following points,
> which I hope will calm and clarify.
> 1) I will do everything in my power to ensure that GCL's license will
> never force a license onto projects that use it as a compiler.
> This is not only achievable, but from my understanding, not even
> controversial among the existing participants of this
> discussion. Please, everyone, rest assured.
> 2) There are several different ways to achieve 1), some more difficult
> than others, including possibly doing nothing at all if it can be
> shown that Dr. Schelter received permission to use unexec more than
> 10 years ago. Frankly I think this is the most likely actuality,
> especially given his work with emacs over the years. But the
> actual path to 1) is not yet clear in my mind, and probably won't
> be for some time. In the mean time, we have the status quo, which,
> with all its ambiguities, is just as functional as its always been.
> 3) This having been said, it is my opinion that axiom would be better
> served by a GPL license. It is of course completely up to the
> axiom developers and any other relevant parties, certainly not me,
> but I feel that the existing BSD license places all the volunteer
> work being poured into axiom at risk of being hijacked by a
> commercial fork of the code. The last thing I am is a lawyer, but
> my understanding of the BSD license is that anyone, including the
> developers, can, if they so chose, relicense their copy/modified
> version of the code under the GPL. This does not violate the BSD
> license, to my understanding, and should require no special
> permission. After all, one can make a commercial fork of BSD code
> without permission, so one should certainly be able also to make a
> GPL fork of said code.
> Again, this decision lies in the hands of others than me; I just
> state this here to clarify the point that should a GPL license for
> axiom ever be desired, it should not require extensive negotiations
> with other parties, who are free to continue to distribute the code
> prior to such a fork under a BSD license.
> 4) The basic confusion surrounding this discussion stems from a
> misunderstanding, IMHO, of how GCL (or lisp in general) works
> technically. Tim basically hit the nail on the head. I will try to
> summarize separately in a note to RMS, but the basic idea is that
> unlike in C programming, lisp executables have the entire compiler,
> linker, and image saver -- basically all of GCL -- in the
> executable itself. I'm still not sure to what extent this is as a
> result of an early GCL design decision, or to what extent it is
> mandated by the Common Lisp standard. In any case, there is a
> *long* history of GCL usage in this mode, which it would be
> completely unfair to suddenly disrupt. I repeat I will do all in
> my power to avoid this.
> 5) From the perspective of fairness, this 'common lisp usage' as
> outlined in 4) cuts both ways. Say someone writes a two line BSD
> lisp file which modifies the compiler to print 'hello world' when
> compiling a file. Say the resulting image is BSD licensed. Then
> someone could make a proprietary fork, release a binary with no
> source, and effectively hijack GCL. Even if the image had some
> intermediate license which required the distributor to just
> distribute the GCL source, we've effectively permitted someone to
> distribute a modified GCL compiler without releasing their
> modifications, which is against even the LGPL.
> On the other hand, it is quite unfair I feel to force large user
> space programs like maxima, acl2 and axiom to choose the GPL for
> their substantial code base because of GCL. The way this is
> typically handled in LGPL situations is to define an 'application
> interface' as a wall between an LGPL'ed "library" and the user's
> main code. Any changes on one side of the wall must have
> modifications distributed in source, whereas there are no
> restrictions to changes on the other side of this 'wall'. Perhaps
> the common lisp hyperspec could be a definition of such an
> interface. Code using functions in this spec might be
> unrestricted, whereas modification of the functions themselves
> would be LGPL'ed. I feel this is what clisp was trying to achieve
> with its exception clause, but I'm really just speculating here.
> 6) I'd be interested to know from the perspective of maxima, acl2, and
> axiom users whether typical usage of the *final distributed binary*
> (as opposed to intermediate images in the build process) would
> require the ability to dump new images and/or load compiled
> 7) I realize these issues are important, as demonstrated with
> exceptional clarity recently by this SCO/Linux mess. (Can anyone
> imagine how much worse the situation might be had SCO not
> itself distributed Linux under the GPL?) But I must confess I'm a
> bit tired of this discussion, and its eating up what little time I
> have to push GCL forward. Can we please get back to the code now?
> I trust a solution will present itself in time, and until then, we
> should be content with the status quo.
> Take care,
> Camm Maguire address@hidden
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
> Axiom-developer mailing list
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
[Axiom-developer] Small patches, Camm Maguire, 2003/07/24
[Axiom-developer] RE: GCL compliance and Bill Schelter, Mike Thomas, 2003/07/25
[Axiom-developer] Re: GCL compliance and Bill Schelter, Richard Stallman, 2003/07/25
[Axiom-developer] GCL compliance and Bill Schelter, root, 2003/07/24