I searched the group archives and the hyperspec but found nothing on
this...
Is there a reasonably portable (standards compliant or widely accepted)
method to identify Common Lisp implementations? (i.e. through CL code
while said implementation is actually running?)
My goal is build an abstraction layer for the handful of simple and
common but non-portable code chunks that I need to use. I'd prefer to
identify the CL implementation while it is running rather than force the
user to edit a config file.
I still need to dig through the documentation of various implementations
to figure a few things out but if you happen to know the implementation
specific ways execute shell commands or how to access the command line
args for the implementations listed below (or others), it will save me
some time on the digging.
;-----------------------------------------------------------------------
; Create Common Lisp implementation portability abstractions
; how to get command line arguments?
; how to execute shell commands?
(defun cl-portability-layer (lisp-type)
(setf (symbol-function 'toaster) #'init-load-rel-data)
(toaster)
(cond
((string= lisp-type "allegocl")
(format t "~%Using Common Lisp Implementation: AllegroCL")
;how to get command line arguments
;how to execute shell commands
)
((string= lisp-type "clisp")
(format t "~%Using Common Lisp Implementation: CLISP")
;how to get command line arguments
(setf CLI_ARGS EXT:*ARGS*)
(format t "~%CLI_ARGS: ~A" CLI_ARGS)
;how to execute shell commands
(setf (symbol-function 'SHELL_EXEC) #'EXT:RUN-SHELL-COMMAND)
;(setf (symbol-function 'SHELL_EXEC) #'EXT:SHELL) ;another way
)
((string= lisp-type "cmucl")
(format t "~%Using Common Lisp Implementation: CMUCL")
;how to get command line arguments
;how to execute shell commands
)
((string= lisp-type "lispworks")
(format t "~%Using Common Lisp Implementation: LispWorks")
;how to get command line arguments
;how to execute shell commands
)
((string= lisp-type "sbcl")
(format t "~%Using Common Lisp Implementation: SBCL")
;how to get command line arguments
;how to execute shell commands
)
;other implementations...
(t
(setq tmpstr (concatenate 'string
"Unknown Common Lisp Implementation: "
(format nil "\"~A\"" lisp-type)
(format nil "~%Please See...")))
(on-error tmpstr))))
(cl-portability-layer "clisp")
Shameless plug.
CL-ENVIRONMENT in the CLOCC.
http://sourceforge.net/project/showfiles.php?group_id=1802&package_id=7259
Cheers
--
Marco
J.C. Roberts wrote:
> I searched the group archives and the hyperspec but found nothing on
> this...
>
> Is there a reasonably portable (standards compliant or widely accepted)
> method to identify Common Lisp implementations? (i.e. through CL code
> while said implementation is actually running?)
>
> My goal is build an abstraction layer for the handful of simple and
> common but non-portable code chunks that I need to use. I'd prefer to
> identify the CL implementation while it is running rather than force the
> user to edit a config file.
>
> I still need to dig through the documentation of various implementations
> to figure a few things out but if you happen to know the implementation
> specific ways execute shell commands or how to access the command line
> args for the implementations listed below (or others), it will save me
> some time on the digging.
>
> ;-----------------------------------------------------------------------
> ; Create Common Lisp implementation portability abstractions
> ; how to get command line arguments?
> ; how to execute shell commands?
> (defun cl-portability-layer (lisp-type)
> (setf (symbol-function 'toaster) #'init-load-rel-data)
> (toaster)
> (cond
> ((string= lisp-type "allegocl")
> (format t "~%Using Common Lisp Implementation: AllegroCL")
> ;how to get command line arguments
> ;how to execute shell commands
> )
> ((string= lisp-type "clisp")
> (format t "~%Using Common Lisp Implementation: CLISP")
> ;how to get command line arguments
> (setf CLI_ARGS EXT:*ARGS*)
> (format t "~%CLI_ARGS: ~A" CLI_ARGS)
> ;how to execute shell commands
> (setf (symbol-function 'SHELL_EXEC) #'EXT:RUN-SHELL-COMMAND)
> ;(setf (symbol-function 'SHELL_EXEC) #'EXT:SHELL) ;another way
> )
> ((string= lisp-type "cmucl")
> (format t "~%Using Common Lisp Implementation: CMUCL")
> ;how to get command line arguments
> ;how to execute shell commands
> )
> ((string= lisp-type "lispworks")
> (format t "~%Using Common Lisp Implementation: LispWorks")
> ;how to get command line arguments
> ;how to execute shell commands
> )
> ((string= lisp-type "sbcl")
> (format t "~%Using Common Lisp Implementation: SBCL")
> ;how to get command line arguments
> ;how to execute shell commands
> )
> ;other implementations...
> (t
> (setq tmpstr (concatenate 'string
> "Unknown Common Lisp Implementation: "
> (format nil "\"~A\"" lisp-type)
> (format nil "~%Please See...")))
> (on-error tmpstr))))
>
>
> (cl-portability-layer "clisp")
>
> * J.C. Roberts <···············@nonp.pbz> [2005-11-14 04:56:06 -0800]:
>
> Is there a reasonably portable (standards compliant or widely
> accepted) method to identify Common Lisp implementations?
others have already pointed you to read-time conditionals.
> My goal is build an abstraction layer for the handful of simple and
> common but non-portable code chunks that I need to use.
please take a look at CLOCC/PORT.
see http://clocc.sf.net
http://clocc.sourceforge.net/dist/port.html
--
Sam Steingold (http://www.podval.org/~sds) running w2k
http://pmw.org.il/ http://www.openvotingconsortium.org/
http://www.iris.org.il http://www.camera.org http://truepeace.org
UNIX is as friendly to you as you are to it. Windows is hostile no matter what.
On Mon, 14 Nov 2005 11:23:49 -0500, Sam Steingold <···@gnu.org> wrote:
>> * J.C. Roberts <···············@nonp.pbz> [2005-11-14 04:56:06 -0800]:
>>
>> Is there a reasonably portable (standards compliant or widely
>> accepted) method to identify Common Lisp implementations?
>
>others have already pointed you to read-time conditionals.
>
Yes, these are going to be very useful.
>> My goal is build an abstraction layer for the handful of simple and
>> common but non-portable code chunks that I need to use.
>
>please take a look at CLOCC/PORT.
>see http://clocc.sf.net
>http://clocc.sourceforge.net/dist/port.html
Hi Sam,
It's a very nobel idea to keep everyone from recreating the wheel by
providing a free portability abstraction layer between various common
lisp implementations. If done well, you end up with a de facto standard
by accepted usage and adoption rather than a ratified official standard
from some standards body.
(sigh... here we go again...)
I would absolutely love to use the CLOCC PORT code but unfortunately,
even if CLOCC PORT code is beautifully written, the LGLP license it is
under still prevents it from ever becoming a de facto standard through
adoption because it cannot be incorporated into closed source software
without substantial legal risk.
1.) Both the GNU GPL and LGPL are legally ambiguous when applied to lisp
2.) I can't afford to multiple lawyers to do legal analysis of licenses.
3.) I can't afford to take necessary legal risks inviting law suits.
4.) Most software companies are in the same situation I am.
You probably do not agree that the GPL and LGPL are legally ambiguous
when applied to lisp variant languages but since neither of us are
willing to pay the bar tab to find out, the only proper due diligence I
can preform is to avoid the "potential" risks completely.
Just as you are dedicated to promoting the agenda of the GNU, in
contrast, I am equally dedicated to making certain my software is
licensed so it is as useful as possible to any person for any purpose
and without unnecessary legal risk or expense.
I also want people to be free to use whatever CL implementation they
want, including CLISP and other GNU licensed CL implementations. There
might be some company that wants to use my programs with your CL
implementation in their internal processes. There might be some company
that wants to use my code to create a closed source product and wants to
use a commercial CL implementation like Allegro or LispWorks. But most
importantly there might be a developer somewhere in this world who wants
to contribute to the project but can't afford a commercial CL
implementation and can't run CMUCL or SBCL because they only have access
to a MS-Windows operating system.
Since I can not incorporate the CLOCC PORT code without incurring
expense and risk, the only responsible choice I have available is to
create YET ANOTHER compatibility layer for CL implementations and put it
under an unrestricted license. Ironically, creating a new open source
compatibility layer only creates YET ANOTHER incompatibility in the
Common Lisp world.
The smart answer is to stop forcing people to reinvent the wheel and
stop splintering CL compatibility by placing the CLOCC-PORT under an
unrestrictive license so everyone can use it and it can become a de
facto standard.
Kind Regards,
JCR
> * J.C. Roberts <···············@nonp.pbz> [2005-11-14 19:12:08 -0800]:
>
> I would absolutely love to use the CLOCC PORT code but unfortunately,
> even if CLOCC PORT code is beautifully written, the LGLP license it is
> under still prevents it from ever becoming a de facto standard through
> adoption because it cannot be incorporated into closed source software
> without substantial legal risk.
please stop spreading the FUD.
CLOCC/PORT was specifically designed to isolate programs from
implementations (and their licenses), and its license is specifically
designed not to affect programs.
you do not need to invent an excuse not to use CLOCC/PORT (or CLISP or
whatever) - just don't use it.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
http://www.savegushkatif.org http://pmw.org.il/ http://www.iris.org.il
http://www.palestinefacts.org/ http://www.dhimmi.com/ http://www.camera.org
WHO ATE MY BREAKFAST PANTS?
On Tue, 15 Nov 2005 09:10:08 -0500, Sam Steingold <···@gnu.org> wrote:
>> * J.C. Roberts <···············@nonp.pbz> [2005-11-14 19:12:08 -0800]:
>>
>> I would absolutely love to use the CLOCC PORT code but unfortunately,
>> even if CLOCC PORT code is beautifully written, the LGLP license it is
>> under still prevents it from ever becoming a de facto standard through
>> adoption because it cannot be incorporated into closed source software
>> without substantial legal risk.
>
>please stop spreading the FUD.
>CLOCC/PORT was specifically designed to isolate programs from
>implementations (and their licenses), and its license is specifically
>designed not to affect programs.
>
>you do not need to invent an excuse not to use CLOCC/PORT (or CLISP or
>whatever) - just don't use it.
If the LGPL licensing of the CLOCC/PORT code was actually clear, it
would already be integrated into every CL implementation as the de facto
portability abstraction. Since it has not been integrated everywhere,
you need to ask yourself why?
Yes, there is a degree of legal uncertainty about the use of GPL and
LGPL licenses on lisp variant code. And yes, the uncertainty does cause
fear and doubt for those who wish to respect the licensing.
Guess why Franz Inc was forced to create their own "LispLGPL" (LLGPL)
license? -They are just trying to be responsible about potential legal
problems caused by the LGPL not addressing how lisp variants work.
The GNU is currently working on Version 3 of their licenses. You are
part of the GNU and hopefully the GNU will listen to a suggestion from
you to clarify/correct their licenses in regards to lisp variant code.
Just ask the GNU to address lisp code issues and you'll solve a
significant problem for everyone who is trying to be responsible about
potential legal problems in software licensing. Nobody wants to stomp on
the GNU or it's rights (well, besides the jerks at microsoft)
intentionally or through ignorance, and making your licensing clear will
only help people respect your rights.
Kind Regards,
JCR
> * J.C. Roberts <···············@nonp.pbz> [2005-11-15 09:46:35 -0800]:
>
> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
> would already be integrated into every CL implementation as the de
> facto portability abstraction. Since it has not been integrated
> everywhere, you need to ask yourself why?
if lisp is so great, linux and windows would have been implemented in it.
since lisp is actually not used by anyone, you need to ask yourself why?
--
Sam Steingold (http://www.podval.org/~sds) running w2k
http://pmw.org.il/ http://www.jihadwatch.org/ http://www.camera.org
http://www.palestinefacts.org/ http://truepeace.org http://ffii.org/
Save the whales, feed the hungry, free the mallocs.
On Tue, 15 Nov 2005 12:54:19 -0500, Sam Steingold <···@gnu.org> wrote:
>> * J.C. Roberts <···············@nonp.pbz> [2005-11-15 09:46:35 -0800]:
>>
>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>> would already be integrated into every CL implementation as the de
>> facto portability abstraction. Since it has not been integrated
>> everywhere, you need to ask yourself why?
>
>if lisp is so great, linux and windows would have been implemented in it.
>since lisp is actually not used by anyone, you need to ask yourself why?
Sam,
Please, there's no need for the nonsense. I'm not here to fight you or
disrespect the terms under which you license your work. I've been a bit
of pain only in an attempt to be responsible about the legal aspects of
your licensing.
If you really think licenses should be blatantly ignored, then just put
all your code into the public domain and it will no longer be an issue
for anyone. If think licenses should be respected, then you need to
clarify your licensing terms so your code will be more useful and
useable.
JCR
> * J.C. Roberts <···············@nonp.pbz> [2005-11-15 10:22:32 -0800]:
>
> If you really think licenses should be blatantly ignored, then just
> put all your code into the public domain and it will no longer be an
> issue for anyone. If think licenses should be respected, then you need
> to clarify your licensing terms so your code will be more useful and
> useable.
Murphy's law prevents clarifying the licensing terms to the degree that
everyone understands them. I tried.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
http://www.camera.org http://www.dhimmi.com/ http://pmw.org.il/
http://truepeace.org http://www.openvotingconsortium.org/
If you try to fail, and succeed, which have you done?
On Tue, 15 Nov 2005 15:05:50 -0500, Sam Steingold <···@gnu.org> wrote:
>> * J.C. Roberts <···············@nonp.pbz> [2005-11-15 10:22:32 -0800]:
>>
>> If you really think licenses should be blatantly ignored, then just
>> put all your code into the public domain and it will no longer be an
>> issue for anyone. If think licenses should be respected, then you need
>> to clarify your licensing terms so your code will be more useful and
>> useable.
>
>Murphy's law prevents clarifying the licensing terms to the degree that
>everyone understands them. I tried.
>
I appreciate that you tried.
Thanks,
JCR
On Tue, 15 Nov 2005 19:22:32 +0100, J.C. Roberts
<···············@abac.com> wrote:
> On Tue, 15 Nov 2005 12:54:19 -0500, Sam Steingold <···@gnu.org> wrote:
>
>>> * J.C. Roberts <···············@nonp.pbz> [2005-11-15 09:46:35 -0800]:
>>>
>>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>>> would already be integrated into every CL implementation as the de
>>> facto portability abstraction. Since it has not been integrated
>>> everywhere, you need to ask yourself why?
>>
>> if lisp is so great, linux and windows would have been implemented in
>> it.
>> since lisp is actually not used by anyone, you need to ask yourself why?
>
> Sam,
>
> Please, there's no need for the nonsense. I'm not here to fight you or
> disrespect the terms under which you license your work. I've been a bit
> of pain only in an attempt to be responsible about the legal aspects of
> your licensing.
>
> If you really think licenses should be blatantly ignored, then just put
> all your code into the public domain and it will no longer be an issue
> for anyone. If think licenses should be respected, then you need to
> clarify your licensing terms so your code will be more useful and
> useable.
>
> JCR
Given that the authors of the library clearly want the source to
be available and usable also in commercial applications.. Yes
Exactly who is going to sue you?
Even if the wording of the LGPL is dubious the intention
of the creators is not. But if you have to be doubly sure
track down the original authors and make a separate contract.
I feel you are all to quick to dismiss it over what I consider
a technicality.
I haven't read the wording of LGPL in a while but I seem to remember
that it states that the library can be used in a commercial setting
provided changes TO THE LIBRARY are made publicly available.
Ie. though the library code is shared the program using the code
can still be proprietary. People have been developing commercial
code with gcc for years and I have never heard of any lawsuits.
That is because the C libraries are LGPL.
Now, say, EMACS is GPL. That means all changes to the code have
to be made publicly available. It is in other words not legal
to create a new EMACS based on the existing code and the sell it
commercially.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> Given that the authors of the library clearly want the source to
> be available and usable also in commercial applications.. Yes
> Exactly who is going to sue you?
> Even if the wording of the LGPL is dubious the intention
> of the creators is not. But if you have to be doubly sure
> track down the original authors and make a separate contract.
> I feel you are all to quick to dismiss it over what I consider
> a technicality.
Well, if you work in a commercial environment, the little details
of the licenses make a *huge* difference. Who would sue a company
that violates e.g. the LGPL? Probably not the author, so probably
noone - or just a nasty competitor who uses this as means to hurt
your company. That is the reason the LLGPL was created, to give
a safe alternative appliccable to Lisp.
> Now, say, EMACS is GPL. That means all changes to the code have
> to be made publicly available. It is in other words not legal
> to create a new EMACS based on the existing code and the sell it
> commercially.
Well, any work based on the EMACS source, is bound to the GPL. While
it is legal to sell GPL based software, it is not a huge business as
everyone buying a copy has then the rights to copy it as often as he
wants. So most software companies handle GPLed stuff only veeerryyy
carefully.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Peter Herth wrote:
>
> Well, if you work in a commercial environment, the little details
> of the licenses make a *huge* difference. Who would sue a company
> that violates e.g. the LGPL? Probably not the author, so probably
> noone - or just a nasty competitor who uses this as means to hurt
> your company.
A competitor can't sue for breach of copyright. It's a matter purely
between the copyright holder and the infringer. If the copyright holder
doesn't want to assert his rights, that's up to him.
On Tue, 15 Nov 2005 21:04:15 +0000, Mark Carter <··@privacy.net> wrote:
>Peter Herth wrote:
>
>>
>> Well, if you work in a commercial environment, the little details
>> of the licenses make a *huge* difference. Who would sue a company
>> that violates e.g. the LGPL? Probably not the author, so probably
>> noone - or just a nasty competitor who uses this as means to hurt
>> your company.
>
>A competitor can't sue for breach of copyright. It's a matter purely
>between the copyright holder and the infringer. If the copyright holder
>doesn't want to assert his rights, that's up to him.
You are exactly correct about who the matter is between, but this is the
exact reason why the GNU/FSF encourages authors to assign copyrights to
the GNU/FSF (i.e. so the GNU/FSF can file the infringement law suits).
Follow the money trail. One of Peters' competitors wants to damage his
company. The competitor contacts the GNU/FSF to complain how Peter is
"STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
looks into it and sure enough Peter is using GPL/LGPL lisp software and
just by using the GLP/LGPL code in his closed source products, Peter is
in a legal gray zone because the way lisp variants actually work is not
properly covered by the licenses.
The GNU/FSF might want to play it safe by investigating further but
since they don't have access to Peters' code, they need to get access to
it through the legal system. So the GNU/FSF asks the author of the
GPL/LGPL code to transfer the copyrights to the organization so they can
proceed with filing lawsuits to do discovery.
Who knows what would happen next? There may or may not be a violation of
the GPL/LGPL in Peters' products, none the less, his competitor has
already done a good job of damaging Peters' company even if Peter did
nothing wrong.
There's also another side to it...
Peter Herth is also correct that the little details of licenses make a
"huge" difference in a commercial environment but not for just the
reason he stated. Let's assume all of the source code used by Microsoft
to create their products was legally declared to be owned by someone
else. What would be the valuation of Microsoft as a company be?
The valuation of Microsoft as a company is based on their ownership of
their source code. If for any reason their ownership is considered
legally questionable (yes, usually via a lawsuit from someone they
ripped off), the valuation of the company is negatively affected.
The primary goal of the GNU is to keep source code available to the
public, so the two GNU licenses (GPL and LGPL) are specifically designed
to enforce the disclosure of source code on any derivative works made
available in binary form. It's a wonderful concept but it doesn't mix
well with the goals of closed source, commercial software vendors.
If Microsoft decided to integrate GPL/LGPL code into their products, it
calls into question their ownership of the result. Who is to say
Microsoft followed all the terms of the GPL/LGPL license perfectly? How
would you know without the expense of highering a very large team of
very talented reverse engineers or somehow getting the access needed to
inspect all of the Microsoft source code and build processes?
Regardless of what the answers are, just the questions alone will
negatively affect the value of the company. -The result is similar to
the previous situation I described; someone will need to pay for at
least investigating it, if not paying the full price of proving it one
way or the other.
--
JCR
> * J.C. Roberts <···············@nonp.pbz> [2005-11-15 14:16:40 -0800]:
>
> On Tue, 15 Nov 2005 21:04:15 +0000, Mark Carter <··@privacy.net> wrote:
>
>>Peter Herth wrote:
>>
>>>
>>> Well, if you work in a commercial environment, the little details
>>> of the licenses make a *huge* difference. Who would sue a company
>>> that violates e.g. the LGPL? Probably not the author, so probably
>>> noone - or just a nasty competitor who uses this as means to hurt
>>> your company.
>>
>>A competitor can't sue for breach of copyright. It's a matter purely
>>between the copyright holder and the infringer. If the copyright holder
>>doesn't want to assert his rights, that's up to him.
>
> You are exactly correct about who the matter is between, but this is the
> exact reason why the GNU/FSF encourages authors to assign copyrights to
> the GNU/FSF (i.e. so the GNU/FSF can file the infringement law suits).
no, only for _some_ programs, like GNU Emacs, and even there their main
concern is that the contributor does not change his mind and pull the
plug on their program all of a sudden.
FSF does not hold copyright for GNU CLISP, nor CLOCC.
BTW, wrt your suggestion that I place my code in the Public Domain
instead of copyrighting it and releasing under a license you do not
like: I will happily do it if everyone else does that too (including MS)
> Follow the money trail. One of Peters' competitors wants to damage his
> company. The competitor contacts the GNU/FSF to complain how Peter is
> "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
> looks into it and sure enough Peter is using GPL/LGPL lisp software and
> just by using the GLP/LGPL code in his closed source products, Peter is
> in a legal gray zone because the way lisp variants actually work is not
> properly covered by the licenses.
no, FSF says: "we have no standing in the matter because we are not the
copyright holder".
> So the GNU/FSF asks the author of the GPL/LGPL code to transfer the
> copyrights to the organization so they can proceed with filing
> lawsuits to do discovery.
and the author says: "they have released the patches to my LGPL program
and that is all I have asked as per my license. Have a nice day."
--
Sam Steingold (http://www.podval.org/~sds) running w2k
http://ffii.org/ http://www.savegushkatif.org http://www.honestreporting.com
http://www.camera.org http://truepeace.org http://www.memri.org/
"Complete Idiots Guide to Running LINUX Unleashed in a Nutshell for Dummies"
J.C. Roberts <···············@abac.com> writes:
> Follow the money trail. One of Peters' competitors wants to damage his
> company. The competitor contacts the GNU/FSF to complain how Peter is
> "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
> looks into it and sure enough Peter is using GPL/LGPL lisp software and
> just by using the GLP/LGPL code in his closed source products, Peter is
> in a legal gray zone because the way lisp variants actually work is not
> properly covered by the licenses.
What on earth? The GPL and LGPL are very different beasts. LGPL
libraries *can* be used in commercial Lisp products without
open-sourcing the whole project. It's a pain, but not an impossible
one. You just have to provide a mechanism for the user to hack the
LGPL library and cause your application to use their modified version
instead. I think the LLGPL is much more appropriate for Lisp code,
but there's nothing mysterious or gray about the LGPL that prevents
using it in commercial work.
It sounds to me like you've been giving yourself legal advice, and
talked yourself into a strange view of OS licenses. Instead of trying
to play lawer, just ask an attorney for their opinion, laying out what
you want to do, why, and what you're worried about. I sincerely doubt
they'll share your terror about the LGPL.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> . . . there's nothing mysterious or gray about the LGPL that prevents
> using it in commercial work.
>
> It sounds to me like you've been giving yourself legal advice, and
> talked yourself into a strange view of OS licenses. Instead of trying
> to play lawer, just ask an attorney for their opinion, laying out what
> you want to do, why, and what you're worried about. I sincerely doubt
> they'll share your terror about the LGPL.
I sincerely doubt that most attorneys who understand software licensing
would share your relaxed attitude towards the LGPL. The practicing
attorney who taught the software licensing course I took in law school
probably would have advised against using LGPL'ed code. Several
authors have written about the "mysterious or gray" ambiguities in the
LGPL. Here are two (free) books that contain very accessible analyses
of the issues:
http://www.oreilly.com/catalog/osfreesoft/book/ ~pg.56
http://rosenlaw.com/oslbook.htm ~pg.128
Sam Steingold wrote:
>Murphy's law prevents clarifying the licensing terms to the degree that
>everyone understands them. I tried.
If at some point in the future you would like (free) assistance with
clarifying the licensing terms for CLOCC/PORT, I'd be happy to help.
-cody
··············@gmail.com" <·············@gmail.com> writes:
> Thomas F. Burdick wrote:
> > . . . there's nothing mysterious or gray about the LGPL that prevents
> > using it in commercial work.
> >
> > It sounds to me like you've been giving yourself legal advice, and
> > talked yourself into a strange view of OS licenses. Instead of trying
> > to play lawer, just ask an attorney for their opinion, laying out what
> > you want to do, why, and what you're worried about. I sincerely doubt
> > they'll share your terror about the LGPL.
>
> I sincerely doubt that most attorneys who understand software licensing
> would share your relaxed attitude towards the LGPL.
I have used LGPL and LLGPL'd libraries in a dozen or two commercial
projects for which the use of the LGPL was reviewed by attorneys.
The only hysterical response I've yet seen was on usenet.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> I have used LGPL and LLGPL'd libraries in a dozen or two commercial
> projects for which the use of the LGPL was reviewed by attorneys.
> The only hysterical response I've yet seen was on usenet.
I'm not suggesting that a hysterical response would be likely. I'm
merely suggesting that the LGPL does in fact contain considerable gray
areas, and any competent attorney should point that out. Did the
reviewing attorneys do so?
In the projects you mention, the benefit of using the libraries
apparently outweighed the chance of being sued due to these gray areas.
That doesn't mean that the gray areas are unimportant, or that
distributors of open source software (including CLOCC/PORT) should
ignore those gray areas.
-cody
··············@gmail.com" <·············@gmail.com> writes:
> Thomas F. Burdick wrote:
> > I have used LGPL and LLGPL'd libraries in a dozen or two commercial
> > projects for which the use of the LGPL was reviewed by attorneys.
> > The only hysterical response I've yet seen was on usenet.
>
>
> I'm not suggesting that a hysterical response would be likely. I'm
> merely suggesting that the LGPL does in fact contain considerable gray
> areas, and any competent attorney should point that out. Did the
> reviewing attorneys do so?
Naturally. The cases were either of the "is it okay to use this
library this way?" variety, or the "how am I allowed to use this
library?" variety. Essentially, I was given conservative guidelines
for how to safely incorporate the LGPL'd code.
> In the projects you mention, the benefit of using the libraries
> apparently outweighed the chance of being sued due to these gray areas.
Rather, the benefit outweighed the inconvenience of avoiding the gray
areas.
> That doesn't mean that the gray areas are unimportant, or that
> distributors of open source software (including CLOCC/PORT) should
> ignore those gray areas.
Certainly. I don't know how many contributers there have been to PORT
or the whole CLOCC, but if it's still a reasonable effort, it would be
good if the major contributors tried to relicense the system under
terms that more clearly express the intent of a Lisper making
something available under the LGPL -- that probably means something
like the LLGPL.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
On 16 Nov 2005 11:58:41 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>··············@gmail.com" <·············@gmail.com> writes:
>
>> Thomas F. Burdick wrote:
>> > . . . there's nothing mysterious or gray about the LGPL that prevents
>> > using it in commercial work.
>> >
>> > It sounds to me like you've been giving yourself legal advice, and
>> > talked yourself into a strange view of OS licenses. Instead of trying
>> > to play lawer, just ask an attorney for their opinion, laying out what
>> > you want to do, why, and what you're worried about. I sincerely doubt
>> > they'll share your terror about the LGPL.
>>
>> I sincerely doubt that most attorneys who understand software licensing
>> would share your relaxed attitude towards the LGPL.
>
>I have used LGPL and LLGPL'd libraries in a dozen or two commercial
>projects for which the use of the LGPL was reviewed by attorneys.
>The only hysterical response I've yet seen was on usenet.
>
>--
> /|_ .-----------------------.
> ,' .\ / | Free Mumia Abu-Jamal! |
> ,--' _,' | Abolish the racist |
> / / | death penalty! |
> ( -. | `-----------------------'
> | ) |
> (`-. '--.)
> `. )----'
Though your experience and council may indicate it is possible to use
LGPL code in proprietary closed source products, you have still exposed
yourself to risk by doing so. Yes, you did it successfully but maybe
your success was merely a matter of beating the odds and getting lucky.
Though you may personally consider the risks of using LGPL code to be
acceptable, many disagree with your views.
If the legal system got everything perfect, you would not have a .sig
advocating the release of a _CONVICTED_ killer.
Yet, when you are presented with links to written opinions of some of
the best lawyers in the field (i.e. Larry Rosen), you simply ignore them
and discount the reasoning as "hysterical" just because the topic was
addressed on usenet.
Good business practice is a matter of managing risks in an imperfect
legal system. You can not manage risks when you refuse to admit they
exist and refuse to even look at the possibility they might exist.
For your sake, I hope you keep getting lucky like an ostrich with your
head in the sand, but for me, I'll continue trying to address and manage
risks appropriately.
JCR
J.C. Roberts <···············@abac.com> writes:
> If the legal system got everything perfect, you would not have a .sig
> advocating the release of a _CONVICTED_ killer.
[ I assume you mean of someone _CONVICTED_ of murder, not that he is a
murder, and also convicted ]
I certainly don't think the legal system gets everything, nor most
things correct.
> Yet, when you are presented with links to written opinions of some of
> the best lawyers in the field (i.e. Larry Rosen), you simply ignore them
> and discount the reasoning as "hysterical" just because the topic was
> addressed on usenet.
I certainly wasn't trying to imply that *that* was hysterical, though
I have seen some articles in this thread I'd consider hysterical.
Certainly it's not in line with reality to claim that because *some*
uses of LGPL licensed code are unclear, therefore *no* use is
possible. I don't think anyone's come out and said that so far, but
that's been the (seeming) implication of some of your responses.
Perhaps that's me misinterpreting good old-fashioned internet
hyperbole.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
On 17 Nov 2005 10:38:26 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> If the legal system got everything perfect, you would not have a .sig
>> advocating the release of a _CONVICTED_ killer.
>
>[ I assume you mean of someone _CONVICTED_ of murder, not that he is a
> murder, and also convicted ]
>
Yes, you phrased it much better than I did. I couple years ago I did
some reading on his case, both sides of course, and there are some very
big "if's" in it.
>I certainly don't think the legal system gets everything, nor most
>things correct.
>
>> Yet, when you are presented with links to written opinions of some of
>> the best lawyers in the field (i.e. Larry Rosen), you simply ignore them
>> and discount the reasoning as "hysterical" just because the topic was
>> addressed on usenet.
>
>I certainly wasn't trying to imply that *that* was hysterical, though
>I have seen some articles in this thread I'd consider hysterical.
>Certainly it's not in line with reality to claim that because *some*
>uses of LGPL licensed code are unclear, therefore *no* use is
>possible. I don't think anyone's come out and said that so far, but
>that's been the (seeming) implication of some of your responses.
>Perhaps that's me misinterpreting good old-fashioned internet
>hyperbole.
To a degree you've been reading a bit much into it. LGPL is very usable
in many ways. In spite of being a wee bit vague when applied to C, the
vagueness is negligible since the GNU is really trying their best to be
clear about their intent. This makes using LGPL'd C-like code in closed
source products an acceptable risk assuming you're careful about how you
do the actual implementation. Using LGPL'd code is also great for
creating other LGPL'd and GPL'd open source projects.
The trouble starts when languages that work in a vastly differently
manner than C are using the LGPL. Even a whole hoard of extremely
talented lawyers would have difficulty using case proven legal terms to
properly define LGPL-like conditions on a lisp variant language. Current
copyright law was just not designed to handle lisp.
Though your opinions differ, some people consider the risk caused by
vague LGPL<->LISP conditions to be unacceptable,and by their standards,
it is impossible to use LGPL lisp code.
Kind Regards,
JCR
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I have used LGPL and LLGPL'd libraries in a dozen or two commercial
> projects for which the use of the LGPL was reviewed by attorneys.
I assume the attorneys reviewed LGPL'd Lisp libraries, not just LGPL'd
C or LLGPL'd Lisp libraries. If so, then this is very reassuring. But
it also raises the question why Franz created the LLGPL.
> The only hysterical response I've yet seen was on usenet.
Maybe you weren't present when Franz decided they needed the LLGPL?
Andras
Andras Simon <······@math.bme.hu> writes:
> Maybe you weren't present when Franz decided they needed the LLGPL?
The lawyers were quite hysterical. But after their Thorazine
injections, they calmed down a bit.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
On 16 Nov 2005 01:37:12 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> Follow the money trail. One of Peters' competitors wants to damage his
>> company. The competitor contacts the GNU/FSF to complain how Peter is
>> "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
>> looks into it and sure enough Peter is using GPL/LGPL lisp software and
>> just by using the GLP/LGPL code in his closed source products, Peter is
>> in a legal gray zone because the way lisp variants actually work is not
>> properly covered by the licenses.
>
>What on earth? The GPL and LGPL are very different beasts. LGPL
>libraries *can* be used in commercial Lisp products without
>open-sourcing the whole project. It's a pain, but not an impossible
>one.
It seems you never bothered to actually read the LGPL yourself and you
are just relying on internet here say. The lawyers I've spoken to
disagree with your views.
The LGPL was written to cover source code written in languages that work
similar to C with some degree of distinction between the library itself
and code that uses the library. Lisp based languages work in a vastly
different manner and implicitly allow run time modification.
More importantly, even with C like languages the GNU itself has no clue
where the library really stops and other code starts or how such things
should be licensed:
http://www.gnu.org/licenses/lgpl.html
| Section 5 Paragraph 3
| <QUOTE>
| When a "work that uses the Library" uses material from a header
| file that is part of the Library, the object code for the work
| may be a derivative work of the Library even though the source
| code is not. Whether this is true is especially significant if
| the work can be linked without the Library, or if the work is
| itself a library. The threshold for this to be true is not
| precisely defined by law.
| </QUOTE>
Even when the LGPL is applied to C library code, the smart lawyers at
GNU itself can admit the threshold is not precisely defined by law. If
they can't do it, and they wrote the license, what makes you think you
magically have concrete answers about a completely different language?
Just ask yourself how a "header file" relates to lisp.
>You just have to provide a mechanism for the user to hack the
>LGPL library and cause your application to use their modified version
>instead. I think the LLGPL is much more appropriate for Lisp code,
>but there's nothing mysterious or gray about the LGPL that prevents
>using it in commercial work.
>
If there was "nothing mysterious" about the LGPL, Franz Inc would not
have created their own LispLGPL. You can safely assume that someone at
Franz Inc, possibly their legal department, also disagrees with your
views.
>It sounds to me like you've been giving yourself legal advice, and
>talked yourself into a strange view of OS licenses. Instead of trying
>to play lawer, just ask an attorney for their opinion, laying out what
>you want to do, why, and what you're worried about. I sincerely doubt
>they'll share your terror about the LGPL.
You are correct in that we really have two choices; (1) you can get more
than one lawyer to review the situation and give you their opinions or
(2) you can continue to believe the uninformed nonsense you've been
reading on the internet.
Which have you done?
I'm very lucky because I have lawyers in my family and know others that
do pro bono work for open source. I have _already_ talked with a few
lawyers and they agree the GNU licensing is ambiguous when applied to
lisp based languages.
As Sam said in this tread, he tried to get things clarified and it is
not going to happen. Having the GNU release another license or adding
things to cover lisp in the upcoming version 3 of their licenses will
probably just make a bigger mess. When the GNU has things to worry about
people subverting their goals and weakening their licenses (like Linus
allowing binary only kernel modules), spending the time and effort to
properly cover the workings of lisp based languages is not very high on
their priority list.
Looking for potential problems and trying to address them openly and
fairly is simply due diligence but for some reason you've quite unfairly
tossed the label "terror" on it. The problem is just a concern and many
people, including the GNU lawyers, agree the issue is real but very
difficult to solve.
Of course opinions will vary and you are free to think whatever you like
but I hope you can accept that many will disagree with you. Blindly
ignoring the fact that others disagree for their own reasons, trying to
discredit them with the "terror" label and simply regurgitating the
misinformation you've scrounged off the net is both adversarial and
unproductive.
There may be no working solution but attacking others while ignoring the
real problems does not make the problems disappear.
Kind Regards,
JCR
J.C. Roberts <···············@abac.com> writes:
> On 16 Nov 2005 01:37:12 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
> >J.C. Roberts <···············@abac.com> writes:
> >
> >> Follow the money trail. One of Peters' competitors wants to damage his
> >> company. The competitor contacts the GNU/FSF to complain how Peter is
> >> "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
> >> looks into it and sure enough Peter is using GPL/LGPL lisp software and
> >> just by using the GLP/LGPL code in his closed source products, Peter is
> >> in a legal gray zone because the way lisp variants actually work is not
> >> properly covered by the licenses.
> >
> >What on earth? The GPL and LGPL are very different beasts. LGPL
> >libraries *can* be used in commercial Lisp products without
> >open-sourcing the whole project. It's a pain, but not an impossible
> >one.
>
> It seems you never bothered to actually read the LGPL yourself
Wow, I like how you assume I'm a complete moron. Straw men are easier
to argue against, huh?
> Kind Regards,
Deez
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
On 16 Nov 2005 12:01:41 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> On 16 Nov 2005 01:37:12 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
>> Burdick) wrote:
>>
>> >J.C. Roberts <···············@abac.com> writes:
>> >
>> >> Follow the money trail. One of Peters' competitors wants to damage his
>> >> company. The competitor contacts the GNU/FSF to complain how Peter is
>> >> "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
>> >> looks into it and sure enough Peter is using GPL/LGPL lisp software and
>> >> just by using the GLP/LGPL code in his closed source products, Peter is
>> >> in a legal gray zone because the way lisp variants actually work is not
>> >> properly covered by the licenses.
>> >
>> >What on earth? The GPL and LGPL are very different beasts. LGPL
>> >libraries *can* be used in commercial Lisp products without
>> >open-sourcing the whole project. It's a pain, but not an impossible
>> >one.
>>
>> It seems you never bothered to actually read the LGPL yourself
>
>Wow, I like how you assume I'm a complete moron. Straw men are easier
>to argue against, huh?
No, I neither assumed you're a moron nor did I call you one.
As for ostrich, yes, in another part of the thread, I said you are
acting like an ostrich by very intentionally ignoring everything that
does not agree with your point of view... such as ignoring everything
but one line in the post you to which you responded.
Yes, maybe you did read the LGPL and yes, maybe you did consult a lawyer
before using LGPL'd code in a closed source, commercial product. Yet,
when there are very well trained lawyers that disagree with your
personal and counciled interpretation, and you refuse to admit other
interpretations exist, it indicates you have not done adequate research
or you are just bluffing.
It's nothing personal. It's just critical analysis.
I am very curious about one thing: Why the heck are _you_ of all people
even arguing about these things when you already know how unclear
licenses cause all sorts of problems?
http://www.ocf.berkeley.edu/~tfb/no-carrier/fare-relicensed/
| <QUOTE>
| Far� Rideau graciously ... allowed me to redistribute his
| pattern-matching sublanguage under a clear license... he
| used the "BugR Off" license because he just wanted to publish
| his code, and not be bothered by licensing questions.
| </QUOTE>
http://www.geocities.com/SoHo/Cafe/5947/bugroff.html
JCR
J.C. Roberts <···············@abac.com> writes:
> I am very curious about one thing: Why the heck are _you_ of all people
> even arguing about these things when you already know how unclear
> licenses cause all sorts of problems?
>
> http://www.ocf.berkeley.edu/~tfb/no-carrier/fare-relicensed/
> | <QUOTE>
> | Far� Rideau graciously ... allowed me to redistribute his
> | pattern-matching sublanguage under a clear license... he
> | used the "BugR Off" license because he just wanted to publish
> | his code, and not be bothered by licensing questions.
> | </QUOTE>
> http://www.geocities.com/SoHo/Cafe/5947/bugroff.html
I am quite happy to use code in ways that appear to be legally clear.
For hobby and academic use, that involves me reading licenses myself.
For commercial use, that's a case-by-case decision made by an
attorney. Some licenses clearly prohibit some things, clearly allow
others, and are unclear about the rest. Some are unclear about
everything. The "BugR Off" license is of the latter sort. The LGPL
is, as far as I can tell and have been counciled, of the former. Lot
of unclarity, but enough clarity to get work done.
I do find it tragic when good code (eg, Zebu, or some of Far�'s code)
where the author clearly wanted others to use it, is unusable for
license reasons.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
J.C. Roberts wrote:
> As Sam said in this tread, he tried to get things clarified and it is
> not going to happen. Having the GNU release another license or adding
> things to cover lisp in the upcoming version 3 of their licenses will
> probably just make a bigger mess. When the GNU has things to worry about
> people subverting their goals and weakening their licenses (like Linus
> allowing binary only kernel modules), spending the time and effort to
> properly cover the workings of lisp based languages is not very high on
> their priority list.
Fortunately, at the same time, the GPL 3 roadmap may be the most
affordable time for GNU to clarify or create licenses for Lisp.
Particularly as Lisp-like languages are increasingly popular. (See for
example Don Box's "This melding of code and data is central to all
dialects of Lisp, and is fundamental to the way Microsoft is
integrating multiple expression languages (most notably SQL) in future
versions of the Microsoft® .NET Framework.")
Tayssir
J.C. Roberts <···············@abac.com> writes:
> I'm very lucky because I have lawyers in my family and know others that
> do pro bono work for open source. I have _already_ talked with a few
> lawyers and they agree the GNU licensing is ambiguous when applied to
> lisp based languages.
I agree with you that the LGPL is ambiguous. However, I also agree
with Thomas that that is not a show stopper. As you say, manage risk
because you can't eliminate it.
Ambiguity is bound to work in favor of the user. If you write a nice
library and release it under the terms of the LGPL and I go ahead and
simply use the the library in good faith, that is I make no
modifications to the library, I just use the provided interfaces, then
I seriously doubt that you could later prevail in a civil suit to get
me to release my code under LGPL.
While Lisp and C are indeed different, the OS doesn't know or care
which language you used. In both cases, the functionality of the
library has to be mapped into the memory space of my application to be
used. An exception to that would be if your library was really an
application providing a service via some form of IPC. In that event,
I would have even stronger defense as I didn't have to touch your
library's code at all. X11 works this way.
Meanwhile, by suing, you risk paying my legal fees to defend the suit
if I can establish that the ambiguity of the license combined with my
good faith effort to conform to the license gave you little reason to
expect to prevail.
IANAL, I am basing this post on my limited knowledge of US law.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
David Steuber wrote:
> Ambiguity is bound to work in favor of the user. If you write a nice
> library and release it under the terms of the LGPL and I go ahead and
> simply use the the library in good faith, that is I make no
> modifications to the library, I just use the provided interfaces, then
> I seriously doubt that you could later prevail in a civil suit to get
> me to release my code under LGPL.
It isn't losing a lawsuit that's painful, but fighting one. People look
to avoid lawsuits, and that doesn't mean entering into contracts which
are ambiguous but seem to work in their favour.* I'd want a contract
that's unambiguously on my side, so that when the other side consults
his lawyer, the lawyer says "you'll almost certainly lose". That way,
I'd only have to worry about people rich and warped enough to sue anyway.
> Meanwhile, by suing, you risk paying my legal fees to defend the suit
> if I can establish that the ambiguity of the license combined with my
> good faith effort to conform to the license gave you little reason to
> expect to prevail.
I don't know much about awards of costs in civil suits save that it
varies greatly among jurisdictions, but I suspect you're wrong. Here
you're trying to have it both ways; using ambiguity in your favour at
the trial and then claiming at the judgment that the other party should
have known there was no ambiguity and thus you should be awarded costs.
See the discrepancy?
* - People that read contracts, that is. People that just sign anything
are another category.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> J.C. Roberts <···············@abac.com> writes:
>
> > Follow the money trail. One of Peters' competitors wants to damage his
> > company. The competitor contacts the GNU/FSF to complain how Peter is
> > "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
> > looks into it and sure enough Peter is using GPL/LGPL lisp software and
> > just by using the GLP/LGPL code in his closed source products, Peter is
> > in a legal gray zone because the way lisp variants actually work is not
> > properly covered by the licenses.
>
> What on earth? The GPL and LGPL are very different beasts. LGPL
> libraries *can* be used in commercial Lisp products without
> open-sourcing the whole project. It's a pain, but not an impossible
> one. You just have to provide a mechanism for the user to hack the
> LGPL library and cause your application to use their modified version
> instead. I think the LLGPL is much more appropriate for Lisp code,
> but there's nothing mysterious or gray about the LGPL that prevents
> using it in commercial work.
I'm not sure I understand what the fuss over the LGPL is. Regardless
of what language you are using, to use a library the code will get
mapped into the memory space of your application whether you have
linked to it statically or dynamically. As far as calls into the
library go, it makes no difference. At least not in your source code.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
David Steuber <·····@david-steuber.com> writes:
> I'm not sure I understand what the fuss over the LGPL is. Regardless
> of what language you are using, to use a library the code will get
> mapped into the memory space of your application whether you have
> linked to it statically or dynamically. As far as calls into the
> library go, it makes no difference. At least not in your source code.
What does it mean to statically link Lisp, Smalltalk, or Java?
Loading from fasls is a pretty clear form of dynamic linking, but with
other ways of using a library in Lisp, it's not so clear how they map
to the C terminology. Hence, the LLGPL, which defines the LGPL's
terminology for Lisp.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > I'm not sure I understand what the fuss over the LGPL is. Regardless
> > of what language you are using, to use a library the code will get
> > mapped into the memory space of your application whether you have
> > linked to it statically or dynamically. As far as calls into the
> > library go, it makes no difference. At least not in your source code.
>
> What does it mean to statically link Lisp, Smalltalk, or Java?
> Loading from fasls is a pretty clear form of dynamic linking, but with
> other ways of using a library in Lisp, it's not so clear how they map
> to the C terminology. Hence, the LLGPL, which defines the LGPL's
> terminology for Lisp.
This isn't a real answer to your question. But I think the same
ambiguity applies to C. How is Lisp loading a FASL when it starts any
different from C loading a .so file when it starts (or .dll if you are
on Windows)? In both cases, the bindings to function names are made
at startup.
C programs can also call dlopen() or some equivalent. Perhaps your C
program knows of three different readline implementations and will
look for one of them when it starts up and use dlopen to load the
first one it finds and resolve the function addresses later on. Lisp
can also do this.
Lisp can also save an image so that you don't have to load FASLs.
This gets particularly interesting when your Lisp image relies on the
implementation's FFI. When the Lisp image is loaded, at some
indeterminate time in the future .so files may get loaded.
In all cases, the binary code ends up in your application's address
space. If you didn't make any modifications to the loaded libraries,
then you are probably just a user of the interfaces. If you modified
the libraries, then you are probably required to release the
modifications to the libraries (under LGPL).
Under GPL there is no ambiguity because mere use is considered a
derivative work which is why Linux includes an amended GPL so that not
all Linux programs are required to be GPL.
I do agree that the LLGPL provides a useful clarification to the
LGPL. I don't think that it is strictly necessary, but lawyers like
to use excessive redundancy so I suppose it is good that licenses do
too.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
David Steuber <·····@david-steuber.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > David Steuber <·····@david-steuber.com> writes:
> >
> > > I'm not sure I understand what the fuss over the LGPL is. Regardless
> > > of what language you are using, to use a library the code will get
> > > mapped into the memory space of your application whether you have
> > > linked to it statically or dynamically. As far as calls into the
> > > library go, it makes no difference. At least not in your source code.
> >
> > What does it mean to statically link Lisp, Smalltalk, or Java?
> > Loading from fasls is a pretty clear form of dynamic linking, but with
> > other ways of using a library in Lisp, it's not so clear how they map
> > to the C terminology. Hence, the LLGPL, which defines the LGPL's
> > terminology for Lisp.
>
> This isn't a real answer to your question. But I think the same
> ambiguity applies to C. How is Lisp loading a FASL when it starts any
> different from C loading a .so file when it starts (or .dll if you are
> on Windows)? In both cases, the bindings to function names are made
> at startup.
Exactly. A Lisp application loading a library from fasls at startup
is pretty clearly linking to it dynamically. The LGPL treats static
and dynamic linking differently. Is that what I'm doing if I dump a
core containing my application linked to a library? Or is it still
dynamic linking? As a user, LGPL licensed Lisp code is significantly
less useful to me than is LLGPL'd code, because I wat to avoid using
code in a way that is not clearly allowed by its license.
[snip]
> I do agree that the LLGPL provides a useful clarification to the
> LGPL. I don't think that it is strictly necessary, but lawyers like
> to use excessive redundancy so I suppose it is good that licenses do
> too.
It's not strictly necessary, but if your motivation in releasing a
library is to let people use it for whatever they want, as long as
they make changes to your library publically available, it's pretty
important to use the LLGPL for Lisp. It *may* be that you can dump a
proprietary Lisp application using an LGPL library, but such a
situation doesn't match the terminology used in the LGPL, so you'll
probably be forced to load it from fasls, in order to stay in a
legally clear situation. Given that Allegro includes an application
delivery system, I don't think Franz wanted to put their own customers
in such a quandry -- hence the LLGPL. And, btw, hence the LLGPL for
LTK :-)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
On Wed, 16 Nov 2005 10:37:12 +0100, Thomas F. Burdick
<···@conquest.OCF.Berkeley.EDU> wrote:
> J.C. Roberts <···············@abac.com> writes:
>
>> Follow the money trail. One of Peters' competitors wants to damage his
>> company. The competitor contacts the GNU/FSF to complain how Peter is
>> "STEALING" some GPL/LGPL licensed Common Lisp software. The GNU/FSF
>> looks into it and sure enough Peter is using GPL/LGPL lisp software and
>> just by using the GLP/LGPL code in his closed source products, Peter is
>> in a legal gray zone because the way lisp variants actually work is not
>> properly covered by the licenses.
>
> What on earth? The GPL and LGPL are very different beasts. LGPL
> libraries *can* be used in commercial Lisp products without
> open-sourcing the whole project. It's a pain, but not an impossible
> one. You just have to provide a mechanism for the user to hack the
> LGPL library and cause your application to use their modified version
> instead. I think the LLGPL is much more appropriate for Lisp code,
> but there's nothing mysterious or gray about the LGPL that prevents
> using it in commercial work.
>
> It sounds to me like you've been giving yourself legal advice, and
> talked yourself into a strange view of OS licenses. Instead of trying
> to play lawer, just ask an attorney for their opinion, laying out what
> you want to do, why, and what you're worried about. I sincerely doubt
> they'll share your terror about the LGPL.
>
Agreed. I thought I already explained the reality of using LGPL :)
At Opera, where I worked earlier, we use gcc on unix platforms.
For 10 years we have used this 'free' product and never has anyone
suggested a potential for a lawsuit. I think this is paranoia.
I guess some peaple will never be comfortable with the fact that
you can get something for nothing. (There has to be a catch..)
If any of you find any cases where a lawsuit has been made based on
the use of LGPL let me know. I have never heard of any.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> Agreed. I thought I already explained the reality of using LGPL :)
> At Opera, where I worked earlier, we use gcc on unix platforms.
> For 10 years we have used this 'free' product and never has anyone
> suggested a potential for a lawsuit. I think this is paranoia.
Sure, *using* gcc is free for all purposes. But when you write code and
link it with gcc, producing a derivative, your code has to be GPL, too.
> I guess some peaple will never be comfortable with the fact that
> you can get something for nothing. (There has to be a catch..)
Well, basically, Apache, gcc, and most Lisps are simply cooperations of
some community to produce a common goal with cheaper (shared) means.
> If any of you find any cases where a lawsuit has been made based on
> the use of LGPL let me know. I have never heard of any.
--
The road to hell is paved with good intentions.
On Wed, 16 Nov 2005 13:25:03 +0100, Ulrich Hobelmann <···········@web.de>
wrote:
>
> Sure, *using* gcc is free for all purposes. But when you write code and
> link it with gcc, producing a derivative, your code has to be GPL, too.
>
Not sure what you mean here. Obviously Opera grinds commercial
applications using
GCC and also (if they are not available) exports gcc library binaries.
Sure they don't distribute a new version of gcc.
(They have a commercial agreement with Troll (adjoint building) to use Qt
which they pay.) Linking code USING gcc does not make it open-source.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Wed, 16 Nov 2005 13:25:03 +0100, Ulrich Hobelmann
> <···········@web.de> wrote:
>
>>
>> Sure, *using* gcc is free for all purposes. But when you write code
>> and link it with gcc, producing a derivative, your code has to be GPL,
>> too.
>>
>
> Not sure what you mean here. Obviously Opera grinds commercial
> applications using
> GCC and also (if they are not available) exports gcc library binaries.
> Sure they don't distribute a new version of gcc.
No, the only thing they distribute is the compiled binary for Opera,
perhaps statically linked with Trolltech's Qt binary. It doesn't matter
if that piece of software is proprietary.
> (They have a commercial agreement with Troll (adjoint building) to use Qt
> which they pay.) Linking code USING gcc does not make it open-source.
Exactly. And I'm sure more than 99,9% of GCC's users only use it, so
they *never* need to worry about GCC's license.
--
The road to hell is paved with good intentions.
Ulrich Hobelmann <···········@web.de> wrote:
> John Thingstad wrote:
>> Agreed. I thought I already explained the reality of using LGPL :)
>> At Opera, where I worked earlier, we use gcc on unix platforms.
>> For 10 years we have used this 'free' product and never has anyone
>> suggested a potential for a lawsuit. I think this is paranoia.
>
> Sure, *using* gcc is free for all purposes. But when you write code and
> link it with gcc, producing a derivative, your code has to be GPL, too.
Right, thats how we gained an Open Source compiler for Objective C,
because NeXT hacked gcc and was after talks with Stallman, decided to
donate the Objective C frontend to it as GPL code.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
John Thingstad wrote:
> Agreed. I thought I already explained the reality of using LGPL :)
> At Opera, where I worked earlier, we use gcc on unix platforms.
> For 10 years we have used this 'free' product and never has anyone
> suggested a potential for a lawsuit. I think this is paranoia.
> I guess some peaple will never be comfortable with the fact that
> you can get something for nothing. (There has to be a catch..)
>
Well, the point with GPL software like gcc is, that gcc comes with
the explicit license statement that programs compiled with gcc are
not falling under GPL. Otherwise you had to gpl all programs compiled
with the gcc.
And I am in no way uncomfortable with the GPL/LGPL licenses. Actually
I am quite in favour of these licences. The catch for any software
author is only to choose the license carefully, that is for Lisp
libraries rather use LLGPL than LGPL to make it easy to use the
library in an commercial environment.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Peter Herth wrote:
> Well, the point with GPL software like gcc is, that gcc comes with
> the explicit license statement that programs compiled with gcc are
> not falling under GPL. Otherwise you had to gpl all programs compiled
> with the gcc.
But why's that? Imagine someone replaces your gcc with some other
compiler (which would be GPLed, if the GPL is indeed as you say), so the
resulting binary would be illegal once released without source. My
point is that you never agreed to anything, nor were you informed that
you breached some license. I mean, compilers don't create derivatives
of the compiler, they merely create machine code (usually) that *does
the same* as the original source, semantics-wise.
Of course it's never quite sure if a binary Linux graphics driver is a
derivative of the kernel (they say it is, so formally it is illegal
though nobody complains), or if a program is a derivative of some
library it uses, or if a compiled Lisp image is a derivative of the
implementation it was compiled on.
I find these distinctions absurd and would for that reason avoid GPL for
everything I can. BSD and MPL seem much better, depending on what
freedoms and restrictions you want.
--
The road to hell is paved with good intentions.
Ulrich Hobelmann wrote:
> Peter Herth wrote:
>
>> Well, the point with GPL software like gcc is, that gcc comes with
>> the explicit license statement that programs compiled with gcc are
>> not falling under GPL. Otherwise you had to gpl all programs compiled
>> with the gcc.
>
>
> But why's that? Imagine someone replaces your gcc with some other
> compiler (which would be GPLed, if the GPL is indeed as you say), so the
> resulting binary would be illegal once released without source. My
> point is that you never agreed to anything, nor were you informed that
> you breached some license. I mean, compilers don't create derivatives
> of the compiler, they merely create machine code (usually) that *does
> the same* as the original source, semantics-wise.
Its quite easy: the machine code created by the compiler is part of the
compiler - no software can "invent" things. So basically the output of
gpl compilers is also gpl. Unless of course, you would not only give
them the input source code, but also a source to binary translation
table. On the other side, the gcc authors were aware of this topic and
so they made the license terms clear: binaries created by gcc do *not*
fall under the gpl. So, because the gcc authors did pay attention to
license issues, it is very safe to use gcc - the gcc usage by many
companies is a testimony of that.
> Of course it's never quite sure if a binary Linux graphics driver is a
> derivative of the kernel (they say it is, so formally it is illegal
> though nobody complains), or if a program is a derivative of some
> library it uses, or if a compiled Lisp image is a derivative of the
> implementation it was compiled on.
For this reason, there are clear statements by Linus Thorwalds about
the Linux kernel licensing and thus unchallenged close-source kernel
modules. Also very clearly, a compiled Lisp image is a derivative of
the Lisp implementationion. So any program built and distributed with a
clisp core is gpl. Sbcl/cmucl on the other side have a mixture of
bsd/mit/public domain license, so no strings attached.
> I find these distinctions absurd and would for that reason avoid GPL for
> everything I can. BSD and MPL seem much better, depending on what
> freedoms and restrictions you want.
>
Absolutely not! There is no good/bad to a license per se. There are only
good and bad choices in comparison to the authors intent. GPL software
is perfectly safe to use, as long as on understands the system. What is
important, is to clearly understand the tradeoffs involved and then to
make the choice of license which fits the parameters best.
So I for example have released software under GPL, LLGPL and BSD
license, which I chose depended on the nature of the software and its
use-model.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
From: Stefan Nobis
Subject: Re: Identifying CL Implementations?
Date:
Message-ID: <87r79gyilk.fsf@snobis.de>
J.C. Roberts <···············@abac.com> writes:
> Who knows what would happen next? There may or may not be a
> violation of the GPL/LGPL in Peters' products, none the less,
> his competitor has already done a good job of damaging Peters'
> company even if Peter did nothing wrong.
So, please tell me: What's here so special about GPL/LGPL? This
very thing may happen with just *ANY* licence you use. Even if you
use sources which say they are public domain, it could be just a
lie or there may be patents pending.
But even if you investigate every legal problems, someone can try
to sue you in court nevertheless. And if someone has much money
and you don't...
Your reasoning is valid, but for every single line of code you
use, even if you wrote it all yourself (-> beware of patents).
--
Stefan.
On Wed, 16 Nov 2005 11:47:51 +0100, Stefan Nobis <······@gmx.de> wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> Who knows what would happen next? There may or may not be a
>> violation of the GPL/LGPL in Peters' products, none the less,
>> his competitor has already done a good job of damaging Peters'
>> company even if Peter did nothing wrong.
>
>So, please tell me: What's here so special about GPL/LGPL? This
>very thing may happen with just *ANY* licence you use. Even if you
>use sources which say they are public domain, it could be just a
>lie or there may be patents pending.
>
>But even if you investigate every legal problems, someone can try
>to sue you in court nevertheless. And if someone has much money
>and you don't...
>
>Your reasoning is valid, but for every single line of code you
>use, even if you wrote it all yourself (-> beware of patents).
Hi Stefan,
Like many things in life and business, it comes down to risk management
where a risk tolerance is set and the reduction of risk is a goal. You
obviously can't eliminate risk completely but good risk management will
reduce risk where ever possible.
Using GPL/LGPL code in the production of a proprietary, closed source
software increases risk.
Kind Regards,
JCR
J.C. Roberts wrote:
> Using GPL/LGPL code in the production of a proprietary, closed source
> software increases risk.
That's because the term "linking" used in the license isn't precise but
fuzzy. Is communicating by calling a shell command linking? Is calling
another program over RPC, or by sending it some text over a TCP link?
Nobody knows. By contrast, MPL, instead of LGPL, is based on the
concept of "file", which most people don't need to argue about.
But I agree with the point of your post: it's risk management, and it's
better to choose something that's more precise so you can estimate the
risk better.
--
The road to hell is paved with good intentions.
Ulrich Hobelmann <···········@web.de> writes:
> By contrast, MPL, instead of LGPL, is based on the concept of
> "file", which most people don't need to argue about.
Never used Smalltalk, huh? (Or, more on topic, INTERLISP)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Stefan Nobis
Subject: Re: Identifying CL Implementations?
Date:
Message-ID: <873blvk4s5.fsf@snobis.de>
J.C. Roberts <···············@abac.com> writes:
> Using GPL/LGPL code in the production of a proprietary, closed
> source software increases risk.
Doing anything (which is sometimes make public, sold or not) in
the software world increases risk, even in Europe. Patents
increases risks much more than using LGPLed Lisp libraries, i
would say.
So even if you wrote anything yourself, you have always the risk
of being sued due to patents. I think, using a libraries with a
not very good suited licence but clear statements from the
author(s) is much less risky.
And, as many have told you before, you could just politley ask the
author(s) the relisence the library for you.
--
Stefan.
On Thu, 17 Nov 2005 10:22:18 +0100, Stefan Nobis <······@gmx.de> wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> Using GPL/LGPL code in the production of a proprietary, closed
>> source software increases risk.
>
>Doing anything (which is sometimes make public, sold or not) in
>the software world increases risk, even in Europe. Patents
>increases risks much more than using LGPLed Lisp libraries, i
>would say.
>
>So even if you wrote anything yourself, you have always the risk
>of being sued due to patents. I think, using a libraries with a
>not very good suited licence but clear statements from the
>author(s) is much less risky.
>
>And, as many have told you before, you could just politley ask the
>author(s) the relisence the library for you.
Hi Stefan,
Sam is part of the GNU and he already said he is not willing to
relicense his work in CLOCC/PORT (particularly, putting it in the public
domain). Pestering Sam by repeatedly asking the same question he already
answered is neither fair nor polite. Marco Antoniotti who did all the
work in the configuration/ and environment/ directories might feel
differently relicensing but it would be a shame to split the two works.
I agree patents are more of a problem for people developing software and
they present a significant risk but when you are cautious, you can still
manage the patent risks fairly well. The best example I know from
experience is the creation of redundancy tools for UNIX operating
systems.
Having redundancy in firewalls and routers was an important missing
feature in OpenBSD and free UNIX systems as a whole. There was an IETF
standard to do this sort of thing and the protocol it defined is called
VRRP (Virtual Router Redundancy Protocol).
Cisco, who had their own patented implementation HSRP (Hot Standby
Router Protocol), immediately filed IPRN's (Intellectual Property Rights
Notice) with the IETF claiming that VRRP infringed on their patents. The
goal of Cisco was to prevent competition, kill off the new protocol and
earn revenue by charging patent license fees.
Myself and a few others from the OpenBSD camp spent a lot of time trying
to convince Robert Bar (head IP attorney at Cisco) to clarify statements
regarding their intent to sue those who implemented the IETF VRRP
standard. All we got from him was usual crap, "Cisco may not actively
pursue those who implement VRRP but we will definitely use our HSRP
patent in counter-suits against anyone who implements VRRP."
When our efforts to free the IETF standard VRRP protocol from legal risk
failed, the only choice was to create a new protocol that specifically
avoids the claims in the Cisco patent. The OpenBSD maintainers created
CARP (Common Address Redundancy Protocol). It's free for everyone to use
however they like and over the last two years it has been gaining
adoption (www.ucarp.org Linux, FreeBSD, NetBSD and possibly others).
There is a similar story about the OpenBSD guys and licensing of the SSH
protocol implementation.
http://www.openssh.com/history.html
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/LICENCE?rev=HEAD
It took a lot of work to get through the vague licensing on the original
code and then fight the TradeMark infringement claims from the companies
involved, but in the end, it's worked out well. By creating the free and
unrestricted OpenSSH implementation, SSH is now available in virtually
every Linux distribution and is available for most operating systems.
The idea is to find the potential risks and address them before they
ever become a problem. The first step is to be aware of the situation,
then talk to the authors/rights holders and if an agreement can not be
found, your only choice is to route around the damage they are causing.
JCR
<···············@abac.com> wrote:
> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
> would already be integrated into every CL implementation as the de facto
> portability abstraction.
Why do you think so?
> Since it has not been integrated everywhere, you need to ask yourself why?
There are several more likely reasons than your vague "the license
isn't clear" hypothesis. For example, it could be because:
* The CL implementors don't think that new portability abstractions
should be added to their implementation
* Chicken and egg: PORT isn't currently a de facto portability
abstraction, so there's no motivation for adding it to a CL
implementation. And it would become a de facto standard if it
was added to the implementations
* The license is clear but not acceptable for the implementation
* The CL implementors are not aware of PORT
* The CL implementors don't like the interfaces presented by PORT
* The CL implementors don't like the implementation of PORT
(I haven't looked at PORT, so the last two items should not be
considered as any sort of critizism of it. They're just possible
reasons.)
--
Juho Snellman
On 16 Nov 2005 04:04:17 GMT, Juho Snellman <······@iki.fi> wrote:
>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>> would already be integrated into every CL implementation as the de facto
>> portability abstraction.
>
>Why do you think so?
1.) Trying to change or add things to the CL spec would not only be a
long drawn out process through ANSI but it will also be messy with lots
of in-fighting. -the usual, welcome to the standards process.
2.) Reinventing the wheel is a waste of time and the "Not Invented Here"
syndrome is a crime of arrogance.
3.) Having more than one compatibility interface for CL implementations
to support is brutally ironic since it only adds more incompatibility.
There are common features absent in the ANSI Common Lisp standard that
are frequently added to CL implementations (sockets, shell, Gray
streams, etc.). These features are frequently added to CL
implementations because they are frequently needed by developers. The
CLOCC/PORT code seems to do the job of smoothing over the differences
between these features in the various CL implementations where the spec
allowed them to deviate when adding needed functionality.
A good specification is like a mini-skirt;
short enough to keep your imagination working
but long enough to completely cover the topic. ;-)
Kind Regards,
JCR
<···············@abac.com> wrote:
> On 16 Nov 2005 04:04:17 GMT, Juho Snellman <······@iki.fi> wrote:
>>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>>> would already be integrated into every CL implementation as the de facto
>>> portability abstraction.
>>
>>Why do you think so?
>
> 1.) Trying to change or add things to the CL spec would not only be a
> long drawn out process through ANSI but it will also be messy with lots
> of in-fighting. -the usual, welcome to the standards process.
>
> 2.) Reinventing the wheel is a waste of time and the "Not Invented Here"
> syndrome is a crime of arrogance.
>
> 3.) Having more than one compatibility interface for CL implementations
> to support is brutally ironic since it only adds more incompatibility.
I don't see how any of these points supports your original assertion
(quoted above).
--
Juho Snellman
On 16 Nov 2005 06:25:34 GMT, Juho Snellman <······@iki.fi> wrote:
><···············@abac.com> wrote:
>> On 16 Nov 2005 04:04:17 GMT, Juho Snellman <······@iki.fi> wrote:
>>>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>>>> would already be integrated into every CL implementation as the de facto
>>>> portability abstraction.
>>>
>>>Why do you think so?
>>
>> 1.) Trying to change or add things to the CL spec would not only be a
>> long drawn out process through ANSI but it will also be messy with lots
>> of in-fighting. -the usual, welcome to the standards process.
>>
>> 2.) Reinventing the wheel is a waste of time and the "Not Invented Here"
>> syndrome is a crime of arrogance.
>>
>> 3.) Having more than one compatibility interface for CL implementations
>> to support is brutally ironic since it only adds more incompatibility.
>
>I don't see how any of these points supports your original assertion
>(quoted above).
Since changing the spec would be bad and trying to invent a new
compatibility layer would be a waste of time, it makes sense to use the
existing CLOCC/PORT to address the CL portability issue.
JCR
J.C. Roberts <···············@abac.com> writes:
> Since changing the spec would be bad and trying to invent a new
> compatibility layer would be a waste of time, it makes sense to use the
> existing CLOCC/PORT to address the CL portability issue.
Of course this assumes that CL portability is high on the list of goals
of CL implementors. While that may be true for open-source
implementations, commercial implementations have economic incentives to
provide their own proprietary extensions which conveniently solve
important problems not covered by the Spec. The benefit to the
manufacturer is to make it more difficult to move your code from one
implementation to another, thus preserving you as a customer -- by
raising the costs of moving to a competitor's implementation.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> J.C. Roberts <···············@abac.com> writes:
>
>> Since changing the spec would be bad and trying to invent a new
>> compatibility layer would be a waste of time, it makes sense to use the
>> existing CLOCC/PORT to address the CL portability issue.
>
> Of course this assumes that CL portability is high on the list of
> goals of CL implementors. While that may be true for open-source
> implementations, commercial implementations have economic incentives
> to provide their own proprietary extensions which conveniently solve
> important problems not covered by the Spec. The benefit to the
> manufacturer is to make it more difficult to move your code from one
> implementation to another, thus preserving you as a customer -- by
> raising the costs of moving to a competitor's implementation.
Unless of course Lisp vendors believe that a) they will benefit more
from growing the Lisp pie than from holding on to their current
fraction of a static or shrinking pie and b) that, in this day of Java
and Python, that having more high-level facilities "standard"[1] in a
"language"[2] (so the answer to "how do I do X in Common Lisp" has an
answer other than, "it depends") will grow the pie.
-Peter
[1] "Standard" in probably the "de facto" sense.
[2] Blurring, of course, the line between language and library.
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
<···············@abac.com> wrote:
>>>>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>>>>> would already be integrated into every CL implementation as the de facto
>>>>> portability abstraction.
[ ... ]
> Since changing the spec would be bad and trying to invent a new
> compatibility layer would be a waste of time, it makes sense to use the
> existing CLOCC/PORT to address the CL portability issue.
Your original claim was that only an unclear license is standing in
the way of CLOCC/PORT world-domination. Enumerating reasons for why
you'd really, really, really like to see PORT included in
implementations doesn't support that claim in any way.
--
Juho Snellman
On 17 Nov 2005 05:03:44 GMT, Juho Snellman <······@iki.fi> wrote:
><···············@abac.com> wrote:
>>>>>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>>>>>> would already be integrated into every CL implementation as the de facto
>>>>>> portability abstraction.
>[ ... ]
>> Since changing the spec would be bad and trying to invent a new
>> compatibility layer would be a waste of time, it makes sense to use the
>> existing CLOCC/PORT to address the CL portability issue.
>
>Your original claim was that only an unclear license is standing in
>the way of CLOCC/PORT world-domination. Enumerating reasons for why
>you'd really, really, really like to see PORT included in
>implementations doesn't support that claim in any way.
Agreed. Looking back, it seems I somewhat misread your question to begin
with and failed to provide the reasoning you asked for in my reply.
There few licenses that provide acceptable risk and tolerable terms to
all parties who develop implementations. The short list is generally
BSD, Apache v1.1, MIT and possibly other unrestrictive licenses as well
as public domain.
Without acceptable risk, we can be certain wide spread adoption will
never happen. You highlighted this in the second and third * point in
your first post and lack of acceptable risk could be one of many
possible reasons for your first * point.
When risk is acceptable, adoption can take place. This of course doesn't
prove it _will_ take place but at the same time, reusing existing work
is the path of least resistance. Though nothing is ever certain, the
path of least resistance has the highest probability of being taken.
Portability between lisp variants was important enough to foster the
creation of "Common Lisp" and its standard to ease transitions, and in
doing so, the path of least resistance has already been taken once. If
both risk and terms were acceptable, increasing portability between
common lisp implementation will most likely take the same route.
The only way to figure out if my opinions are correct is to remove the
road blocks caused by licensing and see what happens. Since things move
slowly, it might take a couple years to find out the results and most
certainly, I could be wrong but if I am, I'll definitely admit it.
Kind Regards,
JCR
From: Stefan Nobis
Subject: Re: Identifying CL Implementations?
Date:
Message-ID: <87mzk4yifq.fsf@snobis.de>
J.C. Roberts <···············@abac.com> writes:
> The CLOCC/PORT code seems to do the job of smoothing over the
> differences between these features in the various CL
> implementations where the spec allowed them to deviate when
> adding needed functionality.
And why should a vendor incorporate these libraries that ease
transistion of customers to other implementations? Because we are
all altruistic?
--
Stefan.
On Wed, 16 Nov 2005 11:51:21 +0100, in comp.lang.lisp Stefan Nobis
<······@gmx.de> wrote:
>J.C. Roberts <···············@abac.com> writes:
>
>> The CLOCC/PORT code seems to do the job of smoothing over the
>> differences between these features in the various CL
>> implementations where the spec allowed them to deviate when
>> adding needed functionality.
>
>And why should a vendor incorporate these libraries that ease
>transistion of customers to other implementations? Because we are
>all altruistic?
It's not altruism. Often the business decision to use or purchase
technology-X is based around the ability to get support for that
technology. Adopting the use of Common Lips is no different.
When a company requires support for their CL implementation, having
portable code makes their decision to purchase (Franz, LW, etc.) easier
because whatever code they might already have (or open source they might
want to use) will work without the unnecessary expense of porting it to
the supported implementation.
You are thinking about the downside of easing the transition _from_
commercial implementations while I'm looking at the up side of easing
the transition _to_ commercial implementation. It goes both ways.
JCR
On Wed, 16 Nov 2005 05:04:17 +0100, Juho Snellman <······@iki.fi> wrote:
> <···············@abac.com> wrote:
>> If the LGPL licensing of the CLOCC/PORT code was actually clear, it
>> would already be integrated into every CL implementation as the de facto
>> portability abstraction.
>
> Why do you think so?
>
>> Since it has not been integrated everywhere, you need to ask yourself
>> why?
>
> There are several more likely reasons than your vague "the license
> isn't clear" hypothesis. For example, it could be because:
>
> * The CL implementors don't think that new portability abstractions
> should be added to their implementation
> * Chicken and egg: PORT isn't currently a de facto portability
> abstraction, so there's no motivation for adding it to a CL
> implementation. And it would become a de facto standard if it
> was added to the implementations
> * The license is clear but not acceptable for the implementation
> * The CL implementors are not aware of PORT
> * The CL implementors don't like the interfaces presented by PORT
> * The CL implementors don't like the implementation of PORT
>
> (I haven't looked at PORT, so the last two items should not be
> considered as any sort of critizism of it. They're just possible
> reasons.)
>
It is about as meaningful as asking why wxWindows isn't a part of the
C++ standard. Obviously the term that changes to the code should be
available to everyone is unacceptable to commercial vendors.
Also CL is a standard not a implementation as are these libraries.
In general most discussions along these lines begine with single
vendor standards (Python, Java, Perl, ..) vs. implementation standards
by specification (C++, Common Lisp, ADA, ..).
I think it is important that people understand the difference.
There are different versions of single vendor product's too
but the take a back step to the single 'standard' vendor and
thus must run the entire range of libraries to compete.
Implementation standards are more liberal.
Since I probably know C++ best I will take a example from there.
There are many different definitions of collections in C++.
The standard C++ library came to late. Hence it is normal to
run 2-3 different libraries in a standard implementation.
(bless CL! :)
Standards tend to be more limited and to allow the implementor
greater freedom at the expense of unity.
So pick a vendor and stick with him. Make it portable if you must,
but remember, there is no such thing as portable software, only
software that has been ported.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
J.C. Roberts wrote:
> I would absolutely love to use the CLOCC PORT code but unfortunately,
> even if CLOCC PORT code is beautifully written, the LGLP license it is
> under still prevents it from ever becoming a de facto standard through
> adoption because it cannot be incorporated into closed source software
> without substantial legal risk.
Are you simply asking for it to be relicensed under the LLGPL?
On Mon, 14 Nov 2005 04:56:06 -0800, J.C. Roberts <···············@abac.com> wrote:
> Is there a reasonably portable (standards compliant or widely
> accepted) method to identify Common Lisp implementations?
> (i.e. through CL code while said implementation is actually
> running?)
You know about read-time conditionals, don't you? These are actually
there so you don't have to make these decisions at runtime but rather
your compiler will do them for you (and your image won't contain code
which is only necessary for other Lisps).
<http://gigamonkeys.com/book/practical-a-portable-pathname-library.html>
<http://www.lispworks.com/documentation/HyperSpec/Body/01_ebaa.htm>
<http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm>
<http://www.cliki.net/features>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 14 Nov 2005 14:08:10 +0100, in comp.lang.lisp Edi Weitz
<········@agharta.de> wrote:
>On Mon, 14 Nov 2005 04:56:06 -0800, J.C. Roberts <···············@abac.com> wrote:
>
>> Is there a reasonably portable (standards compliant or widely
>> accepted) method to identify Common Lisp implementations?
>> (i.e. through CL code while said implementation is actually
>> running?)
>
>You know about read-time conditionals, don't you?
Assimilate the entire 50 years of lisp history, knowledge and wisdom in
less than 10 days? -Only if I was the borg. ;-)
>These are actually
>there so you don't have to make these decisions at runtime but rather
>your compiler will do them for you
Thanks!
>(and your image won't contain code
>which is only necessary for other Lisps).
>
At the moment, I don't know language or implementation internals well
enough to understand if there is an advantage to using images. The only
thing I know about (compile-file ...) images is they are at least
implementation dependent and in some cases, also platform dependent.
My first CL program is a glorified batch file for building other
applications written in various other languages and generating
installers for these applications. Performance is not really critical,
so it's a good place for me to start learning CL.
Since the end users of this CL program are other developers and the
delivery of this program will only be source files, they will be
expected to have their favorite CL implementation installed. If there
are serious performance gains from using images, then I'll create and
load them on the fly (I think the slime code does this).
Thanks Again,
JCR
J.C. Roberts <···············@abac.com> writes:
> On Mon, 14 Nov 2005 14:08:10 +0100, in comp.lang.lisp Edi Weitz
> <········@agharta.de> wrote:
>
>>On Mon, 14 Nov 2005 04:56:06 -0800, J.C. Roberts <···············@abac.com> wrote:
>>
>>> Is there a reasonably portable (standards compliant or widely
>>> accepted) method to identify Common Lisp implementations?
>>> (i.e. through CL code while said implementation is actually
>>> running?)
>>
>>You know about read-time conditionals, don't you?
>
> Assimilate the entire 50 years of lisp history, knowledge and wisdom in
> less than 10 days? -Only if I was the borg. ;-)
You don't know what you're saying. You've been posting to c.l.l. now
for a while. You _are_ attached to the borg. Resistance is futile;
you will be assimilated.
--
Duane Rettig ·····@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
On Mon, 14 Nov 2005 07:59:41 -0800, Duane Rettig <·····@franz.com>
wrote:
>>>You know about read-time conditionals, don't you?
>>
>> Assimilate the entire 50 years of lisp history, knowledge and wisdom in
>> less than 10 days? -Only if I was the borg. ;-)
>
>You don't know what you're saying. You've been posting to c.l.l. now
>for a while. You _are_ attached to the borg. Resistance is futile;
>you will be assimilated.
And I was just wondering why I'm looking kinda pale. ;-)
JCR
Duane Rettig wrote:
> You don't know what you're saying. You've been posting to c.l.l. now
> for a while. You _are_ attached to the borg. Resistance is futile;
> you will be assimilated.
>
I don't know. Tim managed to swim the bay on his second try, Ron
achieved escape velocity, Kent keeps his distance nicely, and I am down
to a bag a week... hell, Christopher's bot even wearied of reporting usage.
--
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
From: Arthur Lemmens
Subject: Re: Escape from c.l.l.atraz? [was Re: Identifying CL Implementations?]
Date:
Message-ID: <op.s0ah44gcwpmq96@news.xs4all.nl>
Kenny Tilton wrote:
> Duane Rettig wrote:
>> You don't know what you're saying. You've been posting to c.l.l. now
>> for a while. You _are_ attached to the borg. Resistance is futile;
>> you will be assimilated.
>>
>
> I don't know. Tim managed to swim the bay on his second try, Ron
> achieved escape velocity, Kent keeps his distance nicely, and I am down
> to a bag a week... hell, Christopher's bot even wearied of reporting usage.
But we got Joel Spolsky in return ;-)
I'd be interested in a summary of his talk, by the way.
"Arthur Lemmens" <········@xs4all.nl> writes:
> Kenny Tilton wrote:
>
> > Duane Rettig wrote:
> >> You don't know what you're saying. You've been posting to c.l.l. now
> >> for a while. You _are_ attached to the borg. Resistance is futile;
> >> you will be assimilated.
> >>
> >
> > I don't know. Tim managed to swim the bay on his second try, Ron
> > achieved escape velocity, Kent keeps his distance nicely, and I am down
> > to a bag a week... hell, Christopher's bot even wearied of reporting usage.
>
> But we got Joel Spolsky in return ;-)
>
> I'd be interested in a summary of his talk, by the way.
Fa real, what kind of a borg doesn't let us hear the thoughts of the
others. Damn buggy AI.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
J.C. Roberts <···············@abac.com> writes:
> On Mon, 14 Nov 2005 14:08:10 +0100, in comp.lang.lisp Edi Weitz
> <········@agharta.de> wrote:
>
>>On Mon, 14 Nov 2005 04:56:06 -0800, J.C. Roberts <···············@abac.com> wrote:
>>
>>> Is there a reasonably portable (standards compliant or widely
>>> accepted) method to identify Common Lisp implementations?
>>> (i.e. through CL code while said implementation is actually
>>> running?)
>>
>>You know about read-time conditionals, don't you?
>
> Assimilate the entire 50 years of lisp history, knowledge and wisdom in
> less than 10 days? -Only if I was the borg. ;-)
You can assimilate them in less than 10 seconds!
Just learn about the HyperSpec and APROPOS:
http://www.lispworks.com/documentation/HyperSpec/Front/X_Perm_I.htm
Click on any of the "*-implemenation-*" symbols.
or in the REPL, type: (APROPOS "IMPLEMENTATION") RET
or: (apropos :implementation) RET
Then open your mind and realize that implementations are not always
the problem, since some features may be present in several
implementations, so search next for FEATURE. Sometimes what matter is
the presence of a given package (eg. GRAY, or MOP), so search for PACKAGE,
etc.
--
"Specifications are for the weak and timid!"
Am 14.11.2005 13:56 Uhr schrieb "J.C. Roberts" unter
<···············@abac.com> in ··································@4ax.com:
>
> I searched the group archives and the hyperspec but found nothing on
> this...
>
> Is there a reasonably portable (standards compliant or widely accepted)
> method to identify Common Lisp implementations? (i.e. through CL code
> while said implementation is actually running?)
Hi,
see these Common Lisp functions/variables:
? (lisp-implementation-version)
"Version 1.0-rc1-050922 (DarwinPPC32)"
? (lisp-implementation-type)
"OpenMCL"
? (software-version)
"8.3.0"
? (software-type)
"Darwin"
? (machine-version)
"PowerBook5,3"
? (machine-type)
"Power Macintosh"
? (machine-instance)
"RJPBG4.local"
? *features*
(:PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON-LISP :MCL
:OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE-THREADS
:OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :POWERPC
:PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32-HOST :DARWINPPC-TARGET
:DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32-BIT-TARGET :32-BIT-HOST
:BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST :OPENMCL-PRIVATE-HASH-TABLES)
?
See also the following forms:
#+unix(print "this is unix")
#-unix(print "this is not unix")
#+lispm(print "this is a Lisp Machine")
#+ansi-cl(print "here we have ansi-cl")
#+cltl2(print "here we have only a cltl2-conforming lisp")
#+openmcl(print "this is OpenMCL")
#+(and openmcl powerpc)(print "this is OpenMCL on a PowerPC processor")
See here http://www.cliki.net/features for more information on actual
"features".
Regards,
Rainer Joswig
J.C. Roberts <···············@abac.com> writes:
> I searched the group archives and the hyperspec but found nothing on
> this...
>
> Is there a reasonably portable (standards compliant or widely accepted)
> method to identify Common Lisp implementations? (i.e. through CL code
> while said implementation is actually running?)
(lisp-implementation-type)
and/or
#+cmu
#+allegro
etc.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
J.C Roberts <···············@abac.com> wrote:
>
> I searched the group archives and the hyperspec but found nothing on
> this...
>
> Is there a reasonably portable (standards compliant or widely accepted)
> method to identify Common Lisp implementations? (i.e. through CL code
> while said implementation is actually running?)
Lisp being both a rather mature language and a multi-implementation
language it has of course such a standard tool: the #+implementation
macro.
Some code from one of my projects where I need a way to get at
environment variables - which is non-standard and there fore implemented
differently in each Lisp:
---------------------- cut here ----------------------
#+clisp
(defun http-getenv (variable)
"get value of the named environment variable"
(ext:getenv variable)) ; works for CLISP
#+sbcl
(defun http-getenv (variable)
"get value of the named environment variable"
(sb-ext:posix-getenv variable))
#+gcl
(defun http-getenv (variable)
"get value of the named environment variable"
(system:getenv variable))
;;; CMU CL demands a bit more work
#+cmu
(defun http-getenv (variable)
"get value of the named environment variable"
(cdr
(assoc
(read-from-string
(concatenate 'string ":" variable))
extensions:*environment-list*)))
#+ecl
(defun http-getenv (variable)
"get value of the named environment variable"
(si:getenv variable))
;;; support for Lispworks thanks to Bob Hutchison <·····@recursive.ca>
;;; he tested it with Lispworks Pro 4.4.5 on Mac
#+lispworks
(defun http-getenv (variable)
"get value of the named environment variable"
(lispworks:environment-variable variable))
-------------------------------- cut here ----------------------
That way, you shift the cost of selecting implementation specific code
to the reader.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
On Mon, 14 Nov 2005 15:07:23 +0100, Alexander Schreiber
<···@usenet.thangorodrim.de> tried to confuse everyone with this
message:
>Some code from one of my projects where I need a way to get at
>environment variables - which is non-standard and there fore implemented
>differently in each Lisp:
>
>---------------------- cut here ----------------------
>
>#+clisp
>(defun http-getenv (variable)
>#+sbcl
>(defun http-getenv (variable)
>
>#+gcl
>(defun http-getenv (variable)
>
>;;; CMU CL demands a bit more work
>#+cmu
>(defun http-getenv (variable)
>
>#+ecl
>(defun http-getenv (variable)
>#+lispworks
>(defun http-getenv (variable)
>
>-------------------------------- cut here ----------------------
Why did you write (defun http-getenv (variable) "bla bla"... 6 times? It
would be much better as
(defun http-getinv (var)
"description"
#+imp1 (code)
#+imp2 (code)
#+imp3 (code)
...)
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
Am 14.11.2005 16:22 Uhr schrieb "Timofei Shatrov" unter <····@mail.ru> in
················@news.readfreenews.net:
> On Mon, 14 Nov 2005 15:07:23 +0100, Alexander Schreiber
> <···@usenet.thangorodrim.de> tried to confuse everyone with this
> message:
>
>
>> Some code from one of my projects where I need a way to get at
>> environment variables - which is non-standard and there fore implemented
>> differently in each Lisp:
>>
>> ---------------------- cut here ----------------------
>>
>> #+clisp
>> (defun http-getenv (variable)
>
>> #+sbcl
>> (defun http-getenv (variable)
>>
>> #+gcl
>> (defun http-getenv (variable)
>>
>> ;;; CMU CL demands a bit more work
>> #+cmu
>> (defun http-getenv (variable)
>>
>> #+ecl
>> (defun http-getenv (variable)
>> #+lispworks
>> (defun http-getenv (variable)
>>
>> -------------------------------- cut here ----------------------
>
> Why did you write (defun http-getenv (variable) "bla bla"... 6 times? It
> would be much better as
>
> (defun http-getinv (var)
> "description"
> #+imp1 (code)
> #+imp2 (code)
> #+imp3 (code)
> ...)
See also the #FEATURE-CASE readmacro:
;;;***********************************************************
;;; #FEATURE-CASE( ... ) :: The FEATURE-CASE MACRO.
;;; A CASE-like reader-macro that dispatches on Features.
;;;
;;;(defun sheet-parent (sheet)
;;; #FEATURE-CASE
;;; (((not :clim) (send sheet :superior))
;;; (:clim-0.9 (clim:sheet-parent sheet))
;;; ((or :clim-1.0 :clim-2) (clim:window-parent sheet))))
;;;
;;; This is nearly equivalent to:
;;;
;;;(defun sheet-parent (sheet)
;;; #-clim (send sheet :superior)
;;; #+clim-0.9 (clim:sheet-parent sheet)
;;; #+(or :clim-1.0 :clim-2) (clim:window-parent sheet))
;;;
;;; These two examples differ in that feature-case provides an implicit
;;; otherwise clause that will generate a useful error message if no
;;; feature matches the current environment, something like:
;;;
;;; ERROR: Sorry, this portion of the program is only supported for:
;;; (not :clim)
;;; :clim-0.9
;;; (or :clim-1.0 :clim-2)
;;;
;;; An ARG to FEATURE-CASE (e.g. #1FEATURE-CASE) suppresses the OTHERWISE/T
clause.
;;; Of course, you are always free to rewrite the clause yourself.
;;;
;;; NOTE: This uses *read-suppress* just like #+ and #- so that illegal
syntax
;;; is not a problem unless the feature matches the current
environment.
;;;*****************************************************************
····@mail.ru (Timofei Shatrov) writes:
> Why did you write (defun http-getenv (variable) "bla bla"... 6 times? It
> would be much better as
He did it so that why you type M-. on HTTP-GETENV in some
source file, emacs/slime takes you exactly to the definition
which was compiled in your image, and you don't have to
read how other implementations are trying to implement
this function.
Personally, I like this.
On Mon, 14 Nov 2005 15:07:23 +0100, Alexander Schreiber
<···@usenet.thangorodrim.de> wrote:
> ;;; CMU CL demands a bit more work
> #+cmu
> (defun http-getenv (variable)
> "get value of the named environment variable"
> (cdr
> (assoc
> (read-from-string
> (concatenate 'string ":" variable))
> extensions:*environment-list*)))
>
hmm..
from shell etc.:
<variable>="#.<evil>"
<run lisp-program>
What happens when someone uses this routine for CGI programming? :)
You probably want to set *read-eval* to nil here.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 14 Nov 2005 18:29:40 +0100, "John Thingstad" <··············@chello.no> wrote:
> On Mon, 14 Nov 2005 15:07:23 +0100, Alexander Schreiber
> <···@usenet.thangorodrim.de> wrote:
>
>> ;;; CMU CL demands a bit more work
>> #+cmu
>> (defun http-getenv (variable)
>> "get value of the named environment variable"
>> (cdr
>> (assoc
>> (read-from-string
>> (concatenate 'string ":" variable))
>> extensions:*environment-list*)))
>
> hmm..
> from shell etc.:
> <variable>="#.<evil>"
> <run lisp-program>
>
> What happens when someone uses this routine for CGI programming? :)
>
> You probably want to set *read-eval* to nil here.
Your example has nothing to do with the code above. READ-FROM-STRING
is used in a contrived way to create a keyword, that's it.
Having said that, I'd rather use
(cdr (assoc (intern variable :keyword)
ext:*environment-list*))
because otherwise you can't access environment variables with lower
case letters in their names.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
>
> Your example has nothing to do with the code above. READ-FROM-STRING
> is used in a contrived way to create a keyword, that's it.
Doh! Right you are.. (Must be getting tired)
>
> Having said that, I'd rather use
>
> (cdr (assoc (intern variable :keyword)
> ext:*environment-list*))
>
Agreed! It's cleaner.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Edi Weitz <········@agharta.de> wrote:
> On Mon, 14 Nov 2005 18:29:40 +0100, "John Thingstad" <··············@chello.no> wrote:
>
>> On Mon, 14 Nov 2005 15:07:23 +0100, Alexander Schreiber
>> <···@usenet.thangorodrim.de> wrote:
>>
>>> ;;; CMU CL demands a bit more work
>>> #+cmu
>>> (defun http-getenv (variable)
>>> "get value of the named environment variable"
>>> (cdr
>>> (assoc
>>> (read-from-string
>>> (concatenate 'string ":" variable))
>>> extensions:*environment-list*)))
>>
>> hmm..
>> from shell etc.:
>> <variable>="#.<evil>"
>> <run lisp-program>
>>
>> What happens when someone uses this routine for CGI programming? :)
>>
>> You probably want to set *read-eval* to nil here.
>
> Your example has nothing to do with the code above. READ-FROM-STRING
> is used in a contrived way to create a keyword, that's it.
I claim lack of Lisp experience (close to none at all) at the time of
writing that. The library this code comes from is the first serious (as
in "used for something productive instead of just fooling around with
the language") Lisp code I wrote.
> Having said that, I'd rather use
>
> (cdr (assoc (intern variable :keyword)
> ext:*environment-list*))
>
> because otherwise you can't access environment variables with lower
> case letters in their names.
I never stumbled over that one due to using CLisp for production and
CMUCL only for the examples.
Thanks for the bugfix and the enlightenment ;-)
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison