Balisage Paper: What does AI mean for Open Source?

Social Concerns

For those human founders and/or contributors whom are not financially compensated for the time and resources they invest in Open Source projects, their contributions can largely be considered a social activity. Indeed, contributing to software that is published as Open Source, through the very nature of the OSD means that you are making something available to society as a whole.

Allowing AI generated code into an Open Source project, regardless of a net-positive or negative outcome, will have both, an immediate impact on the existing human contributors to the project, and also the ability of the project to attract contributors in future.

One overarching concern in this area, is that of trust. In the past, potential new and unknown contributors to an Open Source project were rarely immediately trusted, instead they gained trust and entry into the project by demonstrating their utility and building up a reputation over time. Contributors utilising AI/LLMs change that dynamic; it is now difficult to ascertain their level of experience vs. that of the AI/LLMs. Previous mechanisms for establishing trust between humans are becoming strained, and it is yet not clear what, if any, new mechanisms will replace them [Blates26].

On the one hand, human contributors may be keen to embrace AI, with the potential to help non/less-technical contributors implement code that that would otherwise be beyond their reach [Karim26], or perhaps allow experienced developers to pair with AI to increase their velocity [Zheyuan25, Edwards26].

On the other hand, experienced engineers may be disappointed with the code produced by AI [LinearB26], or lament having to review large change sets that have been partially or entirely generated by AI (that was not well instructed) and exhibit many issues [Song23].

Whether for or against AI, software developers experiencing fear and/or depression triggered by AI is well documented [Lițan25, Spirlet26]; they may experience the feeling of loss that they will no longer be able to enjoy socially crafting code [Orosz26, Lawson26], or the fear that they will be left behind by competitors that have embraced AI where they have not [Kwon26].

Additionally, as human beings we subscribe to and/or create philosophies, ideologies, and belief systems. As such, individuals may, understandably and freely, exhibit and justify ethical and/or non-technical reasoning around the extent to which they embrace or reject AI. Around these new ideologies a number of colloquial terms are forming to describe them, such as AI Vegan [Mahdawi25], and the less strict AI Vegetarian [Proven26/1].

If human contributors within an Open Source project are unhappy with its policy towards AI use, the project may experience a collapse of its social fabric, resulting in a loss of contributions and/or risk being forked. To avoid social conflict and worse, alienation, it would follow that some form of consensus will be required between the founders and/or contributors to the project on, if and how AI may be used in that project. We argue that that consensus, forms the basis of an acceptable use of AI policy for the project, and whilst it may of course evolve over time, it should be clearly communicated to any potential contributors.

Economic Concerns

It remains unclear whether Open Source in and of itself has had a nett-positive or negative affect on reducing the social-economic divide with regards to developing software.

On the one hand, the cost of access to software tools has been reduced through eliminating licensing fees, and self taught developers can study existing code [Pscheidt09, LOS24].

On the other hand, producing and contributing to Open Source software requires hardware, a reliable internet connection, education (specialised technical knowledge), and potentially the wealth to allow individuals to contribute without financial compensation; this can make the cost of entry for those from lower socioeconomic backgrounds impossible [Blind24].

We argue that the use of AI in Open Source projects may further increase the social-economic and digital divide between those that can afford to contribute and those that cannot.

For SaaS (Software as a Service) based AI services, which appear to be the most commonly used, these are typically presented to the end user as either free, or with a subscription and/or token pricing model. The current startup companies behind these services have huge infrastructure and staff costs that are fuelled by large VC (Venture Capital) investments that have yet to be realised. Whilst these companies are striving for market dominance and determining the product-market fit for their offerings, they are operating their services at a loss and spending vast sums of VC money [Sachs24]. During this time, the cost to some of using such services may seem reasonable, whilst to others it may already be prohibitive. We cannot yet determine what the true future price to the user of such services will be when these companies have to start making a profit to repay their investors [Aggarwal26]. The financial markets expectation is that the end-user that wishes to continue using such services will have to pay more than they currently do so.

Sadly, we have not been able to find much evidence of discounted SaaS AI services to help those in developing countries or those from disadvantaged socially-economic backgrounds. What little evidence we have points to no, or meagre, discounts that are out of touch with the economies of developing nations.

The true financial cost of using SaaS AI services cannot yet be determined.

For those who wish to avoid subscription services by operating their own AI/LLM models, there are also considerable costs, some of which are non-obvious [Ivchenko26].

It would seem to follow that those Open Source projects that are well funded and/or operated by large private/government organisations may be able to afford to pay for AI use in their projects, whereas smaller or unfunded projects likely will not.

We are not yet aware of any Open Source projects that strictly mandate the use of AI by contributors, but there are certainly already many projects that encourage its use. Unfortunately while the use of AI/LLM comes with a financial cost, which itself seems likely to increase, it seems inevitable that this will further increase both the economic-social and technical divides in contributing to Open Source projects.

We believe that those championing the use of AI in Open Source projects should consider if they are excluding potential contributors due to social-economic status, and how they might remove that barrier.

Environmental Concerns

A great amount of Open Source software is started under the banner of OSS4SG (Open Source Software for Social Good) [Fang26]; however, serious secondary environmental impacts have been raised in relation to the operation of AI/LLMs which would seem to be at conflict with such a purpose.

The operation of AI/LLMs at scale require large compute resources that pose a number of environmental concerns, the main of which can roughly be divided into three categories:

Early research into the environmental impacts of LLM’s focused on the environmental costs of training the LLM’s. One such study, found that in 2019 training an LLM required nearly the same carbon footprint as an average human being creates during 60 years of their life [Strubell19]. Since that time whilst LLM’s have become much more complex and training them requires ever more data, it is the scale at which they have been deployed, and subsequently made available as a service that has changed this landscape.

Whereas previously training the LLM created a larger carbon footprint than its operation, that position has now been reversed. The latest research focuses on the total environmental cost, or which day-to-day use of the models forms a huge part. The UNU-INWEH (United Nations University Institute for Water, Environment, and Health) recently published a report suggesting that by 2030, global AI data centres will consume 945 terawatt-hours of electricity annually. This will require a massive water footprint for cooling and power generation equivalent to the basic annual needs of 1.3 billion people, alongside a land footprint exceeding 14,500 KM2 [Aczel26].

Such environmental concerns affect us all, and it would seem likely that the impact of AI on our physical environment may be of particular interest to those operating under the banner of OSS4G, and in all likelihood, many more.

We believe that such concerns may dissuade people from using AI, and by extension individuals and organisations may be put-off contributing to, or using, Open Source projects that make use of AI.

At present it can be hard to determine if an Open Source project uses AI or not, we believe that such use should be clearly communicated and form part of the projects AI policy, thus allowing users and contributors to make informed decisions.

Political Concerns

The rise and rapid adoption of AI/LLMs has not gone unnoticed by national and international governments and organisations. These institutions which have political influence or govern, have the ability to control if and whom can use AI, when they can use it, and under what constraints if any. AI/LLMs, like any sufficiently advanced technology, are a powerful tool that can be wielded to change the dynamic of power at a local or international level for the gain of those that can assert control over it.

We must not forget that AI/LLMs whilst appearing to be available internationally, are operated by corporations, and that these corporations are incorporated in, and operating within, the bounds of a particular nation or state. By extension, these corporations are subjects of that nation and its politics, they are required to comply with the laws of their nation, changes to governance of their nation, and their nation’s foreign policy.

Subsequent assertion of control over such advanced technologies after the fact of their creation and adoption has plenty of past precedent.

As an example, the USA has in the past tightly controlled the export of cryptographic algorithms and equipment. During the Cold War, previous legislation was updated in 1976 and as a result the ITAR (International Traffic in Arms Regulations) [WIKI02] officially classified cryptographic algorithms and equipment as munitions. Thus greatly restricting cryptographic inventions born in the USA from being used outside of the USA. In 1996, this was reformed and legislation moved from the ITAR to the EAR (Export Administration Regulations) [EAR96]. Most of these restrictions on cryptography were eventually rescinded in 2000, some 24 years later.

More recently, in October 2022, under the same EAR that imposed cryptographic controls, and the ECRA (Export Control Reform Act) legislation, the USA restricted the export of hardware related to accelerating AI/LLM processing [BIS22]. Further export restrictions were added in October 2023.

Recently it has been reported that the US Government is considering passing legislation to prohibit the use of AI/LLM models produced in China [Curi26]. The FY2026 NDAA (Fiscal Year 2026 National Defense Authorization Act) already prohibits some non-USA developed models from being used in services or products procured by the US Department of Defense [NDAA26].

For an Open Source project that is adopting, promoting, or delivering the use of AI/LLMs, consideration must be given to whether users and/or contributors are subject to such export restrictions. For example, are the models you use also usable by your users and/or contributors. For those dependent on the use of AI/LLMs consideration should be given to whether such services will remain available to them. The European Union AI Act [EU23], China’s Interim Measures for the Management of Generative AI Services [WIKI03], and the proposed AI Kill Switch Act in the USA [Lieu26], offer their respective governments the authority to restrict or shutdown AI/LLM providers. Whilst politicians are often keen to assure us that such measures are an action of last resort, we have seen many governments in recent years restrict or disable access to the Internet and/or mobile telephony services when it suits them, and even for reasons that may at times be perceived as against the interests of their own constituents [Howard11, Stremlau24].

Considering political travel in the opposite direction, the companies operating the largest AI/LLM models are often valued at billions of dollars and have a huge impact on their user base. These companies are often themselves founded or backed by individuals with their own fortunes valued in the billions. These organisations and individuals are able to assert far greater political influence on their nation’s government than the average citizen [Chesterman26]. This influence may be gained through political lobbying [Tolomia26], forming alliances to further shared interests, or often, direct financial contributions to a political party or campaign [Williams26, Wilkins26, Dorn26].

From the individual hobbyist Open Source project, to the largest collaborative project, it is likely impossible that everyone within holds the same set of ethics or political views. Organisations and individuals behind large AI/LLM services are able to influence governments in a left or right direction on a particular matter. For many individuals that concern themselves with local or international politics, it would seem that either as users of, or contributors to, an Open Source project, they may wish to know its AI policy. Such information, allows them to check that the political views of their AI providers (and its backers), align sufficiently with their own.

Legal Concerns

The plethora of legal concerns regarding the use of content produced by AI/LLMs ultimately boil down to two key areas:

Licensing is built upon copyright. As a human creator of a piece of work, that work is your Intellectual Property, and you are automatically assigned the copyright of that work. An exception is that, if you are being compensated by a 3rd-party to create that work (e.g., your employer), depending on the contract between yourself and that 3rd-party, the copyright may instead be vested with that 3rd-party.

Only the copyright owner(s) of a work may license that work for others to use. A license is simply a set of terms granted by the copyright owner to one or more parties about how they may use the copyrighted work. The copyright owner may license their work as many times as they wish, under whatever terms they wish. There is no restriction on them with regards to the terms of the licenses they may offer unless some other contractual agreement to their benefit prevents that. The exception being the legal doctrine of Fair Use, which allows constrained use of a copyrighted work without permission/licensing from the copyright owner for the purposes of criticism, commentary, and teaching.

AI/LLMs are created by training them on vast amounts of information. This information is often scraped from the Internet and includes web pages, artworks, music, video, blog/forum posts, digitised books, journal articles, government documents, news articles, and source code repositories amongst others. Each and every such piece of this information that was used for training an AI/LLM has a pre-existing copyright, and a copyright owner [Milmo25].

Use of this material to train an AI/LLM is subject to the same copyright law, and potentially any licenses offered by the copyright holder, as any other copyrighted work. Until very recently it was argued by many AI/LLM providers that their models were entitled to use such copyrighted works under the legal doctrine of Fair Use, whilst copyright owners argued that such training infringed their rights. Neither argument, had been legally proven until in July 2026 in a US class action lawsuit, Bartz, et al. v. Anthropic PBC [TCA26], a federal court reached a judgement that:

Following this judgement, for a provider to legally use copyrighted works for training an AI/LLM it must at least ensure that firstly, the works have been legally obtained, and secondly: (a) that the works have been licensed from the copyright owner for this purpose, or (b) that the desired use of these works fall under the legal doctrine of Fair Use. Whilst the initial driver for that legal case was focused on books, the outcome (the legal judgement), was relevant to all copyrighted works in general.

This now makes the law around the use of copyrighted works to train an AI/LLM tangible, and relatively clear.

Unfortunately, with regards to training an AI/LLM the concerns around licensing of copyrighted works which builds atop copyright, remain unresolved at this time.

Many AI/LLMs that are aimed at assisting developers have been trained on vast amounts of Open Source code that was acquired from public repositories such as GitHub [Chen21]. The code from these Open Source projects are copyrighted works, but further, many of them declare an Open Source license of some variety. These Open Source licenses impose restrictions on how these works may be used. Whilst there are many different Open Source licenses, a common theme is that the original authors name, copyright notice, and license declaration must be preserved. Furthermore, for some Copy-Left classes of Open Source license, e.g., GNU (GNU’s Not Unix) GPL (General Public License) variants, it can mean that the same license terms have to be adopted Ad infinitum.

The open legal questions around the use of Open Source code to train an AI/LLM revolve around, whether after training, any substantive code produced by an AI/LLM is in violation of the DMCA (Digital Millennium Copyright Act). The code produced by an AI/LLM is not accompanied by the original CMI (Copyright Management Information), e.g., the original authors name, copyright notice, and license declaration. It could be a violation of the DMCA to remove such CMI when reusing Open Source code. The AI/LLM providers argue that the output of their services rarely, if ever, reproduce code that they were trained upon, whereas the representatives for Open Source authors, claim otherwise. This legal uncertainty has been working its way through the US courts since 2022 in the form of the Doe vs. GitHub class action lawsuit [BH2026, Eslinger26].

An appellate ruling from the ninth court on the case is expected within the next six months. However, that is likely not the conclusion, and the case could yet take longer to resolve. The outcome of this case is significant for users of AI/LLMs, as it could prove or reject, that code produced with the use of AI/LLMs is subject to one or more original copyrights and set of license terms.

Should it be determined that the code produced by an AI/LLM is legally void of any original copyrights or licenses used in its training data, then an important question comes into play – Who owns the copyright on code produced by an AI/LLM?

This question arises because under current copyright law, a copyright owner can only be a person, or by extension an organisation, it cannot be by an animal [Guadamuz18], or an AI/LLM [Lanquist26]. Whether copyright on code produced by an AI/LLM at the instruction of a human, is vested with that human revolves around the concept of “meaningful human authorship”, which remains unquantifiable by the US Copyright Office, and is still currently being tested within the US legal system [Evren2026].

For Open Source projects that wish to make use of AI/LLMs, the legal uncertainties around the works (e.g., code) produced by AI/LLMs presents a number of significant issues.

At this time, it is unclear whether such generated works, (a) carry existing copyright and licenses, use of which may be a legal violation in itself, and/or in conflict with the project’s own choice of Open Source license, or if not, (b) whether these works are copyrightable by the human producer, and if not, by extension, they cannot be licensed by the project to others under the project’s choice of Open Source license.

We argue that it would be eminently sensible for Open Source projects to establish an AI policy, whereby contributions involving entirely or partially AI/LLM generated works are clearly labelled as such. By this means, should the courts (a) decide against AI/LLMs reproducing partial or complete copyright and/or licensed works from their training models without CMI, or (b) continue to assert that human assisted AI generated work cannot be copyrighted, then in future, projects can easily identify the contributions in their projects that may need to be undone, or modified, for the project to become compliant with current/new legislation. Should the courts instead decide in favour of AI/LLMs, little has been lost by enacting such a policy as a safe guard.

Technical Concerns

AI/LLMs have demonstrated incredible feats of code generation when successfully directed, and this can be very appealing to Open Source projects which may have a grand vision, but lack the human resources to implement it. Early stage code generation and routine tasks can often be performed faster by AI/LLMs than by humans; one such study found that AI/LLMs were 31.4% faster than humans [Sankhe25]. Other industry articles on the subject have described developers using AI/LLMs as a force multiplier, allowing them to be 10x more productive [Klenk25, Utley26].

The main technical concerns for Open Source projects employing AI/LLM generated code fall into the following two main categories:

Neither of these categories are exclusive to code generated by AI/LLMs, indeed they were equally applicable in the past when only humans were present. The difference now, is the volume and speed at which code is produced.

For example, if a project previously had 10 contributors, each producing 1 contribution per week. If 6 of these contributors decide to adopt an AI assisted workflow, then the number of contributions the project receives per week could increase from 10, to up to between 13 and 100. The use of AI/LLMs becomes a force multiplier across the number of autonomous contributors operating in parallel.

Regarding code quality, code that is produced by AI/LLMs is often verbose, less than optimal, and includes many repeated patterns rather than abstracting commonality into constants, functions, or modules [Harding25, Marinho26]. Worse yet, it is not unusual for AI/LLMs to ‘hallucinate’ and produce nonsensical results [Suprmind26], this can lead to code that doesn’t produce the expected result or perhaps isn’t even syntactically valid.

AI/LLMs as coding assistants are often described as having capabilities commensurate with a human software developer at the ‘Junior Developer’ career level. AI/LLMs just like their human junior level developer counterparts, naturally require very careful direction, mentoring, monitoring, review, and feedback, of their work by a more experienced developer [Iyer26].

Long term project maintainability can be a time consuming task for an Open Source project. Attention to this is essential to ensure the long term health of the project. This can be helped by limiting technical debt before it occurs, and/or by addressing and refactoring it out of the project at regular intervals. Arguably, the most important mechanism to prevent the build-up of technical debt, is for a project to review, and potentially request changes to, each submission before it is accepted into the project [Alami19, Pathirage26].

In many places, AI/LLMs have allowed users without an education in Computer Science and little or no formal Software Engineering experience to create and contribute to software projects [Gama25]. This is an incredible feat of achievement for the producers of AI/LLMs, and should be celebrated. When this works well, it can be very advantageous for Open Source projects to receive contributions from such users. Unfortunately, there are too often downsides to this situation for Open Source projects. Additionally some classes of project require a great deal of rigour to ensure correctness and may not be suited to AI/LLM contributions, for example:

Users newly enabled by AI/LLM coding assistants, who are inexperienced developers, may willingly or ignorantly, submit contributions to projects without understanding exactly how their code works or what it does. This creates a burden on the human reviewers for a project to understand each contribution, review it, and guide the submitter. As the submitter will likely not understand the feedback from the reviewer, this can often result in a cyclic discussion between the AI/LLM and the reviewer, with the submitter simply acting as a copy/paste buffer between the two parties. This can introduce frustrations on both sides, whereby the reviewer feels that they are having a disconnected conversation with the AI/LLM, and the submitter who cares about their improvements struggles to make progress. Terms such as “AI Proxy”, “AI Slopper” [Mourzenko26], and the rather more unpleasant “Meat Proxy” [Gruhn26], have been used, presumably as a result of frustration, to describe this variety of interaction with code submitters. The authors of this paper do not condone these terms; however, it is important to realise that such frustrations are real and have an impact on the human reviewers of open source projects.

Whilst the barrier to contribution may be lowered, there may also be a lowering in quality of submissions [CodeRabbit26]. Driven by the use AI/LLMs in one manner or the other, the volume of submissions to projects is increasing [Iyer26]. Sometimes these contributions even come from entirely automated AI systems that are tasked with scanning thousands of Open Source projects, and then identifying and submitting fixes for various classes of bugs (e.g., security) [Dunn26]. Regardless, more submissions, means that more time is required by humans to review submissions and either reject, request changes, or accept them. There are finite human reviewers in any project, which can lead to the project and the reviewers becoming overwhelmed, and thus spending less time on other key aspects of the project [LiveWyer26].

Some of the technical issues encountered in code generated by AI/LLM contributions could potentially be lessened by better instructing contributors, including the AI/LLMs themselves. Detailed documentation as to, the foundational technical architecture and direction of the project, which technology choices have been made and why, if those choices are open to re-evaluation, and a description of anything that is technically unacceptable. Whilst AI/LLMs are quite capable of digesting documentation written for humans, it can often be beneficial to provide documentation better tailored to an AI/LLM (e.g., an AGENTS.md file) [Huet25]. In the authors’ experience, the larger technical landscape of an Open Source project is rarely documented clearly.

Regarding the increased workload for human reviewers that can be caused by AI/LLMs, again it may be helpful to provide clear documentation on the review criteria for submissions. This is again equally relevant for both human and AI/LLM contributors. Additionally, if there are computable quality factors, e.g.: test suites, code quality/analysis tools that should be run, etc., these and their acceptance criteria should be documented. Such documentation should again likely be tailored once for the human, and then again, if applicable, for any AI/LLM audiences.

We argue that it is valuable for the AI policy of an Open Source project to include documentation about: (a) the technical architecture of the project, (b) its code quality standards, and (b) its code review policy and acceptance criteria for submissions.

Components of an AI Policy

Our research, specifically in section “Concerns for AI in Open Source”, has highlighted a number of nuanced areas where humans may have motivations for or against the use of AI in Open Source projects.

As humans, clear communication is paramount, our knowledge and reasoning is built upon context, and as such we often seek justification to reach an understanding. It would therefore seem important not to just have a position on the use of AI/LLMs, but as a project hoping to attract others, it would seem reasonable, that as part of its outreach, the project can justify its position.

Therefore, we argue that an Open Source project whose AI policy might simply state that: ‘the use of AI/LLMs is allowed’, is lacking. Such a policy should be augmented with additional components, that likely include:

Conversely, we also argue that, an Open Source project whose AI policy simply states: ‘any use of AI/LLMs is forbidden’, may be perceived as having not considered the advantages of such technology, and would likely benefit from a clear and succinct statement as to their concerns.

1 Star Rating

The Open Source project has an AI policy.

This policy considers human factors and was developed though consensus of the project stakeholders.

Guidance: Think about what constitutes acceptable use of AI in your project. Consider, amongst others, any of the applicable concerns raised in section “Concerns for AI in Open Source”. Consider the components that might be included in your policy, as discussed in section “Components of an AI Policy”

2 Star Rating

Fully or partially machine generated contributions to the Open Source project are clearly labelled, and remain identifiable as such in future.

Guidance: To safeguard against potential copyright/licensing issues, or human vs. machine assumptions, consider adopting a DCO (Developer Certificate of Origin) and documenting the AI/LLM tools and models used within each contribution (e.g., code commit). If you reject AI/LLM contributions to your project, then simply ensure that all human contributions are attributable; this may likely already be the case.

3 Star Rating

The Open Source project’s AI policy is documented for humans.

It should be published publicly in an open fashion on the Web, and be easily locatable by humans.

Guidance: Write this in natural language aimed at a semi-technical human audience. Include a copy in your project’s source code repository (e.g., an AI_POLICY.md file), and consider publishing it on your project’s website (e.g., https://example.org/ai-policy, or https://example.org/ai-policy.html).

4 Star Rating

The Open Source project’s AI policy is documented for machines.

It should be published publicly in an open fashion on the Web, and be easily locatable by machines.

Guidance: Write this in a form that is best interpreted by AI/LLMs. Include a copy in your project’s source code repository (e.g., an AGENTS.md file [Huet25]), and consider publishing it on your project’s website (e.g., https://example.org/ai.txt [Cardillo26], https://example.org/llms.txt [Howard26], or https://example.org/.well-known/ai-policy.json [Nottingham19]).

5 Star Rating

The Open Source project has technical contributor documentation.

It should be linked from the AI policy document(s), and be written to target humans and/or machines as applicable.

Guidance: Write this twice (if applicable), once aimed at a semi-technical human audience, and secondly in a form that is best interpreted by AI/LLMs. It should compliment your AI policy but standalone from it. It should include technical aspects of contributing to the project, e.g., code and quality standards, applicable tools, code/contribution review policy, and any contribution acceptance criteria.