>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 <a...@software-lab.de> 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 >
