Inconsistent licensing language

[brson]

Cargo.toml and LICENSE-MIT declare an MIT license, but the README "Contribution" section says contributions are Apache/MIT.

Side note: IMO -sys crates should generally carry the license of the code they are packaging, but since this crate contains significant amounts of its own source code and doesn't seem to vendor openssl, it seems reasonable to carry a separate license. But by doing so, the crate ecosystem tooling can't see that it is linking to BSD+advertising clause openssl code. For backtrace-sys, which does vendor its code, I filed a bug saying it is incorrectly licensed.

[brson]

Which versions of OpenSSL does this crate support now? I see that OpenSSL 3 has completed an Apache-2.0 relicense.

[sfackler]

The README language is there to move towards an eventual relicensing to Apache/MIT.

It supports OpenSSL 1.0.1 through 1.1.1, and LibreSSL 2.5.x through 2.9.x. We'll add support for OpenSSL 3.0.0 when they cut their first preview releases.

[skade]

This is an interesting problem, as openssl-sys can both link statically or dynamically. I assume the second is the common case.

In the second case, for the resulting binary, only the license of the bindings is of interest for the distributor of the software and a contributor.

If the OPENSSL_STATIC flag is used though, it might be useful to make the user aware that they should check the licensing of the artifacts linked, which the build script may be able to print out to stderr in some way.

It might be useful to include a hint, probably in documentation to developers in some way, especially that linking openssl statically to a GPL codebase is incompatible.

[sfackler]

I believe that cargo hides build script output by default, unfortunately.

I'm a bit leery about providing any explicit claims about license compatibility without having them reviewed by someone who's more well-versed in licensing than I am.

[skade]

I'm not a lawyer, but reasonably versed, regularly handling such cases for clients (in which cases the other side is a lawyer).

Hm, build scripts hiding stderr is indeed annoying :(.

The claim that OpenSSL is incompatible with GPL is undisputed[1], with GNU especially advising against it. I would no go as far as giving explicit advice, but it's a good, non-bikesheddable example for things linking OpenSSL statically might bring. Documenting things like the interesting licensing situation (with the base artifact being of interest) would definitely guide the way of the reviewer.

https://www.gnu.org/licenses/license-list.html#OpenSSL

[joshtriplett]

(Preface: I'm not a lawyer, and this isn't legal advice. However, I review licenses and other software legal matters professionally.)

@skade Static versus dynamic doesn't matter for compatibility purposes. (The only time it matters is with the LGPL, where the easiest way to satisfy the LGPL's requirements is to dynamically link.)

Dynamically or statically linking GPLed code to OpenSSL under the existing OpenSSL license (prior to its Apache relicense) creates a combination you can't distribute, because it doesn't satisfy the terms of the GPL. (Even after the relicense, OpenSSL is still incompatible with GPLv2-only code, but it becomes compatible with GPLv3 or "v2 or later" code.)

On the other hand, there are some circumstances where you could have both GPLed and OpenSSL-licensed dependencies and not have a problem; for instance, if only one got linked into the final binary and the other was a build tool such as a parser generator. Metadata has its limits. At best, a tool looking for license compatibility based on metadata could tell you "you might have an issue, you should look at these packages and how you use them".

So, nothing needs to depend on the static flag here. It would be somewhat helpful, for metadata purposes, if the sys crate somehow declared the OpenSSL license; once 3.0 comes out, though, that gets complicated, as the license would depend on the version of OpenSSL.

At some future point, it might make sense to require a feature flag to opt into support for the old OpenSSL and its license. I don't know the best solution here.

But "static" vs "dynamic" definitely doesn't come into play here.