1769261 - Relicensing query re AVL library in Rust package "regalloc.rs"

Status: RESOLVED FIXED

(mozilla.org :: Licensing, task)

Description

[Julian Seward [:jseward]]

This is a followup to bug 1620332. That bug was about taking an AVL tree
library in C, with an "in the public domain" license, translating it to Rust,
and incorporating it into Cranelift, which is Apache-2 licensed.

That was approved. Part of the justification was that the change of language
made the two implementations substantially different, and that did indeed turn
out to be the case. As part of the translation I did considerable cleanup and
tuning of some parts, and added test code. The resulting file is at [1].

I'm now back working on SpiderMonkey and find myself in need of a good AVL tree
implementation. I was thinking of translating said library from Rust into C++
since good open-source implementations of AVL trees with compatible licensing
are very thin on the ground, and I have no desire to write one from scratch.

However, making such a translation might be construed as undermining the
original "different language" justification. Hence I would like to check:

(a) would such an undertaking be OK, from a licensing standpoint?

(b) the current Rust implementation [1] is part of Cranelift and hence is
Apache-2 licensed [2]. Would there be any issues with incorporating a C++
translation of it into Gecko (SpiderMonkey), given the latter is MPL-2 ?

[1] https://github.com/bytecodealliance/regalloc.rs/blob/main/lib/src/avl_tree.rs
[2] https://github.com/bytecodealliance/regalloc.rs/blob/main/LICENSE

Comment 1

[Mike Hoye [:mhoye]]

I believe that the same reasoning applies, and that Rust and C++ are both substantially different and the fact that the original C implementation was public domain implementation of a well-known, generic algorithm largely obviates the question.

That Apache2-licensed code can be integrated with the MPL2 is well established, but even so a rewrite for Spidermonkey of a well-understood general purpose algorithm will not run afoul of licensing concerns; we certainly wouldn't worry about this if it was a bubble sort or whatever, and I don't think we need to worry about it here either.

I'd like a thumbs up from dnazer here, but I think the reasoning is sound.

Comment 2

[Daniel Nazer]

I think the main reason the first licensing decision in bug 1620332 was safe is because the primary work was public domain! No concerns with creating a derivative work from a public domain work - you can license it however you please. The question in this bug is slightly trickier - but I think however we answer it there is a path to doing this and including the code in Firefox.

The general answer is that translating code from on language to another means the second work is a "derivative work" of the first in the copyright sense. This means you need to comply with the license of the first work. This is fine in this case since the Apache 2 license is compatible with the MPL 2.0.

We could maybe take the view that the second work isn't a derivative work because it's basically just re-implementing a public domain algorithm. That is a tricky judgment call. My guess, is that in this case what you're proposing will be a derivative work in the copyright sense (so I actually disagree with MHoye).

For example, if you just remembered the broad structure of the Rust code and some general things about how you approached the problem, the second work probably isn't a derivative work. But if you're going line-by-line as you write, it probably is.

So my advice to be safe is to treat this as if we are vendoring in code from the Rust AVL tree. We should add the license header in the relevant files and, if needed, in about:license

Comment 3

[Daniel Nazer]

Actually, wait, I have an important follow up! Goodness me I think I overlooked something obvious here.

Did anyone else work on that Rust implementation? Because if it's all your own work as a Mozilla employee then we can re-license it however we please. I don't believe the Bytecode Alliance required us to actually assign the copyright to BA. I don't think they even have a CLA. We only need to offer it to their repositories under the Apache 2.0 license, but that doesn't limit how we use the code since we are the author.

Upshot: since it's your code (or rather, Mozilla's code) you can rewrite it in C++ and license it under MPL 2.0

[Edit to add] This is something that's generally true when we contribute to other open source projects. Even for projects where there is a CLA you usually get to keep the copyright in the code that you wrote yourself. You just have to be fine with the fact that the code is also in the other project under whatever license that project has. So say we put some Mozilla-authored code in a Google repo that is MIT-licensed and then put the exact same code in an MPL 2.0-licensed mozilla repo. That's fine! But then someone can decide they prefer the MIT license and copy it from the Google repo instead of our repo.

Comment 4

[Julian Seward [:jseward]]

Daniel, thanks for looking at this.

Did anyone else work on that Rust implementation?

The history of the Rust version is visible at [1]. In short, creation of, and
all modifications to, that file were done by Mozilla employees.

What [1] shows is: I did the majority of the commits, including the initial
translation and some subsequent cleanup and tuning. There was some extension
work done on it by Benjamin Bouvier (bnjbvr); he was a Mozilla employee at the
time but is no longer with the company. There is also an administrative
commit from Dan Gohman (sunfish); he was also a Mozilla employee at the time.

Given that history, does your comment ..

since it's your code (or rather, Mozilla's code) you can rewrite it in C++
and license it under MPL 2.0

.. still apply?

[1] https://github.com/bytecodealliance/regalloc.rs/commits/main/lib/src/avl_tree.rs

Comment 5

[Daniel Nazer]

since it's your code (or rather, Mozilla's code) you can rewrite it in C++
and license it under MPL 2.0

.. still apply?

[1] https://github.com/bytecodealliance/regalloc.rs/commits/main/lib/src/avl_tree.rs

Yes! Good to go.

Comment 6

[Julian Seward [:jseward]]

Thanks both!