<h2 id="llm-backed-generative-ai-recommendations-published-by-sfc">LLM
Backed Generative AI Recommendations Published By SFC</h2>
<p>ICYMI:</p>
<p><a
href="https://sfconservancy.org/news/2026/jun/18/llm-backed-generative-ai-recommendations/">Last
week</a>, Software Freedom Conservancy published <a
href="https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html">Recommendations
When Using LLM-backed Generative AI systems for FOSS Contributions</a>.
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.</p>
<p>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.</p>
<p>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 <a
href="https://sfconservancy.org/llm-gen-ai">series of supporting
materials</a>, including documents, online tutorials, public Q&As,
<a
href="https://sfconservancy.org/casts/the-corresponding-source/">podcasts</a>,
and other community engagement. We will routinely refine our
recommendations and continue to support FOSS contributors as they
navigate this difficult landscape.</p>
<p>On Friday 26 June 2026 at 14:00 UTC, we invite you to a one-hour <a
href="https://bbb-new.sfconservancy.org/rooms/llm-gen-ai">live video
chat</a> 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.</p>
<pre><code>$ date -d "2026-06-26 14:00:00 +0000"</code></pre>
<p>… will provide your local datetime. (It’s 10:00 US/Eastern, 07:00
US/Pacific, and 16:00 Europe/Central.)</p>
<br/>
<br/>
<p>The <a
href="https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html">recommendations
are published on sfconservancy.org</a>, and we include the current
version in its entirety below for your convenience:</p>
<h1
id="recommendations-when-using-llm-backed-generative-ai-systems-for-foss-contributions">Recommendations
When Using LLM-backed Generative AI Systems for FOSS Contributions</h1>
<h3 class="policy-article" id="preamble">Preamble</h3>
<p>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”)<sup>1</sup>. 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.</p>
<p>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 <a
href="https://sfconservancy.org/blog/2022/feb/03/github-copilot-copyleft-gpl/">If
Software is My Copilot, Who Programmed My Software?</a>. 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.</p>
<p>In 2024, <a
href="https://sfconservancy.org/news/2024/oct/25/aspirational-on-llm-generative-ai-programming/">SFC
published an aspirational statement</a>, 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”).</p>
<p>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.</p>
<p>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 (<a
href="https://sfconservancy.org/blog/2026/jun/02/ethical-use-proprietary-develop-free-software-foss/">as
we always have</a>) to utilize such systems when they can advance
software freedom.</p>
<p>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.</p>
<p>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.</p>
<p>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 <em>help</em> us
advance FOSS.</p>
<h2 class="policy-article" id="recommendations">Recommendations</h2>
<p>These recommendations are listed in order of our view of their
relative importance (most important first).</p>
<ol type="1">
<li><p><strong>The FOSS community should support, not just tolerate,
those who outright reject LLM-gen-AI systems.</strong> 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.</p></li>
<li><p><strong>Every FOSS contributor deserves self-determination
regarding LLM-gen-AI.</strong> No one should be <em>required</em> 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.</p></li>
<li><p><strong>FOSS projects should not shun contributors who choose to
use LLM-gen-AI systems.</strong> 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.</p></li>
<li><p><strong>Before submission, FOSS Contributors must invest
substantial time reviewing LLM-gen-AI -assisted and/or -generated
contributions.</strong> 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. <strong>LLM-gen-AI
contributions could erode the best aspects of FOSS if an unsolicited
onslaught of unvetted, prompt-generated contributions become
commonplace.</strong></p></li>
<li><p><strong>Full disclosure of how and when an LLM-gen-AI system was
utilized to assist in creation of a contribution is a moral
imperative.</strong> 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.</p></li>
<li><p><strong>Contributors should only submit “unattended”<sup>2</sup> LLM-gen-AI
contributions in an area explicitly designated for such. If none exists,
such contributions should be assumed unwelcome.</strong> 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.</p></li>
<li><p><strong>LLM-gen-AI users should keep detailed and accurate
records of their interaction and save those meta-artifacts for
posterity.</strong> 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 <em>regardless of license</em> 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.)</p></li>
<li><div id="copyleft-next">
<p><strong>Avoid jumping to conclusions about the legal significance of
generated contributions and whether they are “copyright-washing-machines
that ruin copyleft”.</strong> There remain many unanswered legal
questions, and experts are actively working on solutions. SFC will
publish more on this issue in the coming months.</p>
</div></li>
<li><div id="input-licensing">
<p><strong>Inputs impact the licensing of the artifacts</strong>. The
question of licensing obligations for material passed through the
process called “training” remains undecided. Nevertheless, most
LLM-gen-AI sessions don’t begin <em>only</em> 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 <em>must</em> be
licensed under the project’s license, due to both copyright and
contractual terms of that license.</p>
</div></li>
<li><p><strong>“Copyleft Everything” remains the best viable and safest
approach</strong> 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, <em>nothing</em> 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 <a
href="https://next.copyleft.org">copyleft-next</a> project to eventually
offer a license that is widely compatible with other copylefts and
extremely suitable as a copyleft for LLM-gen-AI outputs.</p></li>
<li><p><strong>When LLM-gen-AI systems (including proprietary ones) can
massively accelerate FOSS improvements, use of such tools is an
appropriate strategic compromise</strong>. 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.</p>
<p>We detest using proprietary tools and we are never comfortable
recommending them. Yet <a
href="https://sfconservancy.org/blog/2026/jun/02/ethical-use-proprietary-develop-free-software-foss/">for
nearly fifty years, FOSS contributors have used proprietary tools</a> to
create and advance software freedom. <em>Writing</em> proprietary
systems is undoubtedly an anti-social act that we all should avoid.
<em>Using</em> proprietary systems, particularly when they can forward
FOSS, is a highly fact-dependent tactical decision.</p>
<p><strong>⚠</strong>: 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.</p></li>
<li><p><strong>Those with skills and interest in making FOSS-friendlier
LLM-gen-AI systems should do so as a matter of high priority</strong>.
While no system meets the (currently) <a
href="https://sfconservancy.org/news/2024/oct/25/aspirational-on-llm-generative-ai-programming/">Impossible
Dream of our aspirational system</a>, 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.</p></li>
<li><p><strong>Do not overuse LLM-gen-AI, or allow your skills to
atrophy</strong>. 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
<em>complement</em> existing skills and tools, not <em>replace</em>
them. Developers should remain <em>curious</em> about why software acts
the way it does, and this curiosity should extend to the LLM-gen-AI
outputs — and even the system itself.</p></li>
<li><p><strong>Think carefully about your usage</strong>. 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.</p>
<p>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.</p>
<p>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:</p>
<ul>
<li><p>don’t run to an LLM-gen-AI immediately for every
problem,</p></li>
<li><p>pay attention to the LLM-gen-AI when it is clearly doing useless
processing, and quickly redirect it to something more useful.</p></li>
</ul></li>
</ol>
<h3 class="policy-article" id="the-road-ahead">The Road Ahead</h3>
<p>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.</p>
<p>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.</p>
<p>SFC walks with you on this multi-generational journey to universal
software freedom and rights.<br />
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 <strong>will continue to work</strong>
when we remain vigilant, mindful, and focused.</p>
<h4 class="policy-article" id="acknowledgments">Acknowledgments</h4>
<p>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.</p>
<hr />
<h4 class="policy-article" id="footnotes">Footnotes</h4>
<p><sup>1</sup></a> 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.
<p><sup>2</sup>
By “unattended”, we mean prompt-generated contributions that received
no further human vetting.</p>
-- <br/>
<p><a href="https://sfconservancy.org/sustainer">Software Freedom Conservancy</a><br/>