The complete lisp+ package
Ben
I really like lisp. I played with it a few months back, and found
the syntax natural and easy to write. What I did not find easy was
programming in a modern, multiple platform environment. I want regular
expressions, I want powerful string parsing, natural pathnames, network
streams, network protocols, and on and on.
I saw a lot of libraries that supported this stuff out there, but I
am writing tools for work, and I didn't want to worry about 8 different
licenses and copyrights for a couple tools.
So I tried Ruby. Ruby has all these things, and some nice concepts
it has taken from Lisp. The only nice thing about Ruby is the library
and the lisp concepts. I can't stand using it with its special case
syntax (all method names should start with a lower-case letter!) and
mysterious characters (you can use : instead of the keyword 'then'!
That's useful.)
Now I'm wondering if there is a "Lisp power package" out there.
Something that puts those library tools all in one place with a common
license. It works under Linux, and Windows, and Solaris, and Cygwin.
Am I dreaming? Is that un-Lispish? It seems like what Lisp could
use most is a little updating to deprecate a few things, and add a ton
more. I'm not trying to start a religious war - this is just an
observation from someone new trying to use a cool language.
Pascal Costanza
> Now I'm wondering if there is a "Lisp power package" out there.
> Something that puts those library tools all in one place with a common
> license. It works under Linux, and Windows, and Solaris, and Cygwin.
>
> Am I dreaming? Is that un-Lispish? It seems like what Lisp could
> use most is a little updating to deprecate a few things, and add a ton
> more. I'm not trying to start a religious war - this is just an
> observation from someone new trying to use a cool language.
This is an area - building an all-in-one package that makes you happy in
all important regards ;) - that is traditionally looked after by
commercial Common Lisp implementations. If there is a chance that you
can afford them, you might want to try out their respective
personal/trial editions.
The open source alternatives (i.e., the packages, not the
implementations) are still at an early stage, and it may stay like that
for a while, especially because the Lisp community is still relatively
small. On the other hand, adoption of Lisp has surprisingly sped up in
recent months/years, so there may be some surprises ahead.
Note that in the current stage there is still a good chance that you can
make yourself a good name by putting your own time and effort into these
things.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Paolo Amoroso
> expressions, I want powerful string parsing, natural pathnames, network
What do you mean by natural pathnames?
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
Emre Sevinc
> I really like lisp. I played with it a few months back, and found
> the syntax natural and easy to write. What I did not find easy was
> programming in a modern, multiple platform environment.
Can you be a little bir more specific about "modern" and
"multiplatform"? I mean by stating exactly the problems you
faced so that maybe people can have better chance of helping.
> I want regular
> expressions,
You got them: http://www.weitz.de/cl-ppcre/
> I want powerful string parsing,
Can you bit a little bit more specific?
Did you check out the cl-cookbook?
http://cl-cookbook.sourceforge.net/
Maybe your questions (if not answered in cl-cookbook)
may lead to important contributions.
> natural pathnames,
Did you check Seibel's book, especially the
chapter where he introduces the filesystem stuff:
http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html
>network
> streams, network protocols, and on and on.
I don't have much experience with that, I'm sure
some of the masters here do have something to say.
> I saw a lot of libraries that supported this stuff out there, but I
> am writing tools for work, and I didn't want to worry about 8 different
> licenses and copyrights for a couple tools.
What kind of copyright problems did you have with the above stuff
I mentioned?
> So I tried Ruby. Ruby has all these things, and some nice concepts
> it has taken from Lisp. The only nice thing about Ruby is the library
> and the lisp concepts. I can't stand using it with its special case
> syntax (all method names should start with a lower-case letter!)
Nice language but as you say, it would be much nicer ;-)
> Now I'm wondering if there is a "Lisp power package" out there.
> Something that puts those library tools all in one place with a common
> license. It works under Linux, and Windows, and Solaris, and Cygwin.
As Pascal Costanza pointed out, integration and putting bits and
pieces together is completely another problem (not a trivial problem
though). I generally go with Debian GNU/Linux and feel fine most
of the time with Emacs+SLIME.
> Am I dreaming? Is that un-Lispish?
I don't think so. Everybody deserves a better development
environment.
> It seems like what Lisp could
> use most is a little updating to deprecate a few things, and add a ton
> more. I'm not trying to start a religious war - this is just an
> observation from someone new trying to use a cool language.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
jcrippen
until the Right Thing is found" along the path towards a free
integrated system of which you speak. It will never be like what is
found with Ruby, Perl, Python, and the like since (Common) Lisp has
many implementations. And unlike C, which has one particularly popular
implementation which can run nearly everything of interest, Lisp has a
number of popular implementations with varying degrees of difference
from each other. This means that software growth and consolidation are
somewhat fitful since porting is a time consuming activity. On the
other hand it also means that the resulting software developed and
ported is much more robust and more fully thought out than what you
might find off the shelf for some other language.
Lisp is older than you are. Lisp is older than most people posting to
this group, if not all of them. With such age comes a tendency towards
slow deliberation, a sense that the time spent mulling over decisions
and examining all possibilities is in the end more fruitful.
If you want to try integrating lots of different libraries for fun, you
should first study ASDF and ASDF-INSTALL. Then when you know how they
work, try rolling your own package which requires all the other ones
you want, and adds your desired functionality. If other people like it
enough then they will help you make your ball of mud bigger, and maybe
it will turn into an avalanche.
Ben
> "multiplatform"?
I mean an environment running Solaris on suns, and linux on x86s, and
windows on x86s, windows running cygwin, and maybe a Mac in a corner
somewhere. I want to parse code and log files, and create source from
data files, and automate builds. Stuff like that. I can probably
force everyone to use clisp, but I can't be sure that they are all
using the same version. If someone wants to use a different lisp
interpreter, all of a sudden the system calls and several other,
implementation unique, common tasks will fail.
I've used the pathnames stuff from "Practical Common Lisp". It is
nice and helpful, but I didn't see any notes anywhere about who is
allowed to use that code for what purposes. I probably just missed
that.
I've seen the other libraries you pointed out as well. I don't want
a full time job upgrading and tracking numerous libraries that are a
part of the standard install for every other language (even C++ will
have standard regexp support in the next version). If someone tries a
different compiler and something doesn't work, either the code or the
compiler is non-standard, and can be fixed. If they download an
experimental ruby interpreter, and it doesn't work, odds are that it is
an interpreter problem, and not just some dark, unspecified corner of
the language. (Maybe the core problem is my strong belief that people
should be allowed to choose their own tools as much as possible.)
Also, when I write a script that parses a log and pulls some key
values into a csv file, it worries me that I pull in six different
copyright and license dependencies. We are required to 'register' all
these licenses with our legal department (the world is getting
paraniod, isn't it?) so the lawyers can make sure we don't expose any
proprietary code to an open source requirement. I hate this mindset,
but I think it needs to be dealt with slowly (everything is slow in big
companies) and asking to get a bunch of licenses approved to extract
some data from a log is going to push them the other way.
Further, there is no book that a code maintainer can pick up to
reference how strings and regular expressions interact. Or to see how
to connect over the network to the code server. It depends on the
particular libraries downloaded by the author of a particular script.
Hopefully the library web pages are still around and the community
still supports it.
I don't think I am expressing new concerns - obviously languages that
are actively changing see these things and are incorporating new ideas
and building huge standard libs. I agree there can be problems with
that in product development, but it sure is a boon in tool development.
Ok, looking back I see that I've started ranting. I honestly don't
have a problem with lisp the language - I love writing the code. If I
am doing a project on my own at home, I am happy to download and use
tools. I won't even read the copyrights and licenses (what I don't
know can't hurt me)! I know that doesn't work in a corporate
environment.
Maybe I'll follow Pascal's suggestion and start putting some things
together. I'm up in the middle of the night with a baby anyway.
Probably not, though. :)
Thanks for your thoughtful replies. I really do appreciate it
despite my grumping about a few things.
-Ben
Raffael Cavallaro
> Also, when I write a script that parses a log and pulls some key
> values into a csv file, it worries me that I pull in six different
> copyright and license dependencies. We are required to 'register' all
> these licenses with our legal department (the world is getting
> paraniod, isn't it?) so the lawyers can make sure we don't expose any
> proprietary code to an open source requirement. I hate this mindset,
> but I think it needs to be dealt with slowly (everything is slow in big
> companies) and asking to get a bunch of licenses approved to extract
> some data from a log is going to push them the other way.
wrt this issue I think it would be a big step forward for common lisp
if all contributed code were available under a single agreed-upon
license. Existing libraries could be relicensed under this common
common lisp license, new libraries would use it and users could just
look for this license and know that the code was ok to use without
legal headaches in commercial products or other commercial work.
Note that this leaves the gpl and lgpl right out for reasons relating
to Section 6 of the lgpl which are specified in the preamble of the
lisp lesser general public license (which wouldn't be a bad choice for
a common license imho):
<http://opensource.franz.com/preamble.html>
I'd like to hear what others think about this idea, and what features a
license would need to work as the "official" common common lisp license.
regards
Edi Weitz
> wrt this issue I think it would be a big step forward for common
> lisp if all contributed code were available under a single
> agreed-upon license. Existing libraries could be relicensed under
> this common common lisp license, new libraries would use it and
> users could just look for this license and know that the code was ok
> to use without legal headaches in commercial products or other
> commercial work.
>
> Note that this leaves the gpl and lgpl right out for reasons
> relating to Section 6 of the lgpl which are specified in the
> preamble of the lisp lesser general public license (which wouldn't
> be a bad choice for a common license imho):
> <http://opensource.franz.com/preamble.html>
>
> I'd like to hear what others think about this idea, and what
> features a license would need to work as the "official" common
> common lisp license.
From the point of view of someone who is using Lisp commercially I'd
say that Franz' LLGPL is the most restrictive license of those that
are still acceptable for commercial deployment. Many Lisp libraries
use it or are distributed under even more liberal terms (BSD or public
domain). I don't think any of these have to change.
As far as the GPL or certain idiosyncratic licenses (like, say, that
of CL-HTTP) are concerned it is my impression that usually the license
is used on purpose - I don't expect them to change it just to make a
couple of commercial developers happy.
Anyway, is this (apart from the technical LGPL/LLGPL distinction)
really Lisp-related?
Just my 0.02 EUR. IANAL. YMMV.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
JP Massar
>Lisp is older than you are. Lisp is older than most people posting to
>this group, if not all of them.
Yow! Just how old do you think Lisp is ?
Joe Marshall
> Lisp is older than you are. Lisp is older than most people posting to
> this group, if not all of them.
It's older than I am, but there are a few people in this group older
than Lisp. But I'd guess that it is older than most people posting
here.
Peter Seibel
>> Can you be a little bir more specific about "modern" and
>> "multiplatform"?
>
> I mean an environment running Solaris on suns, and linux on x86s, and
> windows on x86s, windows running cygwin, and maybe a Mac in a corner
> somewhere. I want to parse code and log files, and create source from
> data files, and automate builds. Stuff like that. I can probably
> force everyone to use clisp, but I can't be sure that they are all
> using the same version. If someone wants to use a different lisp
> interpreter, all of a sudden the system calls and several other,
> implementation unique, common tasks will fail.
> I've used the pathnames stuff from "Practical Common Lisp". It is
> nice and helpful, but I didn't see any notes anywhere about who is
> allowed to use that code for what purposes. I probably just missed
> that.
All the code from by book is under a BSD licence. (If you download the
tar.gz of all the code there should be a license file in there
somewhere.) Also Edi Weitz has packaged up the pathnames code as
CL-FAD (Files and Directories I think) which has some bug and
portability fixes relative to the book code. That lib is available
from his website and is also under a BSD license.
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
JP Massar
Lisp is older than most people, period.
But the earliest reference I found with a cursory Google search was
1959.
In which case I am sure there are people posting here who are older
than Lisp.
Raymond Laning
same problems, perhaps I can offer some useful experience. We ported
our software to about 15 different hardware platforms (including a Mac)
with almost as many operating systems and 4 different window systems.
We used only three CL implementations, with a beta port to a fourth. To
deal with these multiple headaches we created a Kosher package that
contained all system and windowing calls. We could put all the nasty
compiler directives dealing with implementation-specific stuff in two
files (system.lisp and windows.lisp) and not have to muck with the rest
of our code.
This was effective since our move from a Lisp Machine (Symbolics) to Sun
(using X-windows) took only about a man-month. Subsequent ports took
even less time. I should mention that ours was a system with a pretty
complex GUI, so that package was not trivial.
As for the legal issues, we lived in simpler times. We used Portable
Common Loops (public domain) until CLOS arrived.
Mostly we rolled our own utilities. Including an extensive Emacs/RCS
system for code maintainance. We kept our main development environment
on a Unix machine. I don't know if I can lay hands on that chunk of
Emacs lisp or not, otherwise I'd offer it to you.
HTH
Raymond Laning
Robert Uhl
>
> wrt this issue I think it would be a big step forward for common lisp
> if all contributed code were available under a single agreed-upon
> license. Existing libraries could be relicensed under this common
> common lisp license, new libraries would use it and users could just
> look for this license and know that the code was ok to use without
> legal headaches in commercial products or other commercial work.
>
> Note that this leaves the gpl and lgpl right out for reasons relating
> to Section 6 of the lgpl which are specified in the preamble of the
> lisp lesser general public license (which wouldn't be a bad choice for
> a common license imho): <http://opensource.franz.com/preamble.html>
Well, I for one won't release my code save under the GPL or _maybe_,
with a _really_ good reason, the LGPL. But my code is so poor and small
that I doubt anyone would care if I never released it at all, so my
opinion doesn't really matter.
BTW, as a wording nit-pick: the GPL and LGPL allow use in _commercial_
software; what they do not allow is use in _proprietary_ software.
Anyway, no effort to get everyone to co-operate on licenses will work:
you can't prevent folks from doing what they want, and this is a Good
Thing. For my part, I like the software commons provided by the GPL,
but others have other ideas.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Feet an' inches an' lines work best for house framin' work 'cause it is
awful damned hard to get the decimal in the wrong place.
--Jonathan R. Hatfield
Duane Rettig
> On Wed, 14 Sep 2005 13:49:59 -0400, Joe Marshall
> <jmar...@alum.mit.edu> wrote:
>
>>"jcrippen" <jcri...@gmail.com> writes:
>>
>>> Lisp is older than you are. Lisp is older than most people posting to
>>> this group, if not all of them.
>>
>>It's older than I am, but there are a few people in this group older
>>than Lisp. But I'd guess that it is older than most people posting
>>here.
>
>
> Lisp is older than most people, period.
This feels like a setup for a new saying and an analogy. Lisp is
dirt. People older than Lisp are older than dirt!
> But the earliest reference I found with a cursory Google search was
> 1959.
>
> In which case I am sure there are people posting here who are older
> than Lisp.
You think any of us would actually admit to it, though?
:-)
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Kenny Tilton
JP Massar wrote:
> On Wed, 14 Sep 2005 13:49:59 -0400, Joe Marshall
> <jmar...@alum.mit.edu> wrote:
>
>
>>"jcrippen" <jcri...@gmail.com> writes:
>>
>>
>>>Lisp is older than you are. Lisp is older than most people posting to
>>>this group, if not all of them.
>>
>>It's older than I am, but there are a few people in this group older
>>than Lisp. But I'd guess that it is older than most people posting
>>here.
>
>
>
> Lisp is older than most people, period.
>
>
> But the earliest reference I found with a cursory Google search was
> 1959.
Cursory indeed! :)
From http://citeseer.ist.psu.edu/mccarthy78history.html:
"Abstract: This paper concentrates on the development of the basic ideas
and distinguishes two periods - Summer 1956 through Summer 1958 when
most of the key ideas were developed (some of which were implemented in
the FORTRAN based FLPL), and Fall 1958 through 1962 when the programming
language was implemented and applied to problems of artificial
intelligence."
Me, I go with 1956 for the ideas. Other (stuffy) people will go for 1958
for the implementation. (To which I say, come one, the older it is the
cooler it is when it gets discovered in (apparently) 2006.)
>
> In which case I am sure there are people posting here who are older
> than Lisp.
Not likely; some say God used Lisp to create the universe, others think
the universe (including God) /is/ Lisp.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Hartmann Schaffer
> BTW, as a wording nit-pick: the GPL and LGPL allow use in _commercial_
> software; what they do not allow is use in _proprietary_ software.
are you sure about the lgpl? my understanding is that you can use
lgpled code in proprietary software, but the lgpled code itself must be
provided under the same license, i.e. you can keep the part that uses it
secret.
> ...
hs
Christophe Rhodes
> I'd like to hear what others think about this idea, and what
> features a license would need to work as the "official" common
> common lisp license.
I think that people release lisp code for many reasons, not all of
which are or should be subservient to the notion that other people
should be able to do whatever they want with such released lisp code.
Christophe
Raffael Cavallaro
> I think that people release lisp code for many reasons, not all of
> which are or should be subservient to the notion that other people
> should be able to do whatever they want with such released lisp code.
Absolutely. I have no argument with that at all. Your code is yours to
do with whatever you will.
That said, for those people whose intention *is* to have their code
used by others with as few restrictions as possible it would reduce
confusion and more importantly legal hassles in many contexts - large
corporations for example - if such code were all licensed identically.
Then the legal department could approve one license and establish
guidelines for using code licensed that way (how source would be
included in distributed products, how copyright notices are posted,
etc.) and *any* code licensed that way is now approved, now and in the
future.
The alternative is the need to run every single slightly different
license by your lawyers, and establish different guidelines for
conformance for that particular license. This process is a very real
time wasting impediment to the use of these libraries in many contexts.
Robert Uhl
True--I was inaccurate in my phrasing (which was picking a nit with the
OP, who stated that the (L)GPL prevent use in what he called
'commercial' software). Both allow use in commercial software; the LGPL
allows use in proprietary software; neither allows the protected code to
be made proprietary.
--
Robert Uhl <http://public.xdi.org/=ruhl>
For entertaining gas contamination I always liked concentrated sulphuric
acid and elemental iodine. The result of mixing these is a mixture of
gaseous iodine, hydrogen sulphide and sulphur dioxide, so it stinks,
stains everything, is poisonous and corrosive.
Robert Uhl
> used by others with as few restrictions as possible it would reduce
> confusion and more importantly legal hassles in many contexts - large
> corporations for example - if such code were all licensed
> identically. Then the legal department could approve one license and
> establish guidelines for using code licensed that way (how source
> would be included in distributed products, how copyright notices are
> posted, etc.) and *any* code licensed that way is now approved, now
> and in the future.
The solution is not to create Yet Another License, but to use one of the
existing ones: there is a continuum from GPL to LGPL to BSDL to public
domain, and I've yet to see a convincing argument for any other free
software license. As for proprietary licenses, they all differ for
various good reasons, and good luck trying to unify 'em.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.
Eric Hanchrow
might have a lot of what you want.
--
It's hard to ... explain [Lisp programming] ... without sounding
like a wacko.
-- Bill Clementson
Raffael Cavallaro
> The solution is not to create Yet Another License, but to use one of the
> existing ones: there is a continuum from GPL to LGPL to BSDL to public
> domain, and I've yet to see a convincing argument for any other free
> software license.
Except the LLGPL of course, but you meant to include that, right?
> As for proprietary licenses, they all differ for
> various good reasons, and good luck trying to unify 'em.
No need to unify them. Just ask authors to offer a single agreed upon
license as another licensing option. Obviously authors who have chosen
the GPL would be unlikely to also offer a BSD license as an option as
well, but authors who've already chosen a more liberal license might
well be willing to also offer/relicense their code under a single
agreed upon license as well.
The virtue here is simply standardization. Then a single run at the
lawyers is all that's needed to use a large body of existing (and
hopefully future) code. In addition future authors would know how to
license lisp code to ensure the most widespread use.
Thomas A. Russ
>
> JP Massar <mas...@alum.mit.edu> writes:
> > But the earliest reference I found with a cursory Google search was
> > 1959.
> >
> > In which case I am sure there are people posting here who are older
> > than Lisp.
>
> You think any of us would actually admit to it, though?
OK, I'll admit to being barely older than Lisp.
--
Thomas A. Russ, USC/Information Sciences Institute
Ray Dillinger
> Hartmann Schaffer <h...@hartmann.schaffernet> writes:
>
>>>BTW, as a wording nit-pick: the GPL and LGPL allow use in
>>>_commercial_ software; what they do not allow is use in _proprietary_
>>>software.
>>
>>are you sure about the lgpl? my understanding is that you can use
>>lgpled code in proprietary software, but the lgpled code itself must
>>be provided under the same license, i.e. you can keep the part that
>>uses it secret.
> True--I was inaccurate in my phrasing (which was picking a nit with the
> OP, who stated that the (L)GPL prevent use in what he called
> 'commercial' software). Both allow use in commercial software; the LGPL
> allows use in proprietary software; neither allows the protected code to
> be made proprietary.
It's my understanding that the LGPL requirement is simply to
provide to any licensed user of your software, on request, a
linkable image that they can link against a different version
of the LGPL'd libraries. It doesn't have to be source code,
and there's no restriction against forbidding the licensed
user from further distributing or sublicensing.
A certain amount of care might need to be taken in order to
defend against substitute libs written to actively subvert
some feature of your code that you may consider an important
part of the business transaction (like a "stub" library that
prevents the system from reporting usage statistics to your
server and thus enables cheating on the licensing agreement).
Otherwise there seems to be nothing in that that would
require disclosure of source, nor restrict one from selling
or distributing whatever form of the software one prefers,
nor encumber any code you write,
I don't know what property you require code to have in order
to consider it "Proprietary" vs "Commercial." Perhaps a few
definitions of terms would be in order?
Bear
Raffael Cavallaro
> It's my understanding that the LGPL requirement is simply to
> provide to any licensed user of your software, on request, a
> linkable image that they can link against a different version
> of the LGPL'd libraries. It doesn't have to be source code,
> and there's no restriction against forbidding the licensed
> user from further distributing or sublicensing.
Not quite so. Specifically you must allow the user to *modify* and
reverse engineer your app which uses an LGPL library even if you don't
provide your app as source code. Remember that historically the FSF was
born because Stallman wanted to modify applications he was using to
customize them for his purposes but he couldn't do so legally or
practically (no source code). So even though the LGPL speaks mostly
about ensuring that new versions of the library will work with your
app, the LGPL slides the much broader "modification of the work for the
customer's own use" clause in there as well. The only way around it is
to only dynamically link to an LGPL library. This is not an option for
lisp, hence the LLGPL. Here are the relevant portions of both licenses:
Section 5 of the LGPL which triggers section 6:
LGPL
" 5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."
LGPL requires app that statically links to an LGPL library as described
in section 5 above to allow user modification and reverse engineering:
"6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications."
Commentary:
For many companies this means that LGPL libraries are out of the
question - using them would require these companies to allow
modification of their proprietary applications and reverse engineering.
LLGPL specifically declares that section 6 of the LGPL is not
applicable to lisp libraries licensed under the LLGPL:
"Section 5 of the LGPL distinguishes between the case of a library
being dynamically linked at runtime and one being statically linked at
build time. Section 5 of the LGPL states that the former results in an
executable that is a "work that uses the Library." Section 5 of the
LGPL states that the latter results in one that is a "derivative of the
Library", which is therefore covered by the LGPL. Since Lisp only
offers one choice, which is to link the Library into an executable at
build time, we declare that, for the purpose applying the LGPL to the
Library, an executable that results from linking a "work that uses the
Library" with the Library is considered a "work that uses the Library"
and is therefore NOT covered by the LGPL.
Because of this declaration, section 6 of LGPL is not applicable to the
Library. However, in connection with each distribution of this
executable, you must also deliver, in accordance with the terms and
conditions of the LGPL, the source code of Library (or your derivative
thereof) that is incorporated into this executable."
This is why the LLGPL is imho more suitable for lisp code than the LGPL.
regards
Christophe Rhodes
> Commentary:
> For many companies this means that LGPL libraries are out of the
> question - using them would require these companies to allow
> modification of their proprietary applications and reverse engineering.
Does this commentary come from an informed view of the world, or is it
speculation?
As a supplementary question, in which jurisdictions has a licence
agreement prohibiting application modification or reverse engineering
been enforced?
Christophe
Robert Uhl
>
> I don't know what property you require code to have in order to
> consider it "Proprietary" vs "Commercial." Perhaps a few definitions
> of terms would be in order?
The accepted definitions are roughly that proprietary software isn't
free--the source code is not available, or cannot be redistributed, or
modified--and that commercial software is sold for money. That is,
proprietary software has a proprietor and commercial software is an
object of commerce. The categories are orthogonal: Microsoft Windows is
both proprietary and commercial; Red Hat Linux is non-proprietary and
commercial; the Linux kernel is non-proprietary and non-commercial;
certain little bits of freeware are proprietary but non-commercial.
--
Robert Uhl <http://public.xdi.org/=ruhl>
When PCs run new applications successfully, most people feel relief
and almost pathetic gratitude--a standard of reliability tolerated in
no other consumer product. --Economist, 12 Sept. 1998
Raffael Cavallaro
> Does this commentary come from an informed view of the world, or is it
> speculation?
It comes from consulting actual corporate lawyers.
>
> As a supplementary question, in which jurisdictions has a licence
> agreement prohibiting application modification or reverse engineering
> been enforced?
The US Court of Appeals for the Eighth Circuit has ruled that:
1. by clicking "I Agree" one can be bound by a EULA which removes
rights one would otherwise normally have, in this particular case
including reverse engineering and modifcation. From the ruling:
"By signing the TOUs and EULAs, Appellants expressly relinquished their
rights to reverse engineer." ("signing" in this sentence means clicking
"I Agree")
The EULA, found to be a valid, enforceable contract, freely entered
into by both parties, in addition to reverse engineering and
modification, also prohibits copying, photocopying, reproducing,
translating, deriving source code, disassembling, decompiling, the
creation of derivative works, and the removal of any labels.
2. the interoperability exception of the DMCA does not apply if your
reverse engineered, interoperable program allows infringing use of the
program you interopereate with.
The actual decision:
<http://www.eff.org/IP/Emulation/Blizzard_v_bnetd/20050901_decision.pdf>
The EFF's view of how bad it is:
<http://www.eff.org/news/archives/2005_09.php> (see the entry for Sept. 1)
Though not the US Supreme Court, a US Court of Appeals ruling is not
one that any corporate lawyers I know would advise thier clients to fly
in the face of.
Bottom line: EULAs that prohibit reverse engineering and/or
modification are enforceable in the US.
Ray Dillinger
> On 2005-09-19 13:04:31 -0400, Ray Dillinger <be...@sonic.net> said:
>
>> It's my understanding that the LGPL requirement is simply to
>> provide to any licensed user of your software, on request, a
>> linkable image that they can link against a different version
>> of the LGPL'd libraries. It doesn't have to be source code,
>> and there's no restriction against forbidding the licensed
>> user from further distributing or sublicensing.
>
>
>
> Not quite so. Specifically you must allow the user to *modify* and
> reverse engineer your app which uses an LGPL library even if you don't
> provide your app as source code.
So? It doesn't require you to provide support for the modified
versions, nor permit them to release modified versions in
competition with your product. And if said modification permits
an infringing or unlicensed use of your products or servers,
it's illegal anyway. So the activity protected by this license
is people making non-infringing changes for their own use in
software they bought from you for their own use. I don't see
a problem with that.
Bear
Raffael Cavallaro
> So the activity protected by this license
> is people making non-infringing changes for their own use in
> software they bought from you for their own use. I don't see
> a problem with that.
Not just modification - the activities which must be permitted are
*reverse engineering* for the purpose of modification and the
modification itself. Those are two things - reverse engineering and
modification - that many proprietary software developers specifically
wish to prohibit in their licenses and frequently do. As mentioned
elswhere in this thread, such EULA prohibitions have recently been
found to be legally enforceable in the US so one would expect they will
become even more common in the future. This effectively makes many
proprietary licenses and the LGPL incompatible.
josh g.
> I saw a lot of libraries that supported this stuff out there, but I
> am writing tools for work, and I didn't want to worry about 8 different
> licenses and copyrights for a couple tools.
> Now I'm wondering if there is a "Lisp power package" out there.
> Something that puts those library tools all in one place with a common
> license. It works under Linux, and Windows, and Solaris, and Cygwin.
I don't know if this is exactly what Ben has in mind, but I would love
to see a Lisp version of Perl's PPM and CPAN. I miss the quick
centralized search, and the one-step download-install-setup.
I suppose that such a beast would be made more complicated by the fact
that there are differing implementations, though.
- josh g.
Thomas F. Burdick
This is a horrid idea, and I'm glad it has basically no chance of
happening. GPL libraries are essentially impossible to use in a
corporate context. LLGPL is usable, but it does imply additional
overhead, so if it's not (much) more work to roll your own instead of
using an LLGPL library, that might be the easiest. No need to
struggle with the lawyers. BSD and MIT licensed libraries are easily
usable, and it's no problem to throw a bunch of little liberally
licensed libraries into a project.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Raffael Cavallaro
Burdick) said:
> This is a horrid idea, and I'm glad it has basically no chance of
> happening.
You're right what was I thinking - we wouldn't want to standardize
something as complex as licensing - just let everyone work it out for
themselves...
> GPL libraries are essentially impossible to use in a
> corporate context. LLGPL is usable, but it does imply additional
> overhead, so if it's not (much) more work to roll your own instead of
> using an LLGPL library, that might be the easiest. No need to
> struggle with the lawyers.
Absolutely - as you say everyone can just roll their own. Then we don't
have to worry about libraries at all.
Robert Uhl
>
> GPL libraries are essentially impossible to use in a corporate
> context.
Hardly--GPLed libraries are used in many corporate contexts. They're
not used in much proprietary software (shouldn't be used in _any_, but
some folks are dishonest), but plenty of corporations use GPL libraries,
and plenty of corporations use GPLed libraries in their (GPLed)
software.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Familiarity doesn't breed contempt; familiarity _is_ contempt. --Florence King
Thomas F. Burdick
Okay, you're going in the killfile for that one. For the record, the
dishonest, distorting cut made to my post was to remove this:
Mark Carter
> I really like lisp. I played with it a few months back, and found
> the syntax natural and easy to write. What I did not find easy was
> programming in a modern, multiple platform environment. I want regular
> expressions, I want powerful string parsing, natural pathnames, network
> streams, network protocols, and on and on.
I am a n00b at Lisp. It's the sort of thing that I play with for a
little while, and then forget about when I can't figure out anything I'd
like to do with it.
I always thought that what lisp could do with is a damn good dose of
integration. In my latest whirl on the lisp merry-go-round, I actually
managed to get GUI (wxCL) and ODBC (plain-odbc) packages going on CLISP
on Windows. There's an SMTP library that works on CLISP, and probably a
regex library, too. I reckon that if I shovel all this in a box, close
the lid really quickly, and make it available on the internet, then I'm
thinking that it would be very popular. And I'm tempted to do it, too.
I agree with your comments about licenses. What people want is a nice
BSD license where they can just do pretty much whatever they want. I
wouldn't be able to offer this, though, as I'm basically just
integrating other packages, which have their own (mostly GPL) licenses.
Raffael Cavallaro
Burdick) said:
> BSD and MIT licensed libraries are easily usable, and it's no
> problem to throw a bunch of little liberally licensed libraries into
> a project.
Sorry you object to that cut, but since we were discussing how to use
*less* liberally licensed libraries (such as code under the LGPL) the
ease of use of BSD and MIT licensed libraries is irrelevant. If all
lisp code were licensed as BSD or MIT then we wouldn't be having this
discussion at all. If you feel the need to killfile me for not quoting
that last sentence and then merely appending my own comment of
"irrelevant," then go for it.
The point stands - to advise rolling one's own if a license is too
restrictive defeats the whole purpose of libraries. I still maintain
that asking as many authors as are willing to add the option to license
under a more liberal license than GPL or LGPL (such as the LLGPL) would
make more lisp libraries usable by more people in more projects and is
therefore a reasonable thing to want not a "horrid idea." Moreover, it
would encourage future authors to license their code under a more
widely usable license.
regards
Ray Dillinger
> t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>>GPL libraries are essentially impossible to use in a corporate
>>context.
> Hardly--GPLed libraries are used in many corporate contexts. They're
> not used in much proprietary software (shouldn't be used in _any_, but
> some folks are dishonest), but plenty of corporations use GPL libraries,
> and plenty of corporations use GPLed libraries in their (GPLed)
> software.
Lots of companies use GPL'd libraries to build software
that they never release to the public. Little utilities
to read app-server logs and print statistics, etc. If
you don't ever release it to anybody else, none of the GPL
burdens on your code are ever invoked.
I think this unreleased software is "proprietary" as it
belongs to the company and is used in the course of their
business. I'm pretty sure you mean something else by the
word, but I'm still not sure what.
Bear
Thomas F. Burdick
>
> >>GPL libraries are essentially impossible to use in a corporate
> >>context.
I should probably add more context here: GPL libraries are essentially
impossible to use if you are producing products or potential products
in a corporate context. Ie, not as a part of a small consulting firm
(done that, and GPL software works great there), and not for
purely-internal use (where it's fine as well); I mean when you're
working on something that is or could become a Real Product for a
corporation. Basically, industrial use, not artisinal use.
> Robert Uhl wrote:
>
> > Hardly--GPLed libraries are used in many corporate contexts. They're
> > not used in much proprietary software (shouldn't be used in _any_, but
> > some folks are dishonest), but plenty of corporations use GPL libraries,
> > and plenty of corporations use GPLed libraries in their (GPLed)
> > software.
*AHEM*. "Many"? "A few" certainly, but I doubt "many".
Ray Dillinger <be...@sonic.net> writes:
> Lots of companies use GPL'd libraries to build software
> that they never release to the public. Little utilities
> to read app-server logs and print statistics, etc. If
> you don't ever release it to anybody else, none of the GPL
> burdens on your code are ever invoked.
>
> I think this unreleased software is "proprietary" as it
> belongs to the company and is used in the course of their
> business. I'm pretty sure you mean something else by the
> word, but I'm still not sure what.
Probably he meant "proprietary" in the sense I tried to clarify above.
Not that I'm saying people *shouldn't* GPL their software, if that's
what they want. At least it's a license that many software engineers
understand and are comfortable with. Just, if you're releasing your
software to the public, think about *why* you're doing that. Maybe
you don't want to share at all. Maybe you think you have a gem, and
you want to prevent someone from turning around and productizing it
out from under you (in which case, GPL is great). Maybe you have a
really useful GUI library that you want people to use, and you want
their changes to come back into the main branch, or at least make it
hard for someone to make a proprietary fork -- the LLGPL is perfect
for LTK, for example. Or maybe you just have a tool that you want to
share, and let people do with as they want, in which case BSD or MIT
licenses are a good solution.
I think the Lisp authors of freely available software have turned a
wonderful corner in the last 10 years. If you look in the CMU AI
repository, there is all sorts of useful code in there under weird
licenses. One-off licenses where people want you to send them a
postcard or specifically not charge for the software, or only use it
for educational purposes, or all kinds of odd things. Got a piece of
software? Great, make up some bizzare license of your own, and ship
it out to the world to share! Parser-generators that are GPL'd for
godsakes, meaning whatever it is you wanted to use the generated
parser in is now subject to the GPL -- as though parsing were the most
interesting thing it was going to do!
Nowadays, there's a little bit of Public Domain code, but mostly BSD
or MIT licenses, LLGPL, LGPL or GPL. Not to mention source-available
commercial products. That's a spectrum we can all handle -- it gives
authors enough room to express their wishes for their creations, while
compromising with the users by limiting the licenses to a few known
categories. Am I the only one impressed by the status quo here? I
can now type (asdf-install:install :thingy-lib), which will find it
online, download it, build it, and make it available to me in any of
the three or so implementations I routinely use. I can look in the
asd file and in several seconds I can usually determine if the license
terms are something I can live with. Some more infrastructure woudn't
hurt, and it's still not as nice as Squeak (Smalltalk envy may well be
eternal), but now even things like lexer-generators and date/time
parsers are easier to reuse than to write my own! This is news! Lisp
is very productive, little things like this are extremely easy to
write in it, and those of us who were writing commercial CL software
in the late '90's (as far back as I can vouch for) have re-written
these things a million times, because it was easier. No longer!
[ Ahem, (decf (overenthuziasm *lisp-community*)) ]
Pascal Bourguignon
> I think this unreleased software is "proprietary" as it
> belongs to the company and is used in the course of their
> business. I'm pretty sure you mean something else by the
> word, but I'm still not sure what.
Let's call it "secret" and reserve "proprietary" to software
distributed to the public.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
Karl A. Krueger
>> > t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>> >>GPL libraries are essentially impossible to use in a corporate
>> >>context.
>
> I should probably add more context here: GPL libraries are essentially
> impossible to use if you are producing products or potential products
> in a corporate context. Ie, not as a part of a small consulting firm
> (done that, and GPL software works great there), and not for
> purely-internal use (where it's fine as well); I mean when you're
> working on something that is or could become a Real Product for a
> corporation. Basically, industrial use, not artisinal use.
Every corporation that produces or resells a Linux distribution is a
counterexample to your claim.
--
Karl A. Krueger <kkru...@example.edu> { s/example/whoi/ }
Pascal Bourguignon
Indeed! This is the success of the GPL: making corporations produce
open software.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Peter Herth
Of course there are some companies, which have a business model geared
around selling GPL software (though notice how few companies are left
that sell Linux distributions...). But most companies are not centered
around GPL in their business model, and for those, GPL libraries are a
big no-no.
I am not trying to badmouth GPL, I think its a great idea and for
example I attribute the success of Linux to a no small part of it being
licensed under GPL - and the wide adoption of Linux in the business
world shows that GPL works for products where it fits. So the company I
am working in is using Linux, but for my development work, GPL cannot
be used. LLGPL on the other side works nicely. So, as Thomas already
said, it is very important that authors carefully choose their licenses.
There is no "good" or "bad" license, but only good and bad choices :)
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Robert Uhl
>
>> Robert Uhl wrote:
>>
>> > Hardly--GPLed libraries are used in many corporate contexts.
>> > They're not used in much proprietary software (shouldn't be used in
>> > _any_, but some folks are dishonest), but plenty of corporations
>> > use GPL libraries, and plenty of corporations use GPLed libraries
>> > in their (GPLed) software.
>
> *AHEM*. "Many"? "A few" certainly, but I doubt "many".
The number of corporations dealing with GPLed code is not small. Red
Hat and MySQL AB (I think that's the name...) leap to mind. Both are
corporations. IBM uses GPLed libraries!
--
Robert Uhl <http://public.xdi.org/=ruhl>
I really have to hand it to Fox this time, they've hit an all new low.
And I just love new lows. They remind me that progress is growth, and
growth is a two way street. --Rick Felice
Lars Brinkhoff
> Lisp is older than you are. Lisp is older than most people posting
> to this group, if not all of them.
Even the preferred Lisp editor, Emacs, is probably older than quite a
few of the posters, even though it's much younger than Lisp.