Forgot your password?
Close
typodupeerror
Debian

Debian is Voting on Whether to Allow AI-Assisted Contributions (linuxiac.com) 50

Posted by EditorDavid from the poll-request dept.
Debian developers are voting on whether to ban AI-assisted contributions, reports the blog Linuxiac, with a ballot listing eight proposals and a "None of the above" option. The first one is still the original proposal to ban LLM-assisted contributions by changing the Debian Social Contract. This would stop generative AI from being used for direct Debian work like packaging, software, documentation, translations, websites, and project communication. However, upstream projects made with AI help would not be affected. The proposal gives several reasons for the ban, such as unclear copyright and licensing, doubts about the reliability of AI-generated work, extra review work for maintainers, aggressive scraping of Free Software resources, and the high resource use of large AI systems...

The second option would clearly allow contributions that are partly or fully made by an LLM, as long as contributors check their technical quality, security, licensing, and usefulness, fully understand the changes, and disclose major AI help. It would also ban sending private or sensitive Debian information to untrusted external AI services. A similar fourth option recognizes worries about generative AI but says banning it would be hard to enforce and not helpful. This proposal would accept AI-assisted Debian work if it follows the Debian Free Software Guidelines, is properly reviewed and understood by the contributor, and is marked as AI-assisted when needed. The fifth proposal is even more open. It says Debian should not support or ban generative AI tools, but should apply the same standards for quality, correctness, maintainability, and legality to all contributions, no matter how they were made...

One unique proposal is called "Debian is created by humans." Instead of banning AI tools for contributors, it focuses on what actually gets included in Debian. With this approach, contributors could use generative AI for research, analysis, exploration, or critique, but could not submit AI-generated output directly as Debian packaging, patches, documentation, bug reports, project communications, or other Debian work. As the proposal says: humans create Debian. Another, much stricter proposal asks Debian contributors to avoid LLM use as much as possible. It would require all Debian communication, like bug reports, mailing-list messages, Salsa discussions, and Planet Debian posts, to be written only by humans. Any AI use in Debian work would have to be disclosed, and violations could be handled under the project's Code of Conduct.
The CEO/founder of AI-native compliance management platform company Strike Graph believes a Debian AI ban is "the wrong fix for the actual problem" at hand, reports The New Stack: "Debian's ban isn't really about banning AI," [CEO Justin] Beals says. "It's an admission that nobody has built a reliable way to verify what an AI agent actually produced before it lands in a codebase this many systems depend on, including infrastructure running in orbit. That's a legitimate thing to be worried about...." He thinks that any policy statement that says AI isn't allowed simply won't hold up, as the tooling keeps getting harder to detect...

Looking across the complete set of tabled propositions, proposal A (no LLM contributions to Debian via social contract) needs a 3:1 majority to pass; the other seven proposals (B to H) need a simple majority.
This discussion has been archived. No new comments can be posted.

Debian is Voting on Whether to Allow AI-Assisted Contributions More

Debian is Voting on Whether to Allow AI-Assisted Contributions

Comments Filter:

  • News just in (Score:3)

    by BladeMelbourne ( 518866 ) on Sunday August 23, 2026 @04:03AM (#66302884)

    A company which makes money because AI exists - doesn't want this!

    More news at 11.

  • AI will rot our brains (Score:5, Interesting)

    by Damouze ( 766305 ) on Sunday August 23, 2026 @04:38AM (#66302916)

    Personally, I would go for the "Debian is made by humans" option or the option to exclude it alltogether.

    I feel very strongly that AI - at least the current way it is deployed - does more harm than good. Loss of (human) cognitive function through its overuse. An enormous ecological impact due to massive energy and cooling requirements of megadatacenters, you name it.

    The future of AI lies, as far as I'm concerned, in smaller scale applications, such as a domestic AI appliance, or in even smaller devices such as mobile phones.

    • Re: (Score:3)

      by sinij ( 911942 )
      I don't think ignoring AI and remaining relevant is an option that is available to Debian, at least insofar as Information Security. AI code analysis in search of vulnerabilities is a significant force multiplier, to the point that we are flooded with CVEs for almost every major commercial product. AI's ability to identify vulnerabilities in existing code is already working very well, ability to preemptively fix these issues during AI-generated code is still being worked on. As such, very soon AI generated

    • Re: (Score:3, Insightful)

      by Gravis Zero ( 934156 )

      While I mostly agree, the one part I may disagree with is with documentation. It's not uncommon that documentation can be scarce for certain things which means that if someone can generate, review, and publish documentation for part of the project, I see that as a way of helping users that would otherwise have very little, just poor documentation, or in some cases no documentation at all.

    • Re: (Score:3)

      by allo ( 1728082 )

      No matter if it will or not, your strong opinion won't stop what other people do. So do you really want to exclude those people from debian? Volunteers are hard to find and restricting a project on how volunteers are allowed to contribute will lead to fewer volunteers. If you exclude anyone who uses emacs instead of vi you may get better code due people not exiting the editor too early, but you will get fewer contributors as some belonging to the church of emacs are hard to convert.

    • Re: (Score:3, Insightful)

      by Espectr0 ( 577637 )

      every advance in technology comes at the expense of "rotting our brains"

      example: calculators caused our brains to "rot", because we no longer are good at math

      computers caused our brains to "rot", because we no longer need to manually process tons of data

      AI will cause our brains to "rot", because now we have someone do our work for you.

      yes, AI WILL replace some jobs, and at the same time it will help us do things that we couldn't do before. a bunch of new jobs will be created, as humans still need to code an

      • Re: (Score:2, Informative)

        by allo ( 1728082 )

        The environmental impact is smaller than people want to make you think. They show absolute numbers without showing a baseline. If you say "A query is worth 9 seconds of TV" (just powering your TV, not calculating the power required by your router, your ISPs infrastructure, the streaming server, etc. at all) and five drops of water, it suddenly sounds way less impressive than showing the absolute number.
        If some service is used a lot, it uses a lot of resources, even when the per-use resources are pretty low.

        • Re: (Score:1)

          by MrNaz ( 730548 )

          Problem is people aren't just querying. They're saying "generate a video of a cat riding a shark", which uses a LOT of inference and compute.

          • Re: (Score:2)

            by allo ( 1728082 )

            To put this in relation: Generating such a video takes about 5 minutes on a 300W graphics card (recent models, consumer card). That are 25 Wh for the video. Data center cards are a bit faster and more efficient for that, but let's assume the energy is about the same as using the diy models. If you would create the video without AI (let's say using playdough and a camera to create a stop motion video) it would take more than 25Wh alone to power the lights in your room while you create it.

            • Re: (Score:1)

              by MrNaz ( 730548 )

              The issue is that those videos are being created en masse. People would simply not create them in the first place. Making resources so easily available that people waste them without thinking is the reason capitalism has turned our society into a planet destroying machine and called it "quality of life". Nobody's quality of life is improved by the existence of videos of fake cats doing improbable things, yet we've now invested a civilization worth of resources into creating them. It's the broken window fall

              • Re: (Score:2)

                by allo ( 1728082 )

                "If we destroy the tools people won't create stuff and therefore not need resources to create stuff" is certainly true, but not what we want to do.

                • We should have the tools. I'm not arguing that we should go back to agrarian lifestyles. But somehow we as a society should find a way to not permit wanton waste of resources in the name of cheap, fleeting entertainment.

    • Re: (Score:2)

      by grumbel ( 592662 )

      "Debian is made by humans" makes as much sense as "holes dug by humans with shovels" when you have an excavator on site. AI is a force amplifier, an insanely fast and good one at that. It can not only write software, it can package it, port it, reverse engineer drivers for your favorite hardware and everything else a human might be able to do with a computer, but can't find the time, knowledge or motivation to do. AI is what basically turns all software into Open Source software, since AI isn't stopped by

  • thinking it through (Score:4, Interesting)

    by martin-boundary ( 547041 ) on Sunday August 23, 2026 @05:24AM (#66302966)

    He thinks that any policy statement that says AI isn't allowed simply won't hold up, as the tooling keeps getting harder to detect...

    It shouldn't be about detecting and preventing AI contributions with 100% accuracy. Some AI contributions will get through because people will always try something.

    It should be about spelling out the rules, then banishing people who break them, ripping out their "contributions" and shaming them publically if and when they are found out.

    This is not any more difficult than policing licensing terms is today. Debian already has a history of banishing non-Free software packages into special source repos. And, like any serious open source project, they already rip out code that isn't legally safe for them to use (eg if someone steals code and passes it off as their own and makes up a fake license).

    Eventually, the answer will be to have a standard mechanism for reporting suspicious sloppy source code and whistleblowing on the cheaters.

    • Re: (Score:1)

      by Anonymous Coward

      shaming someone publicly is never a good idea. This shows your project in a bad light and scares away contributors who think for what reason you may shame them. Your approach here is toxic for communities.

      • It's a balance. The absence of enforcement of rules is toxic in a different way. I believe that when rules are spelled out up front, anyone who deliberately flaunts them does not have the good of the community in mind. So why should they remain members of said community?

    • "This is not any more difficult than policing licensing terms is today. "

      It significantly more difficult that policing licensing terms. Any act that would break licensing terms is an act that is necessarily done publicly. While there would be dispute about whether the act violates a license, it would be easy to reach consensus that the act took place. E.g. in a questions of incompatible licenses, there may be argument over whether a submission's license in compatible with the projects it would be plainly vi

      • The breaking of licensing terms often takes place in private. For example, if X steals his employer's source code, slaps a fake open source license on the stolen code, and submits it to Debian, there's no way to know. Except if another employee Y happens to find the code online and notifies Debian about X's fraud.

        Enforcing a lifetime ban on X's contributions is the least Debian can do in that case to protect itself legally from the wronged company.

        • "submits it to Debian"

          It is nonsensical to suggest that you can submit to Debian privately. The accuser then says "Here is my original code; this submission which everyone can access equally, is a copy." There can be debate over whether the submission is a copy or not, but the existence of the submission and the existence of the accuser's original is are ground truths.

          For the use of AI case, the accuser says "this submission used AI" and then what? If someone saw the submitter use an AI that is direct evide

  • Unlike the systemd vote where they deliberately skipped asking a lot of people?

  • Correct one obvious (Score:3)

    by loufoque ( 1400831 ) on Sunday August 23, 2026 @06:47AM (#66303004)

    The correct choice is obvious, this sort of thing was already experienced in the Linux kernel and elsewhere.

    Patches are submitted by humans. It doesn't matter what tools you used to build the patch, so long as you stand behind it as a human and are responsible for it, meaning you did review it and make sure it is meaningful and worthwhile.

    The main concern with AI use is that it will continuously write code and pull requests with no effort; it moves the effort from writing the code to reviewing it. If you don't actually review and just push that responsibility to others, you're not doing anything of value and just causing more work for others.

    • Re: (Score:2)

      by Rei ( 128717 )

      I think the obvious counter to an influx in bug reports / pull requests is to have the first layer of review of bug reports / pull requests to be AI as well.

      Final remains humans.

      • I think the obvious counter to an influx in bug reports / pull requests is to have the first layer of review of bug reports / pull requests to be AI as well.

        Final remains humans.

        The only way this can end is using AI on some level. I agree. Simply rejecting patches because they are AI written does invite the solution of AI to reject AI patches..... The loop closes again.

      • Re: (Score:2)

        by allo ( 1728082 )

        And this isn't even about "slop" patches anymore. AI gets better at writing bugreports and finding real bugs and people might even get sensitive about not reporting so many duplicates. But now think of a bad actor trying to use AI to sneak a backdoor into a bugfix. The new amount of work due to AI heavily contributing may overwhelm people to let things slip and allow bad actors to exploit that lack of attention. The bad actor doesn't even need to use ai, they just need to exploit things slipping through as

    • Re: (Score:2)

      by allo ( 1728082 )

      I think all approaches basically contain "A human is responsible" in their core.

  • The summary implies a very bad wording of the measure. Any requirement that "no AI be used" fails, because you can't tell whether it happened or not.

    • Re: (Score:3)

      by batkiwi ( 137781 )

      Kernel 7.3 has a device driver (the intel iGPU driver) which was assisted by AI. This was done by Linus himself, not someone random.

      So anyone refusing to run AI assisted code is stuck on Kernel 7.2, or needs to disable this driver.

  • slop vs security (Score:3)

    by SysEngineer ( 4726931 ) on Sunday August 23, 2026 @09:49AM (#66303080)
    AI can create slop, but it can also find security issues.
    I verify the code with AI to find issues.

    • Re: (Score:3)

      by allo ( 1728082 )

      The problem is no longer about reports being bad, but currently about reports being duplicate. You write a bug, ten people's AIs find the bug and report it. You need to read ten reports about the bug and decide that nine are duplicates. Also the people reporting the bug don't understand it as well as their AI. This would not matter that much if it were about contributing with the help of (good) AI, but many of these will ask for a bounty, because they weren't interested in the project first place, but want

      • Re: (Score:2)

        by bsolar ( 1176767 )

        The problem is no longer about reports being bad, but currently about reports being duplicate. You write a bug, ten people's AIs find the bug and report it. You need to read ten reports about the bug and decide that nine are duplicates.

        An AI can easily decide that, at least as first step triage. It's one of the activities where it can be exceptionally good.

  • Nobody understands the AI generated code. Including the developer who prompted the AI. There could be unsafe paths in the code that could lead to failure modes.

Slashdot Top Deals

"Plan to throw one away. You will anyway." - Fred Brooks, "The Mythical Man Month"

Close