I should preface this with the fact that I am by no means a lawyer or anything like it. Nothing here constitutes a legal argument or should be taken as true. I may be completely wrong or have missed crucial details.

As part of a rust project I’ve been working on at dayjob, I’ve had to audit all dependencies for license compatibility with the AGPLv3, our preferred license. Sadly, I encountered what I think is a major ecosystem blocker, and we will likely not be able to license the code under AGPLv3, or any GPL license for that matter, having to go with a more permissive, but compatible license until the problem this post is about is fixed. Which is a shame, and something I wanna bring more attention to.

A fairly fundamental crate in rust is ring, providing “safe, fast, small crypto using Rust”. To understand how fundamental it is, consider that other crates such as rustls, the aws-sdk-rust crate, and sct make use of ring. And this is by no means an exhaustive list.

The problem with ring, as you may well notice if you dare read its rather convoluted license[1], is that amongst it’s licenses is the OpenSSL license. The problem with the OpenSSL license is it’s equivalent to a BSD4 clause license. That is, it contains the problematic advertisement clause.

1
2
3
4

 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

This clause is well known for being GPL-incompatible, and indeed, if you look up the OpenSSL license on the gnu.org list of gpl compatible licenses, it is indeed the case that the license is considered GPL-incompatible.

But so what? Big deal?

Big deal… yes. This means that if you want to interface with s3 storage[3], or use rustls, you’ll be GPL incompatible!

For example, consider the following GNU Affero General Public License Version 3 projects that use crates in the aws-sdk suite, or rustls.

• zed
• Signal-Calling-Service
• garage s3
• quickwit
• rustdesk

And these are just some quick examples I found with a quick github search, there is probably much more software currently out there in the rust ecosystem that’s using a license that its crates are fundamentally incompatible with[2].

While this is a problem the ring crate seems to be aware of, it’s sad to see that there is such a large wound on the FOSS compatibility of the rust crate ecosystem. Not to put any blame anywhere. I am well aware that if this was easy to fix, it wouldn’t be a problem anymore, and anyone wanting to criticize the ring devs should spend the effort helping them fix the situation, rather than complaining, they seem eager to solve this. But it is something I think needs more awareness.

Update 2024-06-19: We’ll try to go with EUPL-1.2, as it is compatible with all BSD licenses. Also, it seems to have many other useful properties. This does not make the problem disappear however, but it does create a path forward for a stronger license for rust projects affected that want SaaS loophole protections.

Footnotes

[1]: This is a problem the ring devs are working on. Let it be a lesson to start your project off using REUSE or paying the price down the line >:3

[2]: Yes, there are potential ways to mitigate this, but by a quick skim, I haven’t seen any of those implemented in these projects, and implementing them would likely be both architecturally ugly, and horribly inefficient. For… reasons, I’ll not actually elaborate on how you could potentially circumvent licenses like this, because I’m really not a lawyer.

[3]: Yes, there are other crates than the aws-sdk, but when investigating this for the project in question, none seem to be tennable solutions. Vet your dependencies!