Eternal November — this new influx of users may be better than the last one

by Denver Gingerich on April 15, 2026

Update: This blog post received significant immediate response — with strong reactions in multiple directions. Everyone on SFC's Copyleft Team has carefully considered for four years (i.e., since our policy fellow Bradley's 2022 article) what policies might make sense given the advent of LLM-assisted coding tools. We're now looking toward formulating formal policy recommendations with input from you. We believe movements are best built not by one person's proclamations, but rather through collaborations and planning for the best way forward together.

Below, I get us started by sharing my personal thoughts. Please come to a video chat session on one of the following days to discuss with us if you can (more details on the chats at the end of the post):

$ date -d '2026-04-21 15:00 UTC'
$ date -d '2026-04-28 23:00 UTC'

If you cannot attend these chats, and are already in personal contact with any SFC staffer, we all welcome you to chat with them or book a call — they would be happy to discuss. You can also reach out to <info@sfconservancy.org> and someone from our staff will engage in a slower email thread with you. As always, SFC never dictates mandatory policies on our member projects or our community. We look forward to hearing what you think at the sessions! My initial ideas follow:

---

Many people may recall Eternal September (in 1993) — when Usenet membership increased overwhelmingly — marking the annual September rush of student joins. The ensuing moderation challenges changed the culture of Usenet (the largest Internet discussion fora back then). Many early Usenet adopters left quickly. While this onslaught of “newbies” knew little of Usenet's traditional cultural norms, they nonetheless benefited greatly from these novel connections to discuss and learn together with people worldwide. The times were turbulent then, but eventually revised cultural norms emerged that benefited both the Eternal September arrivals and the old guard who stuck it out. Usenet (while less popular than it once was) survives today as the only widespread store-and-forward discussion fora optimized for low-bandwidth, spotty connectivity.

Today, another similar cultural change is afoot. I call it Eternal November. November 2025 — the month of Opus 4.5's release — has been widely identified as a similar inflection point: LLM-backed generative AI coding tools made a substantial leap to increased usefulness. A new wave of software developers — unfamiliar with traditional FOSS development culture — are adopting these systems quickly and making many (sometimes disastrous) mistakes. Some refuse to learn historical cultural norms, and others are genuinely confused (like all newbies) at the hostile responses.

We're all tempted — as some were in 1993 — to shun these “newbies” and reject their contributions aggressively. But what is really going on here? As in 1993, good and well-intentioned people just discovered newly interesting and hitherto unexplored ways to interact and engage with computing. FOSS's old guard reasonably feels angst, concern, and legitimate fear. We curated our norms over decades. But these norms are not sacrosanct. I urge us to reluctantly but seriously embrace this opportunity. We have much to teach these newcomers, and we must resist our arrogance of experience and assumptions that they've nothing to teach us.

I encourage all of us in the FOSS community to welcome the new software developers who've adopted these tools, investigate their motivations, and seriously consider cautiously and carefully discussing their workflows and consider if they may ultimately benefit FOSS. Seasoned software developers understand the benefits and limitations of LLM-assisted coding tools: we've studied for a few years the maintainability costs they incur, and the dangers of their flagrant, undisciplined use. We should give a try at explaining this to the newcomers. For example, if it comes from an individual (i.e., not a bot), an AI slop pull-request often offers an opportunity to educate a newcomer as to what they did wrong. Indeed, most FOSS developers that I know submitted a human-written-slop as their first contribution to a project. The ones who stayed are the ones who had an experienced developer explain what they did wrong — so they could improve and try again.

FOSS maintainers have decried for decades how few upstream contributions they receive. Maintainers today mostly bemoan the “AI slop”, and I agree that the slop is (at its absolute best) raw material to help make an actual contribution and (at its worst) tantamount to spam. Nevertheless, we must seek the goal of engagement to increase human collaboration (and thus maintainability). It is our job to recognize these opportunities, to communicate them, and to help new software developers build maintainable projects with us. It's a tall order: since the inception of FOSS, we've always needed to perpetually service the airplane while flying it: maintain the projects we have, while also creating the FOSS communities of the future for those projects. Only this approach has ensured FOSS will thrive and flourish. This is no time to give up that time-honored and documented successful approach.

The tiresome onslaught of slop (at least that presented by real humans) stems from a fundamental newbie confusion — but we can help newbies understand! We've always accepted (and encouraged) folks to keep private forks if they really like a patch that upstream determined was slop. My friend and colleague Bradley told me years ago that he maintained a personal fork of rsync for most of the 1990s because his extremely sloppy first-of-his-life submitted patch was rejected by upstream. Users who make a sloppy change that “works for them” should never be shunned; instead, they should be educated to make their own Git repository and rebase off upstream to their heart's content.

This is not to say we shouldn't encourage people to improve their behavior so they can contribute to and join FOSS projects. However, we do need to recognize when someone is ready and interested in doing that (and willing to put in a bit of extra time to help others), and when they just want to do a thing on their own, and that's fine for them. In the latter cases, we have always simply asked them to please stop sending us what they've got.

By recognizing what new technologies can do well, and what they can't, and how this differs from the technologies of the past, we can not only adapt our communities to these changes, but also take advantage of the new wave of people who are excited about our craft. It took time, but we adapted to the Eternal September. We can learn from that experience and do it again. The first steps are to recognize rapid changes, consider how they can benefit society, and then patiently and open-mindedly bring our ideals and extensive knowledge to the table to accelerate that positive change — while politely warning of the drawbacks (which are obvious to us but not to the newcomers).

There are many issues with LLM-backed generative AI coding tools; this blog post puts forward a few ideas about one of dozens of issues we now face (or will face in the near future). But every hope of improvement must begin somewhere. Therefore, if you help lead a FOSS project, or if you are using LLM-backed generative AI coding agents and want to learn to help rather than hinder upstream, please join us to discuss your concerns and the need to help welcome these new people to your communities in a manner that is productive. We will be running a series of interactive video chats, starting on April 21 at 15:00 UTC and April 28 at 23:00 UTC, in this room. SFC staff and volunteers will discuss these issues with the public. We'll consider how we can adapt FOSS projects to improve pro-AI contributor onboarding and how to better understand how newcomers are using and making software these days. Please also follow us using the linksa at the bottom of the page to learn about future such chats. SFC has dedicated 20 years already to successfully making FOSS the best it can be. We plan to do the same for the next 20 years, by understanding the needs of billions of new software developers, and welcoming them to our community with grace and education.

[permalink]

What the FCC router ban means for FOSS

by Denver Gingerich on April 2, 2026

Last week, the Federal Communications Commission in the United States (the FCC) banned the sale of all new models of home routers not made in the U.S., which is ... all of them. The stated reason for this is that routers "pose an unacceptable risk to the national security of the U.S. or the safety and security of U.S. persons." A router manufacturer can apply for a "Conditional Approval" exemption to try and convince U.S. government bodies that their router should be allowed into the U.S., but this requires "A detailed, time-bound plan to establish or expand manufacturing in the United States" and "A description of committed and planned capital expenditures, financing, or other investments dedicated to U.S.-based manufacturing and assembly", and "an update on the status of their onshoring plan once a quarter" among other impractical asks. Devices built in the U.S. generally cost at least twice as much as devices built in Asia (see the Librem 5 (USA) for example) because U.S. manufacturing facilities are not ready with the scale and efficiency required to enable competitive pricing. The reason we chose to build the OpenWrt One in Asia is that it makes sure the device is as feasible as possible for people around the world to purchase. We expect it will take decades before the U.S. is ready to produce competitively-priced devices - user freedom can't wait that long.

And, in case you were hoping to buy an OpenWrt One, don't worry: the One has already received FCC approval so there is no change to its availability in the U.S. Naturally, we are concerned about the effect this has on any new hardware that SFC might develop, but this decision by the FCC does not create any near-term problems for us, or for FOSS generally.

We do applaud the FCC for recognizing how important home routers are to people's security. While the rulemaking is misguided, it's absolutely correct that the proprietary router manufacturers be accountable in relation to the hardware and software that individuals bring into their homes and their lives. We believe that manufacturers of routers that are primarily FOSS are in a much better position to evaluate the security of their devices, and so we analyzed the rulemaking taking into specific account its software aspects.

While the FCC decision focuses mainly on hardware, there are also some requirements for software. In particular, the FCC has hinted that it may restrict updates to existing hardware, in particular that existing routers "may continue to receive software and firmware updates that mitigate harm to U.S. consumers at least until March 1, 2027".

Since software updates to already-FCC-approved devices do not require a new FCC approval, it appears the FCC is trying to move beyond its usual authorization procedures to restrict what manufacturers are allowed to push to existing routers. However, the FCC notably does not restrict software changes made by owners of routers in the U.S. In particular, there is no indication that updates people make to their own routers, using software they have sourced themselves, would run afoul of any past or present FCC rule.

As a result, we do not believe that this new FCC decision affects whether and how people can run OpenWrt or other user-selected firmware updates on routers they have already purchased. Not only is this an important right in relation to our ownership and control of our own devices, it also ensures that people can keep their routers secure for far longer than the manufacturer may choose to provide security updates, by allowing them to install up-to-date community software that supports routers for 10, 15, or even more years after their initial release date, as OpenWrt does for many devices.

This leads us back to the stated goal of the FCC in making these changes: to ensure that routers do not "pose an unacceptable risk to ... the safety and security of U.S. persons." We certainly agree that all persons (including U.S. persons) should use technology that is safe and secure. And there are standards that exist to ensure this is the case, such as NIST IR 8425A, which the U.S. government already paid to research and produce and, alongside NIST, is recommended by Consumer Reports and other right-to-repair groups already. We have been assessing our existing processes (for OpenWrt, and especially the OpenWrt One) against NIST IR 8425A, and are now accelerating those efforts to ensure we can show that routers using OpenWrt are indeed safe and secure, as determined by independent bodies. This not only helps U.S. persons, but everyone around the world, as OpenWrt is available to anyone regardless of whether they are in the U.S. or not. We strongly encourage any regulation targeting safety and security to take a holistic view, recognizing that safety and security in our technology does not depend on what country we are in, but rather on common properties of the hardware and software we use, and a shared understanding of what technological safety and security means for all humans.

We have reached out to the FCC for clarity on this topic, and look forward to updating this post with their reply.

[permalink]

Tags: conservancy, GPL, security, licensing, software freedom for everyone, inclusion

SCOTUS Declines to Hear LLM-Backed AI Case Regarding Copyright

by Bradley M. Kühn on March 4, 2026

No Serious Implications for FOSS from SCOTUS' Denial

Earlier this week¹, the U.S. Supreme Court (SCOTUS) denied certiorari (cert) in Thaler v. Perlmutter. Thaler contended that an image — generated by a Large Language Model (LLM)-backed Artificial Intelligence (AI) — deserved copyright registration. Since the U.S. Copyright Office refused to grant the registration, Thaler appealed to the U.S. District Court for the District of Columbia (DC Circuit). That Court affirmed the Copyright Office's decision. SCOTUS' denial of “cert” means they will not hear the case. Strictly speaking, this denial does not affirm the DC Circuit Court's ruling, but it does mean the DC Circuit decision stands.

Many in the Free and Open Source Software (FOSS) community raised concerns about the impact on copyleft — and even FOSS in general. TL;DR: Don't Panic! — this case is extremely limited in scope.

First, a proviso: this case is about copyright of an artistic image, not software. Copyright law — and the legal precedents around it — differ widely for different types of creative works. Analysis of the copyrightability of works of software varies in notable ways. Therefore, do not to assume that analysis for images apply broadly to software.

Second, while the decision is “published” ², there are also many other cases related to LLMs and AI currently pending throughout the U.S. Courts. Courts and laws always lag behind technological advancement. Indeed, this is precisely why copyleft was invented: as a mechanism to achieve with existing laws and precedents what we could not accomplish in the legislature. Forty-one years after copyleft's invention, we still do not have a federal law that mandates software right to repair!

Third, the Court found that a registration was not valid (at this time) if the work's sole author is a computer program. Thaler (who was both (one of) the author(s) of that computer program and its user) repeatedly waived any claim to consider Thaler's own copyright in the LLM-backed AI prompting process. Thaler also did not argue any copyright interest in the LLM-backed AI system itself were subject of the registration. So, this decision does not evaluate any creative expression by (a) the author(s) of the prompts themselves, (b) copyrights held in the LLM, its weights, generation, curation, or its user interface, and (c) copyrights held in underlying works in the LLM training data.

Thaler's original registration was the root cause of this substantial narrowing because the registration contended that the AI system itself was the author of the image. This case only considers a copyright registration where the sole “author” is identified as a specific computer program. Thaler stipulated that the work was generated solely through prompts and no human modified the work thereafter. As such, even if the other districts begin citing this case regularly, and even if many districts decide it applies to software without further consideration of the difference in the types of works, such precedent causes no disaster for FOSS.

Admittedly, some LLM-backed generative AI agents can be merely prompted to create a work of software from scratch that has some transient utility. However, the most common workflow in using these agents (at least in FOSS development) is as follows:

1. Start with an existing large FOSS codebase.
2. Prompt the LLM-backed AI agent to generate various changes and improvements to that codebase.
3. Apply creative, human effort to modify and refactor the output to yield a patch suitable for upstream.

This case — in addition to not considering software at all — does not consider that third step.

Furthermore, dicta ³ — appearing in the DC Circuit ruling — supports a conclusion that the human actions on that third step would constitute creative expression — affixed in tangible medium — suitable for copyright registration. Indeed, their ruling states:

First, the human authorship requirement does not prohibit copyrighting work that was made by or with the assistance of artificial intelligence. The rule requires only that the author of that work be a human being — the person who created, operated, or used artificial intelligence — and not the machine itself.     —  (Thaler v. Perlmutter, 130 F.4ᵗʰ 1039, 1049 (D.C. Cir. 2025))

Given the current state of LLMs and AI, this rule — even if universally adopted — would not cause serious harm to FOSS.

The Court also indicated these other issues are for a future time in another case. The DC Circuit readily admits that their ruling applies only to the state of AI systems at the time of writing⁴. Again quoting from their ruling:

Of course, the [Thaler's AI] Machine does not represent the limits of human technical ingenuity when it comes to artificial intelligence. Humans at some point might produce creative non–humans … Science fiction is replete with examples of creative machines that far exceed the capacities of current generative artificial intelligence. For example, Star Trek’s Data might be worse than ChatGPT at writing poetry, but Data's intelligence is comparable to that of a human being. See Star Trek: The Next Generation: “Schism” (Paramount television broadcast Oct. 19, 1992) (“Felis catus is your taxonomic nomenclature, an endothermic quadruped, carnivorous by nature”). There will be time enough for Congress and the Copyright Office to tackle those issues when they arise.     — (Thaler, 130 F.4ᵗʰ at 1050)

I agree with that statement by the Court completely. I also profusely thank Judge Millett for quoting one of my top-ten favorite ST:TNG episodes to support the Court's dicta.

[ As always, SFC is not a law firm, IANAL, and TINLA. ]

---

¹ I — and my colleagues at SFC — acknowledge that SCOTUS made other decisions recently regarding an array of important social justice causes. Since SCOTUS' decision to deny cert in this particular case is so closely related to my work, I'm writing about it. However, all of us at SFC acknowledge that our community is reeling from other recent decisions.

² In this context, “published” is a term of art that lawyers use to describe a case that the publishing Court (in this case, the DC Circuit) felt was important enough to “share officially and formally” with other Courts. While (in a precedent-based legal system) any Court can cite an unpublished case from another Court, published cases are much more likely to be cited than unpublished ones.

³ “Dicta” is explanatory language found in a court's decision that isn't necessary to the court's conclusion. . Dicta isn't precedential but it can be persuasive.

⁴ Note that the DC Circuit issued their ruling in March 2025. It is not uncommon for SCOTUS to delay for a year (or more) before issuing a ruling to grant or deny cert.

[permalink]

Tags: conservancy, GPL, law

Interview with Tracy Homer about Software Freedom and Maker Spaces

by Daniel Takamori on January 26, 2026

My name is Tracy and I'm the Operations Manager here at Software Freedom Conservancy. Basically that means I support many different parts of the organization, from writing up contracts for project developers to banking reconciliation. I also manage our annual conference, FOSSY.

Below is a conversation I had with our Executive Director Karen Sandler about my story with free software. Part of which centers my work with Knox Makers, the Makerspace I'm a board member of. Software freedom is an issue that affects us all, and I hope to bring some light to both my own story and a wider view of how non-FOSS developers and users interact with free software in an everyday way.

Karen Sandler: How did you first encounter the idea of software freedom?

Tracy Homer: It was a slow discovery process. When I first started using Linux, it's primary draw was that it was free (as in beer). I didn't really know it had anything to do with free as in speech and copyleft licensing. Over time I've learned how important it is to be able to modify your own devices and see what goes on behind the screens in the services that hold our most personal information.

Karen: What was the first FOSS software you used?

Tracy: Inkscape, one of SFC's member projects! I use it for all kinds of design work -both for SFC and personally. If you've been to FOSSY or visited our booth at other conferences, chances are the print material was designed in Inkscape.

Karen: We know you are very involved with the makerspace, Knox Makers. How does Knox Makers use FOSS?

Tracy: Knox Makers is committed to open source software and hardware wherever possible. We feel it is an aspect of accessibility for our members, and allows them the ability to try out and learn deeply all kinds of different tools, without having to pay expensive licensing fees, or worry about their art being sucked up by AI, or needing to buy a certain OS to run it. We've modified some software to make it more community user friendly, and written our own plugins and tools for our member's use as well. Knox Makers is actually how I learned of SFC in the first place, as a few of my good friends there are sustainers.

Karen: What are some projects you've recently done personally?

Tracy: I just finished a year's long project, embroidering a globe. It doesn't sound like it fits with free sofware but it does! I created my own pattern in QGIS (open source geographic software) using depth of the ocean translated into different shades of blue. Then I exported each of the 20 spherical triangular pieces into Inkscape to add some registration lines and print out. It took so long that I feel kind of lost what to work on next.

Karen: How does software freedom enrich your daily life?

Tracy: The few proprietary systems I still have to use are intensely frustrating. I feel like it's a game of cat and mouse trying to figure out how to use a "new and better!" interface with no documentation and no way to revert changes feels very disheartening. Any searching for error messages just brings up a long thread of other users with the same issue and maybe a rote answer from the company, typically unhelpful. That maybe doesn't answer the question, because I went the other way with it. But so most of my life is using open software and hardware that it's really become a non issue. I have a problem with something; I fix it. I can switch to something different if I really don't like it - I can even change up my whole computer system if I find it doesn't suit my needs. I don't get ads and other popups thrown in my face every where I turn, and I know my data and art belongs to only me.

Karen: You've been at SFC for over 3 years! And, as Operations Manager, you take care of some of the least glamous work that we have. What do you enjoy about your job? (hopefully it's something!)

Tracy: Working here has been great - everyone at SFC is lovely and I think we make a great team. I really enjoy meeting other people in the FOSS world, so I like tabling at conferences. And seeing everyone at FOSSY too. Weirdly, I enjoy the accounting aspects, because it feels like a puzzle to put together. All the numbers have to fit somewhere and they all have to sum up perfectly in the end so tracking down the missing pieces is a fun challenge.

Karen: What do you hope to accomplish in software freedom, either personally or professionally in the coming months or years?

Tracy: I've only done the most minor contributions to projects, and someday I'd like to develop the skills to do more. I'd also like to focus on adding more to my city in OpenStreetMap - it's pretty sparse in places. I think with SFC I'd like to help focus on on advocacy and how software freedom benefits many different aspects of life, especially in the creative space.

[permalink]

Tags: conservancy