Add AI tools policy#13726
Conversation
| Disclosure of the use of AI tools in the PR description is appreciated, | ||
| while not required. Be prepared to explain how the tool was used and what | ||
| changes it made. |
There was a problem hiding this comment.
So ultimately I don't expect crates.io to have a lot of PRs or issues so I think that ultimately this is just me giving advice that you're free to ignore. But at least from what I found, even projects which strongly support AI tools have been in favour of disclosing just so they know what they're dealing with, and I think that it's okay to have a hard rule with no punishments for forgetting it.
Like, I figure the rate of issues/PRs is so low that you have the time/resources to just individually talk to each person and figure out what they're working with anyway, but it can be helpful to ask for to see what people are using.
Just a few examples of other policies that feel relevant here:
There was a problem hiding this comment.
But at least from what I found, even projects which strongly support AI tools have been in favour of disclosing just so they know what they're dealing with, and I think that it's okay to have a hard rule with no punishments for forgetting it.
This would also be my preference.
I litigated this at some length within the Foundation when we were drafting our internal AI policy, so my apologies to @Turbo87 for the repeat, but the short version is that I believe that we should require disclosure for two primary reasons:
- Legal concerns. While I suspect our US-focused legal advice that LLM contributions are not subject to copyright will eventually end up being codified into international copyright law, this isn't even fully settled in the US, and we also have to operate in other, slower moving jurisdictions. If this does not end up being the result, we will need to be able to account for the origin of every contribution. Even if that outcome is unlikely, I think the minimal cost of requiring disclosure now is a small price to pay to make it easier to handle that eventuality.
- Review practicalities. While I don't think knowing LLMs have been used would meaningfully change how I review PRs from within the crates.io team, we do accept external contributions, and the sorts of things I expect to look for in review would change for a developer who used LLM assistance versus not, as would how I communicate with that contributor.
I don't want this to be some onerous process. I'd be happy with an Assisted-By or Co-Authored-By trailer in either the commit message or the PR description, much like the Linux kernel policy. But I do think it's important that we require this.
There was a problem hiding this comment.
It would be interesting to hear from counsel on the first point. I would expect to hear a mixed set of pros and cons for each choice — widespread disclosure seems likely to carry some risks too for the Project. Regarding the second point, the relevant comment in the Python discussions was this one — in short, reviewers need to assume LLM use anyway.
Disclosure has more than minimal cost:
- The transparency dilemma finding includes considerable data showing that, contrary to intuition, disclosure of LLM use erodes trust.
- Once primed about LLM use, people start to see LLM fingerprints that aren't actually there — we're creatures that see faces in clouds. Disclosure can increase the risk of false accusations of more LLM use than was disclosed.
- We're operating in an environment where people are actively shaming others who use LLMs. Highlighting one's use subjects one to the risk of this shaming.
Mandating disclosure has additional costs. It becomes something we need to enforce fairly and consistently. As part of a moderation policy, we'd be talking about banning people from the Project over this. If it turns out the policy is unenforceable and that people choose not to disclose due to these costs, then we'll have created a kind of policy fiction. That's not any good for us.
Similar to Python, we can encourage disclosure without incurring the costs that accompany mandating it.
There was a problem hiding this comment.
So, it is worth reiterating on the legal point that generally the result of using LLMs is the removal of copyright protections, not the addition of extra burdens, which does not matter given the extremely permissive license crates.io uses. It does matter for proprietary code and copyleft code, but for open source, permissively licensed work, it seems fine.
Additionally, it seems incredibly likely that if any copyright questions came up, e.g. someone was upset that code verbatim was used without authorisation, there would be ample time to fix the issue (removing the offending code) rather than these being immediate repercussions.
Most of the projects that I've seen be concerned with copyright issues are copyleft and thus specifically rely on copyright to enforce licencing, which just isn't the case here. So, while I do think there are other points to discuss, I don't think the legal point is particularly compelling here, which also matches the existing advice given by Foundation counsel on the matter.
There was a problem hiding this comment.
I think I do most of the PR reviews on crates.io at the moment (obviously excluding my own PRs…), and knowing whether AI was involved wouldn't change much how I review. The "explain your changes" requirement is already what I actually care about. For first-time contributors with zero context I agree disclosure can help, but that's a pretty different situation from someone opening a dozens of PRs each month.
On the legal point: the PSF landed on this exact wording without requiring disclosure. I don't know what their counsel actually said about it, so I'm only guessing, but I'd be a little surprised if a project that size shipped an AI policy without running it past their lawyers at some point. If that's roughly right, it makes me want to understand what's specifically different about our situation before treating the legal angle as a strong reason to go further than they did.
And I think Travis is right that disclosure has real downsides in the current climate. Adding a trailer to every PR also adds quite a bit of friction when LLM tooling is opening them, and getting that tooling to reliably add trailers is a whole separate problem.
That said, here are a few things I'd be happy to put in the policy, if it helps:
- Bump "appreciated, while not required" to "encouraged, especially from new contributors"
- Add something like "reviewers may ask about AI usage when it would help, and contributors should answer honestly"
Two other options to avoid the additional friction for regular contributors:
-
We can flip the framing: say explicitly that reviewers should assume AI may have been used, and make disclosure of non-use the optional opt-in. At this point the vast majority of recent crates.io PRs had LLM involvement and IMHO it's better to optimize for the 90% case.
-
One-time disclosure for regulars, recorded privately: contributors who use AI tooling regularly disclose it once (e.g. via a comment on a designated issue in the team's private ops guide repo) instead of repeating it on every PR. The record exists, so reviewers on the team have access and the legal/review-practicalities angle is covered, but the disclosure isn't sitting in a public list that anyone can scrape and turn into a target. For someone like me who opens a lot of PRs that drops the per-PR friction effectively to zero while still leaving the information available where it matters. First-time or external contributors would still get asked by a PR template or maybe by the reviewer.
There was a problem hiding this comment.
I mean, ultimately, I do think that the small number of contributions is more than sufficient to prefer an ad hoc method of explaining/disclosing since, like I said, you probably have the bandwidth to just talk to everyone individually about their changes. I think that encouraging more transparency is good, but if you think the downsides outweigh the upsides here, that's fair.
There was a problem hiding this comment.
FYI for those that were not there: we discussed this policy proposal and the disclosure thread in particular in the team meeting last friday.
@rust-lang/crates-io I'm still open to feedback to my last comment in this thread. if I don't hear anything by the end of the week I'll assume that there are no objections to merging this as-is.
There was a problem hiding this comment.
In the opening comment here I read:
Project-wide AI policy for rust-lang is still being debated [...] ]If a project-wide policy is later adopted, we can align with it.
The policy discussed here differs in many parts from rust-forge#1040 (for example the disclosure policy) and I appreciate you want something out sooner.
But I want to raise a more general question: this policy is more lenient than the other one, so I think that if you want to adopt rust-forge#1040, you might find yourself deciding to backpedal on some items that are now allowed (or not mentioned), like the disclosure clause which we feel strongly about and many others, like bots reviews, typos fixes, etc.
How does the t-crates.io team feels when (or if) comes the question about adopting the rust-lang/rust policy?
|
This is something I totally didn't even consider until now, but are there any other public repos managed by the crates.io team or is everything besides this just like, private infra accounts for controlling the actual deployed resources? I mostly ask since, this makes the most sense to just say "this is the policy of the crates.io team," but I don't actually know if there's anything else that would be controlled by you folks. |
There was a problem hiding this comment.
Approved is probably a strong word here, so I won't use it.
I have significant ethical concerns with the current state-of-the-art with regards to LLM assistants, and will not use them myself in any generative context. However, that is my own boundary, and I accept that everyone gets to make their own choice.
As discussed below, I think we should require disclosure. With that change, I would accept this policy.
| Disclosure of the use of AI tools in the PR description is appreciated, | ||
| while not required. Be prepared to explain how the tool was used and what | ||
| changes it made. |
There was a problem hiding this comment.
But at least from what I found, even projects which strongly support AI tools have been in favour of disclosing just so they know what they're dealing with, and I think that it's okay to have a hard rule with no punishments for forgetting it.
This would also be my preference.
I litigated this at some length within the Foundation when we were drafting our internal AI policy, so my apologies to @Turbo87 for the repeat, but the short version is that I believe that we should require disclosure for two primary reasons:
- Legal concerns. While I suspect our US-focused legal advice that LLM contributions are not subject to copyright will eventually end up being codified into international copyright law, this isn't even fully settled in the US, and we also have to operate in other, slower moving jurisdictions. If this does not end up being the result, we will need to be able to account for the origin of every contribution. Even if that outcome is unlikely, I think the minimal cost of requiring disclosure now is a small price to pay to make it easier to handle that eventuality.
- Review practicalities. While I don't think knowing LLMs have been used would meaningfully change how I review PRs from within the crates.io team, we do accept external contributions, and the sorts of things I expect to look for in review would change for a developer who used LLM assistance versus not, as would how I communicate with that contributor.
I don't want this to be some onerous process. I'd be happy with an Assisted-By or Co-Authored-By trailer in either the commit message or the PR description, much like the Linux kernel policy. But I do think it's important that we require this.
That's a good call out, but in this case, this repo is the only public repo owned by the crates.io team. I expect this policy — if approved — would also apply to our one private repo (our ops guide), but I'm not sure it's necessary to change this to explicitly include that. 🤷 |
|
Yeah, I figure that this kind of policy doesn't need to be clarified for private repos considering how it's mostly aimed at contributors who aren't on the team and thus don't have expectations set yet. So, with this being the only public crate for the repo and the repo receiving such a small amount of traffic externally as-is this policy is more than sufficient. I don't know if there are any crates.io team members who aren't Foundation staff but I feel that regardless, just deferring to Foundation policy for internal stuff would be sufficient. |
Quick correction on the scope claim: there are actually a few other public repos in the crates.io team's orbit. The authoritative list is in the team-api (https://team-api.infra.rust-lang.org/v1/repos.json), but off the top of my head:
For the repos where the policy is actually relevant (
That way we don't have to manage copies, and as the team's repo list changes the policy follows automatically. |
|
Specifically for Might poke around later to see if the current infra we have allows automatically doing this via the Edit: It appears that this is done manually: https://github.com/rust-lang/team/blob/main/repos/rust-lang/crates.io-index.toml So, I'll open a thread on Zulip about it. |
This imports the AI tools guidelines from the CPython devguide (python/devguide#1778) verbatim, as a starting point for our own policy. The text is licensed under CC0-1.0. Source: https://github.com/python/devguide/blob/main/getting-started/ai-tools.rst
crates.io has no published "testing principles" document equivalent to the one this sentence references, so the guidance does not translate.
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
7 participants
This PR proposes adopting the CPython devguide's AI tools policy as crates.io's own, as
docs/AI-TOOLS.md(with one Python-specific testing sentence dropped). It is linked fromCONTRIBUTING.mdandAGENTS.md.The CPython policy puts responsibility for content on the submitter, requires contributors to be able to explain their changes, and doesn't try to ban AI tooling outright. That matches how things are already done in this project and seems a reasonable starting point.
Project-wide AI policy for rust-lang is still being debated in two open RFCs (neither close to consensus), with a separate
rust-lang/rust-scoped policy that explicitly excludes crates.io. If a project-wide policy is later adopted, we can align with it.Open to feedback on whether this is the right policy and whether anything should be adjusted before merging.
Related
rust-lang/rustrust-forge#1040