On Sat, 02 Jan 2021 11:16:03 -0500 John Scott wrote:
> In general, this license clash doesn't seem to be a strictly downstream issue.
Well, in my own personal opinion, it is also (if not mainly) an issue
for anyone who distributes prebuilt binaries linked with the
incompatible library...
Hence, I think it is indeed a downstream issue (too)...
> Perhaps you should file bugs with the upstream projects to either revise their
> licensing if they can or explicitly depend on libeditreadline-dev, especially
> for the projects that fail to build with it.
...although I agree that each of these issues is best resolved
upstream, if possible.
I think that the possible suggestions for the upstream developers (or,
if all else fails, for the Debian package maintainers) should be one of
the following alternatives (in descending order of preference):
a) port the program to a GPLv2-compatible readline replacement (such
as libedit or similar, possibly by using a shim library such as
libeditreadline)
b) re-license the program from GPLv2-only to GPLv2-or-later
c) disable any link with readline and make do without command
editing/history (which is not great, but it could be necessary in
some cases)
d) build the program by linking with an old
GPLv2-compatible version of readline
Please note that the drawbacks of option c could be mitigated by using
wrappers such as rlwrap or rlfe...
[...]
> In any case I appreciate the digging you've done.
+1
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Attachment:
pgpDcbvXsAB9s.pgp
Description: PGP signature