![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
by Denver Gingerich
by on November 5, 2026
Over the past few months, there have been an increasing number of reports of people successfully gaining access to their own devices that were designed to prevent them from installing their own updates and modifications. Nearly every one of these reports notes that an LLM-gen-AI was used. While there are obviously a huge number of issues with LLM-gen-AIs (as we note in our LLM-gen-AI recommendations), it is hard to ignore the benefits to people's digital autonomy that reverse engineering like this brings.
As an example, one device that was previously difficult to install updates on was recently freed by OpenWrt (part of SFC). Specifically, the Zyxel XS1930 (a 10- or 12-port network switch, with dual-core 1.0 GHz MIPS CPU), which ships with a fully proprietary OS called ZyNOS, has been upgraded to OpenWrt using the ZyNOS web UI, which only recently became feasible, thanks to the efforts of developers using LLM-gen-AI. Previous efforts to install OpenWrt or other Linux-based systems on the XS1930 required hardware modifications, but now people can update to OpenWrt in a couple of minutes, ensuring they will be able to maintain the security of their device long after Zyxel stops supporting it, not to mention all the new (OpenWrt) features they can now enable if they so choose.
There are many other recent examples of such successful reverse engineering efforts. I covered several of these in the keynote at SeaGL a couple weeks ago (including a guitar amp, the Meta Quest bootloader, a variety of music gear, and the Nintendo Switch 2 - see Slide 16 of the slides for details). Since then there have been even more, including this article on the sub-$100 FM-1, which was covered more thoroughly by an electronic music news site just last week.
Some journalists, recognizing how many of these projects are developed, have been raising the alarm about where this will go if we're not careful. Jason Koebler of 404 Media notes that Inevitably, poorly coded, barely-functional, insecure software is going to be installed on critical hardware, which will lead to devices and networks being hacked
. He's right, and this is why we need FOSS communities more than ever.
In the example of the Zyxel XS1930, freed by OpenWrt, LLM-gen-AI was used only to the extent necessary to understand the binary software image format the stock firmware expects. Beyond that, the device runs all the upstream projects distributed by OpenWrt, which have been carefully reviewed and developed by humans over the past several decades. This contrasts with many of the other reverse engineering projects mentioned above, where the software that replaced the proprietary code that previously ran on the device was itself generated by LLM-gen-AI with little or no human review. Especially with the LLM-gen-AI available today, this can be very dangerous, as Koebler correctly noted.
We at SFC, with our long history of finding ways for users to take control of their devices (using a variety of mechanisms, like lawsuits when necessary, our ongoing work toward software freedom on 3-D Printers also building our own community-focused hardware), have reached out to these reverse engineering projects to see if we at SFC can help, and to make connections with our member projects, where it makes sense and does not increase the risk of project burnout.
A related endeavour that I've personally been pushing since my first year at SFC over 15 years ago is to encourage companies to intentionally make their devices open to software modifications. While there have been hints about big companies doing this recently, which people have good reason to be skeptical about, there are smaller examples like several makers of electronic music gear mentioned earlier, that explicitly encourage people to run their own firmwares on the equipment they sell, when they recognized this would be a huge boost to sales and reputation with the community. If you are part of a company or know a company who wants to promote software modifications on the devices the company sells, please reach out.
Beyond the efforts described above, SFC will continue to look for new ways to engage with people who are working to bring the best of FOSS, including to the new world of increasingly modifiable devices that is now, whether Big Tech likes it or not, truly upon us.
by 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.
by 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.
by on September 3, 2025
You may have heard that Google will be limiting sideloading in the next few months, which is likely to be enforced through Google Play Services, something that runs on virtually all Android phones. Google plans include blocking sideloading of apps where the developer has not shown their ID to Google. Many people have been asking us how they can support app developers who will not or cannot be involved in a Google-run identity verification program.
In particular, we've been increasingly hearing that Android users want to remove their dependence on Google, for this and many other reasons, including the tracking and surveillance that come with using Google Play Services and other Google apps. As a result, we will be hosting a Q&A session this week, in conjunction with folks from F-Droid, to discuss how to best remove proprietary Google code from your phone, and ensure that you control how your phone operates, and which apps can run on it (and from whom).
We will cover the basics of which Google apps and other code you might be using, which of that you can remove while maintaining the use cases you have for your phone, and how to adapt use cases to potentially further reduce reliance on other non-free tools that prevent you from using your phone as you wish.
Among other options, we'll talk about how to use LineageOS on your phone, or another phone you might have already, what you can expect from alternate OSes in general, and how you can keep doing what you need, while giving yourself more control over what you can do in the future. Alongside participants from F-Droid, we will also discuss the F-Droid project, which hosts free apps that provide alternatives for non-free apps from Google Play, as well as classifying apps by how your data is handled, so you can maintain as much say over your privacy and freedom as possible.
We're excited to chat about how to improve your phone experience through the tools and expertise that software right to repair enthusiasts have created to ensure your phone and what you do on it is truly in your own hands!