MK:DEFSYSTEM
Mark Kantrowitz
current maintenance status of the MK:DEFSYSTEM utility I
wrote several years ago.
Marco Antoniotti <mar...@parades.rm.cnr.it> is hereby
designated the official maintainer for this utility,
and will be distributing the software using a more liberal
distribution license he negotiated with me.
The purpose of this is to ensure that the software is kept
up to date and extended as necessary, allowing it to
become a de facto standard for Common Lisp.
Questions regarding MK:DEFSYSTEM should be directed to Marco.
Mark Kantrowitz
mk...@cs.cmu.edu
P.S. Mail to mk...@cs.cmu.edu will not be read. (Last time
I checked, there was 40mb of junk mail in my inbox at CMU.)
I am not posting this using my current email account because
I want to keep that address relatively free of junk mail.
Marco Antoniotti
mk...@cs.cmu.edu (Mark Kantrowitz) writes:
> This message is intended to answer questions regarding the
> current maintenance status of the MK:DEFSYSTEM utility I
> wrote several years ago.
>
> Marco Antoniotti <mar...@parades.rm.cnr.it> is hereby
> designated the official maintainer for this utility,
> and will be distributing the software using a more liberal
> distribution license he negotiated with me.
>
> The purpose of this is to ensure that the software is kept
> up to date and extended as necessary, allowing it to
> become a de facto standard for Common Lisp.
>
> Questions regarding MK:DEFSYSTEM should be directed to Marco.
>
> Mark Kantrowitz
> mk...@cs.cmu.edu
I want to thank Mark for having trusted me to keep up all his
execellent work. I have been using his utilities set for a long time
now and have always been very happy with them.
As for MK:DEFSYSTEM, I have a new web page ready which will
(hopefully) end up on http://www.cons.org. The code will be available
soon there (and elsewhere!) with a first set of patches I have been
collecting here and there, mainly to make the system run with newer
implementations of CL.
The new license will have the 'compensation' clause removed. This was
always pointed out as the major stumbling block for MK:DEFSYSTEM wider
acceptance.
If you have any patch that you want to see included in MK:DEFSYSTEM,
please send it directly to me for the time being.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Bruno Haible
Thanks, Marco, for picking up the torch.
> The new license will have the 'compensation' clause removed. This was
> always pointed out as the major stumbling block for MK:DEFSYSTEM wider
> acceptance.
What will the precise wording of the license be? If you just remove the
"no fees or compensation" clause, it is still not Free Software:
- It permits "use and copying", but not "distribution". As I understand it,
"copying" is making [backup] copies for oneself, whereas "distribution"
is handing out a copy to other people.
- It permits the preparation of derivative works, but not their use,
copying, or distribution.
- A compiled defsystem.fasl will not contain the copyright notice. Will it
still be legal to distribute it?
Bruno
Kaelin Colclasure
how just this issue can be a significant barrier to the propogation of
"free"
software. While individuals or organizations may have the best of intentions
in drafting their own "open source" licenses, doing so does significantly
complicate the picture of deciding wether or not some code you've downloaded
is "free enough" for you to actually use.
Most developers are not intellectual property legal experts.
May I suggest that serious consideration be given to adopting the GPL or
LGPL? These licenses are perhaps not without their flaws -- most certainly
they have their detractors -- but I submit that they've already been
scrutinized and that the developer community has a pretty good idea of what
each means.
-- Kaelin
Bruno Haible <hai...@ilog.fr> wrote in message
news:80vbre$v7u$1...@news.u-bordeaux.fr...
Gavin E. Gleason
Better yet, something along the lines of BSDL or the Xfree86 licence.
Those are less restrictive then the GPL or LGPL. Of course it depends
on the what the author wants to become of the code...
Gavin E. Gleason
--
"Syntactic sugar causes cancer of the semicolon."
-Alan Perlis
Fernando Mato Mira
> - A compiled defsystem.fasl will not contain the copyright notice. Will it
> still be legal to distribute it?
If someone says something like `this copyright notice must appear in all copies',
put double quotes around it,
and ensure the string is embedded in the code, I'm compliant.
Martin Cracauer
>May I suggest that serious consideration be given to adopting the GPL or
>LGPL?
GPL for defsystem? You don't know what you're talking about. using the
GPL for anything that is not completely standalone means that things
get *more* complicated, not less.
Please read about it, my propaganda material is on
http://www.cons.org/cracauer/gpl.html
>These licenses are perhaps not without their flaws -- most certainly
>they have their detractors -- but I submit that they've already been
>scrutinized and that the developer community has a pretty good idea of what
>each means.
Obviously not.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a junk operating system, eh?
Kaelin Colclasure
news:81182v$rrm$1...@counter.bik-gmbh.de...
> "Kaelin Colclasure" <kae...@everest.com> writes:
>
> >May I suggest that serious consideration be given to adopting the GPL or
> >LGPL?
>
> GPL for defsystem? You don't know what you're talking about. using the
> GPL for anything that is not completely standalone means that things
> get *more* complicated, not less.
>
> Please read about it, my propaganda material is on
> http://www.cons.org/cracauer/gpl.html
I'm quite cognizant of the issues you raise -- and in agreement that the
LGPL
is much more appropriate than the GPL in many (if not all) circumstances.
You
might be so kind as to note that I proposed "the GPL or LGPL".
I would contend that MK:DEFSYSTEM *is* "completely standalone" -- just as
GNU make is completely standalone. The fact that you use a system definition
in your code base doesn't mean MK:DEFSYSTEM has been incorporated in source
or binary form in your application. Would you assert otherwise?
And I can imagine that MK:DEFSYSTEM's author or maintainer *might* prefer
the
more rigorous terms of the GPL over the LGPL for reasons of their own.
Certainly RMS staucnhly advocates that the "Lesser GPL" not be used in all
circumstances (see http://www.gnu.org/philosophy/why-not-lgpl.html).
> >These licenses are perhaps not without their flaws -- most certainly
> >they have their detractors -- but I submit that they've already been
> >scrutinized and that the developer community has a pretty good idea of
what
> >each means.
>
> Obviously not.
I read nothing in the document you cited which was inconsistant with my
understanding of the GPL, the LGPL, or the ramifications of either. And
I'm too busy to indulge in flaming, so please spare me the ad-hominum
provocations.
If, on the other hand, you have a compelling argument to make, I'm
certainly interested in hearing it.
Fernando D. Mato Mira
> Martin Cracauer <crac...@bik-gmbh.de> wrote in message
> news:81182v$rrm$1...@counter.bik-gmbh.de...
> > "Kaelin Colclasure" <kae...@everest.com> writes:
> >
> > >May I suggest that serious consideration be given to adopting the GPL or
> > >LGPL?
Ask the author. [Why would you that? He's already giving you more than what you
need.
If you want to fork your own `Mistrust Release' you're free to do so (unless he
specifically forbid that, of course)]
> I would contend that MK:DEFSYSTEM *is* "completely standalone" -- just as
> GNU make is completely standalone. The fact that you use a system definition
> in your code base doesn't mean MK:DEFSYSTEM has been incorporated in source
> or binary form in your application. Would you assert otherwise?
If the application if a CL development system, you probably want to
incorporate. It can be considered a llibrary, so LGPL would be OK. While LGPL
would be good for disallowing proprietary extensions, it wouldn't allow then to
hold back some things as a competitive advantage (eg: performance
improvements), and that could be also a motivator for developing their own
similar but different thing, which is not what you want. Just adopting a
standard is a form of retribution.
On a related note, there's a couple of files I've given away to some people,
and in the license I state:
* Permission is hereby granted to use or copy this program for any purpose
* EXCEPT INCLUSION IN GNU GPL'ed LICENSED LIBRARIES OR RUN-TIME ENVIRONMENTS,
* provided the above notices are retained on all copies.
* Permission to modify the code and to distribute modified code is granted,
* provided the above notices and this paragraph are retained,
* and a notice that the code was modified is included
* with the above copyright notice.
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Tim Bradshaw
> I would contend that MK:DEFSYSTEM *is* "completely standalone" -- just as
> GNU make is completely standalone. The fact that you use a system definition
> in your code base doesn't mean MK:DEFSYSTEM has been incorporated in source
> or binary form in your application. Would you assert otherwise?
Yes. Lisp is not C. What if I want to ship a system (a dumped lisp
image, say) with defsystem in it, so the user can do, say, system
definition without having to load this whole package, or find it on
the net somewhere and compile it up themselves? Perhaps I might be,
for instance, a Lisp vendor, who doesn't want to distribute my system
under the GPL, and therefore almost certainly is not willing to ship
it with something GPLd in the image.
Or perhaps I'm just a lisp user, but I too want to ship images with
defsystem in so my customers can use it?
Now, I know, all the Lisp vendors & users who don't ship everything
under the GPL are evil horrible people out to do nothing but rip
everyone off, and they should just obviously be distributing all their
code under the GPL. But perhaps it's going to be a bit hard to
enlighten them, and perhaps, since people actually use their products
astonishingly enough, they might benefit if they could rely on them
shipping a common defsystem, the same way they benefit by there being
a common Lisp in the first place.
The alternative to having a common defsystem that can be shipped in
images is waiting n years while J13 beats out some kind of standard,
and then waiting for all the vendors to implement that (all
separately, all from scratch, and they all already *have* a functional
defsystem so they might not be in a big hurry). I know which I'd
rather see happen.
Sigh.
--tim
Kaelin Colclasure
news:3834504D...@iname.com...
[...]
> On a related note, there's a couple of files I've given away to some
people,
> and in the license I state:
>
> * Permission is hereby granted to use or copy this program for any
purpose
> * EXCEPT INCLUSION IN GNU GPL'ed LICENSED LIBRARIES OR RUN-TIME
ENVIRONMENTS,
> * provided the above notices are retained on all copies.
> * Permission to modify the code and to distribute modified code is
granted,
> * provided the above notices and this paragraph are retained,
> * and a notice that the code was modified is included
> * with the above copyright notice.
Fernando,
I'm certain you have sound, conscientious objections to some aspects of the
GPL which provoked you to insert this clause, and as the author you are
certainly entitled to add whatever arbitrary restrictions to the reuse of
your code happen to strike your fancy -- but can you not see that you are
in fact emphasizing my own point?
Let me restate it before it becomes further distorted in this thread. My
assertion is that the proliferation of unique "free" license terms just
makes day-to-day re-use of open source code *more* problematic, not less
so. And it's more problematic for all development contexts -- traditional
commercial endeavors or open source projects.
I never said the GPL/LGPL combination was superior to any existing
alternative, or that it was representative of any personal ideal of
software freedom that I might have. I said, in effect, that it's been
around for some time, and it's been applied quite successfully for a
variety of projects -- and that "they've already been scrutinized [meaning
by an intellectual property lawyer] and that the developer community has a
pretty good idea of what each means."
-- Kaelin
Kaelin Colclasure
news:ey3u2mj...@lostwithiel.tfeb.org...
> * Kaelin Colclasure wrote:
[...]
> Yes. Lisp is not C. What if I want to ship a system (a dumped lisp
> image, say) with defsystem in it, so the user can do, say, system
> definition without having to load this whole package, or find it on
> the net somewhere and compile it up themselves? Perhaps I might be,
> for instance, a Lisp vendor, who doesn't want to distribute my system
> under the GPL, and therefore almost certainly is not willing to ship
> it with something GPLd in the image.
>
> Or perhaps I'm just a lisp user, but I too want to ship images with
> defsystem in so my customers can use it?
The LGPL would permit both of the scenarios above, the only caveat
being that the vendor / user would have to make the MK:DEFSYSTEM
source available and would have to ship something that can be "linked"
with a newer version of MK:DEFSYSTEM.
Some have interpreted the former constraint so liberally as to mean
merely providing a URL to a GNU archive site in the release notes of
their distribution. And the latter requirement is a lot easier to meet
in Common Lisp than it is in C. For that reason, the LGPL seems a lot
more natural for CL than for C.
> Now, I know, all the Lisp vendors & users who don't ship everything
> under the GPL are evil horrible people out to do nothing but rip
> everyone off, and they should just obviously be distributing all their
> code under the GPL. But perhaps it's going to be a bit hard to
> enlighten them, and perhaps, since people actually use their products
> astonishingly enough, they might benefit if they could rely on them
> shipping a common defsystem, the same way they benefit by there being
> a common Lisp in the first place.
Now, I know that it's a lot more visceral and exciting to stoke up an
old Usenet flame than it is to actually *read* an entire thread before
posting a rebuttal. But perhaps despite this fact it is possible to
hold a useful discourse in this forum. Astonishingly enough, many of
the participants of comp.lang.lisp do productively exchange ideas and
information here. And we all might benefit if we could download a
piece of code from an archive site and use it without having our
source base scrutinized by expert legal consul first.
> The alternative to having a common defsystem that can be shipped in
> images is waiting n years while J13 beats out some kind of standard,
> and then waiting for all the vendors to implement that (all
> separately, all from scratch, and they all already *have* a functional
> defsystem so they might not be in a big hurry). I know which I'd
> rather see happen.
So please, enlighten me as to in what fashion the LGPL precludes this.
Suggest an alternative to the GPL/LGPL duo and propose its adoption
as a "standard" open-source license for the Common Lisp community. If
*all* of the existing alternatives are fundamentally flawed, strike up
an effort to draft the new, perfect document.
You give *excellent* reasons to prefer the LGPL over the GPL for
MK:DEFSYSTEM. I agree completely. But the choice is not yours or mine
to make. At present, MK:DEFSYSTEM is distributed under its own
(relatively) unique set of license terms. I merely proposed that the
relative obscurity of the license is *itself* a barrier to re-use, and
petitioned that while the terms were being revisited, perhaps this
point might be addressed.
I politely suggested the "GPL or LGPL" as well-known representatives
of open-source license alternatives. My opinion holds that the LGPL is
preferred *between these two* -- but we're not talking about my code,
and reasonable and enlightened individuals may disagree.
> Sigh.
Sigh, indeed!
> --tim
-- Kaelin
David J. Cooper
>
> Suggest an alternative to the GPL/LGPL duo and propose its adoption
> as a "standard" open-source license for the Common Lisp community.
>
Something derived from the Apache License (http://www.apache.org/LICENSE.TXT) has
been suggested to me for use with some open-source Common Lisp software which
we at Genworks are releasing. Does anyone have opinions on using this one?
--
David J. Cooper Jr, Chief Engineer Genworks International
dco...@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
Robert Monfera
I think you have a good point that it is beneficial to use an existing,
proven license (like FreeBSD). It helps avoid legal costs associated
with making sure the license says what it seems to say, amongst other
hassles.
However, you wrote:
> the vendor / user would have to make the MK:DEFSYSTEM
> source available and would have to ship something that can be "linked"
> with a newer version of MK:DEFSYSTEM.
I would argue (and I'm not sure what the FreeBSD or other liberal
licenses says about it) that the best thing is not to have to show the
license to a customer.
Imagine a scenario where you try to sell something commercially - maybe
you only provide an .fsl, say, because it is a shrinkwrapped package.
Maybe you don't even want to reveal it is in Lisp when you hand over the
application.
Now, I can not imagine anything more ridiculous than having to include
MK:DEFSYSTEM as a source file in your distribution. Depending on your
potential client, you and your application may be considered weird.
Even with the most positive attitude, the client may feel obliged to
have legal experts analyze what's written next to all those semicolons
(even for well-known licenses), which they may not do enthusiastically
if at all.
I don't see how the requirement of including source (or a license or
even a reference) benefits anyone. It does not benefit me, because I'll
have to explain things I don't want to. It does not benefit the client,
because they couldn't care less about the innards of the application.
It does not benefit the maintainer (hello Marco!), because if anybody
between the client and me, it will be me reporting bugs, suggesting
improvements etc., not the client - the alternative may be that I don't
use it at all, which is probably not Mark's or Marco's intention.
Don't take this argument as a statement that certain things should
obviously be hidden from a client. In certain cases, you may want to
provide the customer with all or some of your source code. But there
are times and scenarios where any obligation on (compiled) use is
tiresome and impractical, let alone pointless.
(I did not address issues like the fact that DEFSYSTEM is mainly for
source code management, presenting us with an even more awkward
situation. There may not be anything in your .fsl or image file that is
a residue of DEFSYSTEM. Also, it is a pretty unusual concept to have to
be able to link with DEFSYSTEM. The reason for not addressing these is
that this licensing issue is more general than the licensing of
DEFSYSTEM in particular.)
Kaelin, I wasn't arguing with you here, I just disprefer something on
the basis of practicality you may not worry about.
Regards
Robert
His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
>>>>> "DJC" == David J Cooper <dco...@genworks.com> writes:
DJC> Something derived from the Apache License
DJC> (http://www.apache.org/LICENSE.TXT) has been suggested to me
DJC> for use with some open-source Common Lisp software which we
DJC> at Genworks are releasing. Does anyone have opinions on using
DJC> this one?
Some may object to the license's "advertising clause" (i.e. that the
"product includes software developed by Yoyodyne Corporation"). Some
proponents of the BSD-style license recommend cribbing the XFree86
license, which omits this restriction.
I've been thinking about licensing software for Lisp for a while, and
while I'm an advocate of the FSF's philosophy, I currently feel that
the most appropriate license for Lisp code is BSD-style without the
advertising clause. It's a lot simpler than the Lesser GPL, and seems
(to my uneducated eyes) to accomplish the same thing. But I haven't
come to a firm conclusion on this matter---I personally would prefer
the power of the GPL, as I want my code base to *remain* freely
available, but Lisp blurs the lines traditionally among the "operating
system" and "libraries" and "linkage units" and all that other stuff
one has to worry about when programming in C, that the GPL as it is
currently worded seems overbroad in its scope. (And I see the LGPL as
being too weak, to easily worked around, that if I'm going to go that
route, I may as well open the code all the way up, e.g. BSD-style.)
I'd be interested in hearing what RMS has to say on the topic of
licensing Lisp code, though I may have to ask him directly. I'm sure
he wants everything under the GPL, but unlike in the C and UNIX world,
that greatly complicates matters when I want to run my GPLed software
in a incompatibly-licensed Lisp environment.
(I think that this discussion is off-topic for comp.lang.lisp. Note
Followup-To in the header.)
--
"I'm very busy. I'm preparing my next mistake." -- B. Brecht
Erik Naggum
| Suggest an alternative to the GPL/LGPL duo and propose its adoption as a
| of the existing alternatives are fundamentally flawed, strike up an
| effort to draft the new, perfect document.
the FreeBSD license has been suggested. I'm partial to it myself. it is
much less restrictive than the LGPL, and has also been subject to serious
legal scrutiny.
let's face it, GPL and only to a lesser extent LGPL, lock you into a set
form of freedom, namely that of others: they are extremely altruistic.
while this may be good in some people's view, and few would go out and
say "altruistic is bad!", the vast majority of people find altruism quite
literally appalling when force is being used to apply it -- they want to
_choose_ who they give things away to. that lack of choice is in great
part the reason that the GPL is not winning and why the FSF needs to make
people use it instead of LGPL whenever possible. all this means is that
supposedly free software will be free only in the museum sense -- anyone
is free to look at it and learn from it, but if you want to create your
own piece of art, you have to go home and start all over from scratch.
| I merely proposed that the relative obscurity of the license is *itself*
| a barrier to re-use, and petitioned that while the terms were being
| revisited, perhaps this point might be addressed.
let me assure you that people who want to release their source code to
the general public are indeed occupied with these ideas, and that's
because the GPL and LGPL are extraordinarily unsatisfactory solutions.
| I politely suggested the "GPL or LGPL" as well-known representatives
| of open-source license alternatives. My opinion holds that the LGPL is
| preferred *between these two* -- but we're not talking about my code,
| and reasonable and enlightened individuals may disagree.
well, those who write new code are encouraged to make their code GPL.
take the GNU readline library, for instance. it is now GPL, not LGPL,
because it's an invention of the GNU project, and they want people to
write GPL'ed code, so if they want to use readline, they have to. this
is good for the FSF. it is not good for people who are not "ready" to
GPL their code. at least not until a really free alternative comes up.
personally, I'd rather be able to buy a license to use some library and
be done with it. all this talk and pondering about code and programmer
freedom takes up so much time I could probably have paid USD 500 out of
my own pocket just to use the GNU readline library in an application and
come out far ahead. it would cost me at least ten times that much to
write my own version or a modified wrapper that my Lisp program could
know it was talking to (which then had to be built and run on different
platforms, one of them Windows -- shudder), so the command-line interface
to my application is harder to use than it need be. this kind of stuff
happens all the time, and it's quite annoying.
so, to the GPL and even LGPL fans, I have one particular question: is the
author or copyright holder free to license the material to any comer on
any basis _other_ than GPL or LGPL, whichever applies, once it has been
GPL'ed? if so, the GPL or LGPL applies only to people who have not
approached the author or copyright holder for such a license, and this
means that the public at large will receive the restricted (GPL) version,
and anyone who wants to can receive a properly licensed version they can
use according to their own definitions of freedom. only if this is OK,
do we have a situation that is not completely unpalatable. now, my
understanding is that the FSF does _not_ grant extra-GPLular licenses,
but that other authors may, and that transfer of copyright to the FSF or
the author of a package is still voluntary and not covered by the GPL.
provided that my understanding is correct, we might have a sign saying:
"Source tourists, please obey the GPL or LGPL as appropriate. Residents
and commercial users inquire within." I believe this is why people form
consortia.
#:Erik
--
Attention Microsoft Shoppers! MS Monopoly Money 6.0 are now worthless.
Michael Hudson
[schnipp]
> so, to the GPL and even LGPL fans,
well...
> I have one particular question: is the author or copyright holder
> free to license the material to any comer on any basis _other_
> than GPL or LGPL, whichever applies, once it has been GPL'ed?
Yes. It would be an amazing legal feat if the GPL stopped this
wouldn't it?
Of course there's a difference between GPLed software you wrote, and
stuff like gcc where you have to sign over the copyright on your
contributions before they are accepted. But I'd guess you knew that.
> if so, the GPL or LGPL applies only to people who have not
> approached the author or copyright holder for such a license, and
> this means that the public at large will receive the restricted
> (GPL) version, and anyone who wants to can receive a properly
> licensed version they can use according to their own definitions
> of freedom. only if this is OK, do we have a situation that is
> not completely unpalatable. now, my understanding is that the FSF
> does _not_ grant extra-GPLular licenses, but that other authors
> may, and that transfer of copyright to the FSF or the author of a
> package is still voluntary and not covered by the GPL.
Yup, that about sums it up; look what I just found in the GPL:
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to
the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this.
Our decision will be guided by the two goals of preserving the
free status of all derivatives of our free software and of
promoting the sharing and reuse of software generally.
> provided that my understanding is correct, we might have a sign saying:
> "Source tourists, please obey the GPL or LGPL as appropriate. Residents
> and commercial users inquire within." I believe this is why people form
> consortia.
Here's someone who's done just that:
the page isn't terribly enlightening, other than the line
Libart is free software (all components are either GPL or
LGPL). Libart is also available for commercial licensing. I own
the copyright to the libart code base.
Regards,
Michael
Fernando D. Mato Mira
> Fernando D. Mato Mira <mato...@iname.com> wrote in message
> news:3834504D...@iname.com...
>
> [...]
> > On a related note, there's a couple of files I've given away to some
> people,
> > and in the license I state:
> >
> > * Permission is hereby granted to use or copy this program for any
> purpose
> > * EXCEPT INCLUSION IN GNU GPL'ed LICENSED LIBRARIES OR RUN-TIME
> ENVIRONMENTS,
> > * provided the above notices are retained on all copies.
> > * Permission to modify the code and to distribute modified code is
> granted,
> > * provided the above notices and this paragraph are retained,
> > * and a notice that the code was modified is included
> > * with the above copyright notice.
>
> Fernando,
>
> I'm certain you have sound, conscientious objections to some aspects of the
> GPL which provoked you to insert this clause, and as the author you are
> certainly entitled to add whatever arbitrary restrictions to the reuse of
> your code happen to strike your fancy -- but can you not see that you are
> in fact emphasizing my own point?
No. The above is simple to understand. Not like a multiple-page viral license.
If you're not sure your GPL program might qualify as a `run-time environment',
you might safely assume it does,
and so you can't use this.
I won't get into a discussion of why I think GPL licensing is perverted for
libraries.
The original motivation to include this clause was that a lot of people dont
know about the LGPL and just go GPL without thinking.
You can add now that RMS actively discourages use of the LGPL.
Regards,
Erik Naggum
| I have one particular question: is the author or copyright holder free to
| license the material to any comer on any basis _other_ than GPL or LGPL,
| whichever applies, once it has been GPL'ed?
* Michael Hudson <mw...@cam.ac.uk>
| Yes. It would be an amazing legal feat if the GPL stopped this wouldn't
| it?
not really -- most contracts have restrictions on which other contracts
people can enter regarding the exact same material or time or work or
whatever is involved. I'm generally looking for the word "non-exclusive"
and can't find it in the GPL. but, yes, I'm pushing to make sure that we
don't wind up with GPL'ed code that can't be used by "normal people", and
that we all understand that GPL doesn't mean diddly-squat when it comes
to what can be done between the legal owner of the code and whoever else
he wants to deal with.
Tim Bradshaw
> So please, enlighten me as to in what fashion the LGPL precludes this.
> Suggest an alternative to the GPL/LGPL duo and propose its adoption
> as a "standard" open-source license for the Common Lisp community. If
> *all* of the existing alternatives are fundamentally flawed, strike up
> an effort to draft the new, perfect document.
one of the BSD licenses.
--tim
Daniel Barlow
> I never said the GPL/LGPL combination was superior to any existing
> alternative, or that it was representative of any personal ideal of
> software freedom that I might have. I said, in effect, that it's been
> around for some time, and it's been applied quite successfully for a
> variety of projects -- and that "they've already been scrutinized [meaning
> by an intellectual property lawyer] and that the developer community has a
> pretty good idea of what each means."
For C-style programs, yes. But where the delivered product is a lisp
image that contains the project whose licensing is at issue, I don't
think that the developer community really does have a clear idea.
If I want to write and distribute a C program, and decide that for
ease of rebuilding it I want to include a copy of Gnu Make, it's
fairly straightforward. Make is a "standalone" program, which is
executed by running it from the command line. I don't need to link it
into my program, so the GPL clearly says I'm OK as long as I
distribute the source for make along with the make binary. I don't
need to ship source for my app and it doesn't end up under the GPL
itself.
If I want to write and distribute a CL program and want to include
somebody else's DEFSYSTEM, I probably want that DEFSYSTEM in the lisp
image I ship. Is that a derived work? Is it "mere aggregation"?
Are my fasl files "libraries"? Is my lisp image a library? Suppose
the image allowws access to a repl - does that change things? All
these points are arguable.
The GPL and LGPL are well understood for applications that conform to
the C world view, but I don't think people really know enough about
using them in a Lisp world. We're into the hazy territory, where
people get lost for years arguing about whether KDE is really free ...
That said, your point about using an existing licence where possible
is imho a good one and I'd echo it. I don't think the LGPL is the
most useful, though - I'd probably go for BSD-sans-advertising. Or,
heavens, public domain. It works for CMUCL.
-dan
Marco Antoniotti
Well, since I incidentally started all of this.... :)
I am obviously following all this debate very carefully. Let me just
comment on a couple of circumscribed things.
Daniel Barlow <d...@tninkpad.telent.net> writes:
> The GPL and LGPL are well understood for applications that conform to
> the C world view, but I don't think people really know enough about
> using them in a Lisp world.
I believe this is correct. Also I believe that MK:DEFSYSTEM (this is
and will be the official name; the CL package name is and will be "MAKE")
could really be looked at as a "library" in the more or less C
traditional way. This mauy be a minimalist view and probably not
water-tight, but it may simplify things.
> That said, your point about using an existing licence where possible
> is imho a good one and I'd echo it. I don't think the LGPL is the
> most useful, though - I'd probably go for BSD-sans-advertising. Or,
> heavens, public domain. It works for CMUCL.
The main issue in the case of MK:DEFSYSTEM is to guarantee consistency
in the code base. I am thinking of a required renaming clause for
"diverging derivative work". But, thanks to many private comments I
received, the whole issue is not settled yet.
This is a very difficult thing to do. Moreover, I could go even
further and open a nice can of European worms. Paolo, what do you
think should the Italian version of the license contain? :)
Cheers
PS. I know what happened to GCC. I had my office two floors above the
maintainer.
Fernando Mato Mira
> The GPL and LGPL are well understood for applications that conform to
> the C world view,
Really? Does everybody think about everything? I haven't read the GPL lately,
but AFAIK:
- A plug-in calling functions in a host GPL program is infected.
- If you write an .idl for a GPL library, The .idl is whatever you want; the
server-side code is infected (so you'd like to generate this code and
the .idl automatically from header files, which does not infect the .idl, BTW);
the client stubs are whetever you want; the client is whatever you want if
you're calling from another language (even in the same process, the non-infected
ORB you have to go through isolates you from the GPL), or from the same language
but a different process (same language in same process = infection).
Fernando Mato Mira
> Some may object to the license's "advertising clause" (i.e. that the
> "product includes software developed by Yoyodyne Corporation"). Some
> proponents of the BSD-style license recommend cribbing the XFree86
> license, which omits this restriction.
What's the big deal about this? Credit where credit is due..
Phillip Lord
>>>>> "Fernando" == Fernando Mato Mira <mato...@iname.com> writes:
Fernando> "His Holiness the Reverend Doktor Xenophon Fenderson, the
Fernando> Carbon(d)ated" wrote:
>> Some may object to the license's "advertising clause" (i.e. that
>> the "product includes software developed by Yoyodyne
>> Corporation"). Some proponents of the BSD-style license
>> recommend cribbing the XFree86 license, which omits this
>> restriction.
Fernando> What's the big deal about this? Credit where credit is
Fernando> due..
Well the end result can be that a compilation of various bits
of software end with several hundred of these clauses, which
effectively make advertising impossible. Thats the theory anyway....
Phil
Tim Bradshaw
> If I want to write and distribute a CL program and want to include
> somebody else's DEFSYSTEM, I probably want that DEFSYSTEM in the lisp
> image I ship. Is that a derived work? Is it "mere aggregation"?
> Are my fasl files "libraries"? Is my lisp image a library? Suppose
> the image allowws access to a repl - does that change things? All
> these points are arguable.
Even more odd cases are packages which declare a bunch of classes
which you then subclass (this should be OK, Java does this), define
your own methods on (Java doesn't do that). Or perhaps a package some
of whose classes are subclasses of your classes. Some of these things
can become seriously entangled with your image, to the extent where
*I* for one would be uncomfortable using the LGPL for fear of
contamination (assuming I minded that contamination). For instance I
can quite easily imagine using a package which I simply could not
factor out of an image without exposing large amounts of my internal
stuff which I do not want people to see -- and that could happen
*without* it being the kind of SW-engineering catastrophe that it
might be in C-derivatives, simply because CL is so dynamic.
People who don't like CL will point out that a lot of these problems
are because CL fails to distinguish development & delivery
environments well enough. Possibly.
That's why I think a license that does not have this risk of
contamination is important, because there are people for whom that
risk is unacceptable, and for whom the legal issues involved in
working out if the risks are real are unacceptably expensive.
--tim
David J. Cooper
>
> That's why I think a license that does not have this risk of
> contamination is important, because there are people for whom that
> risk is unacceptable, and for whom the legal issues involved in
> working out if the risks are real are unacceptably expensive.
>
> --tim
Sorry i'm not following this up to comp.gnu.misc or whatever,
i still think this is a pretty lisp-specific thread.
There must be some kind of balance between usability and security,
analogous to systems security in general.
Basically, I would like to release some Common Lisp-based languages,
toolkits, etc., such that people feel free to use them for personal,
and hobby use, as well as for building commercial applications.
However this is not complete altruism. Genworks is not a charity
organization and we have to fund our existence somehow. Today,this
is largely done through consulting, but I would like to spread into
other areas which ``scale up'' better than consulting.
Therefore I have a long-term interest in releasing software packages
which people will want to use, can can use freely, and can expand
their own businesses, but which will also generate an ever-increasing
business potential for Genworks.
To this end, I really need a license which allows for the following
freedoms and protections:
o Protection against someone else blatantly ripping off my free system,
packaging it as a non-open-source commercial product, doing slick
marketing and advertising on it, and peddling it as entirely their
own commercial product for big bucks (maybe i'm just paranoid and
have delusions of grandeur about how useful these systems really
are anyway, but that's another story... :)
o Freedom for others to contribute to the core system, port to other
Lisps and OS's, etc, and some means to prevent chaotic code forking.
o The ability for Genworks to sell commercial licenses for the package
which include a certain amount of support (like RedHat and others do
with Linux).
o The ability for Genworks to offer and sell training seminars on how
to use these systems to their full potential.
o The ability for Genworks to offer and sell documentation (e.g. books)
on how to use these systems to their full potential.
In the spirit of free competition, etc., I don't think I would want to
prevent others from selling support, training, etc. for the systems,
but naturally I would think Genworks would have an inside track in these
areas since we originated the systems.
It's a balancing act -- we have to capitalize on our own work to a certain
extent, but we also have to capitalize on the power of open-source to spread
the demand for our services and products potentially orders of magnitude
faster than we could do by trying to make everything a closed commercial
product.
I want everyone to get rich together, and that's one of the things which makes
software so powerful -- it *can* allow people to get rich together since it is
has the unique quality that the more you give away, the more you have.
I firmly believe that this is the way God intended software to be used by humans;
the evil perverted reflection of this is the completely lopsided, closed,
proprietary, fraudulent approach which causes huge amounts of the wealth
naturally generated by the technology to become concentrated in a few fraudulent
hands...need i say more, i think i've rambled long enough.
Kaelin Colclasure
news:31519870...@naggum.no...
> * "Kaelin Colclasure" <kae...@everest.com>
> | Suggest an alternative to the GPL/LGPL duo and propose its adoption as a
> | "standard" open-source license for the Common Lisp community. If *all*
> | of the existing alternatives are fundamentally flawed, strike up an
> | effort to draft the new, perfect document.
>
is
> much less restrictive than the LGPL, and has also been subject to
serious
> legal scrutiny.
I wasn't acquainted with the FreeBSD license, so I looked it up on the Web.
I found it at:
<http://freebsd.nwserv.com/copyright/>
It does have brevity to recommend it, and it certainly lets me do what I
want with software it covers -- including undertaking Microsoft-style
subversion-by-extension in a commercial offering.
> let's face it, GPL and only to a lesser extent LGPL, lock you into a set
> form of freedom, namely that of others: they are extremely altruistic.
> while this may be good in some people's view, and few would go out and
> say "altruistic is bad!", the vast majority of people find altruism
quite
> literally appalling when force is being used to apply it -- they want to
> _choose_ who they give things away to. that lack of choice is in great
> part the reason that the GPL is not winning and why the FSF needs to
make
> people use it instead of LGPL whenever possible. all this means is that
> supposedly free software will be free only in the museum sense -- anyone
> is free to look at it and learn from it, but if you want to create your
> own piece of art, you have to go home and start all over from scratch.
Interesting. I have a different perspective on this same set of
restrictions.
Altruism is not the *only* motivation for releasing your work as open
source.
I personally am also attracted to the idea of "open engineering". I open the
implementation of my software to a community of peers. Some small fraction
of this community offers feedback on where I can make improvements. An even
smaller fraction might contribute enhancements or bug fixes of their own.
My contribution does (hopefully) benefit others -- but I benefit as well.
From feedback, bug reports, bug fixes, enhancements ... all of these will
presumably improve the quality and breadth of my software -- from which I
am incidentally still trying to make a living.
So, yes, the GPL and LGPL do restrict what the recipiant of my "altruism"
can do. They *protect* the non-economic benefits I expected to derive when
I opened up my source. They protect me from having some corporate entity
pluck my work out of my hands, throw a hundred developers at the task, and
then run me out of business with a derivitive of my own technology.
> | I merely proposed that the relative obscurity of the license is *itself*
> | a barrier to re-use, and petitioned that while the terms were being
> | revisited, perhaps this point might be addressed.
>
> let me assure you that people who want to release their source code to
> the general public are indeed occupied with these ideas, and that's
> because the GPL and LGPL are extraordinarily unsatisfactory solutions.
I respectfully disagree that they merit the label "extraordinarily
unsatisfactory". I've read both fairly carefully, and the LGPL seems to me
to offer the protection I desire without unduly encumbering the potential
benefit to the community of my peers.
I don't think the GPL is appropriate for the work I'm doing at present,
but I acknowledge that it does have its place. I attribute a lot of the ill
sentiments of parts of the community towards the GPL as the natural
reaction to the confrontational style of evangalization behind the GPL.
> | I politely suggested the "GPL or LGPL" as well-known representatives
> | of open-source license alternatives. My opinion holds that the LGPL is
> | preferred *between these two* -- but we're not talking about my code,
> | and reasonable and enlightened individuals may disagree.
>
> well, those who write new code are encouraged to make their code GPL.
> take the GNU readline library, for instance. it is now GPL, not LGPL,
> because it's an invention of the GNU project, and they want people to
> write GPL'ed code, so if they want to use readline, they have to. this
> is good for the FSF. it is not good for people who are not "ready" to
> GPL their code. at least not until a really free alternative comes up.
I agree -- but the operative word is "encouraged". This doesn't change the
terms of the LGPL, and we're all free to ignore the encouragement. :-)
> personally, I'd rather be able to buy a license to use some library and
> be done with it. all this talk and pondering about code and programmer
> freedom takes up so much time I could probably have paid USD 500 out of
> my own pocket just to use the GNU readline library in an application and
> come out far ahead. it would cost me at least ten times that much to
> write my own version or a modified wrapper that my Lisp program could
> know it was talking to (which then had to be built and run on different
> platforms, one of them Windows -- shudder), so the command-line
interface
> to my application is harder to use than it need be. this kind of stuff
> happens all the time, and it's quite annoying.
>
> so, to the GPL and even LGPL fans, I have one particular question: is
the
> author or copyright holder free to license the material to any comer on
> any basis _other_ than GPL or LGPL, whichever applies, once it has been
> GPL'ed? if so, the GPL or LGPL applies only to people who have not
> approached the author or copyright holder for such a license, and this
> means that the public at large will receive the restricted (GPL)
version,
> and anyone who wants to can receive a properly licensed version they can
> use according to their own definitions of freedom. only if this is OK,
> do we have a situation that is not completely unpalatable. now, my
> understanding is that the FSF does _not_ grant extra-GPLular licenses,
> but that other authors may, and that transfer of copyright to the FSF or
> the author of a package is still voluntary and not covered by the GPL.
This is certainly my understanding of the GPL and LGPL. And I believe it's
completely consistant with the ideas behind those documents. That the FSF
chooses not to do this (or may even evangelize against it) is irrelavant.
> provided that my understanding is correct, we might have a sign saying:
> "Source tourists, please obey the GPL or LGPL as appropriate. Residents
> and commercial users inquire within." I believe this is why people form
> consortia.
This is a fine idea.
Paul D. Smith
fmm> "His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" wrote:
>> Some may object to the license's "advertising clause" (i.e. that the
>> "product includes software developed by Yoyodyne Corporation").
fmm> What's the big deal about this? Credit where credit is due..
Credit isn't the issue. The issue is that you must place the notice on
all advertising materials.
Consider what would happen if, as would well happen in the free software
world, you had to include 30 or 40 different such notices every time you
tried to announce a new version, etc.
Yuck.
Anyway, any restriction like that violates the letter of the GPL, which
says you can't force any additional requirements on GPL'd software. A
special exception would be needed, and RMS doesn't want to give one.
And finally, for the case of BSD in particular it's moot since UCB
announced recently that section 3 of the BSD license is no longer in
force, for all software they hold copyright to. Although, of course,
this doesn't effect other BSD-like licenses with different authors.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Kaelin Colclasure
[...]
> I won't get into a discussion of why I think GPL licensing is perverted
for
> libraries.
> The original motivation to include this clause was that a lot of people
dont
> know about the LGPL and just go GPL without thinking.
So what not use the LGPL and add a plug explaining why you think the GPL is
innapropriate? Adding arbitrary legal restrictions on re-use of your code
only complicates things for everyone. As you've demonstrated, even the
briefest of legal notices can contain land-mines and must be carefully
scrutinized. :-)
> You can add now that RMS actively discourages use of the LGPL.
I have a lot of respect for RMS -- both for his ideology and his
contributions to the tools I use every day. But I disagree with him on this
point, and I am free to make my own choices for my own work, and so is
everyone else. :-)
-- Kaelin
Steven G. Johnson
> Xenophon Fenderson wrote:
> > Some may object to the license's "advertising clause" (i.e. that the
> > proponents of the BSD-style license recommend cribbing the XFree86
> > license, which omits this restriction.
>
This is a FAQ. It's not a question of mere credit. Even the GPL requires
that copyright notices be maintained intact, and that modified versions
include prominent notices indicating the changes.
The problem with the original BSD license is that it requires
*advertising* to include credits, and this can create headaches down the
road if everyone does it. Imagine what would happen if all Linux
software used BSD-style licenses, requiring credit in ads for *all* of the
authors. If a company like RedHat wanted to put out an ad, they would
probably need a couple of full page ads and 3-point type to list everyone;
it would look like the Vietnam War Memorial.
Note that this is no longer a problem with the Berkeley License per se,
since Berkeley has lifted the advertising requirement for all code that it
owns the copyright to. The problem is with licenses based on the original
BSD license.
(See also http://www.gnu.org/philosophy/bsd.html)
Steven
PS. I like to think of it in the following way: When I write scientific
papers, I expect people who use my work to reference me, and will be upset
if they don't. But I would vigorously oppose making referencing a legal
requirement, which would result in a nightmare for researchers. There's
no contradiction between expecting courtesy and opposing the requirement
of courtesy--with all legal impositions, one must weigh the benefits
against the costs.
Asbjørn Sæbø
> so, to the GPL and even LGPL fans, I have one particular question: is the
> author or copyright holder free to license the material to any comer on
> any basis _other_ than GPL or LGPL, whichever applies, once it has been
> GPL'ed?
It seems to me that Hans Reiser does this for his filesystem:
"This project is GPL'd, but I sell exceptions to the GPL to commercial
OS vendors and file server vendors."
<URL: http://www.idiom.com/~beverly/reiserfs.html#Business Model and Licensing>
Asbj.S.
--
Asbjørn Sæbø (Asbjoern Saeboe), E-mail: sae...@tele.ntnu.no
NTNU - Norwegian University of Science and Technology, Acoustics group
<URL: http://www.tele.ntnu.no/users/saeboe/>
Public PGP-key: <URL: http://www.tele.ntnu.no/users/saeboe/pgp/pgp.html>
Kaelin Colclasure
news:38358530...@genworks.com...
[...]
> To this end, I really need a license which allows for the following
> freedoms and protections:
>
> o Protection against someone else blatantly ripping off my free system,
> packaging it as a non-open-source commercial product, doing slick
> marketing and advertising on it, and peddling it as entirely their
> own commercial product for big bucks (maybe i'm just paranoid and
> have delusions of grandeur about how useful these systems really
> are anyway, but that's another story... :)
>
> o Freedom for others to contribute to the core system, port to other
> Lisps and OS's, etc, and some means to prevent chaotic code forking.
>
> o The ability for Genworks to sell commercial licenses for the package
> which include a certain amount of support (like RedHat and others do
> with Linux).
>
> o The ability for Genworks to offer and sell training seminars on how
> to use these systems to their full potential.
>
> o The ability for Genworks to offer and sell documentation (e.g. books)
> on how to use these systems to their full potential.
>
> In the spirit of free competition, etc., I don't think I would want to
> prevent others from selling support, training, etc. for the systems,
> but naturally I would think Genworks would have an inside track in these
> areas since we originated the systems.
This list of requirements almost exactly matches my own -- and I believe
the LGPL offers a reasonable approximation of matching it. Certainly it
is a better fit than a BSD-style license.
David, I'd be quite interested in your take on the LGPL.
-- Kaelin
Fernando Mato Mira
> Fernando D. Mato Mira <mato...@iname.com> wrote in message
> news:3835140F...@iname.com...
>
> [...]
> > I won't get into a discussion of why I think GPL licensing is perverted
> for
> > libraries.
> > The original motivation to include this clause was that a lot of people
> dont
> > know about the LGPL and just go GPL without thinking.
>
> So what not use the LGPL and add a plug explaining why you think the GPL is
> innapropriate? Adding arbitrary legal restrictions on re-use of your code
There's a plug, but I didn't quote it because it's not to the point, and I
didn't want to get into a religious war:
* The above permissions are expressely granted for GNU LGPL'ed software.
* (Rationale: Promote LGPL use over GPL, which is more fair to
* all kinds of users (while still protecting the author, of couse!)).
> only complicates things for everyone. As you've demonstrated, even the
> briefest of legal notices can contain land-mines and must be carefully
> scrutinized. :-)
You're right. But just today I realized that in this era of "dot com"
companies, it's easy to find a high degree of unbalance on the way different
people may freely profit from GPL programs, so I'll change the restriction to
"GPL software" - period.
> > You can add now that RMS actively discourages use of the LGPL.
>
> I have a lot of respect for RMS -- both for his ideology and his
> contributions to the tools I use every day. But I disagree with him on this
> point, and I am free to make my own choices for my own work, and so is
> everyone else. :-)
Good for you. But a lot of kids think RMS is God (others think it's Knuth, but
everyone here knows better ;->)
Bruno Haible
> If I want to write and distribute a CL program and want to include
> somebody else's DEFSYSTEM, I probably want that DEFSYSTEM in the lisp
> image I ship. Is that a derived work?
Yes. The GPL explains that a "derived work" is "a work containing the
Program or a portion of it".
> Is it "mere aggregation"?
Certainly not, because there is no way to take apart a memory image into
separate fasls.
> Are my fasl files "libraries"?
According to the LGPL definition, yes.
> Is my lisp image a library?
This is irrelevant. Your lisp image is in "object code or executable" form,
hence section 4 of the LGPL applies.
> Suppose the image allows access to a repl - does that change things?
No. GPL and LGPL are not concerned with the functionality a program has.
> The GPL and LGPL are well understood for applications that conform to
> the C world view, but I don't think people really know enough about
> using them in a Lisp world.
Here is how I'd interpret the terms used in the GPL and LGPL:
"object code" = a fasl file or memory image
"executable" = a memory image
"library" = a fasl file or some fasl files linked together
Bruno http://clisp.cons.org/~haible/
Disclaimer: I'm not a lawyer.
Tim Bradshaw
> Even more odd cases [...]
And I missed the obvious case: macros.
--tim
Lieven Marchand
> not really -- most contracts have restrictions on which other contracts
> people can enter regarding the exact same material or time or work or
> whatever is involved. I'm generally looking for the word "non-exclusive"
> and can't find it in the GPL. but, yes, I'm pushing to make sure that we
> don't wind up with GPL'ed code that can't be used by "normal people", and
> that we all understand that GPL doesn't mean diddly-squat when it comes
> to what can be done between the legal owner of the code and whoever else
> he wants to deal with.
A clearer example is Aladdin ghostscript. You can find the details at
http://www.cs.wisc.edu/~ghost/aladdin/doc/New-user.htm#Find_Ghostscript
I believe it is even embedded in some printers.
The main problem with this is, that you can't accept patches from
people without having them sign legal documents allowing you at least
the rights your non GPL licenses require.
--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Tim Bradshaw
> well, those who write new code are encouraged to make their code GPL.
> take the GNU readline library, for instance. it is now GPL, not LGPL,
> because it's an invention of the GNU project, and they want people to
> write GPL'ed code, so if they want to use readline, they have to. this
> is good for the FSF. it is not good for people who are not "ready" to
> GPL their code. at least not until a really free alternative comes up.
Incidentally, there *is* a free alternative to readline, which may not
be quite as complete but is reasonably functional. I think it has
fairly old origins, but it received recent development *precisely*
because someone could not use gnu readline in their (BSD-free at
least) code.
look at the festival speech synthesis system, at www.cstr.ed.ac.uk,
which uses this code.
--tim