![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
tagged resources
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 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!
by on December 12, 2024
Since the Linux project removed a number of entries from the MAINTAINERS file, all of whom were putatively Russian, in October, we've been receiving questions about U.S. sanctions against Russia and what, if anything, we should do about them. As I explain below, our position is that such drastic action, though defensible, is unnecessary.
What would compel the Linux project to take action against specifically Russian
contributors—and is it a good enough reason such that other FOSS project should follow
suit? The Linux project has access to the lawyers of the Linux Foundation, after all. Unfortunately,
the Linux project's initial announcement said only that the removals were due to various
compliance requirements.
The announcement added that the Russian contributors can
come back in the future if sufficient documentation is provided.
But it didn't say what sort of
documentation would be required. Linus Torvalds added a little clarity when he said that
"sanctions" were the cause.
Speculation quickly centered on Executive Order (“EO”) 14071, one of the U.S. sanctions against Russian. It had recently been expanded to include software development and IT services, just a month before the Linux project's announcement. (EO 14071 dates to April 2022, but its scope is expanded from time to time to include new industries.)
The problem with this theory is that EO 14071 doesn't apply to contributions from a Russian national to a software project (even though it now applies to software development). It is true that, when a Russian national makes a copyrightable contribution to a software project governed by the GPL, the Russian national enters into a contractual relationship with (at least) all downstream distributors. But EO 14071 doesn't sanction any and all contractual relations with Russian nationals. It only prevents the provision of certain software- and IT-related services (including software development and consulting) to Russian nationals from a “U.S. person”. In other words, EO 14071 works in reverse to the Linux project's situation.
So, if it's not EO 14071, could it be some other U.S. sanction? There are, after all, quite a number of them. On October 24, James Bottomley provided something of an answer. Citing Linux Foundation lawyers, Bottomley wrote that the Linux project means to exclude companies on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company the list.
(OFAC is the Office of Foreign Assets Control, a division of the Treasury Department, in charge of maintaining these sorts of sanctions. SDN means “Specially Designated Nationals,” i.e., persons and businesses, as opposed to entire regimes.) Under this analysis, the documentation referenced in the initial announcement would be paperwork tending to prove that the contributor did not work for such a sanctioned company.
Alas, this doesn't tell us very much. Not only are there several U.S. sanctions against Russians, which cover different activites and serve different purposes, but each of them affects its own set of (overlapping) Russian parties. Wading one's way though these sanctions is a slog that almost no FOSS projects can possibly wade through. You have to parse the actual statutory and regulatory language, review later regulations and executive orders that might alter the sanction's scope, check whether a given Russian individual or entity is subject to that particular sanction (because two given sanctions don't necessarily apply to the same Russians), then check whether your activity or relationship with that Russian individual or entity is covered by the sanction. (On the upside, the U.S. government provides a handy website that allows you to check which sanctions, if any, affect a particular Russian person or entity. But, even if you can be sure you've checked the right person/entity, you still need to determine whether the sanction actually applies to your own activity.)
This is a lot of work. And I think that explains the Linux project's cautious approach: namely, suspending all Russian contributions to the project temporarily; then checking each contributor, case-by-case; and (presumably) reinstate them if they don't show up on any sanctions list. Even this strategy might not be feasible for many if not most projects. They might be more reliant on Russian contributions, be less able to withstand the blowback from sudden suspensions, or simply lack the legal resources.
In my view, none of the Russian sanctions prevents Russians from contributing to American-based software projects governed by the GPL. While the approach taken by the Linux project is reasonable and understandable, I do not believe SFC's projects to take similar actions at this time.
Besides, the spirit of FOSS, I think, requires a bias toward acceptance of otherwise valid and competent contributions. The goal is great software that, in many cases, affirmatively improves people's lives. Rejecting good contributions undermines that goal. Further, rejecting otherwise good contributions does nothing to further the sanctions' goals. The sanctions are primarily intended to punish Russia for, and to degrade its ability to conduct, its interference in U.S. elections, its flouting of international rules, and its aggression in Ukraine. It is difficult to see how rejecting Russian contributions furthers any of these goals.
There remains one final mystery. Some of these Russian sanctions are several years old, so why is this an issue now? My best guess is that EO 14071 brought the issue of Russian sanctions to Linux Foundations's attention because it was explicitly directed at software development. Even if EO 14071 was found to be inapplicable, Linux Foundation couldn't ignore the whole raft of other Russian sanctions, which would take time to sort through.
Ideally, we could keep geopolitics (and lawyers!) out of FOSS. But that's not always possible. U.S. sanctions are one reason. There's no harm in being cautious, so long as the spirit of FOSS is respected. Different projects and organizations will reasonably come to different conclusions on this matter.
Links to the documents referenced above:
by on May 2, 2022
Defending your right to modify and repair the software on your electronics has been a cornerstone of Software Freedom Conservancy since its inception. We defend these rights in a variety of ways: petitioning the Copyright Office to return our repair and modification rights, investigating reports people send us where companies are using our member projects' code but aren't providing the source or repair and modification information that the project's license requires, contacting those companies to remind them of the license requirements, and (eventually, in rare cases after companies ignore our gentle reminders for many months) filing lawsuits against intransigent companies who refuse to give you the complete source and instructions you deserve (and that they are required to provide by the licenses of the software they freely choose to use).
In the rare cases where Software Freedom Conservancy has been forced to move its enforcement actions from gentle reminders to filing lawsuits, we have used a variety of approaches. Our lawsuit filed in 2007 against several manufacturers, used copyright law (specifically copyrights in the BusyBox project) to compel those manufacturers to comply with the GPL (such as Westinghouse). The lawsuit we filed last year against Vizio takes an approach more appropriate for widely marketed and available consumer devices. Namely, the claim in Vizio is a contract claim for third-party beneficiary rights under the GPL, which will allow us (and all other customers who bought Vizio TV's) to receive the repair and modification instructions to the software more directly.
Since we began enforcing the GPL fifteen years ago, the landscape of GPL violations has deteriorated: GPL'd software now appears in nearly every consumer device smarter than a toaster, and very rarely do the manufacturers even bother to offer source code to users — and almost never does the source release meet the requirements of the GPL. As a result, we at Software Freedom Conservancy continue to dedicate more time and resources to our enforcement efforts. We seek to ensure that the situation does not get even worse, and we believe that we can improve the situation even more.
The best approach, in our view, is to continue to bring a variety of different types of actions against intransigent violators. As always, we use litigation and litigation-like means as a last resort, but we've reached that point with dozens of companies. There are a variety of types of actions we could take and lawsuits that we could bring, and different ways we can go about preparing for them. But, to have the full scope of options, we need your help.
As a contributor to copyleft projects, one way that you can help us right now is to assign the copyrights of your software freedom works to Software Freedom Conservancy. As the Vizio suit shows, copyright-based claims will not be the sole focus of our enforcement. However, there are some key types of products where copyright claims are ideal. By assigning your copyrights to us, you can give us the ability to stand up for your software freedom and rights and, more importantly, the rights of your users. While we understand the FOSS community has some aversions to copyright assignment, we also know that, right now, many developers automatically assign their copyrights to their employers without demanding that their employers stand up for the copyleft rights of their users. We ask the community to reconsider this common practice, and request those who haven't already assigned copyright to their employer to assign their copyrights to us, and we urge those who have entered work-for-hire arrangements with employers ask those employers to give them back their copyrights immediately. (See our ContractPatch project for more information on how to do this.)
Today, we launch our self-service Copyright Assignment form. This new form, carefully vetted by our lawyers, allows you to quickly and easily assign your rights in your code, documentation, and other copyrightable works to Software Freedom Conservancy. We will use these copyrights to ensure companies follow the copyleft licenses that they use. You can assign copyrights for projects that are not members of Software Freedom Conservancy too. We will always enforce them in accordance with our Principles, and we will welcome you onto an internal mailing list and regular meetings to discuss our enforcement efforts.
Through the various software freedom lawsuits we have filed over the years, along with the lawsuits we've helped fund, Software Freedom Conservancy has established a track record of tangible enforcement actions.
We are very happy for all the support we've received from software freedom activists, developers, and other community members over the years in our software freedom enforcement actions. We hope you will continue to support us, and encourage others to do so, in whatever ways you can and, if it makes sense for you, by assigning your software freedom works to us so we can ensure the repairability of your electronics (and everyone else's!) going forward.