License compatability: Oils vs readline

[the-moog]

While commenting on another issue, I noted that GNU readline is used in Oils, though I am not sure if this is 100% always true on all platforms as I only came across Oils a couple days ago.

This is an issue due to the license of GNU readline, though being a library, unusually it is under the full GPL not the LGPL. GPL being a deliberate decision at it's inception many years ago.

As I am sure people are aware static linking a GPL binary or a binary object derived from GPL source code automatically makes the resulting object GPL, however Oils is under the more permissive Apache2 licence. In fact some distributions omit Readline completely because of this, and use, e.g. libedit.

As suggested in the other issue, there are alternative libraries that can be used to circumvent this, e.g. https://github.com/reeflective/readline

[greggyb]

Apache, the FSF, and GNU all agree that the Apache License 2.0 (the license of Oils) and GPL3 (the license of GNU readline) are compatible with one another.

[greggyb]

This is also only a question when distributing a binary distribution. There is no license concern for building yourself (or using any platform with a ports tree, where you'd be compiling yourself via that infrastructure).

[the-moog]

@greggyb

I've not got time right now to research and link references, but if you think that will help I may find time at the weekend. Right now consider the following to be to the best of my knowledge (and as it is part of my job, hopefully accurate)

Apache may be 'compatible', but that does not mean an app distributed (as source or binary) under Apache can use GPL components without implications. The issue is that any static linkage of GPL3 source or binary automatically makes the resultant binary AND the source code that invokes it GPL3. Even including a GPL3 header file can be an issue unless that header is only for a dynamic library and shipped separately (e.g. in lib*-dev package) and it not part of the derived package source distribution in any way. The Apache license does not have that limitation.. (for obvious reasons. Otherwise any Apache served website that uses static linkage to any of the Apache libs would also become GPL)

The main difference between most licenses and GPL 3, is that with any GPL 3, source or static binary and any resulting source code or library must be shared (copy left) and must also be GPL3 even if another license is also used (e.g. some proprietary licences are also GPL3 - FOSS does not mean IP without ownership rights).

Note: GPL2 and LGPL are both different to GPL3. Hence why Linux kernel is GPL2 and not GPL3, and most GPL libraries use LGPL, Apache, BSD or MIT. The fact that there is more than one GPL and many FOSS licenses is often the cause of confusion...

Consider this. If I create an add-on for Oils, currently it must be GPL3 even if only used within my org as when I compile that add-on it will link to readline. Most companies run away from GPL3 with a wide margin, and ban inclusion of any GPL src or bin, in whole or any part, even if only used internally as they don't want to have a claim on any parts of their IP or risk systems being compromised due to the need to remove low level dependencies. Big companies (like the one that I work for) have massive legal departments and processes in place just to prevent this, large value means worth it as targets for legal compensation. GPL 3 is more restrictive than many commercial licenses. We go through a careful study before release for that exact purpose.

Or to put it another way. A GPL 3 project can distribute any components of this project without issues, but the opposite is not true. (This is what 'compatible' means, BTW) The other way round the GPL license is not reciprocal in that it never adopts the other license. That is not the same as Apache. By static incorporation, in part or in whole, of any GPL the 'derived works' project effectively becomes GPL, so may as well be GPL, and any further derived projects can't dissociate past or future code from GPL.

Commercial OS vendors (like my employer, M$ and Apple) are very wary of GPL code as they don't want to have to prove in court they have not used GPL components, especially well known ones.

A shell is useless without an OS, If this project wants to become widely used it will need to be part of a distribution. For that to happen any such license issues will need resolving, and doing that sooner rather than later would be far less hassle. From my view the world is desperate for a 'better bash', it would be a shame to limit that by making an official binary distribution impossible.

This is why many projects avoid GPL3 as it is a very restrictive license. Apache allows others to fork, change, contribute, incorporate and improve without limits. GPL3 does not, (with the exception of improve).

I hope that all makes sense?

[greggyb]

Bash is GPLv3 and Oils aims to be compatible with Bash. I don't think license compatibility is an explicit project goal.

If someone is replacing Bash, then they are probably already okay with their shell being GPLv3 licensed, I think.

[greggyb]

I also have personal knowledge of Bash being used internally at several FAANG/MAMAA companies, if we want to defer to our own personal experience in the workforce. I've even used Bash at a couple of those!

The use cases I've seen are a mix of interactive usage and the typical shell scripts you might expect. Neither use case has any risk of falling afoul of GPL licensing concerns. And there are shockingly few scenarios I am aware of where you'd need to link your shell into software being distributed.

The Oils project is not distributing readline, nor is readline a hard dependency of Oils. Oils can be licensed however it wants.

I agree that it would be nice to have an option for libedit or some other permissively licensed alternative, but it seems a low priority right now.

In the meantime, if there are concerns about licensing, just run $ ./configure --without-readline when building and there will be no linking to readline. You could then even get a fair bit of readline functionality by invoking the shell with $ rlwrap osh, which will give you line editing and history without linking of any sort. Thus you could have an unencumbered oils binary and still enjoy a nice interactive experience, with no risk of accidentally distributing a binary under GPLv3. All of this presupposes that you are distributing oils yourself, and not just using it.

[andychu]

Yeah my understanding is that GPLv3 and Apache 2 are fine

But GPLv2 and Apache 2 weren't ?

Not sure but in any case we're not distributing binaries

...

Honestly I don't care that much about Apache 2 and maybe a shorter BSD license is better ... that was a decision made like 8 years ago

[dezren39]

gplv3 and apache-2.0 are fine together, however, the resulting product is gplv3

https://www.apache.org/licenses/GPL-compatibility.html

Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.