Anyone who sponsors a small package into Debian (or sits downstream of one) ends up watching every patch land in front of a human reviewer before it ships. Two months into using a coding assistant to draft changelog entries, the disclosure question becomes real fast: do you tell your sponsor on the first patch, or wait for them to ask. This week Debian published its first formal policy on AI-assisted contributions, and the resolution is short enough to fit on a screen. The interesting part is not what the policy says. The interesting part is what it does not say, and what it implies about the next year of open source maintainership.
The resolution is called “Responsible Use of Generative AI.” Generative AI refers to models trained on large text corpora that produce new text or code in response to a natural-language prompt. The outcome was permissive-with-guardrails. Tools are allowed for development, maintenance, and documentation. The contributor owns the output. Disclosure is encouraged. Sensitive material cannot be sent to a third-party AI service. That last clause is the hard part. The rest is framework.
What the resolution actually permits
Debian treats AI assistance as a productivity tool, the same way it treats an IDE (integrated development environment) autocomplete or a code-search utility. A maintainer can use a model to draft a patch, write a man page, or sketch a configuration snippet. They must understand what they submitted, they must review it, they must test it, and they must change it where it is wrong. There is no “the AI wrote this” exception, because there is no “the IDE wrote this” exception either. The human remains the unit of accountability, every time.
Disclosure is the soft part. The resolution says contributors are “encouraged” to note when AI tooling was used. That word choice is deliberate. Mandatory disclosure would have produced a flood of low-value notes, and a hard ban would have driven the practice underground. Encouragement is the middle path, and it relies on reviewer judgment to ask when something looks off.
The security carve-out is the hard part. You cannot pipe Debian security work through a third-party AI service. That covers CVE numbers (the public identifiers used to track disclosed vulnerabilities), embargoed advisories (security issues kept confidential until a coordinated release date), package signing keys, and any internal infrastructure information. Generative AI providers are not Debian’s threat model in the usual sense, but their training pipelines and prompt logs are not under Debian’s control, and the project is treating them as a confidential-data sink. That is the correct posture for a security-sensitive project, and most projects do not yet have it.
Three things the resolution does not mention
Three omissions are louder than the policy itself.
- No minimum disclosure threshold. The policy does not say when disclosure is required, only that it is encouraged. That works for a typo fix or a config tweak, and it works for a 500-line patch you drafted with a model. The policy leaves the call to the contributor, and it does not say what happens if a contributor gets the call wrong.
- No review tooling requirement. The policy does not require or recommend any specific detection or review tooling. Detectors exist for AI-generated text and code, but they are noisy and easy to fool with light editing. The signal still comes from a human reading the diff (the line-by-line change in a code review) carefully, which costs reviewer time.
- No enforcement mechanism. The policy is a resolution, not a license change. There is no automated check, no pre-commit hook (a script that runs before a commit is accepted, to catch policy violations), and no maintainer-level escalation path beyond the existing dispute process. Enforcement happens through social pressure and reviewer judgment.
For a hobbyist running Debian on a laptop, none of this changes your daily experience. Your system will not start shipping AI-written configuration files next week. What changes is the culture of the project you get updates from. You are buying into that trade, knowingly or not.
Why the open source world is splitting into three buckets
Debian is not the first project to wrestle with this. It is the latest in a long line, and the patterns are clear enough to name. Most large projects are landing in one of three buckets, and the bucket a project chooses tells you a lot about its risk tolerance and contributor base.
- Hard ban. GCC and OpenJDK have decided that the risk of bad code outweighs the productivity gain. AI-assisted patches are rejected on submission. This is the easiest policy to enforce and the hardest to maintain as contributors drift in from training pipelines where AI is normal.
- Tag and review. The Linux kernel is the canonical example. AI-assisted patches are allowed, but reviewers must know what they are looking at. The generated code still has to follow the project’s license. GPL 2.0 (the GNU General Public License version 2.0, the open source license that requires derivative work to also be open source) does not bend for the tool you used.
- Permissive with guardrails. Debian, the Fedora drafts, and a handful of smaller projects fall here. You can use AI, but you own the output, and you cannot pipe sensitive material through third-party services. Review burden is the implicit cost, and the smaller the project, the heavier that cost lands.
- No policy yet. Most small projects, including most language-specific package registries and many single-maintainer libraries, have not published anything. They are waiting to see which way the wind blows, and they will be forced to write something either when a contributor asks or when the first AI slop lands in their tree.
The reaction is the part to watch
When a foundational project publishes a policy, the comments under the announcement tell you more than the policy itself. Debian’s announcement pulled the usual two camps out of the woodwork, and the loudest voices on the no side were not arguing about whether AI is useful. They were arguing about what kind of project Debian is supposed to be. At least one long-time contributor announced they were leaving, and the joke renames spread faster than the actual resolution. When maintainers walk away from a project over a procedural vote, it usually means the values question underneath feels larger than the policy text, and that is the part to watch over the next year.
The next twelve months of Debian contributions will be the dataset everyone else uses to decide whether the compromise held. If the policy produces a steady stream of well-reviewed AI-assisted patches with clear disclosure, the middle bucket becomes the safe default. If it produces a stream of low-quality AI slop that the reviewers miss, the next policy will look a lot more like the GCC hard ban. Either outcome is informative, and both will move through the open source world faster than any resolution text could.
What I would write differently
The disclosure clause is the soft underbelly of the whole resolution. “Encouraged” is doing a lot of work in the text. If I were writing the policy, I would make disclosure mandatory for anything larger than a typo fix, with a short note in the commit message or pull request body. The cost to contributors is small. The benefit to reviewers is large. Right now the policy trusts contributors to do the right thing, and that is a fine assumption most of the time, but the failure mode when it is wrong is bad AI slop landing in a stable distribution.
Package metadata is the security carve-out I would add. The current carve-out covers CVE details, embargoed advisories, and signing keys, but it stops short of the package metadata that other distributions mirror first. A poisoned metadata entry has a wider blast radius than most maintainers realize, and the model providers do not need to see CVE numbers to leak it.
Reviewer time is the cost nobody is going to budget for. If your reviewer pool is two people on a good day, the new policy is a real cost. Budget reviewer time, or write the rules for your own project before you have to make the call under pressure. The projects that wrote their rules in calm times are doing better than the ones still arguing mid-vote, and that is the lesson most worth keeping for your own work, even if you never touch a Debian package.
Trade-offs
The compromise is permissive on the input side and strict on the output side, which is the right shape in principle but expensive in practice. Reviewers now have to catch AI slop they never had to look for before, and the tooling to catch it is not standardized. Some projects are experimenting with detectors, but detectors are noisy and easy to fool with light editing. The signal still comes from a careful human reading the diff. That costs time, and time is the thing most open source projects do not have.
The alternative was a hard ban like the one GCC and OpenJDK chose. A hard ban is easier to enforce and easier to explain, but it locks out a generation of contributors who learned to use AI tools in college and expect to use them at work. The compromise tries to keep the door open without losing accountability. Whether that survives the next round of AI slop incidents is the open question, and the answer will depend on how seriously the community takes reviewer burden in the first twelve months.
If you maintain a project downstream of Debian, the trade is real but bearable. Expect one to two extra review cycles per non-trivial patch, expect to write a short AI policy for your own project, and expect at least one contributor to argue about it on your mailing list in the first month. If you only run Debian on a laptop and never touch packaging, the trade is invisible to you. The argument is happening above your head, and that is fine.
What I would tell past me
Three things, if I could send a message back to the version of me that ran my first apt upgrade on a Debian box.
- A policy written in calm times is worth more than a policy written after the first incident. Debian did this right. They argued about it on a mailing list, then voted, then published the resolution. Most projects will be forced to write their policy after the first AI slop lands in their tree, and that is the worse order to do it in.
- The security carve-out is the part that matters. Generative AI tools leak prompt inputs in ways that are not always obvious. Treat anything sensitive as if you sent it to a public mailing list, because in practice you did. The Debian policy forbids this for security material, and your own project should too.
- Reviewer time is the hidden cost. If your reviewer pool is small, the new AI era is the era of more reviewer time, not less. Plan for it, or accept lower-quality contributions. There is no third option that holds up under load.