Re: how to compile pil20 on termux

[Alexander Shendi]

Hi,

I don't see any problems:
You probably need to install the following packages:
- clang
- llvm
- (GNU) make
- libffi
- readline
- anything I forgot

You may need to run termux-clean-elf on the "picolisp" executable and set 
LD_LIBRARY_PATH explicitly.

Best Regards,

Alexander 

Am 23. November 2020 06:45:26 MEZ schrieb Bruno Franco 
:
>since it does not come as a termux package anymore, can I compile it on
>my
>phone?

-- 
Ceci n'est pas un courriel. 

How to compile pil21 on termux

[Alexander Burger]

Hi Bruno,

> since it does not come as a termux package anymore,

Really? I can see the picolisp package here in Termux.

It is still on pil64 though. I asked Fredrik, the maintainer of Termux, last
week to change to pil21. Didn't get an answer yet.


> can I compile it on my phone?

Yes, just like on other systems (see INSTALL, some packages differ for Termux):

   $ apt install make clang llvm readline libffi openssl pkg-config
   $ wget https://software-lab.de/pil21.tgz
   $ tar xfz pil21.tgz
   $ cd pil21
   $ (cd src; make)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

how to compile pil20 on termux

[Bruno Franco]

since it does not come as a termux package anymore, can I compile it on my
phone?

Re: Licence Dilemma

[Richard Z]

On Sun, Nov 22, 2020 at 09:22:29AM +0100, Alexander Burger wrote:

> Yes, I want pil21 as a piece be completely "free", in the spirit of MIT.

corporations tend to abuse the idealist "spirit of free" often. I prefer 
something in the middle of GPL and MIT which LGPL does in many cases. 

The practical problem with MIT is that anyone can fix bugs in his version 
of the software without giving the fixes back to the comunity.

Richard

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Richard Z]

On Sun, Nov 22, 2020 at 09:03:47AM +0100, Tomas Hlavaty wrote:
> On Sun 22 Nov 2020 at 01:32, Alexander Williams  wrote:
> > Not a lawyer here, but PicoLisp 21 does **not** need to be GPL'd.
> 
> it does not because it is already compatible with GPL
> 
> > Everyone seems to confuse "linking to a GPL'd library that exists on the 
> > host computer" VS "linking to a GPL'd library that's included with the 
> > source code".
> >
> > Please stop mixing these things.
> 
> strange, i don't think that's right
> 
> > If you don't have libreadline on your system, you can't compile pil21.
> 
> this means that pil21 depends on GPL software
> 
> and the combined work is licensed under GPL

it isn't. It may be a violation of one of those licenses in some
circumstances but that does not ever convert the licence of your own
prject.

The only time you have to worry about this is if you would distribute
binaries. The sources itself can't violate the licence and everyone
is free to compile them without violating the licence.

Richard

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[pd]

my vote to go for GPL and readline. As you said compatibility is guaranteed
and everybody knows it.

On Sat, Nov 21, 2020 at 9:23 AM Alexander Burger 
wrote:

> Hi all,
>
> at yesterday's PilCon it turned out that pil21 has a serious licence
> problem.
>
> A major design decision of pil21 was to use readline(3) instead of the
> self-
> rolled @lib/led.l from pil64/pil32.
>
> The reason was compatibility with the rest of the world (readline supports
> both
> vi- and emacs-mode right out of the box, uses the same ~/.inputrc as bash
> and
> other tools, and everybody is used to it), and high configurability.
>
>
> I took a look at editline() / libedit. Very different API! It does not
> even use
> ~/.inputrc but requires a separate ~/.editrc.
>
> I don't see that it supports all the features pil21 needs (hooks to various
> functions for signal handling, background tasks and display control (see
> pil21/src/lib.c).
>
>
> Better go back to GPL with pil21?
>
> I'm getting fed up with these licence wars!
>
> ☹/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Licence Dilemma

[John Duncan]

I think it should be fine. Picolisp is distributed as source code. The code
implementing readline can be GPL licensed. The code implementing everything
else can be a less restrictive license if desired. Binaries including
readline can be distributed as GPL, binaries without readline can be MIT.
The README can say, "if you need to use this in an GPL-incompatible way,
you have to leave out the readline support file".

The important thing is that we're talking about binaries and source code. A
single GPL file in a project does not and cannot relicense all the other
files in the project. However, if it is included in the binaries, it
affects the license of the binary.

This should not be a problem for debian distributions, etc.

On Sun, Nov 22, 2020 at 6:24 AM Alexander Williams 
wrote:

> Tomas, you're allowed to relicense the MIT version of PicoLisp you
> received, as GPLv3, as long as you maintain the MIT license text.
>
>
> AW
>
> On Sun, 22 Nov 2020, Tomas Hlavaty wrote:
>
> > what if i don't want to risk going to court because of this?
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


-- 
John Duncan

Re: Flame wars

[Alexander Burger]

On Sun, Nov 22, 2020 at 04:45:41PM +0100, Davide BERTOLOTTO wrote:
> Great! :)

In fact, there is one very important reason why to avoid GPL in PicoLisp:

It is too complicated.

Just look at the long discussions we had here, and probably thousands of other
people around the world, trying to make sense out of it. Even the lawyers
disagree, as the three Points of view in

   https://en.wikipedia.org/wiki/GPL#Linking_and_derived_works

show.

Totally against the spirit of PicoLisp. PicoLisp strives for Simplicity.

GPL Version 3 has 674 lines / pil21's MIT licence just 19 :)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

UNSUBCRIBE

[Jay H]

Coolest environment I've ever seen, but I need more handholding, no
segfaults, and eons of time.

Re: Flame wars

[Davide BERTOLOTTO]

Great! :)

On Sun, Nov 22, 2020, 15:17 Alexander Burger  wrote:

> On Sun, Nov 22, 2020 at 02:49:58PM +0100, Davide BERTOLOTTO wrote:
> > Well, outside of the "flame wars", I think that this it is a genuine
> > problem that has to be solved by Alex.
>
> Yes, OK, and it *is* solved.
>
>
> > * use readline and make pil21 GPL
> > * Make readline optional ...
> > * Ditch readline completely ...
>
> None of them.
>
> 1. PicoLisp is MIT/X11, so anybody can change to GPL if she does not like
> it.
>But *I* will not limit freedom.
>
> 2. It is not a problem anyway. I follow the link in Wikiqedia
>
>   https://www.linuxjournal.com/article/6366
>
>the opinion of Lawrence Rosen (a one-time Open Source Initiative general
>counsel). PicoLisp is not derivative work and linking is mostly
> irrelevant.
>
> End of discussion.
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Flame wars

[Alexander Burger]

On Sun, Nov 22, 2020 at 02:49:58PM +0100, Davide BERTOLOTTO wrote:
> Well, outside of the "flame wars", I think that this it is a genuine
> problem that has to be solved by Alex.

Yes, OK, and it *is* solved.


> * use readline and make pil21 GPL
> * Make readline optional ...
> * Ditch readline completely ...

None of them.

1. PicoLisp is MIT/X11, so anybody can change to GPL if she does not like it.
   But *I* will not limit freedom.

2. It is not a problem anyway. I follow the link in Wikiqedia

  https://www.linuxjournal.com/article/6366

   the opinion of Lawrence Rosen (a one-time Open Source Initiative general
   counsel). PicoLisp is not derivative work and linking is mostly irrelevant.

End of discussion.

☺/ A!ex


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Flame wars

[Davide BERTOLOTTO]

Well, outside of the "flame wars", I think that this it is a genuine
problem that has to be solved by Alex.

Using readline for pil21 in the current form requires him to use GPL for
Picolisp. I know it's nasty and almost nobody likes that, but it is the way
the GPL license works, at least on paper.
If anyone will complain in the future about him not doing that has to be
seen, but legally he's on the weak side.

Let's close this topic by putting the possible options on the table - Alex
will have to take a decision:
* use readline and make pil21 GPL
* Make readline optional (i.e. that can be activated via config), maybe
with a thin pil interface calling readline via native. The interface file
will be GPL, but pil can be released with MIT license and the reworked led.l
* Ditch readline completely and use an alternative with a more permissive
license

Any other suggestion is welcome. :)

Regards,
Davide

On Sun, Nov 22, 2020, 14:25 Alexander Burger  wrote:

> On Sun, Nov 22, 2020 at 07:36:57AM -0500, r cs wrote:
> > Have you been putting up with flame wars this often in the past, or is it
> > worse during COVID-19?
>
> No flame war please! :)
>
> The question came up at PilCon, so I asked here.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Flame wars

[Alexander Burger]

On Sun, Nov 22, 2020 at 07:36:57AM -0500, r cs wrote:
> Have you been putting up with flame wars this often in the past, or is it
> worse during COVID-19?

No flame war please! :)

The question came up at PilCon, so I asked here.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Sean Case]

Look, the FSF own readline.  They want every program that uses readline
to be released under the GPL.  This may be antisocial of them, but
unless you specifically want to annoy them, you can either comply with
their conditions or stop using their code.

Sean Case



-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Flame wars

[r cs]

Alex:

Have you been putting up with flame wars this often in the past, or is it
worse during COVID-19?

Thank you for supporting the rest of us and sharing your work with the
world.

Respectfully and with appreciation,
rcs

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 12:09, Alexander Burger  wrote:
> On Sun, Nov 22, 2020 at 11:49:11AM +0100, Tomas Hlavaty wrote:
>> it is only mess because you really want to find a loophole
>
> I don't want to find a loophole. I leave everything as it is (MIT/X11). I just
> want to point out how nonsensical it all is.

why is tomato vegetable?

why is it allowed to shoot welschman with bow and arrow in chester after
midnight?  (this one is actually funny
)

why are some people systemrelevant?

why is football allowed and music not?

why can viener filharmonie go for a concert tour to japan and be
excluded from corona rules?

why is Grundgesetz worked around again?

   Bund und Länder dürfen mit einfachen Rechtsverordnungen in
   grundrechtliche Freiheiten eingreifen – ohne Vorbehalt des
   Parlaments.  Angekratzt ist auch eine weitere Hoheit des Bundestags:
   das Budgetrecht.“

i don't think laws are meant to make sense

> I would rather re-activate and perhaps rewrite the old lib/led.l

this seems like a reasonable solution

> I don't care what RMS says. He is a docmatic actually *restricting*
> freedom.

i'd rather discuss ideas than people

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 11:16, Alexander Williams  wrote:
> Tomas, you're allowed to relicense the MIT version of PicoLisp you 
> received, as GPLv3, as long as you maintain the MIT license text.

what about customers that ban GPL on their machines?

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Alexander Williams]

Tomas, you're allowed to relicense the MIT version of PicoLisp you 
received, as GPLv3, as long as you maintain the MIT license text.



AW

On Sun, 22 Nov 2020, Tomas Hlavaty wrote:


what if i don't want to risk going to court because of this?


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 11:12, Davide BERTOLOTTO  
wrote:
> Right, but apparently nobody went to court for such topics, so it is still
> gray zone.

what if i don't want to risk going to court because of this?

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 11:23, Alexander Burger  wrote:
> On Sun, Nov 22, 2020 at 11:03:31AM +0100, Alexander Burger wrote:
>> In my understanding it is irrelevant how the library is linked, or the fact 
>> that
>> pil21 "depends" on it
>
> This is all such a mess! What is "linking" other than calling external code at
> runtime?
>
> In pil you can call any other library at any time with 'native'. At that 
> moment
> the library gets linked. How should we prevent that?

it is only mess because you really want to find a loophole

> Or calling a GPLed program with (call "program" "arg" ...). This is 
> functionally
> also equivalen to linking, as it "uses" the code in another program.

it is completely different

otherwise you could use rlwrap as already suggested and call it a day

and you already clearly explained, why rlwrap is not an option iirc

> If 'native' does not violate the GPL, then pil21 could be rewritten to use
> 'native' to call the readline API.

this is what Stallman said to Haible:

   The FSF position would be that this is still one program, which has
   only been disguised as two.  The reason it is still one program is
   that the one part clearly shows the intention for incorporation of
   the other part.

   I say this based on discussions I had with our lawyer long ago.  The
   issue first arose when NeXT proposed to distribute a modified GCC in
   two parts and let the user link them.  Jobs asked me whether this was
   lawful.  It seemed to me at the time that it was, following reasoning
   like what you are using; but since the result was very undesirable
   for free software, I said I would have to ask the lawyer.

   What the lawyer said surprised me; he said that judges would consider
   such schemes to be "subterfuges" and would be very harsh toward them.
   He said a judge would ask whether it is "really" one program, rather
   than how it is labeled.

   So I went back to Jobs and said we believed his plan was not allowed
   by the GPL.

   The direct result of this is that we now have an Objective C front
   end.  They had wanted to distribute the Objective C parser as a
   separate proprietary package to link with the GCC back end, but since
   I didn't agree this was allowed, they made it free.

   So I don't think the GPL actually requires a correction for this.
   But perhaps it would be a good idea to add a note explaining this.

you are not the only one trying to find loopholes in GPL.
you should read why clisp is under GPL.

another thought experiment: say my customers ban GPL software on their
machines.  0 GPL there.  would i be able to use pil21 for those
customers?  no because pil21 needs GPL software.

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Davide BERTOLOTTO]

>From the wiki page they you shared, quoting the FSF

Where's the line between two separate programs, and one program with two
parts? This is a legal question, which ultimately judges will decide. We
believe that a proper criterion depends both on the mechanism of
communication (exec, pipes, rpc, function calls within a shared address
space, etc.) and the semantics of the communication (what kinds of
information are interchanged).

If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run linked
together in a shared address space, that almost surely means combining them
into one program.

By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs.

This means that 'call' is not a problem

Since native doesd dynamic linking (does it?), in principle it may be a
problem.

Legally this is always in the hands of the judge.

In my view I don't believe that someone will sue Picolisp for using
readline like Alex is doing, but there is always a possibility.

What about any of the mentioned replacements? Is there any viable one?



On Sun, Nov 22, 2020, 11:31 Alexander Burger  wrote:

> On Sun, Nov 22, 2020 at 11:03:31AM +0100, Alexander Burger wrote:
> > In my understanding it is irrelevant how the library is linked, or the
> fact that
> > pil21 "depends" on it
>
> This is all such a mess! What is "linking" other than calling external
> code at
> runtime?
>
> In pil you can call any other library at any time with 'native'. At that
> moment
> the library gets linked. How should we prevent that?
>
> Or calling a GPLed program with (call "program" "arg" ...). This is
> functionally
> also equivalen to linking, as it "uses" the code in another program.
>
> If 'native' does not violate the GPL, then pil21 could be rewritten to use
> 'native' to call the readline API.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Licence Dilemma

[Alexander Burger]

Hi Davide,

> Anyway, Alex what about this editline (not to be confused with the BSD
> one)? It may be enough for pil21 implementation:
> https://github.com/troglobit/editline#introduction

I believe it cannot do what I need.

I decided to abandon the @lib/led.l used in pil32 / pil64 and instead use a
"standard" everyone is used to. This means for me to have a vi-mode (very
important) but for most people it stays with the default emas-mode (depending on
inputrc). So the lib must use ~/inputrc.

Then, to fully inter-operate with the PicoLisp REPL, the line editor API must
provide hooks for

1. TAB completion (this seems to exist in editline, not sure how configurable)
2. history (also in editline, not sure how configurable)
3. multiplexed input (select / poll system call) to handle pil's background
   tasks
4. supporting PicoLisp's different delimiters (non-symbol characters) and
   quoting characters
5. controlling the line being edited in such a way that background tasks can
   interact (hide, redraw, show) with it
6. handling OS signals (for all signals supported by PicoLisp)

Perhaps more ...

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Alexander Burger]

On Sun, Nov 22, 2020 at 11:03:31AM +0100, Alexander Burger wrote:
> In my understanding it is irrelevant how the library is linked, or the fact 
> that
> pil21 "depends" on it

This is all such a mess! What is "linking" other than calling external code at
runtime?

In pil you can call any other library at any time with 'native'. At that moment
the library gets linked. How should we prevent that?

Or calling a GPLed program with (call "program" "arg" ...). This is functionally
also equivalen to linking, as it "uses" the code in another program.

If 'native' does not violate the GPL, then pil21 could be rewritten to use
'native' to call the readline API.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Alexander Burger]

On Sun, Nov 22, 2020 at 11:03:31AM +0100, Alexander Burger wrote:
> In my understanding it is irrelevant how the library is linked, or the fact 
> that
> pil21 "depends" on it, as long as it is not distributing (modified (derived) 
> or
> not) parts of libreadline.

According to https://en.wikipedia.org/wiki/GPL three different views exist on
that subject.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Alexander Burger]

Hi Davide, Tomas,

On Sun, Nov 22, 2020 at 10:07:44AM +0100, Tomas Hlavaty wrote:
> Hi Alex,
> 
> On Sun 22 Nov 2020 at 09:22, Alexander Burger  wrote:
> > Yes, I want pil21 as a piece be completely "free", in the spirit of MIT.
> 
> then it cannot depend on GPL library

I do not think so.

   The GPL series are all copyleft licenses, which means that any derivative
   work must be distributed under the same or equivalent license terms

In my understanding it is irrelevant how the library is linked, or the fact that
pil21 "depends" on it, as long as it is not distributing (modified (derived) or
not) parts of libreadline.

> if you combine MIT and GPL software in the same process, the combined
> work must conform to GPL

pil21 does not "combine" (and then distribute) libreadline in any way. It just
refers to the names of readline API functions in its source, which are later
compiled and linked.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 09:59, Davide BERTOLOTTO  
wrote:
> In my personal opinion it will be okay if we use the readline library in
> pil21, since it is a *library* and we are not making a 'derivative' work
> out of it

this is wrong

there is exactly the same precedent already, see clisp
https://raw.githubusercontent.com/JoshCheek/clisp/master/doc/Why-CLISP-is-under-GPL

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

Hi Alex,

On Sun 22 Nov 2020 at 09:22, Alexander Burger  wrote:
> Yes, I want pil21 as a piece be completely "free", in the spirit of MIT.

then it cannot depend on GPL library

>>From what I underseod so far, the GPL is all about "distributing". PicoLisp 
>>does
> *not* distribute any GPLed code (neither source nor binary), but "uses" what 
> it
> finds on the target system at runtime and just *calls* it by creating a 
> dynamic
> link. Am I wrong?

why would that be relevant?

if you combine MIT and GPL software in the same process, the combined
work must conform to GPL

if you want the combined work not to conform to GPL, do not use GPL
software in the same process

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Davide BERTOLOTTO]

According to the GPL FAQ *technically* a dynamically linked object still
falls under GPL
https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic

However it seems that not everyone agrees on that fundamentalist view:
https://www.linuxjournal.com/article/6366

As far as I know, there has not been any court ruling on such issues, so we
are a bit in the gray zone here.

In my personal opinion it will be okay if we use the readline library in
pil21, since it is a *library* and we are not making a 'derivative' work
out of it

Regards,
Davide

On Sun, Nov 22, 2020, 09:30 Alexander Burger  wrote:

> Hi Tomas,
>
> > even though pil21 is MIT licensed, the GPL dependency makes the combined
> > work GPL licensed
> >
> > if i understand the raised issue correctly, alex wants the combined work
> > to be MIT licensed, which means pil21 cannot depend on GPL software
>
> On Sun, Nov 22, 2020 at 09:08:32AM +0100, Tomas Hlavaty wrote:
> > the question is: does pil21 depend on GPL software?  if yes, the
> > combined work has GPL licence.  if not, pil21 has MIT licence.  if you
>
> Yes, I want pil21 as a piece be completely "free", in the spirit of MIT.
>
> But you focus on the term "depend" / "dependency".
>
> >From what I underseod so far, the GPL is all about "distributing".
> PicoLisp does
> *not* distribute any GPLed code (neither source nor binary), but "uses"
> what it
> finds on the target system at runtime and just *calls* it by creating a
> dynamic
> link. Am I wrong?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Licence Dilemma

[Alexander Burger]

Hi Tomas,

> even though pil21 is MIT licensed, the GPL dependency makes the combined
> work GPL licensed
> 
> if i understand the raised issue correctly, alex wants the combined work
> to be MIT licensed, which means pil21 cannot depend on GPL software

On Sun, Nov 22, 2020 at 09:08:32AM +0100, Tomas Hlavaty wrote:
> the question is: does pil21 depend on GPL software?  if yes, the
> combined work has GPL licence.  if not, pil21 has MIT licence.  if you

Yes, I want pil21 as a piece be completely "free", in the spirit of MIT.

But you focus on the term "depend" / "dependency".

>From what I underseod so far, the GPL is all about "distributing". PicoLisp 
>does
*not* distribute any GPLed code (neither source nor binary), but "uses" what it
finds on the target system at runtime and just *calls* it by creating a dynamic
link. Am I wrong?

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 07:00, Alexander Burger  wrote:
> It is not even linked at *compile* time, but - dynamically - at runtime
> (shared library).

i don't think this makes any difference

the question is: does pil21 depend on GPL software?  if yes, the
combined work has GPL licence.  if not, pil21 has MIT licence.  if you
load GPL library, the combined work is GPL.  that's why LGPL exists iirc

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 01:32, Alexander Williams  wrote:
> Not a lawyer here, but PicoLisp 21 does **not** need to be GPL'd.

it does not because it is already compatible with GPL

> Everyone seems to confuse "linking to a GPL'd library that exists on the 
> host computer" VS "linking to a GPL'd library that's included with the 
> source code".
>
> Please stop mixing these things.

strange, i don't think that's right

> If you don't have libreadline on your system, you can't compile pil21.

this means that pil21 depends on GPL software

and the combined work is licensed under GPL

> Finally, it is also possible for PicoLisp to be "dual-licensed" under
> GPL and MIT, allowing the recipients to choose which license applies
> to them, but that solves nothing since MIT is already compatible with
> GPL. People would normally dual-license for commercial reasons, or
> when the license isn't compatible with GPL.

this does not solve the issue because of the above

even though pil21 is MIT licensed, the GPL dependency makes the combined
work GPL licensed

if i understand the raised issue correctly, alex wants the combined work
to be MIT licensed, which means pil21 cannot depend on GPL software

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe