Re: [MAINTAINERS SUMMIT] The role of AI and LLMs in the kernel process

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Sasha,

Thank you for summarizing the long discussions. I won't ask if this
summary has been written by an LLM :-)

On Sun, Dec 07, 2025 at 08:12:51PM -0500, Sasha Levin wrote:
> This (and parallel) threads have generated substantial discussion across
> several related topics.  In preperation for the Maintainer's summit, here's a
> summary of where we appear to have consensus, where we don't, and some
> questions to consider before the summit.
> 
> Where We Have Consensus:
> 
> 1. Human accountability is non-negotiable:
> 
> The From: line must always be a human who takes full responsibility for the
> patch. No "but the AI wrote that part" excuses. This maps cleanly to our
> existing DCO requirements and approach to tooling.
> 
> 2. Some form of disclosure is needed:
> 
> Whether it's a trailer tag, a note below the cut line, or something else,
> there's broad agreement that AI involvement should be disclosed. The exact
> mechanism is debatable, but the principle is not.
> 
> 3. Maintainer autonomy matters:
> 
> Individual subsystem maintainers should be empowered to set their own policies.
> An opt-in approach per-subsystem seems preferred over a kernel-wide mandate
> that doesn't account for different subsystem needs.
> 
> 4. This isn't going away:
> 
> Industry is already using AI extensively. We're already receiving AI-generated
> bug reports. Ignoring this won't make it disappear; better to have a thoughtful
> policy than no policy.
> 
> 5. Language assistance for non-native speakers is legitimate
> 
> Using AI to improve documentation and commit messages should not be stigmatized
> or treated the same as AI-generated code.
> 
> 
> Where We Don't Have Consensus:
> 
> 1. The nature of AI errors:
> 
> Some argue AI makes fundamentally different errors than humans - subtle
> mistakes that slip past review because we're trained to spot human-pattern
> errors. Others argue AI errors are obvious when the model is under-trained, and
> that better training can address most issues. This affects how much scrutiny
> AI-assisted patches need.
> 
> 2. Same bar or higher bar?
> 
> The kernel already has a significant bug rate - roughly 20% of commits in a
> release cycle are fixes. Should we hold AI to the same standard we hold humans,
> or does the kernel's criticality demand a higher bar for AI? There's genuine
> disagreement here.
> 
> 3. Legal risk tolerance:
> 
> DCO clause (a) requires certifying "I have the right to submit it under the
> open source license." With AI training data provenance unclear and litigation
> ongoing, how cautious should we be? Some advocate waiting for legal clarity;
> others argue the legal concerns are overblown and we should focus on practical
> guardrails.
> 
> 4. The asymmetric effort problem:
> 
> AI can generate patches in seconds; review takes hours. Unlike human
> contributors who learn from feedback and improve, AI models will repeat the
> same mistakes. How do we prevent maintainer overload? There's no clear answer
> yet.
> 
> 
> Questions for the Summit:
> 
> 1. Policy scope: Should we establish a kernel-wide minimum policy, or
>     simply document that subsystem maintainers set their own rules?
> 
> 2. Disclosure format: What should disclosure look like? Options discussed
>     include:
> 
>     - Trailer tag (e.g., `Assisted-by:`, `Generated-by:`)
>     - Below-the-cut note
>     - Verbose commit log explanation
>     - Technology-agnostic "tooling" terminology vs. AI-specific
> 
> 3. Generation vs. review: AI for code review and debugging seems less
>     controversial than AI for code generation. Should we treat these
>     differently in policy?
> 
> 4. What requires disclosure?: Where's the line? Clearly, wholesale
>     AI-generated patches need disclosure. What about:
> 
>     - AI-suggested fixes that a human then implements?
>     - Using AI to understand an API before writing code?
>     - AI assistance with commit message wording?
> 
> 5. Legal stance: Should we take a position on AI-generated code and DCO
>     compliance, or leave that to individual contributors to assess?
> 
> 6. Enforcement reality: We can't even get everyone to run checkpatch.
>     Whatever policy we adopt, how do we think about enforcement?

This is a pretty good summary. It's missing one point in my opinion,
partly related to the legal stance: the ethical stance.

The Linux kernel is governed by the GPL. There are contributors who care
about the copyleft aspect of the license. Even if the legal issues get
cleared in the future, not everybody will agree that usage of GPL code
as input to create proprietary LLMs is ethical: it may not breach the
letter of the license while breaching the spirit. I would like to see
this question being discussed.

> Looking forward to the discussion.

-- 
Regards,

Laurent Pinchart