1314071 - Licensing checklist for vendoring 3rd party sources

Status: NEW

(Firefox Build System :: General, defect)

Description

[Gregory Szorc [:gps]]

In bug 1294565 we added a `mach vendor rust` command that vendors into mozilla-central source dependencies for newly-introduced Rust dependencies.

Historically, vendoring new sources that are compiled into Firefox has been a somewhat rare occurrence - maybe something that happens a few times a year. As such, we don't really have a streamlined process for dealing with the licensing aspect of adding new dependencies - everything is more or less treated as a one off.

With Quantum, I expect us to introduce a number of Rust dependencies in rapid order. With each one, we need to consider licensing implications.

gerv: Most licensing questions tend to wind up on your plate. How would you like us to handle the introduction of new 3rd party sources compiled into Firefox going forward? e.g. should there be an explicit license review as part of the code review process before committing to mozilla-central? Is this something that can happen periodically post review/landing? Under what circumstances does about:license need updated?

Comment 1

[(not currently active) Ted Mielczarek]

Crates can specify a license in their Cargo.toml. I did some cursory googling and found a `cargo-license` tool we could build on:
https://github.com/onur/cargo-license

We should definitely require that all crates we vendor have a license, and we could certainly require it to be in a set of approved licenses.

Comment 2

[Gervase Markham [:gerv]]

The licensing team (basically, me) needs to approve the license of new imported code if it's not exactly identical to something we already use. (So, for example, the standard Rust Apache 2.0/MIT dual license probably needs including once in about:license but then anything else under it can just be imported without further admin.)

This isn't usually a heavyweight process, and could happen in batches, as long as we don't get to a point where if the team says "we can't use this", we have problems because it's already irredeemably entangled. about:license needs to contain a copy of the license for everything shipped with Firefox.

Does that help?

Gerv

Comment 3

[Gregory Szorc [:gps]]

Yes, this helps.

Looking through https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust, we already have plenty of libraries using the Apache 2.0/MIT dual license. I'll get a bug on file to add that to about:license.

https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust/matches is an interesting case. Its Cargo.toml says it is MIT license but there is no LICENSE (or similar) file nor a license header in the source file. Not sure if the Cargo.toml metadata is sufficient there.

https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust/byteorder appears to be licensed dual MIT and "Unlicense." Presumably this needs about:license love as well.

I also noticed that unicode-bidi's Cargo.toml lists it license as "MIT / Apache-2.0" instead of "MIT/Apache-2.0" (note the spaces).

Comment 4

[Mike Hommey [:glandium]]

(In reply to Gervase Markham [:gerv] from comment #2)
> The licensing team (basically, me) needs to approve the license of new
> imported code if it's not exactly identical to something we already use.
> (So, for example, the standard Rust Apache 2.0/MIT dual license probably
> needs including once in about:license but then anything else under it can
> just be imported without further admin.)

about:license contains paths, surely new code with the same license should have its path added, right?

Comment 5

[Mike Hommey [:glandium]]

(Note about about:license for rust code: the corresponding paragraphs should be #ifdef'ed on the appropriate MOZ_RUST_*)

Comment 6

[Gervase Markham [:gerv]]

(In reply to Gregory Szorc [:gps] from comment #3)
> Looking through
> https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust, we already
> have plenty of libraries using the Apache 2.0/MIT dual license. I'll get a
> bug on file to add that to about:license.

Well, we can just say we are using the code in Firefox under the Apache license (that's the license most people are expected to use, out of the two) and that's already present. So no real need here.

The sources will, of course, remain dual-licensed, as will our contributions.

> https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust/matches is
> an interesting case. Its Cargo.toml says it is MIT license but there is no
> LICENSE (or similar) file nor a license header in the source file. Not sure
> if the Cargo.toml metadata is sufficient there.

I think we should seek clarity from the author as a matter of good practice. It doesn't take much to check in a LICENSE file.

> https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust/byteorder
> appears to be licensed dual MIT and "Unlicense." Presumably this needs
> about:license love as well.

We'll take that under the MIT. The Unlicense is not OSI-approved.

> I also noticed that unicode-bidi's Cargo.toml lists it license as "MIT /
> Apache-2.0" instead of "MIT/Apache-2.0" (note the spaces).

Not legally significant :-)

> about:license contains paths, surely new code with the same license should have its path added, right?

Yes, but the license has to be absolutely identical. Often with MIT or BSD, there are irritating small variants.

Gerv

Comment 7

[Bobby Holley (:bholley)]

(In reply to Gervase Markham [:gerv] from comment #6)
> > https://hg.mozilla.org/mozilla-central/file/tip/third_party/rust/matches is
> > an interesting case. Its Cargo.toml says it is MIT license but there is no
> > LICENSE (or similar) file nor a license header in the source file. Not sure
> > if the Cargo.toml metadata is sufficient there.
> 
> I think we should seek clarity from the author as a matter of good practice.
> It doesn't take much to check in a LICENSE file.

The author (or at least maintainer) is Simon.

Comment 8

[Simon Sapin (:SimonSapin)]

I just published https://crates.io/crates/matches version 0.1.4 with a LICENSE file.

> Yes, but the license has to be absolutely identical.

Let me know if I can tweak it to help with this.

Comment 9

[Gervase Markham [:gerv]]

(In reply to Simon Sapin (:SimonSapin) from comment #8)
> I just published https://crates.io/crates/matches version 0.1.4 with a
> LICENSE file.

The trouble with MIT/BSD is that they start with a copyright line, and if the copyright line is different, the license is different :-| There's not really a great solution to that. Copyright lines have no legal effect, so one option is to say:

Copyright (c) 2014 Contributors

and then if everyone else adopts that convention, then the license is identical and we only need one copy.

Gerv

Comment 10

[Simon Sapin (:SimonSapin)]

Should I change matches to do this?

Can the year also make a license not identical?

Comment 11

[Gervase Markham [:gerv]]

(In reply to Simon Sapin (:SimonSapin) from comment #10)
> Should I change matches to do this?

It can't hurt :-)

> Can the year also make a license not identical?

Yes, actually. So just say Copyright (C) Contributors.

Gerv