Project-wide LLM policy

[clarfonthey]

View all comments

Preface

A lot of discussion has occurred in private about the topic of LLM policy, and while some of that context has been included in the prior art, most of it is intentionally omitted here.

To keep things focused on policy, there are two broad categories of comments we'd like to request you avoid:

• Simply stating your viewpoint on LLMs, even if you provide reasons. While these arguments can be useful for the RFC, they are better worded as explicit suggestions to specific areas of the RFC, rather than as just general comments.
• Debating others' viewpoints on LLMs, or calling others out on their viewpoints. Again, we would rather these be focused on specific policy points and the merits of those points, than just general bickering.

In general, defer to the code of conduct.

Important

Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.

If you don't have a particular section of the RFC to comment on, you can click on the "Comment on this file" button on the top-right corner of the diff, to the right of the "Viewed" checkbox. This will create a separate thread even if others have commented on the file too.

Existing policies

Right now, this policy is also proposed concurrent with multiple policies which are scoped to specific teams/repos:

• rust-lang/rust repo policy: Add an LLM policy for rust-lang/rust rust-forge#1040
• crates.io team policy: Add AI tools policy crates.io#13726]
• rust-analyzer team policy: Adopt uv's AI policy rust-analyzer#22505

Additionally, the Leadership Council has proposed: rust-lang/leadership-council#308

This RFC intentionally does not supersede any scoped policies; those policies are free to be merged before this one. In fact, even if after an RFC is accepted, they can still be merged, since updating the policies everywhere takes time, and getting a policy out immediately is still a net benefit.

Once an RFC is accepted, things can be adjusted for consistency, and whether it is formally accepted by the Leadership Council or a delegated committee doesn't matter to the discussion at the moment.

Summary

This policy details the requirements for using generative Artificial Intelligence (AI) models, particularly Large Language Models (LLMs), in all aspects of the Rust project. This includes (but is not limited to) contributions of code, documentation, chat messages, issue descriptions, etc.

1. Trivial LLM usage is always allowed, and thus irrelevant to this policy.
   We allow changes made by LLMs are indistinguishable from those made by humans, where the LLM didn't have any creative input.
2. Slop, also known as vibe-coding, is spam and moderated accordingly.
   We disallow changes made by LLMs with minimal human intervention.
3. Potentially non-trivial LLM usage must be disclosed, ideally with as much detail as possible.
   (RFC-only note: This may necessitate additional tooling to notify new contributors about the policy and explain how disclosure works.)
4. Non-trivial usage, if correctly disclosed, is merely rejected or closed without any additional action.
   There are no formal punishments for non-trivial usage with disclosure.
5. Non-trivial usage without proper disclosure can become a Code of Conduct violation.
   There are formal punishments for frequent non-trivial usage without disclosure; this is seen as intentionally refusing to honor the boundaries we've set.
6. If a contributor does not fully understand the code they submit, their contribution may be rejected for that reason alone.
   This is similar to, but not always slop. For example, they may understand a large portion, but not all of it, which shows that they still put in a lot of effort.

In general, as long as contributors are demonstrating an earnest effort to reduce LLM usage, even if said reduction is not total, then they should be commended for that instead of punished, even if the project itself draws the line at non-trivial usage for accepted contributions.

RFC-only note: In terms of additional tooling for disclosure, this RFC encourages the creation of a bot that automatically replies to contributions from new users informing them of the LLM policy and what constitutes sufficient disclosure. As mentioned, in general, going into as much detail as possible (e.g. prompts used, etc.) is preferred, but not always required. The RFC leaves the exact details of such implementation unspecified and up for revision later.

Rendered

GitHub is being weird. I already merged these changes, so, it's weird it's showing them as unaddressed.

[imyxh]

Whatever it means to you to hear this from the outside: I sympathize greatly with your frustrations here and I appreciate your work more than you can imagine. Please take care, please feel better.

[lumi-me-not]

Thank you for all the work you've done. I also really appreciate it.

Take a break if you need to, take care of yourself. If you wish to vent, feel free to reach out.

Wishing you the best.

[clarfonthey]

So, it appears that somehow the root of this thread got hidden because of a direct report to GitHub, which is extremely concerning. For now, you can read it on rustbot's view, since it appears that GitHub implemented this (likely new) feature very poorly. But note that not even the moderators can unhide this comment, and I'm not even sure org admins can either. Will have to investigate, but, since Rust Week is this week, might take a while.

[olivia-fl]

So I understand that my voice does not have very much weight here, since I have only made fairly minor contributions to rust. I do not currently intend to make any future contributions due to the project's external appearance of support of LLMs. I am very strongly in support of this policy, especially now that it has been changed to ban non-trivial LLM use entirely. If it were accepted I would consider contributing to the project again. This is both because of the requirements it would impose but also, more importantly, because it takes the extensive ethical issues seriously rather than pretending that they do not exist or are somehow irrelevant to the practice of software-making. Seeing this gives me hope.

View changes since the review

[lumi-me-not]

I also have been thinking of contributing for a while, and having a policy like this would be very encouraging for me. I want to contribute to projects that care about ethical issues.

[jplatte]

As another contributor who hasn't done that much¹, I am in the same boat.

¹ a couple refactors towards const generics during libs blitz, some std API improvements / additions

[spookyvision]

thirded, I find pro LLM stances extremely offputting, have made minor contributions to Rust, rust-analyzer etc. in the past, and am absolutely not motivated to further engage with an ecosystem that is welcoming towards this technology.

[clarfonthey]

Also just clarifying, I explicitly mentioned I appreciated this being posted despite it potentially falling under:

• Simply stating your viewpoint on LLMs, even if you provide reasons. While these arguments can be useful for the RFC, they are better worded as explicit suggestions to specific areas of the RFC, rather than as just general comments.

I think that pointing out the sheer number of people who have been outright turned away from this project because of its inability to reject LLMs and their harm is important. So, as long as people keep their comments on this specific point confined to this thread, I think it's fine.

[Cyborus04]

I'm in much the same position. I won't contribute until a policy at least as strict as this one is adopted, and honestly even then, I'd still be hesitant to so long as pro-LLM voices are in positions of power in the project.

[NthPortal]

I'd like to voice a similar sentiment: I started learning Rust seven(?)-ish months ago, and I've rapidly fallen in love. while I haven't contributed yet, I became a core contributor to/maintainer of the last language I fell in love with, and have already contemplated contributing to Rust once I have a bit more experience reading and writing it. if this policy or another that is similarly strict against the use of LLMs is adopted, and I otherwise feel safe in the community, there is a good chance I will contribute. if Rust adopts a policy that is permissive of LLMs, I assuredly will not contribute

[Zireael-N]

I haven't contributed to the language myself, but Rust is a language that I really like. It's been my go-to language for personal projects for the last 6 years, it's a language I advocate for at my workplace. And seeing rust-lang/rust-forge@14956c3 made me rather disappointed.

Anyway, just wanted to say thanks to those of you who have contributed and are taking a stand right now. You are appreciated. ❤️

[oli-obk]

We (leadership council) are taking this off our nomination list. We don't have something concrete to discuss about it at present, but it can be renominated once the rust-lang/rust policy is merged (or otherwise handled) and there is a concrete ask of the council.

[clarfonthey]

I was honestly not expecting it to get nominated in the first place, so, that makes sense, although I would assume that the LC would be the ones on the FCP unless I'm mistaken.

[clarfonthey]

Hello, everyone!

You may have noticed that all the active discussion threads have been resolved, minus two:

• One thread for people to express that they would not be comfortable supporting the project if it does not restrict LLM usage.
• One thread where, upon sharing my personal exprerience with the vitriol surrounding this policy discussion, GitHub decided to block my comment under the "acceptable use" policy, even though it does not. They've refused to even respond to my support requests, even after it has been privately brought up through other channels to them.

Both of these remain relevant throughout the policy discussion and emphasise the need to put our feet down and unilaterally condemn and restrict LLM usage. Note that I still say restrict, not ban, because LLM usage is entirely unrestricted up until the point where it affects the content being written. If LLMs are still useful for accessibility, or if they are still usefull for sifting through data and other tasks, these usages are unaffected. See the RFC itself for more motivation and details.

If you're wondering where the old Motivation section went, a lot of people complained that it should be a blog post, and now it is. Note: effectively all the links that were shared in that motivation section are still included as relevant citations, summarised in the newer, shorter motivation section, and the blog post version is linked alongside it for context. I decided to concede that this context was an unnecessary barrier to reading the RFC, but importantly, all of the relevant citations are still included. Technically, the justification is all there, just in a form that offers additional reading instead of constituting required reading.

Side note: unfortunately, because GitHub doesn't like accessible semantic HTML, specifically on the GitHub view, you will need to expand the citations explicitly for links within them to work. (In plain HTML, <details> are automatically opened when anchors within them are linked. GitHub hates this for some reason.)

The RFC now is almost entirely the actual policy, a timeline of events in the Rust project, and examples of other policies in effect. There are only minor wording changes to the actual policy, plus one additional clause: Co-Authored-By trailers are explicitly forbidden, and Assisted-By and similar trailers are discouraged but not forbidden. This is for two reasons: one, that the presence of these trailers generally indicates nontrivial usage, and two, that they effectively provide advertisements for LLM providers in contributor lists.

Side note: I won't talk too much on the outstanding discussion to create a committee to shepherd the policy discussion. It is my opinion that this policy can continue to solicit feedback from project members regardless of who ultimately ratifies it. I believe that any accepted policy will have a shape similar to this one, similar to the proposed Forge policy, etc. and also believe that the committee should work with existing proposals rather than try to shut them down, which has already been expressed in that discussion.

View changes since the review