![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
by Denver Gingerich
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!
by on December 3, 2024
Software cannot run without hardware. To have software freedom, we need hardware to run our software. Sadly, the vast majority of hardware is not built with software freedom in mind. Too often, we are beholden to the big hardware companies that sell us our laptops, phones, routers, TVs and other devices. Few manufacturers today build devices with user modifiability and longevity in mind. And it's getting worse. Hardware is becoming more and more locked down, making the need for devices that will work in our interests more and more acute.
Software Freedom Conservancy announced on Friday, in conjuction with our OpenWrt member project, that the first router designed from the ground up by the OpenWrt community is now shipping. OpenWrt developers and SFC staff have been coordinating over the past year to design and produce a hardware device that showcases the best of what OpenWrt has to offer. From the upstream-first approach, to the up-front source code availability, no stone was left unturned in ensuring the device would give people flexibility and control over the software (and hardware) that runs their network.
SFC works toward GPL compliance across the industry, so the devices running Linux out there (which now include toasters, dishwashers, fridges, and dryers, as well as laptops, phones, routers, and TVs) all comply with the copyleft terms that give you the right to modify and reinstall changes onto your device. GPL enforcement is one way we tackle this problem, but we constantly seek other approaches. In the case of OpenWrt, we have yet another example that shows the device manufacturers that haven't yet complied with the GPL (and given users the rights they are owed) how to do it right — to give people what they want and what the GPL requires.
We are very excited to watch the interesting applications you find for your OpenWrt One. We're amazed and impressed to learn some people are already running Doom and other software that just won't run on a router that you buy from one of the big name router brands. :) We think it's important for people to have the freedom to make their software work for them, to explore, and enjoy their software experience. The GPL and other copyleft licenses exist to make this possible.
The OpenWrt One is admittedly not perfect. It's sadly a prime example of hardware from recent eras that relies on a few binary component firmwares (in this case, for small parts of the wifi, 2.5 GbE port, and RAM calibration). It is difficult to construct modern hardware without a few of these binary blobs. While this reality is a travesty, we are excited that nearly all the source code for the software on the OpenWrt One is freely licensed. This ensures the maximum possible ability to repair and improve the device. We hope the device will last, and someday, since the binary parts are electronically upgradable, future users can replace the binary component firmwares as FOSS replacements become available. The design and distribution of the OpenWrt One shows that it is not only possible to distribute a device containing both copylefted and non-FOSS code, but that it is also cost-effective and straight-forward to comply with the relevant licenses, and allow users to modify and reinstall the device from source.
SFC wants to build this future of freedom for all your electronics (especially those running Linux and other GPL'd software). I work every day through private channels (and the courts, when needed) to get companies to respect your rights under the GPL. I'm ecstatic that we're now creating new hardware to show the world what is possible when we put software rights first! We're excited for everyone to join us on this journey, and encourage you to read our OpenWrt One launch announcement for more details on this first step.
We just started our annual fundraiser and we'd be thrilled if you could support us by becoming a sustainer. For a limited time, until January 15 (or $204,887 of donations), all donations will be matched, so renew or become a Sustainer today! Thanks for helping us bring software freedom (and hardware respecting it) to everyone!
by on October 3, 2024
We were excited and very happy to participate in Linux Plumbers Conference this year, which happened last month (Sep 18-20) in Vienna. As one of the premiere programs using a software right to repair license (GPLv2), Linux is crucial for the future of software freedom in our devices, from those we use to develop and write new code, to the phones many of us carry with us, to the many appliances and even cars that bring conveniences to our lives. And so we were delighted to discuss Linux and its role in our connected future with Linux kernel developers and other enthusiasts who attended this technical conference.
We hosted a BoF, Let's talk about GPL and LGPL enforcement!, which brought dozens of developers together to discuss the hard questions of how we can ensure that Linux's license is enforced so people can get the code they're entitled to, and the current state of GPL and LGPL enforcement across the board. After some discussion of how often companies use software under the GPL and LGPL without honoring the license terms (it's unfortunately very very common), we fielded some questions about source candidates that people had received. The first example that a participant provided as a positive example of a company meeting its obligations turned out to actually be from a company that SFC had sued in the past, showing that SFC's prior enforcement efforts were helping to change behavior, causing companies to provide GPL/LGPL source code when they hadn't before.
The discussion moved on to how we can bring the next generation of developers into the Linux community, so they can keep improving the Linux kernel in the coming decades. It was noted that a lot of new computer users aren't getting the same computing environment that most Linux developers grew up with. In particular, most Linux developers today started computing with desktop or laptop computers that gave them a wide range of software options, and easy ways to switch operating systems and other key software. However, today most new computer users are getting less capable devices, not because they are less powerful, but because the devices don't have the same malleability and accessibility as they did two decades ago, which is due in part to GPL violations where the user is prevented from reinstalling modified Linux or other software onto their device.
This really struck me, as I had many conversations in the "hallway track" where I asked people how they got into FOSS, and the responses were invariably a version of "to do more interesting things with my computer". It was clear that the computing devices of the 90s and early 2000s really promoted this developer mindset, and that we would have to keep the momentum going to ensure that new developers would have the same opportunities. This leaves us with a mission to make sure that as computing platforms change, we retain the freedoms that enabled the current generation of technology to flourish.
While GPL enforcement isn't the only factor in ensuring people can access developer tools and make meaningful changes to their devices, it is certainly an important piece of the puzzle, given everything we heard at Plumbers this year. With large percentages of Linux devices still distributed without giving users the freedoms that Linux's license is designed to give them, GPL enforcement is immensely important, as our discussions at Plumbers and elsewhere remind us.
The feedback from the BoF was overwhelmingly positive, and we were so happy to be able to take questions, share information, connect with longtime contributors and meet newcomers with such a keen interest in copyleft and enforcement. As always, we invite feedback about this work. You can email us anytime at compliance@sfconservancy.org, and we'll be scheduling some synchronous sessions later in the year.
In the meantime, we are proud to continue the work to ensure that everyone can repair and modify the software on their Linux devices, and everything else using software right-to-repair licenses, for current and future generations of software users and developers.