In the context of discussing the use of the “Sashiko” patch reviewing program which queries LLMs to provide a comprehensive review of a patchset. Torvalds is responding to a email thread on discourse surrounding interacting with Sashiko’s reviews.
Yes.
And no, that’s not the position of the Linux kernel.
I realize that some people really dislike AI, but this is an area where I’m willing to absolutely put my foot down as the top-level maintainer.
Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.
Or just walk away.
AI is a tool, just like other tools we use. And it’s clearly a useful one.
It may not have been that “clearly” even just a year ago, but it’s no longer in question today.
There are other questions around AI (like what the economy of it will actually look like in the end), but “is it useful” is no longer one of those questions. Anybody who doubts that clearly hasn’t actually used it.
Yes, it can also be a somewhat painful tool, both for maintainer workloads and just from a “it keeps finding embarrassing bugs” standpoint.
But the solution is not to put your head in the sand and sing “La La La, I can’t hear you” at the top of your voice like some people seem to do.
The solution is to make sure those LLM tools help maintainers instead of just causing them pain. There’s no question on that side.
We’re not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it.
And no, AI isn’t perfect. But Christ, anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time.
Because it’s not like natural intelligence is always all that great either.
The kernel project has been and will continue to be about the technology.
Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project.
This is NOT some kind of “social warrior” project, never has been, and never will be.
In the kernel community we do open source because it results in better technology, not because of religious reasons.
And so we make decisions primarily based on technical merit. Not fear of new tools.
Linus
Torvalds being a hair away from straight up calling LLM criticism “woke” now.
https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Recommendations
When Using LLM-backed Generative AI
Systems for FOSS Contributions
Preamble
The entire community of computer users, which quickly approaches every human, faces the growing conundrum of generative artificial intelligence systems backed by Large Language Models (“LLM-gen-AI”)1. Software freedom activists face particularly difficult challenges in this regard; these LLM-gen-AI systems have been applied in earnest to the endeavors of software creation and modification.
We cannot sufficiently mitigate this tricky problem with merely one statement or a few blog posts. In 2022, Software Freedom Conservancy began our journey on this particular issue when our policy fellow, Bradley M. Kühn, published If Software is My Copilot, Who Programmed My Software?. In the last year, that journey grew in complexity and urgency when some of SFC’s member projects and supporters began to regularly request moral and ethical guidance on these matters. SFC spent these months in almost-daily internal discussions about the plethora of dilemmas presented by LLM-gen-AI systems.
In 2024, SFC published an aspirational statement, a thought experiment rather than a definition. We now make urgent recommendations to those ordered by their employers to use LLM-gen-AI code assistants to contribute to Free and Open Source Software (“FOSS”).
Some FOSS project leaders have taken a zero-tolerance approach to any LLM-gen-AI contributions to their projects. We support leaders who make such decisions. FOSS project leaders deserve our sympathy and understanding regarding the voluminous onslaught of new contributions. Patch evaluation has always required careful analysis (after all, humans write bad code too). Now, that analysis demand (reasonably) feels daunting to maintainers. Everyone should respect their decisions.
Nevertheless, we cannot and must not ignore the many FOSS contributors who decide to explore these tools for the betterment of FOSS. Software freedom activism only succeeds when we admit that we are at least decades away from universal software freedom. Proprietary systems will continue to exist; there is a real danger they will continue to leapfrog FOSS. We should resist the use of proprietary systems, which include the most popular LLM-gen-AI systems, but we should also remain willing (as we always have) to utilize such systems when they can advance software freedom.
After much study, consideration, collaboration, and consultation with many FOSS leaders, SFC formulated the following recommendations for FOSS contributors who have decided to use LLM-gen-AI systems to augment their FOSS work. We expect to update these recommendations periodically. These are not mandates, demands, conclusions, nor definitions; rather, they are best practices that we have formulated after careful study of the undeniable reality that some FOSS contributors do want to use these LLM-gen-AI systems.
In the months following the announcement of these recommendations, SFC plans an ongoing engagement campaign, including documents, online tutorials, public Q&As, and other community engagement, on these matters. SFC does not make these recommendations in isolation; rather, we offer sustained assistance to the community, particularly to FOSS projects working with proprietary LLM-gen-AI systems.
The long term goal of software freedom is to eliminate the harm of proprietary technology. While we work toward that greater goal, we should seek to mitigate the harms that we cannot immediately eliminate. These recommendations aim to abate the damage of these systems, and also consider how these tools might counter-intuitively help us advance FOSS.
Recommendations
These recommendations are listed in order of our view of their relative importance (most important first).
The FOSS community should support, not just tolerate, those who outright reject LLM-gen-AI systems. There are many intersecting ethical and moral issues regarding these systems, many of which are not currently fully understood. Anyone who chooses to avoid them deserves our support and assistance.
Every FOSS contributor deserves self-determination regarding LLM-gen-AI. No one should be required to use these systems under duress. We make special note here of the increasing reports from technology workers who have been ordered by their management (often under penalty of termination) to use these systems for all their work: FOSS and proprietary. Such mandates are unconscionable and we call on the industry to make use of LLM-gen-AI fully optional, and adopt non-discrimination policies regarding those who opt out.
FOSS projects should not shun contributors who choose to use LLM-gen-AI systems. Even FOSS projects that have chosen a zero-tolerance policy should make an effort to welcome contributors who submit a contribution that includes content or who received assistance from an LLM-gen-AI system. Such contributions should be treated no differently than a technically inadequate “first patch”: such submitters should be welcomed to the community and receive a gentle (albeit perhaps form language) response thanking them for their interest and explaining gently why the project will not accept their contribution.
Before submission, FOSS Contributors must invest substantial time reviewing LLM-gen-AI -assisted and/or -generated contributions. Such contributions need curation. Contributors should acquire an in-depth understanding of their contribution. FOSS processes yield software systems that are resilient, highly maintainable, and contributor-friendly. Human contributors engage with FOSS projects (even as volunteers) because of the enjoyment and satisfaction available in FOSS projects. LLM-gen-AI contributions could erode the best aspects of FOSS if an unsolicited onslaught of unvetted, prompt-generated contributions become commonplace.
Full disclosure of how and when an LLM-gen-AI system was utilized to assist in creation of a contribution is a moral imperative. FOSS project leaders cannot make good decisions about LLM-gen-AI policy if they cannot survey which contributions were assisted, and how much they are assisted. Part of the contribution process should (at least) include a disclosure of what LLM-gen-AI system was used, its version (as these system change over time), and a brief description of how the system assisted the contributor. This information should be included in a machine-readable format in commit logs.
Contributors should only submit “unattended”2 LLM-gen-AI contributions in an area explicitly designated for such. If none exists, such contributions should be assumed unwelcome. FOSS maintainers are often volunteers, or permitted to work only a limited amount of time on their upstream projects. Maintainers’ time is precious, and is best used in human-to-human interactions with new and existing human contributors. New contributors should respect existing decisions about “unattended” LLM-gen-AI. Maintainers should think carefully about the types of unattended LLM-gen-AI contributions that may be useful. We encourage project leaders to flexibly and regularly (but also slowly and deliberately) consider policy changes on unattended contributions when new contributors present new ideas.
LLM-gen-AI users should keep detailed and accurate records of their interaction and save those meta-artifacts for posterity. LLM-gen-AI systems excel at automation of users’ logs of prompts, notes, and other written details of the interaction that led to the creation of an artifact. FOSS contributors should keep such meta-artifacts, and regardless of license they should be archived as if they are part of the Corresponding Source for the contribution. (In the coming weeks, SFC will publish tutorials and templates to assist in automating this important process.)
Avoid jumping to conclusions about the legal significance of generated contributions and whether they are “copyright-washing-machines that ruin copyleft”. There remain many unanswered legal questions, and experts are actively working on solutions. SFC will publish more on this issue in the coming months.
Inputs impact the licensing of the artifacts. The question of licensing obligations for material passed through the process called “training” remains undecided. Nevertheless, most LLM-gen-AI sessions don’t begin only with a prompt. By contrast, most commonly, the user points the LLM-gen-AI at a codebase and receives its assistance to generate a patch for that codebase. If that codebase is under a copyleft license, your changes must be licensed under the project’s license, due to both copyright and contractual terms of that license.
“Copyleft Everything” remains the best viable and safest approach Certainly those who want to release FOSS under non-copyleft licenses have more to worry about when using these tools. It’s apparent that every widely used LLM-gen-AI was trained on much well-known copylefted code. Courts need years to deliver guidance on many relevant legal questions. In the meantime, nothing stops you from using a copyleft license for the work you generate, particularly a license that is widely compatible with other copyleft licenses. SFC will make its staff time available to the [copyleft-next](https://next.copyl/