Figure out a strategy for licensing considerations

[ehuss]

Support for licensing was previously owned by the core team. I think the Council should consider what strategy they want to take for supporting licensing questions and considerations for the Project as a whole. Should the Council be responsible? Should a team be created to delegate that responsibility? Can the Foundation provide support somehow?

Some examples of questions or considerations:

• When new licenses are added to the Rust distribution, how do we make decisions on those?
  • Some recent examples are questions about including libgcc GPL code (https://rust-lang.zulipchat.com/#narrow/stream/386786-rustc-codegen-gcc/topic/Add.20script.20to.20build.20libgccjit.20easily.3F, https://rust-lang.zulipchat.com/#narrow/stream/231349-t-core.2Flicensing/topic/cg_gcc.20vendoring)
• Do we need a better copyright/license collection? (See Rust code copyright situation is unclear rust#63232, Rewrite the COPYRIGHT file rust#39897)
  • Last year, REUSE support was added, but I am not clear where things go from there.
  • New collector added Jan 2025: Add COPYRIGHT-*.html files to distribution and update COPYRIGHT rust#133461
• Are there problems with the existing license exceptions that we have?
• Who is assigned copyright?
• Possible violations (like GPL currently in rustup)?
  • rustup GPL removed in Remove GPG signature support rustup#3277. Are there others?
  • Consider adding an org-wide license checker.
• Supporting issues like the apfloat rewrite. (Replace in-tree rustc_apfloat with the new version of the crate rust#113843)
• Confusion over the "above copyright notice" that doesn't exist: rust-lang/rust@2a8807e#commitcomment-28375512
  • Resolved: Add COPYRIGHT-*.html files to distribution and update COPYRIGHT rust#133461
• Rename (or otherwise replace) the t-core/license Zulip channel.
• See also Clarify the Rust compiler's licensing status core-team#8
• See also (Apache-2.0 OR MIT) explanation page rust-forge#241
• Support rust-lang projects that need to answer questions of how to handle licensing details. Example: License headers in files generated by mdbook init --theme mdBook#2220
• What is the license and requirements of the standard library? (Licensing: It's unclear exactly what license text must be included in a Rust binary. rust#67014)
• Finalizing the RFC relicensing: Tracking issue for RFC 2044: dual-MIT/Apache2 licensing rust#43461
• Are we properly honoring all of the licenses in all rust-lang projects? For example, some licenses require the license to be included in binary distributions, which we don't always do.
• Anything in rust-lang/rust A-licensing

What other questions or considerations are there?

[crlf0710]

Also, finishing up rust-lang/rust#43461 .

[eholk]

Here's a recent PR that was relevant here: rust-lang/rust#125419

[traviscross]

We discussed this in our meeting today, as this item is marked as needing a decision by the council but had not seen an update in some time.

We talked about how there may be two issues here: 1) what to do about the backlog of things to be resolved, and 2) how to handle the questions that come up periodically going forward. The first of these is probably the harder problem.

On this backlog work, the Foundation has previously replied that, to help with this, they would need to budget for this project. We discussed how we might want to ask them to do this.

We also discussed how this might be a good example of where we could use some kind of RFQ (request for quotation) process. That is, where we could identify and describe some scope of work, and then solicit quotations for tackling that work. We would pay for that out of our standard budget.

[eholk]

If there are two issues here, should we fork one of them off into its own issue?

[ehuss]

I think the number of issues is not distinct. From a high level, I think they are:

• Should the Council form a team to be responsible for managing licensing and copyright within the Project? If so, who would be on that team? What would be their responsibility? If we cannot handle this with volunteers, can the Foundation directly take responsibility?
• Go through the (large) backlog of outstanding licensing and copyright issues and bring them to completion.
• Establish policies for licensing and copyright. Currently we have ad-hoc policies, many of which are not written down. This may require answering what our values as a project are.
• Set up a clear process for coordinating and answering new license and copyright questions via the Foundation as needed.
• Set up tooling to monitor license and copyright use throughout the project (to avoid random teams from inadvertently breaking policies).

But, imagine this hypothetical (wishful) scenario: We decide that we cannot manage this as volunteers, and the Foundation agrees to take responsibility for resolving the backlog and ongoing concerns. If that's the answer, then there is only one issue (toss this onto them).

However, if that's not the answer, then there might be multiple issues that might go in different places. The backlog itself could be split into a dozen issues. Determining the Foundation interaction could be multiple issues, such as determining budget concerns. If we form a separate team, then they would probably have a GitHub repo of their own where we can break all these issues out into separate smaller pieces. Some of these issues might be ones they directly handle (like technical issues), and some might be ones only the Council can handle (project-wide policies) and some only the Foundation.

My intention with this issue was to answer the first question first, and then the following actions would depend on how that goes.

[traviscross]

Thanks @ehuss for those details. Thinking about those, here's a sketch of a proposal. The design idea of this proposal is to keep things simple while taking a concrete step forward toward solving the outstanding problems. We could always do more later.

Here's that sketch:

1. We want all artifacts of the Rust Project to be redistributable under the terms of MIT OR Apache-2.0.
   • Exceptions to this are to be approved by the council.
   • Repositories within the project should use cargo-deny or similar tooling in CI to verify license compliance and to track exceptions.
     • We'll start by simply asking all teams to please do this for the repositories they own.
2. Questions about licensing should be directed to the council.
   • E.g., PRs to add license exceptions to deny.toml should be marked I-council-nominated and cc @rust-lang/leadership-council.
   • For straightforward questions, knowledgeable members of the council may be able to provide an answer directly.
   • For some questions, the council may need to consider it as a group (i.e. en banc).
   • For other questions, the council may ask Foundation counsel to advise.
   • The council may later charter a team to handle licensing; handling this itself is an initial step to solve the immediate problem and build experience that will be useful in determining whether and how such a team should be chartered.
3. For the backlog items, the council will ask the Foundation to please draw up a plan and budget for working to solve the problems necessary so as to bring all artifacts of the project in line with item 1.

What do people think?

(I'll nominate for us to discuss this sketch and any follow-up comments that result. I'd expect this discussion to take 15 minutes.)

[ehuss]

Overall it sounds good, but I have a few concerns with that outline:

• I'm concerned about relying on the council members to be knowledgeable enough to be responsible for answering questions. Licensing is a specialized area, and if we have expectations that people routinely rotate in/out of the council, that means new people have to regularly gain that knowledge. If we expect the council to not be experts in licensing (which I think is the current state), then I wouldn't put any responsibility on them to make decisions before experts were consulted.
• An important pillar is creating guidelines for what is accepted and where. For example, there may be different constraints for first-party code versus licenses of dependencies. https://github.com/rust-lang/rust/blob/HEAD/src/tools/tidy/src/deps.rs contains a bunch of our exceptions, but I think many of those have been added ad-hoc without any overarching guidelines. For example, we may want to have specific guidelines for the Rust runtime (standard library + support) that appears in user's code, versus rustc, versus tools like cargo, versus internal tooling. We've been using slightly different criteria for those classes, but without any written reason or guidelines. It would be very helpful for someone to write those guidelines down and be responsible for them.

That's why I'm leaning towards having people who are knowledgeable in this area to be the primary point of responsibility. Only when those people want to change general policy should they get the council to approve it.

[traviscross]

@rustbot labels -I-lang-nominated

We talked about this in the last meeting. The general feeling was that this would need a team. So we'll revise the proposal and renominate later.

[rustbot]

Error: This repository is not enabled to use triagebot.
Add a triagebot.toml in the root of the default branch to enable it.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[ehuss]

Reached out at https://rust-lang.zulipchat.com/#narrow/channel/392734-council/topic/license.2Fcopyright.20support to solicit feedback on how we can get this unstuck.