Ludovic CourtèsMar 13

It’s already tempting notably for smallish projects to resort to genAI:
https://toot.aquilenet.fr/@civodul/116132543248503962

But I think a race to the bottom has started in #FreeSoftware, with this rationale: if “we” don’t use genAI in our project, then we will lose to the competition, whether free slopware or proprietary.

Ludovic Courtès (@[email protected])

I think these two factors—lack of humanpower and a “big” vision—coupled with the passion for technicalities typical of such projects make them particularly vulnerable to genAI. Because yes, “we” want SMP support in Mach and it’s not been happening until this contributor achieved something with the help of genAI.

Aquilepouet
Show threadLudovic CourtèsMar 13

… which is short-sighted and loses track of the whole user empowerment goal that free software is supposedly about.

But the “economic” incentives are here.

Show threadCarlos O'DonellMar 13
@civodul I'm working on a glibc (and jointly a gcc) LLM policy which I'll propose for public review, and the difficulty is in threading the needle between technology that we could use ourselves, and user freedoms. My position ends up being that I want to define a policy that allow the projects the to outright reject *or* accept such changes as they see fit, within certain constraints that support user freedom e.g. either you understand the code or it is reproducible with a tool.
Show threadSiddhesh PoyarekarMar 13
@codonell @civodul that speaks to the validity of the code, and maybe empowers/includes more people (maybe the opposite too, if LLM use discourages those ideologically opposed?) in the development community for the project. What does it do for the bigger software freedom picture though? What does it do for copyleft code bases? Is the move towards all FOSS code becoming public domain (given that US courts are leaning towards LLM generated code not being copyrightable) a net positive one?
Show threadCarlos O'DonellMar 13
@siddhesh_p @civodul You can only control your own actions, and I would continue to contribute creatively to copyleft projects, and I would encourage others to do the same. Even if someone else, who I don't control, uses an LLM to create a clone, they could always have done that with a fork. They will still not have my time or my attention.
Show threadSiddhesh PoyarekarMar 13
@codonell @civodul yes but someone having an LLM fork the project is not a concern when it comes to drafting LLM policies for projects. That's a separate dumpster fire.
Show threadCarlos O'DonellMar 13
@siddhesh_p @civodul The existence of public domain contributions in our projects does not directly weaken our copyleft positions. For example glibc considers all locale data to be public domain, and the FSF claims no copyright on that data. Yet we're still an LGPL2+ project. We generate boiler plate all the time that is not novel or expressive, and it doesn't undermine our ideals. There are extremes here that carry risk, and I think a good policy should express those risks.
Show threadSiddhesh PoyarekarMar 13
@codonell @civodul that's only because today, public domain contributions are quarantined to specific, strategic areas (like locales). LLM contributions will change that.
Show threadCarlos O'DonellMar 13
@siddhesh_p @civodul Any contributor to the GNU Project can go through a disclaimer process putting their works in the public domain and contribute them to glibc. It is one of the currently valid processes. It's not the ideal case, and does not support my copyleft ideals, but I respect the wishes of the contributor, and they are furthering the project goals. We should not operate under the slipper slop fallacy that we are heading towards 100% public domain.
Show threadSiddhesh PoyarekarMar 13
@codonell @civodul what I'm arguing is that it's not just a theoretical slippery slope, it's real this time. There's also the question of what the project goals are after all, are they simply to achieve technical goals and solve difficult computer science problems?
Show threadCarlos O'DonellMar 13
@siddhesh_p @civodul I'd say the GNU Project. the GNU Toolchain, and glibc have broader free software goals that include collaboration with all FOSS projects, and supporting user freedoms. How is the slippery slope not theoretical? How does a single step of possibly accepting public domain code (however it is generated) in a Makefile trigger the eventual removal of my freedoms?
Show threadSiddhesh PoyarekarMar 13

@codonell @civodul the pre-LLM possibility of copyleft code being replaced by public domain code relies on there being a set of motivated individuals who are prolific in their contributions to the project and at the same time, want their contributions to be under the public domain.

In contrast, with LLM usage, simply allowing LLM contributions has a tangible risk of any and all contributions that come in, to be in the public domain. The realm of possibility expands quite greatly.

Show threadSiddhesh PoyarekarMar 13
@codonell @civodul of course with your example of "makefile patch" I assume you're thinking of the possibility of LLM use in a restricted area of sources, which is a different thing from someone coming along with optimized implementations of string functions for all architectures.
Show threadCarlos O'DonellMar 13
@siddhesh_p @civodul While you write "tangible risk" this still follows a slippery slope fallacy. What is the risk exactly? We've always allowed public domain, and we still do today. We will always keep mixing in LGPLv2+ code in glibc, since we are adding festures, fixing bugs, and refactoring as developers supporting a copyleft project. This resulting work remains LGPLv2+. The act of accepting these works does not in and of itself cause risks to the 4 freedoms except indirectly.
Show threadSiddhesh PoyarekarMar 13
@codonell @civodul increased adoption of LLMs will drive up contributions that are public domain? Do you think it's not something that will happen?
Show threadLudovic CourtèsMar 14

@siddhesh_p @codonell We don’t know yet if LLM output will be considered public domain, and in which jurisdictions.

If it turns out to be the case, will it be a win? Eventually all software would be public-domain?

My guess is that much software would be private. With fewer people mastering software development, the power in the hands of LLM-operating companies would be huge.

But this is pure speculation.

Show threadCarlos O'DonellMar 14

@civodul @siddhesh_p LLM output is already being considered public domain in the U.S. and while other jurisdictions matter, the FSF is based there and for copyright assignment purposes U.S. law is relevant.

I have a case today with localedata where a contributor claims copyright and a license in the Netherlands for unique and novel expression, but the FSF in the U.S. does not, so the project files have a disclaimer.

There are LLM cases winding through the courts today... I'm curious 🤔

Show threadLudovic CourtèsMar 14

@codonell @siddhesh_p I’m aware of a report suggesting that LLM output be considered public domain in the US:
https://copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

But it’s not the same as this being a settled matter, AIUI.

Also, there’s for instance this class action against Anthropic that could challenge this:
https://www.anthropiccopyrightsettlement.com

Show threadCarlos O'Donell
@civodul @siddhesh_p I agree it is not a settled matter. What are the consequences upon our actions? My goal is to write the best possible policy today with the given knowledge, risks, and community goals in mind. If things change then I'll change the policy.
Mar 14 at 8:49pmWeb
Show threadLudovic CourtèsMar 14

@codonell @siddhesh_p The practical consequence is that accepting “legally significant” code in a project is risky.

Gnulib only accepts up to 5 lines of LLM output, citing the risk of LLMs regurgitating copyrighted material:
https://lists.gnu.org/archive/html/bug-gnulib/2026-02/msg00064.html

an LLM policy

Show threadCarlos O'DonellMar 14
@civodul @siddhesh_p Accepting only 5 lines is the equivalent of accepting nothing. I'd be willing to accept any number of Makefile lines generated by LLM because they are boilerplate for glibc, gcc, binutils and gdb. Likewise an LLM writing a glibc test that uses the "support/" framework to verify ISO C fprintf() compliance is very unique to glibc. However, implementing fprintf() runs a high risk of infringing on training data, and I'd reject LLM submissions for new standard features.
Show threadCarlos O'DonellMar 14

@civodul @siddhesh_p Risk tolerances are per individual, per project, and subjective. We should be empathetic towards each other as we each feel these risks subjectively differently. One might keep me up at night, and you might sleep well.

I strongly agree with your opinion that the habits and behvaiours we are encouraging here run the risk of isolating community members from eachother. Policy won't solve that.

Show threadCarlos O'DonellMar 14

@civodul @siddhesh_p To put a positive spin on things...

What will help:
* Physical meetups (GNU Tools Cauldron)
* Weekly virtual f2f project meetings (glibc patch queue review)
* Monthly virtual f2f project meetings (2x Office Hours for the GNU Toolchain across two timezones)

What needs to be done:
* Better volunteer onboarding discussing the values of the community.