Re: Licence Dilemma
Thanks Alexander, thanks for this plausible explanations! > Not a lawyer here, but PicoLisp 21 does **not** need to be GPL'd. > > 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". > In PicoLisp's case (pil21), libreadline is > only linked to at compile time. It is not > being distributed with PicoLisp in binary or > source form. Minor note: It is not even linked at *compile* time, but - dynamically - at runtime (shared library). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Licence Dilemma
I don't see what all the confusion is about. Not a lawyer here, but PicoLisp 21 does **not** need to be GPL'd. 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. In PicoLisp's case (pil21), libreadline is only linked to at compile time. It is not being distributed with PicoLisp in binary or source form. If you don't have libreadline on your system, you can't compile pil21. There is no GPL issue since the software itself (pil21) does not **include** GPL'd software. The "linking" clause of the license is specifically for software that is distributed with GPL'd software linked to it (ex: in binary form, or if libreadline sources were included with pil21 sources). This is not the case, so please let's close this discussion, it's a non-issue. I know it's long, but it's worth a read: - https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) - https://choosealicense.com/licenses/gpl-3.0/ 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. Cheers, AW On Sat, 21 Nov 2020, Kevin Ednalino wrote: I built mruby from AUR and when I do ldd there is no linking to libreadline: linux-vdso.so.1 (0x7ffe02708000) libm.so.6 => /usr/lib/libm.so.6 (0x7f6f005cb000) libc.so.6 => /usr/lib/libc.so.6 (0x7f6f00402000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x7f6f00804000) Looking into the sources, the flag "MRB_USE_READLINE" seems to be only set for the "Intel Edison" platform. It is also capable of using linenoise. So maybe that makes it possible to be permissively licensed since it can be proven to run without GPL (ergo it is not a derivative work). To be pedantic, ldd picolisp: linux-vdso.so.1 (0x7ffe0b5bc000) libc.so.6 => /usr/lib/libc.so.6 (0x7fa342e6f000) libm.so.6 => /usr/lib/libm.so.6 (0x7fa342d29000) libdl.so.2 => /usr/lib/libdl.so.2 (0x7fa342d23000) libreadline.so.8 => /usr/lib/libreadline.so.8 (0x7fa342cd1000) libffi.so.7 => /usr/lib/libffi.so.7 (0x7fa342cc5000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x7fa3430d7000) libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x7fa342c54000) ..and picolisp can't be built/run without libreadline. On Sat, Nov 21, 2020 at 2:26 PM Mike wrote: On Nov 21, 2020, at 15:30, Jeronimo Pellegrini wrote: "Mike" writes: Hello, Jeronimo, mruby is not ruby itself, but also created by Matsumoto https://github.com/mruby/mruby I see this is under MIT. How it was possible ? But is it distributed with/links to libreadline? https://www.archlinux.org/packages/community/x86_64/mruby/ This meta info about package links readline as dependency, like pil21 do (mike)
Re: Licence Dilemma
I built mruby from AUR and when I do ldd there is no linking to libreadline: linux-vdso.so.1 (0x7ffe02708000) > libm.so.6 => /usr/lib/libm.so.6 (0x7f6f005cb000) > libc.so.6 => /usr/lib/libc.so.6 (0x7f6f00402000) > /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 > (0x7f6f00804000) > Looking into the sources, the flag "MRB_USE_READLINE" seems to be only set for the "Intel Edison" platform. It is also capable of using linenoise. So maybe that makes it possible to be permissively licensed since it can be proven to run without GPL (ergo it is not a derivative work). To be pedantic, ldd picolisp: linux-vdso.so.1 (0x7ffe0b5bc000) > libc.so.6 => /usr/lib/libc.so.6 (0x7fa342e6f000) > libm.so.6 => /usr/lib/libm.so.6 (0x7fa342d29000) > libdl.so.2 => /usr/lib/libdl.so.2 (0x7fa342d23000) > libreadline.so.8 => /usr/lib/libreadline.so.8 (0x7fa342cd1000) > libffi.so.7 => /usr/lib/libffi.so.7 (0x7fa342cc5000) > /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 > (0x7fa3430d7000) > libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x7fa342c54000) ..and picolisp can't be built/run without libreadline. On Sat, Nov 21, 2020 at 2:26 PM Mike wrote: > > > On Nov 21, 2020, at 15:30, Jeronimo Pellegrini wrote: > > "Mike" writes: > > Hello, > > Jeronimo, > > mruby is not ruby itself, but also created by Matsumoto > > https://github.com/mruby/mruby > > I see this is under MIT. > > > How it was possible ? > > > But is it distributed with/links to libreadline? > > > https://www.archlinux.org/packages/community/x86_64/mruby/ > > This meta info about package links readline as dependency, like pil21 do > > > (mike) > >
Re: Licence Dilemma
> On Nov 21, 2020, at 15:30, Jeronimo Pellegrini wrote: > > "Mike" writes: > > Hello, > >> Jeronimo, >> mruby is not ruby itself, but also created by Matsumoto. >> https://github.com/mruby/mruby >> I see this is under MIT. >> >> How it was possible ? > > But is it distributed with/links to libreadline? > https://www.archlinux.org/packages/community/x86_64/mruby/ This meta info about package links readline as dependency, like pil21 do (mike)
Re: Licence Dilemma
Hi, > The software modules that link with the library may be under various GPL > compatible licenses, but the work as a whole must be licensed under the > GPL Also found this https://opensource.stackexchange.com/questions/6062/using-gpl-library-with-mit-licensed-code Damn, this is “Licence Dilemma” but nightmare. (mike)
Re: Licence Dilemma
Jeronimo, mruby is not ruby itself, but also created by Matsumoto. https://github.com/mruby/mruby I see this is under MIT. How it was possible ? November 21, 2020 2:15 PM, "Jeronimo Pellegrini" wrote: > "Mike" writes: > >> hi all, >> >>> at yesterday's PilCon it turned out that pil21 has a serious licence >>> problem. >> >> We already discussed this pseudo problem with Alex in Delta Chat thread. >> If I understand now correctly this is not a problem and Pil21 should keep >> using readline GPL >> library and be covered by MIT/X11 licence. > > As I understand, this is exactly what the GPL was intended to not let > happen. And this is what led CLISP to be licensed under the GPL long > time ago: > > https://gitlab.com/gnu-clisp/clisp/-/blob/master/doc/Why-CLISP-is-under-GPL > > Haible, in his last email in that thread, mentions that > > I had to put CLISP under GPL because libreadline.a was something I wanted > to use and I didn't want to write myself. libgmp.a is similar in this > respect, and it may therefore help putting some new packages under GPL. > > Building libgmp.a was just too hard work. Other people shouldn't get it for > free. > >> 1. >> Lets take a real world example, get all packages of ArchLinux required by >> readline, "Required By >> (133)" on the right: >> https://www.archlinux.org/packages/core/x86_64/readline >> >> https://www.archlinux.org/packages/community/x86_64/mruby >> Mruby, ruby's official mini implementation from Mr. Matsumoto covered by MIT >> licence and have >> readline as dependency. >> I assume Matsumoto knows everything about licences. > > I'm not sure what happens with Ruby; there seems to be a "GPL" file in > their repository, but the "COPYING" file only mentions the Ruby > license and the BSD license. > > https://github.com/ruby/ruby/blob/master/COPYING > https://github.com/ruby/ruby/blob/master/GPL > > The "LEGAL" file, which would list all used software and their licenses > do not mention readline. > > https://github.com/ruby/ruby/blob/master/LEGAL > > Ruby used to be licensed under GPLv2 also, but they dropped it. > readline switched from GPLv2 to GPLv3 in version 6. > > Anyway -- see below about the meaning of a license being compatible > with the GNU GPL. > >> 2. Wikipedia text for MIT says: "... The MIT license is compatible >> with many copyleft licenses, such as the GNU General Public License >> (GPL); ..." > > Compatible means you can use them together. Butif you do, the resulting > software needs to be licensed under the GPL. From the GPL, section 5(c): > > c) You must license the entire work, as a whole, under this License to > anyone who comes into possession of a copy. This License will therefore > apply, along with any applicable section 7 additional terms, to the > whole of the work, and all its parts, regardless of how they are > packaged. This License gives no permission to license the work in any > other way, but it does not invalidate such permission if you have > separately received it. > > So you'd need to license the entire work, as a whole, under the GPL. > > From the MIT license: > > Permission is hereby granted, free of charge, to any person obtaining a > copy of this software and associated documentation files (the > "Software"), to deal in the Software without restriction, including > without limitation the rights to use, copy, modify, merge, publish, > distribute, sublicense, > > "Sublicense" -- it allows you to relicense the work under a different > license. > > From RMS/FSF (https://www.gnu.org/licenses/license-compatibility.html): > > By the same token, lax licenses are usually compatible with any copyleft > license. In the combined program, the parts that came in under lax > licenses still carry them, and the combined program as a whole carries > the copyleft license. > > Also (https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL), > > The software modules that link with the library may be under various GPL > compatible licenses, but the work as a whole must be licensed under the > GPL > > J. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Subscribe
Hi Gaston, > Hello I'm interested in learning picolisp Great! Welcome! :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello I'm interested in learning picolisp
Re: Licence Dilemma
hi all, > at yesterday's PilCon it turned out that pil21 has a serious licence problem. > We already discussed this pseudo problem with Alex in Delta Chat thread. If I understand now correctly this is not a problem and Pil21 should keep using readline GPL library and be covered by MIT/X11 licence. 1. Lets take a real world example, get all packages of ArchLinux required by readline, "Required By (133)" on the right: https://www.archlinux.org/packages/core/x86_64/readline/ https://www.archlinux.org/packages/community/x86_64/mruby/ Mruby, ruby's official mini implementation from Mr. Matsumoto covered by MIT licence and have readline as dependency. I assume Matsumoto knows everything about licences. 2. Wikipedia text for MIT says: "... The MIT license is compatible with many copyleft licenses, such as the GNU General Public License (GPL); ..." (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Licence Dilemma
libedit probably not a suitable replacement: https://github.com/conda-forge/python-feedstock/issues/387 > OK, let me rephrase, then. I am that person. I work on some other projects > that use readline/libedit. I can tell you that it is a huge headache, even > on Mac, when libedit is used instead. This is because libedit only > partially implements the readline API. It is not 1:1 and many APIs are > missing. It causes tons of issues for users & developers who have a really > hard time figuring out what went wrong. It really doesn't make sense to > treat them as equivalent. > > In terms of specific missing functionality, it has been a couple of years, > but I believe it was a lot of stuff related to tab completions, and that > libedit doesn't respect the full key-binding syntax that readline has. > mruby might have been overlooked, but better safe than sorry? https://github.com/conda-forge/conda-forge.github.io/issues/209 > Basically, it boils down to: "is the code running in the same memory space > as other GPL code". > > However, if your program is compiled with the readline library for > example, certain binaries in that package have included material portions > of code protected by GPL. > > You can use ldd to check for yourself. If a library is linked to GPL > code, it is GPL. > If you find that a library is linked to GPL code, then by definition > (GPL-v3, clause 3), that particular instance of the compiled library is now > protected by GPL. And as such, you must abide by clause 3, which means you > must give > a) Give prominent notice with each copy of the object code that the Library > is used in it and that the Library and its use are covered by this License. > b) Accompany the object code with a copy of the GNU GPL and this license > document. > > Would linenoise be another possibility? https://github.com/antirez/linenoise > A minimal, zero-config, BSD licensed, readline replacement used in Redis, > MongoDB, and Android. > >- Single and multi line editing mode with the usual key bindings >implemented. >- History handling. >- Completion. >- Hints (suggestions at the right of the prompt as you type). >- About 1,100 lines of BSD license source code. >- Only uses a subset of VT100 escapes (ANSI.SYS compatible). > > On Sat, Nov 21, 2020 at 8: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
Thanks Mike! this looks good indeed! ☺/ A!ex On Sat, Nov 21, 2020 at 09:45:42AM +, Mike wrote: > 1. > Lets take a real world example, get all packages of ArchLinux required by > readline, "Required By (133)" on the right: > https://www.archlinux.org/packages/core/x86_64/readline/ > > > https://www.archlinux.org/packages/community/x86_64/mruby/ > Mruby, ruby's official mini implementation from Mr. Matsumoto covered by MIT > licence and have readline as dependency. > I assume Matsumoto knows everything about licences. > > 2. Wikipedia text for MIT says: "... The MIT license is compatible with many > copyleft licenses, such as the GNU General Public License (GPL); ..." -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Licence Dilemma
On Sat, Nov 21, 2020 at 10:41:23AM +0200, Yiorgos [George] Adamopoulos wrote: > Do you absolutely need this? Why not remove it all and work with rlwrap > when you need command line editing? No way. Check pil21/src/lib.c pil21 needs a lot of stuff to interoperate with the command line. And, as I said, I want compatibility (e.g. ~/.inputrc) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Licence Dilemma
Do you absolutely need this? Why not remove it all and work with rlwrap when you need command line editing? On Sat, 21 Nov 2020 at 10: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 > > -- keep raising the bar
Licence Dilemma
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
