nix repl: License compatibility

[aneeshusa]

The original nix-repl repo seems to be licensed under the GPLv3, but this repo is LGPL v2.1. I don't believe it's possible to relicense contributions from various contributors without getting their explicit approval.
@edolstra Is there a record of contributors agreement to relicensing for the merging of nix-repl into this repo?

cc other nix-repl contributors (list taken from https://github.com/edolstra/nix-repl/graphs/contributors)
cc @solson @fkz @ehmry @olejorgenb @orbekk @mbbx6spp

[orbekk]

Approval granted (for a trivial change).

[vcunat]

AFAIK simple changes don't require approval, but at least @solson's contributions seem large enough. (I'm no lawyer.)

[solson]

I'm fine with relicensing for this repo.

[fkz]

approval granted, too

[mbbx6spp]

:+1: sorry for delay.

[armijnhemel]

@edolstra they rise a good point. I would highly recommend getting approval from @ehmry and @olejorgenb

[aneeshusa]

It looks like nix repl depends on GNU readline, which is licensed under the GPLv3 (presumably this is why nix repl also is GPLv3). This complicates the question because now that nix repl is part of nix, the overall combination depends on the GPLv3 GNU readline. I believe that LGPLv2.1 is compatible, but IANAL so it would be good to get a more official answer.

And yes, we still need approval from the remaining contributors, or else I believe (IANAL) we need to remove/rewrite the parts of the code they contributed.

[armijnhemel]

@edolstra I have asked the opinion of a lawyer (and Nix user), but @aneeshusa is IMO correct.

[silverhook]

I suspect I may be the lawyer in question here 😜

It is correct that for changing the (future) license of the code from a copyleft to a more lax licensing (e.g. GPL to LGPL or even MIT), you would need to have agreement of all authors.

That being said, as @aneeshusa mentioned, in this case GPL-3.0 of _GNU readline_ also has to be taken into account here. I have not dived into the technical details of how _nix repl_ links with _GNU readline_ here. @armijnhemel is much more knowledgeable on this than I, so I expect that GPL is relevant here, otherwise he would have mentioned it already as irrelevant.

If you read the compatibility matrix more carefully – see second table under “I want to use a library under: GPLv3" row and the “I want to license my code under: LGPLv2.1” column – you can see that _1)_ you actually can license it as LGPL-2.1 if it’s linking with GPL-3.0 code, but also that _2)_ inevitabely the final product would have to be GPLv3 anyway.

Which means that a LGPL-2.1 tag on this repo might be factually OK for the repo, but ultimately misleading, as for many for whom it applies, it applies as GPL-3.0.

So, I would suggest that you don’t bother with it and simply keep/license this repo as GPL-3.0(+), unless:

1. you have a use case where LGPL-2.1 _much_ preferred, and
2. you plan (or let others) to replace _GNU readline_ with something that is not under GPL.

[copumpkin]

Can we just switch to editline or similar to avoid all this GPL noise?

[Ekleog]

If that's for readline, there also exists rlwrap, which brings most (all?) of the benefits of readline without having to link to it, as far as I can tell.

[vcunat]

In nix-repl I very much enjoy that it suggests identifiers defined in the expression, and rlwrap can't technically achieve, IMO.

Currently nix-repl uses linking, dynamic one by default to libreadline.so. I don't remember whether editline is usable directly as a drop-in replacement without any other restrictions/changes.

[edolstra]

I've been looking at https://github.com/antirez/linenoise as a replacement for readline. It also has the advantage that it gets rid of the ncurses dependency.

[silverhook]

@edolstra, that sounds like a plausible solution to me (at least on 2h sleep on an airport).

[vcunat]

I don't think it tries to be API-compatible, but it's possible nix-repl can be rewritten easily to this.

[armijnhemel]

Looks clean to me.

[domenkozar]

Still waiting on a word from @olejorgenb and @ehmry