LLM-Backed Generative AI Recommendations Published By SFC
Software Freedom Conservancy
info at sfconservancy.org
Wed Jun 24 13:31:01 UTC 2026
LLM Backed Generative AI Recommendations Published By SFC
ICYMI:
Last week¹, Software Freedom Conservancy published *Recommendations When
Using LLM-backed Generative AI systems for FOSS Contributions*². SFC's
Copyleft and Software Right to Repair Team co-drafted these policy
recommendations in collaboration with a team of volunteers from the Free
Software community. These recommendations include substantial feedback that
SFC received in its ongoing public sessions and meetings with SFC member
projects.
The recommendations reflect the extremely difficult dilemmas that these
systems pose for FOSS contributors. SFC and its volunteers understand that
FOSS developers are approaching LLM-gen-AI from a variety of
perspectives. The recommendations offer practical assistance to minimize the
damage caused by using proprietary systems, whether FOSS contributors reject
LLM-gen-AI or choose (voluntarily or by employer mandate) to use them.
These recommendations are best practices (but not definitions or
requirements) that SFC and its volunteers formulated after careful study of
the growing LLM-gen-AI use among FOSS contributors. SFC will follow these
recommendations with a series of supporting materials³, including documents,
online tutorials, public Q&As, podcasts⁴, and other community engagement. We
will routinely refine our recommendations and continue to support FOSS
contributors as they navigate this difficult landscape.
On Friday 26 June 2026 at 14:00 UTC, we invite you to a one-hour live video
chat <https://bbb-new.sfconservancy.org/rooms/llm-gen-ai> with some of the
folks who drafted these recommendations. We know that many of you have
concerns and questions, and we welcome your feedback and hope to incorporate
your ideas into updates to the recommendations.
$ date -d "2026-06-26 14:00:00 +0000"
… will provide your local datetime. (It’s 10:00 US/Eastern, 07:00 US/Pacific,
and 16:00 Europe/Central.)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The recommendations are published on sfconservancy.org, and we include the
current version in its entirety below for your convenience:
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”)⁷. 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).
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. Contributors should only submit “unattended”¹¹ 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.
7. 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.)
8. 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.
9. 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.
10. “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¹² project to eventually offer a license
that is widely compatible with other copylefts and extremely suitable as
a copyleft for LLM-gen-AI outputs.
11. When LLM-gen-AI systems (including proprietary ones) can massively
accelerate FOSS improvements, use of such tools is an appropriate
strategic compromise. Most FOSS developers are not experts in the area of
creation and training of LLM-gen-AI systems. Those developers should feel
comfortable making the strategic choice to use LLM-gen-AI systems in
these cases.
We detest using proprietary tools and we are never comfortable
recommending them. Yet for nearly fifty years¹³, FOSS contributors have
used proprietary tools to create and advance software freedom. Writing
proprietary systems is undoubtedly an anti-social act that we all should
avoid. Using proprietary systems, particularly when they can forward
FOSS, is a highly fact-dependent tactical decision.
⚠: do take great care to fully understand the implications of any
proprietary license. SFC will publish in the coming weeks some guidance
on how to approach such analysis.
12. Those with skills and interest in making FOSS-friendlier LLM-gen-AI
systems should do so as a matter of high priority. While no system meets
the (currently) Impossible Dream¹⁴ of our aspirational system, there are
obvious avenues of pursuit that will make progress in that direction. SFC
will highlight on our blog in the coming months individuals working in
these directions.
13. Do not overuse LLM-gen-AI, or allow your skills to atrophy. In our
discussions with the FOSS community about LLM-gen-AI, there seems to be
one universal conclusion: the systems are most effective and help the
most when a very experienced FOSS developer sits at the prompting
helm. LLM-gen-AI systems should complement existing skills and tools, not
replace them. Developers should remain curious about why software acts
the way it does, and this curiosity should extend to the LLM-gen-AI
outputs — and even the system itself.
14. Think carefully about your usage. As software technologists, we have for
decades made complex choices regarding resource consumption
vs. convenience. The advent of CI, as just one example, led to massive
increases in computing time, while at the same time simplified
contribution workflows. As individual FOSS developers, we are unlikely to
change the bad behavior of these proprietary software companies who are
either focusing on the creation of, or mandating the excessive use of,
LLM-gen-AI.
There are hundreds of intersectional issues of societal significance and
social justice that are touched by these technologies, including the
environmental impact of the development and use of these systems. Our
focus and expertise centers on the implications for software; here we
assess user freedom and add our ideas to the overall social conversations
about how this technology should be used, controlled, and distributed in
the context of FOSS. On matters unrelated to software freedom, we defer
to experts that focus on environmental and other intersectional issues.
In our experience, FOSS contributors are historically much more mindful
and concerned about how their actions impact others than developers of
proprietary software and systems. Bring that mindfulness to your use of
LLM-gen-AI. As just two examples:
□ don’t run to an LLM-gen-AI immediately for every problem,
□ pay attention to the LLM-gen-AI when it is clearly doing useless
processing, and quickly redirect it to something more useful.
The Road Ahead
Most new technologies have some adverse outcomes. We must carefully recognize
and mitigate them. Social justice movements (including the software freedom
and software right-to-repair movements) succeed when well-intentioned
individuals act sustainably and consistently to bring needed change. In FOSS,
those individuals constantly invent and improve new technologies that respect
users’ rights and freedoms.
The recommendations above are a start. We’re ready for revision and further
explanation as facts change. Our community has successfully deployed our
unique acumen, and will again to shift this current imbalance of power. We
must creatively act as we always have; the FOSS community excels at
strategems that counteract proprietary software with ingenuity.
SFC walks with you on this multi-generational journey to universal software
freedom and rights. Expect (but embrace) the trepidation as we take this
next step together now. SFC’s goal is steadfast: empower consumers and users
to advance and exercise software freedom, and their right to software
repair. Remember these strategies have worked and will continue to work when
we remain vigilant, mindful, and focused.
Acknowledgments
Software Freedom Conservancy publishes this statement after months of
internal deliberation and discussions with a group of volunteers, including
John Sullivan, Stefano Zacchiroli, and many anonymous contributors. The
statement was drafted by SFC in collaboration with that group.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Footnotes
⁷ These Recommendations are made specifically for systems (most of which are
currently proprietary), such as Claude Code, Copilot CLI, Antigravity, and
OpenCode. These systems utilize an LLM to generate textual artifacts that
assist software project contributors. There is no known shorthand for
referring to these systems, so we refer to them here as “LLM-gen-AI” to
remind the reader throughout that these recommendations are not
necessarily intended to apply to other forms of AI nor other uses of LLMs.
¹¹ By “unattended”, we mean prompt-generated contributions that received no
further human vetting.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Links
¹ https://sfconservancy.org/news/2026/jun/18/llm-backed-generative-ai-recommendations/
² https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
³ https://sfconservancy.org/llm-gen-ai
⁴ https://sfconservancy.org/casts/the-corresponding-source/
⁵ https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
⁸ https://sfconservancy.org/blog/2022/feb/03/github-copilot-copyleft-gpl/
⁹ https://sfconservancy.org/news/2024/oct/25/aspirational-on-llm-generative-ai-programming/
¹⁰ https://sfconservancy.org/blog/2026/jun/02/ethical-use-proprietary-develop-free-software-foss/
¹² https://next.copyleft.org/
¹³ https://sfconservancy.org/blog/2026/jun/02/ethical-use-proprietary-develop-free-software-foss/
¹⁴ https://sfconservancy.org/news/2024/oct/25/aspirational-on-llm-generative-ai-programming/
--
Software Freedom Conservancy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/announce/attachments/20260624/10ecb4bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1560 bytes
Desc: not available
URL: <http://lists.sfconservancy.org/pipermail/announce/attachments/20260624/10ecb4bd/attachment.ics>
More information about the announce
mailing list