Extending the license

[Kobzol]

This repository currently does not have a top-level LICENSE file (#1880), which means that not all of its code is covered by a license. This is a problem on its own, but it became problematic recently since we now package the contents of this repository as a part of the Rust toolchain source distribution.

Currently, there is a MIT license file for code under the collector and site directories, but not the rest of the codebase. Ideally, we would like to add a top-level MIT license file that would cover the whole codebase, but for that we (probably?) need agreement from contributors that have modified code outside of these two directories.

Now, let's take a look at some statistics about these contributors. Historically, there was a top-level license file up until the commit e99853d4777a1df001853c619eead0c891c28488, created on 2. 9. 2017. Therefore, people who contributed to the codebase before this commit should have been covered by the license.

There are tens of contributors who committed to this repository after that commit (excluding people that have only contributed to collector or site, these are not counted at all, since these directories are covered by a license). However, it is not clear if all modifications should be counted, or if we should only take into account "non-trivial" contributions. Below you can find the number of such contributors, depending on how we count the modifications:

• Contributors who only made a change to the database and intern directories, which are arguably the only remaining non-trivial parts of the codebase (apart from documentation, CI configs, etc.): 13
• Contributors who made a change to anything else than collector or site: 36

We should probably get an agreement from one of these two sets of contributors to apply the top-level MIT license.

[Mark-Simulacrum]

@abibroom Can you help us figure out the right procedure to follow for getting the licenses here in better shape? In particular I think some key questions:

• How can we get sign-off from people on the license?
• Is there any differences in process whether we aim for Apache 2.0 OR MIT vs. just MIT?
  • If we do MIT first (since that's requiring less people), does that complicate follow-up to Apache 2.0, or no real difference?

We have some prior art in rust-lang/rfcs#2076 / rust-lang/rfcs#2044, but those are fairly old, so I'd like a fresh perspective. @Kobzol has written up some of the historical details in the description, happy to chase down more if needed.

[abibroom]

Based on what I know about other projects/foundations that have undertaken a relicense and the complexities it can involve, I would want to do the process once, which is to say pick what license you want to end up with and shoot for that from the start! (That said, I haven't looked at the size of codebase / number of contributors in those other cases. It could be that the stats @Kobzol quotes above mean that this wouldn't be such a huge undertaking.)

Having each individual contributor leave a comment stating that "I license past and future contributions under [license], allowing licensees to chose either at their option" (or just their past contributions if they prefer) seems like a reasonable, low-overhead way to go about it if Rust doesn't want to go full CLA.

I would recommend preparing a message for all the contributors that sets out the need for the license change, why this particular license was chosen, and any legal or other implications for the contributors - and then what we'd like them to do next. Make it easy for people to decide, and then easy to act on their decision.

How to distribute that message is an interesting question since I assume we probably don't have individual contact details for all the contributors. Perhaps tagging them in via an @-mention on this issue would be enough; but I wouldn't want it to come across as "we already decided this and we just need you to rubber-stamp it", so individual outreach might be better. Are all/most/any of these contributors still active in the Rust Project, on Zulip, etc?

There should be a threshold for agreement decided on in advance - the point at which the change can go forward even if some people have not yet responded. This probably boils down to deciding between getting a majority of people, or a majority of lines of code. For instance, Apache Foundation, when accepting new projects, requires the "major contributors (by volume)" to have completed Apache's CLA.

If anyone who has provided significant contributions is non-responsive after enough time and reminders, then it could be necessary to consider rewriting those bits of the code, but let's hope that's not an issue.

[Kobzol]

Thanks for the info! It sounds reasonable. Most contributors (especially in the group of 13 people) should be available for contact on Zulip (and also GitHub).

Deciding on a time threshold is a good idea, rust-lang/rfcs#2076 has been stuck for 5+ years because there was no such deadline decided up front.

However, the main thing that I am interested in is who exactly is a "major contributor". As with most repos, there are a few people that contributed a lot to this codebase, and then there's of course the long tail of people that have 1-5 small commits with some small details, but there are many of such people, which makes contacting them harder. I wonder if we could define whose contribution is "major enough" to decide which contributors we should ask for the (re)licensing (and could we perhaps eventually do this as a global policy across rust-lang repositories?).

[abibroom]

However, the main thing that I am interested in is who exactly is a "major contributor".

That's the hard part. :) It's a bit subjective, and the definition could be different for different repos. Off the top of my head I can think of a few factors to consider:

• Contributed at least X% of the total lines of code
• Contributed a major feature
• Has made at least X commits
• Has been consistently active since rustc-perf's beginnings
• Is (or was) a Rust Project team member

[Kobzol]

Thanks! We have discussed this with Mark, and I have suggested this wording:

Please let me know what do you think, thank you.

[nnethercote]

The checkoff image doesn't show the full checkoff text, but it looks like it doesn't mention rustc-perf explicitly. It should say something like "I license past and future contributions to the rustc-perf project under the ..."

[Kobzol]

I took the text from rust-lang/rfcs#2076 and Abi suggested the same wording. But being explicit doesn't hurt anything I suppose, so I can add rustc-perf to the text, fine by me.

[abibroom]

The first sentence of this issue:

This repository currently does not have a top-level LICENSE file (#1880), which means that not all of its code is covered by a license.

explains really well the problem you're trying to solve, so I think I'd add that to the new message as well.

[Kobzol]

Good point!

So, new text:

This repository currently does not have a top-level LICENSE file (#1880), which means that not all of its code is covered by a license. We would like to license the whole rustc-perf repository (apart from the collector/compile-benchmarks directory, which has its own licenses) under the MIT License, to make it easier to use rustc-perf in rustc source distributions. In the future, we might want to extend this license to MIT/Apache 2.0 (although currently we're aiming at MIT, as a start, since it is easier), hence we would like to ask the contributors to agree with a dual MIT/Apache 2.0 license, as a sort of future-proofing.

To do that, we need contributors that made commits to this repository (with some caveats, see below) to agree by posting a comment stating their approval to this issue. Please see instructions at the bottom of this issue if you are mentioned in the list below. I will try to also contact the contributors individually.

And the modified agreement line:

I license past and future contributions to the `rust-lang/rustc-perf` repository under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Sounds good?

[Kobzol]

Created the checkoff issue here.

[Kobzol]

We got an approval from 30/31 contributors. The last remaining contributor has contributed code that has since been deleted and is no longer a part of this repository as of today (#1933 (comment)).

@abibroom Do you see any remaining concerns or can we move forward with applying a top-level (MIT) license to this repository?

[abibroom]

That's really impressive! 🎉

No further concerns from me - go ahead.

[Kobzol]

Great! We have added the top-level license: #1933 (comment).