![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
tagged conservancy
by on June 2, 2026
In this philosophical essay, I explore the question: “When (if at all) is it ethically and morally acceptable to use proprietary software in the production and/or improvement of urgently needed copylefted FOSS?”
The question presents a complex conundrum. I attempt herein to rigoriously examine it through both a priori ethical analysis and a posteriori (and folksy) consideration of my personal experience and the shared experiences of the early software freedom movement.
I surprised myself at the outcome of my analysis. I conclude that under some circumstances (of which we have already witnessed in key historical examples), use of proprietary software by FOSS contributors to create/improve FOSS becomes a moral imperative. And, that imperitive often supersedes the moral imperative to avoid using that proprietary software.
I grew up lower middle class in the USA — which is quite privileged by global standards. As such, I never went hungry, but most meals did not include second helpings. My family were early adopters of “extreme couponing”. My earliest childhood memories are climbing through (on Monday mornings) the gigantic bin of recycled Sunday newspapers behind the grocery store. My job in this endeavor was “Sunday insert extraction”. Back then, more than half of all households received the Sunday paper. That Sunday insert was the goldmine. The insert paid for the paper subscription (and much more) through its colorful 30-40-page advertisements filled with coupons. Get your hands on 10–20 more of those inserts freely from the recycle bin, and you could get “Extreeeme!”.
The late 1970s and early 1980s were the wild west of extreme couponing. There were nearly no restrictions on how many identical coupons one shopper could use. A shopper could use 50¢-off coupons for 49¢ trial-sized products. I remember once my mother filled the entire checkout belt with 30+ trial size dishwashing liquids — for which my mother paid ≈65¢ (i.e., just the sales tax).
My young indoctrination to extreme couponing now feels as if it’s part of my DNA. If you’re ever on on mute during a voice call with me and I don’t reply quickly, it might be because I’m currently standing in a grocery store aisle — comparing value per volume of different sizes and cross-referencing that with a coupon’s fine print.
I actually miss having my hands covered in newspaper ink every Monday — as that analog way was superior to digital. For much of my life, I enjoyed “extreme couponing” as one of the few activities that put aside my worries about the future of users’ software freedom, rights, and privacy. Sadly, about ten years ago, everything started to change. Now, using any coupon is a constant battle with proprietary, bait-and-switch spyware.
Major grocery chains in the USA provide proprietary apps — now the primary place providing coupons. Most chains have parallel websites that allow account holders to “clip” them digitally. Printed ads still exist, but are rife with phrases like “Digital Deal only”. Shoppers now collide in the grocery aisles while navigating the Kafkaesque apps and websites to figure out how to (virtually) clip a good coupon.
The once relaxing process of watching television on a Sunday afternoon while clipping paper coupons slowly morphed into a two-hour ordeal of figuring out the minimum proprietary Javascript required, then building a text cross-list noting the discounts, screenshotting the bigger discounts, and then using the list and screenshots to prove to the grocery manager that I really was supposed to get $1-off of 4+ avocados this week. And, yes, I clipped it in the web browser. And, no, I can’t install the app on this device to “check it in the app”. 🙄
Most of my life, I couponed due to absolute financial necessity. I can fortunately now afford to pay full price, but frugality is part of my moral code. While the correct moral action for these grocery chains is to simply reduce prices for all shoppers automatically, they behave unethically. They prefer to use proprietary software to track you, to attempt to manipulate you into buying items you don’t need, and all the other obvious anti-features. In response to their unethical affront to the public, I feel the moral imperative to exploit that system by not falling for the manipulation tactics, maximizing my grocery budget, and acting as a watchdog when the digital coupons just seem to “not work”.
My colleague Karen Sandler and I have keynoted three times regarding our own ethical and moral analysis of software freedom in today’s digitized world. Our primary thesis: one must constantly compromise some software freedom purity to merely participate as a normal citizen. My lifelong grocery shopping experience exemplifies one situation of hundreds where tasks that once included no software interaction now mandate proprietary software usage. I lament this reality; it annoys me. But annoyance isn’t immorality, and software freedom activism was founded on pragmatic idealism. I fear that recent hard-core FOSS rhetoric has forgotten what that means.
As a fan of Kantian moral frameworks, my formulation of pragmatic
idealism focuses on ranking the competing moral imperatives. While “use
no proprietary software myself” is a noble moral tenet, its value
remains paltry when viewed comparatively.
The moral imperative to avoid writing proprietary software
towers over the moral imperative to avoid using it.
The conclusion is similar in a Utilitarian ethical analysis: provided one does not encourage others to join them, using proprietary software harms only the self. Writing proprietary software harms everyone who ever uses it — perhaps into the distant future.
The reverse situation yields similar analysis. Often, an individual, by using proprietary software today, can assure that many others will ultimately use less proprietary software in the future. In such situations, use of proprietary software by the individual is clearly a higher-ranked moral imperative (because it prevents many others from facing similar moral dilemmas). This also serves the greatest good for the greatest number: one person uses proprietary software so that many others won’t.
SFC lives this truth every day we operate. As part of SFC’s fiscal sponsorship of our member projects, we use a lot of annoying proprietary and/or trade-secret software (including banking systems, corporate donation and purchase order systems, third-party donation services, etc.). Yet, if SFC didn’t use those systems on our member projects’ behalf, at least one individual (possibly many) from each project would use them, instead.
Application of pragmatic idealism shows that using proprietary software is occasionally the right ethical choice for at least three reasons: (a) serving a higher moral imperative outside the scope of FOSS, (b) limiting the number of people who use proprietary software (now or in the future), and (c) increasing the efficiency and/or efficacy of urgently needed FOSS advancement.
While my opening example of using proprietary software to increase efficiency for FOSS’ advancement focused on the non-FOSS imperative of frugality, the principle expands well beyond that. In fact, the earliest FOSS contributors clearly believed that other imperatives sometimes justify proprietary software use.
By the time Richard M. Stallman (RMS)1 began to formulate software freedom as an essential right in the mid-1980s, proprietary software was the norm. Most computer users were using a Microsoft, Apple, or proprietary Unix system. RMS chose to write a copylefted Unix-like system (GNU) to replace proprietary Unix on its existing hardware.
But consider how RMS and the other early GNU contributors approached that work. If the goal was to minimize the developers’ use of proprietary software, the obvious approach would have been as follows: write a small bootable kernel on the existing ITS computers for the new hardware. Then, one could painstakingly write the basics of a C library in assembler (because, no FOSS cross-compilers existed in those days). After probably a decade of fulltime work by 3–5 people, there might have then been enough of a C library, a C compiler, a shell, and a text editor that others might also have software freedom.
I’m quite glad that the early GNU contributors did not take this approach. In fact, RMS started by writing the key program he knew best how to write quickly: another Emacs implementation — designed for existing proprietary Unix systems. And, GNU Emacs was working nicely in less than one year!2 Next, the GNU contributors tackled GCC — but not by bootstrapping in assembler. Instead, they used existing, proprietary C compilers to bootstrap. That too brought software freedom to C programming much more quickly than the “pure” approach.
Nearly all readers already know how the story ends: these early contributors quickly brought most of a working POSIX system to users — all licensed under copyleft licenses — except for the kernel. That story is often told, yet so rarely is the most important point the focus: the entire FOSS community used part-FOSS/part-proprietary systems for at least 15 years. Our (correct) focus was to deliver as much software freedom to other users as we could — as quickly as possible. Our overarching moral imperative was “create as much copylefted software as possible” — even if we used proprietary software as part of FOSS’ production.
The users’ software freedom matters much more than the developers’ software freedom. If FOSS developers find a path that accelerates software freedom for their users, then that higher moral imperative demands that path.
We dream of a world without proprietary software — where every byte of code on every piece of hardware provides complete, Corresponding Source to its users. Despite our best efforts, we drift further from that world every day. We race against the wealthy people whose wealth grows faster when they produce more proprietary software. We will not beat them in our lifetimes, but we can make progress. Along the way, we must constantly reconsider: Should we use some proprietary software to accelerate urgent improvements to FOSS? Willingness to sometimes answer that with “yes” (pursuant to rigorious criteria) epitomizes pragmatic idealism!
Every day, I find that I’m using more proprietary software than I did in the early 2000s. I’ve been on that unfortunate trajectory since the mid-2010s. I was one of the last hold-outs who using only X200 and T500 laptops — the last laptops ever made that could run all FOSS code from the up-top to the down-deep. Nevertheless, in November 2025, I switched to a Novacustom V54 that requires so many blobs for the internal devices that 77.5% of the packages contained in the firmware distribution are proprietary.
Today, my personal software freedom on my own laptop (at boot-time)
is measurably 77.5% less than it was when I lugged around the
T500. However, everything I do for SFC now happens quicker. I spend
substantially less time waiting for beancount to load SFC’s
books. I can attach three additional external displays (instead of just
one). I stopped injuring myself every time I travel from the T500’s
weight (as my X200 became too slow many years before). These and so many
other efficiency improvements from my Novacustom laptop made my work at
SFC (at least) 50% more efficient.
I gladly take that trade-off all day long. My job is to preserve, protect, and promote users’ software right to repair. That moral imperative outranks my moral squeamishness every time the blob on my wireless card processes a network packet.
Frankly, the software freedom and rights of computer users of the future deserve priority over activists’ and developers’ preference to use only FOSS. We should reluctantly but doggedly use any proprietary software that assuredly accelerates creation of and improvements to essential and urgently-needed copylefted FOSS.
1 RMS deserves substantial credit for formulating the first ethical framework for software freedom, his invention of copyleft, and his authorship of the earliest GNU programs. I am however not comfortable mentioning RMS and his work without noting his bad behavior that I frequently witnessed and his ongoing refusals to curtail or apologize for that behavior.
2 Free Software, Free Society: Selected Essays of Richard M. Stallman, 3ʳᵈ edition (2015). GNU Press, Boston, MA. Page 21.
by on May 17, 2026
Years ago, copyleft violations were often a mere misunderstanding; vendors intended to comply but made mistakes. In those “before times”, a simple request and short discussion often led to the complete, Corresponding Source (“CCS”) for the the distributed binary works (or, in the case of network-service copyleft, the deployed systems).
Today, nearly all copyleft violations are done with forethought (and frequently nefarious) intent. As such, the most common form of violation is not what we call “no-source-or-offer” or even “offer-fail”, but rather “incomplete-ccs”. That last form of violation is unforunately most complicated to resolve.
An “incomplete-ccs” violation means that the vendor has released some subset of required copylefted materials, but has purposely held back some necessary parts. For example, vendors sometimes provide byte-for-byte upstream source versions (absent their own changes entirely). Upstream sources obviously lack the vendors' “scripts used to control compilation and installation of the executable”. Even when some scripts are included, they are often not the actual scripts used to compile and install, but instead they're an alternative, incomplete version — often created specifically to thrwart efforts to recompile and install. Occasionally, vendors also withhold source code for some key modules, libraries, or other components governed by the copyleft license. Unsurprisingly — in general — vendors withhold the most interesting and most difficult to reimplement parts of the complete, Corresponding Source. Users are left with mere pieces of what the license agreement promises; users have immense difficulty reproducing the build and installing it. In network-service copyleft licenses (like the AGPLv3), users further struggle to properly deploy the service for self-hosting — a right that AGPLv3 guarantees.
These incomplete CCS “candidates” often exhibit “truthiness”. (Stephen Colbert wittily dubbed “truthiness” to refer to false or misleading material that appears to have the quality of truth at first glance — just enough that most won't bother to “trust but verify”.) When we enforce copyleft licenses in “incomplete-ccs” scenarios, we face a protracted argument with most vendors who insist — usually for some seemingly plausible but actually altogether specious reason — that the previous CCS candidate that they provided truly is complete and Corresponding Source. The average number of “rounds” of incompleteness reports that we send until reaching actual, valid CCS is approximately fifteen (on average).
We have spent many years pondering and refining advice for the users and consumers of these products. The users face the worst conundrum here: they sit confused with a copylefted binary and/or object code — yet they cannot effectively exercise their own rights under copyleft nor can they redistribute any object code to anyone else until they have proper CCS.
Fortunately, all is not lost. Here are a few simple facts (which apply to all known copyleft licenses — including the AGPL, LGPL, GPL, and copyleft-next):
For example,
AGPLv3§1
states You may make, run and propagate covered works that you do not
convey, without conditions … a "covered work" [is defined as]
either the unmodified Program or a work based on the Program
.
AGPLv3§4 goes on to state: [y]ou may convey verbatim copies of the
Program's source code as you receive it, in any medium
.
AGPLv3§5 grants that you may convey a work based on the Program, or
the modifications to produce it from the Program, in the form of source
code under the terms of section 4
. The list of requirements you must
meet when doing so under AGPLv3§5 are easy. (Summarizing AGPLv3§5(a-d): they
require that you add/maintain certain required textual notices,
and outbound-license the whole Covered Work under AGPLv3 itself.)
In short, there's no need to think twice if all you're doing is redistributing a copylefted work in pure Source Code form.
This License explicitly affirms your unlimited permission to run
the unmodified Program … You may make, run and propagate covered
works that you do not convey, without conditions
(AGPLv3§2). Other copyleft licenses have similar language.
Do take care not to give someone else direct access to the machine where you do this, and firewall the system so only you can access it via a network. If you distribute and/or convey the software to third parties (or deploy to others a network-service-copylefted system), there may be other parts of the copyleft license that will create obligations for you.
This concept can be counter-intuitive at first, but is extremely important when a vendor continues to provide incomplete/non-corresponding source code for a long time. If the vendor shipped portions of the work in non-source form only (for example, Linux modules in Object Code (i.e., .ko file) format), those files must be distributed under the copyleft license pursuant to its terms. While you face difficulty1 if you personally want to redistribute the non-source form of the software, your rights to analyze, modify, examine, reverse-engineer, or “figure out” those non-source components remain unimpeded due to your rights under the copyleft license.
Similarly, if the violator is withholding (all or some of) “the scripts used to control compilation and installation” — and you have the patience to painstakingly reproduce the build and install the software — you are fully permitted to try.
If you are lucky enough to succeed in your reverse-engineering effort and yield a non-source form that has clear and correct CCS that you can provide yourself, then you can make your own binary/Object Code distribution and redistribute2 all of it together (i.e., pursuant to AGPLv3§6).
These are three of the ways you can still exercise a few of your software freedoms and rights even when vendors have curtailed them by a copyleft violation. This isn't an exhaustive list; rather, it represents the most common “real world” scenarios that users and consumers face against badly behaved vendors.
Keep in mind that vendors will regularly bully users and inaccurately claim these rights don't exist. And it can get nasty!: we've seen violating vendors send DMCA takedown notices, get lawyers to send cease and desist letters, and even publicly shame the brave users who engage in the activities above. If this happens to you, keep your nerve, and remember that all copyleft licenses are irrevocable — vendors don't get to change their mind about your rights after the fact.
Finally, please never hesitate to reach out to us at SFC if you have other scenarios that you face and wonder what your rights are under copyleft, or if you face bullying, harassment, or other further bad behavior from vendors who refuse to grant users the rights they deserve under copyleft. ∎
As always, the usual disclaimers apply: Software Freedom Conservancy is not a law firm, I am not a lawyer, and the advice in this post is not legal advice. You may indeed face legal action by violators even if the rights and permissions that you exercise are obvious. You may wish to consult legal counsel in these situations, and we particularly recommend that you do so if you engage in any distribution and/or software deployment commercially.
1 Note that most copyleft licenses give extra rights to users who wish to non-commerically redistribute object code forms received from their upstream. With most copyleft licenses (and certainly with the GPL Agreements), if you want to redistribute Object Code components just as a vendor gave them to you, you are permitted to simply pass along the offer for CCS from the upstream commercial entity (e.g., see AGPLv3§6(c)). As such, we at SFC usually feel comfortable freely redistributing non-source forms of software that we know are violating; and, we simply point to the upstream violator. When we do so, we encourage users to demand source from the vendor. However, we at SFC do this kind of work every day. We urge anyone who wants to imitate our behavior in this regard to discuss privately with us first, and also consult legal counsel. (NB: Since we're not a law firm, we can't be your legal counsel).
2 The
OpenWrt origin story provides an
excellent historical example of a burgeoning
FOSS project following
these three guidelines. In early 2004, Cisco's Linksys
released incomplete and non-corresponding source code for its
WRT54G router (— following a six-month copyleft enforcement action that I led).
While that release was not CCS, it was juuust enough to allow the newly
formed OpenWrt project to reverse-engineer the build and installation
systems (by making their own with buildroot). Furthermore,
OpenWrt redistributed a binary Linux module (.ko file) for which Broadcom
(Linksys' vendor) refused to release CCS. To my knowledge,
Broadcom never took any action against OpenWrt on this matter —
likely because Broadcom itself violated GPLv2, and they did not want to draw attention
to their own nefarious behavior. Furthermore, OpenWrt's distribution was
non-commercial and therefore Broadcom had no “profits” to go
after. (By contrast, for SFC's OpenWrt One router, we made sure that no third-party
upstream non-compliant binaries were included — not only because we'd never
sell (or even encourage use) of a product that violated, but also because it's
very
risky to sell software that violates copyleft.)
by on April 16, 2026
This article discusses a current-headlines situation regarding Affero General Public License, version 3, Section 7, paragraph 4 (AGPLv3§7¶4.). I begin however with an explanation of the problem that clause sought to solve and how the clause works. This may seem an estoric license issue, but in fact this issue regularly impacts users today — particularly with the advent of “badgeware” (software that allows redistribution but includes annoying advertising that cannot be removed). Hopefully, this explanation helps readers understand the importance of the issue and gain vigilance when reviewing potential “further restrictions” placed on their copylefted software.
I began my work in copyleft licensing and policy in the late 1990s. In those days, there was a growing problem regarding usage of the GNU General Public License, version 2 (GPLv2) that threatened the software freedom and rights of users. It's a nefarious licensing slight-of-hand that works as follows:
The vendor seems to offer the software under a copyleft license. There's
a copy of GPLv2
in the top-level directory of the source code in a file called
GPLv2. All seems in order, and folks excitedly
engage in their right to copy, modify, and install modified versions of the
software. Maybe a few even think of a viable business idea that would
include (usually permissible) commercial redistribution of the software
for profit.
Unfortunately, someone notices a file
called LICENSE in the top-level directory that says:
Copyright (©) 1999, Sneaky Company, Inc.
This software is licensed under GPLv2, except that commercial modification and redistribution is strictly prohibited.
They've sadly discovered a self-contradictory license. Unfortunately, under GPLv2, these users are basically stuck; they have to go with the strictest possible interpretation given the self-contradiction. In essence, the licensor giveth, but the licensor immediately taketh away. In those days, these users couldn't start their business; they'd have to find or write another codebase.
I was tangentially involved with the drafting of GPLv3. On my list of issues to raise with the drafters was this very issue. By the time of GPLv3 drafting (circa 2006), this problem was rampant. Users were quite confused when they saw these self-contradictory licenses.
The solution was not obvious. Both GPLv2 and the earliest drafts GPLv3-family of licenses
(which includes GPLv3,
AGPLv3, and
LGPLv3)
already had this clause: You may not impose any further
restrictions on the recipients' exercise of the rights granted herein
(quoting the GPLv2 version; the
GPLv3/AGPLv3 version varies slightly).
The problem: this only prevented downstream licensors from imposing further restrictions. If a sole entity is the original author, copyright holder and initial licensor of the work — and if they hold those powers exclusively — typically that entity may issue a self-contradictory (or even completely incoherent) license. In that case, downstream licensees are awash with legal uncertainty. So, that “may not impose” clause just does not solve this particular problem.
A new clause was needed. Later drafts of the GPLv3 (which is almost textually identically to AGPLv3 — only §13 differ between the two licenses) included a fascinating solution in §7¶4:
If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
Copyleft is indeed most inventive when it empowers the downstream user (who, of course, is often just the next entity in a long distribution chain of (both commercial and noncommercial) software sharing). AGPLv3§7¶4 is an innovative and very necessary clause that liberates users who face the situation described at the start of this article. Had our excited new business seen this …
Copyright (©) 2008, Sneaky Company, Inc.… they could simply toss away the additional restriction like so …
This software is licensed under AGPLv3, except that commercial modification and redistribution is strictly prohibited.
Copyright (©) 2008, Sneaky Company, Inc.… and copy, modify, redistribute, redistribute modified versions and/or install modified versions of the software freely under AGPLv3's pure terms.
This software is licensed under AGPLv3, except that commercial modification and redistribution is strictly prohibited.
There remains one drawback to this solution: it demands courage from the user that strikes the “Further Restriction”. In theory, all is well and safe. In practice, the types of companies that pursue tactics like self-contradictory licenses and “gotcha” further restrictions are also the most predatory, unfriendly, litigious, and aggressive businesses. One who exercises their clear and correct rights under AGPLv3 will certainly face public condemnation, and possibly frivolous litigation.
For years, the Neo4j case was the primary exemplar of this phenomenon. SFC followed the case closely, I served as an expert witness for the Defendant, and SFC filed an amicus brief on the appeal. The lower court decision was highly problematic, and the case concluded with a voluntary dismissal (and as such has not been heard by any Appeals court). Thus, while the lower court decision does not create bad precedent, it also does not offer any good precedent for those corageous users who exercise this particular right.
(Full disclosure: SFC runs a self-hosted Nextcloud instance — but other than being fans of their work and satisfied users — we have no formal relationship with Nextcloud (or IONOS). We also certainly have no relationship whatsoever with Onlyoffice or Ascensio System SIA.)
A few weeks ago, yet another saga in the history of AGPLv3§7¶4 began. Ascensio System SIA published Onlyoffice with the sneakiest “Further Restriction” that I've ever seen. Ascensio's further restriction states:
Pursuant to Section 7(b) of the License you must retain the original Product logo when distributing the program.
Pursuant to Section 7(e) we decline to grant you any rights under trademark law for use of our trademarks.
This restriction is particularly nefarious because it is dressed in the trappings of explicitly permissible requirements in AGPLv3§7.
In addition to our beloved AGPLv3§7¶4, the rest of AGPLv3§7 includes some provisions designed for cross-FOSS-license compatibility. During the GPLv3 drafting process, a survey was conducted of all popular FOSS licenses. In the spirit of making sure no terms of GPLv3 inadvertently contradict a requirement in one of those licenses, AGPLv3§7(a-f) were devised for maximal cross-FOSS-license compatibility.
For example, the 3-Clause-BSD license's third clause states:
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission
Now, get ready for Onlyoffice's trick, which takes three moves:
The trick is “too clever by half”. Ascensio have indeed created a self-contradictory license, since the users are prohibited from displaying the trademarked logo, yet the users are also forbidden to remove the code that displays that trademark logo.
We thought through this problem already years ago during AGPLv3's drafting. In fact, I recall much discussion to verify there were no strange interactions between 7(b) and 7(e) — and there are not. AGPLv3§7(b,e) states (including relevant definitions from earlier sections):
An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. …
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:…
[7]b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or …
[7]e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks;
Nota bene: there is a very short list of things that a licensor can require
downstream licensees preserve. Logos, advertising, and similar are not on the list. Badgeware
is not a reasonable legal notice
.
Nextcloud has partnered with IONOS to fork Onlyoffice to create Euro-Office. To my knowledge, this codebase complies completely with the valid AGPLv3§7(e) requirement: Ascensio's trademarks have been scrubbed from the sources. However, since what Ascensio purports as a license term supplement pursant to AGPLv3§7(b) is actually a backdoor Further Restriction, Nextcloud and IONOS are completely within their rights (pursuant to AGPLv3§7¶4) to remove that further restriction.
As expected, Ascensio published an unfair, inaccurate, aggressive, and community-unfriendly response. I predicted long ago that adjudication of AGPLv3§7¶4 would require nerves of steel. This unwarranted denigration of an upstanding member of commercial FOSS community — Nextcloud — demands condemnation and Nextcloud deserves our thanks for confronting this bully.
As I did in the Neo4j case, I've told Nextcloud that I'm available as an expert witness if they end up in litigation with Ascensio. I hope, however, that Ascensio will realize their error, remove the further restriction themselves, and embrace the value of AGPLv3. Pure AGPLv3 was designed to faciliate web service business models. Our community would quickly and gladly embrace Onlyoffice, help its upstream development, and welcome them to the FOSS community. ∎
About the author: Bradley M. Kühn is a lifelong FOSS activist and has focused his career on FOSS licensing generally, and copyleft licensing in particular. Kühn invented the Affero clause in the original AGPLv1, and co-drafted AGPLv3§13.
Bradley is not a lawyer, SFC is not a law firm, and this article is not legal advice.
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.
[1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53