![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
tagged law
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 March 4, 2026
Earlier this week1, 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” 2, 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:
Furthermore, dicta 3 — 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))
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 writing4. 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)
[ As always, SFC is not a law firm, IANAL, and TINLA. ]
1 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.
2 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.
3 “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.
4 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.
by on January 26, 2026
We at Software Freedom Conservancy are disappointed at some surprising news. Two weeks ago (THU 2026-01-08), we had our original pretrial motions hearing scheduled in our historic impact litigation against Vizio. Just about an hour before the hearing's start-time, Judge Sandy Leal issued a minute order that rescheduled the hearing and (effectively) removed the trial (which was set to start on Monday 12 January 2025) from her calendar.
The rescheduled hearing date was Monday 2026-01-26 at 09:00. At 08:15 that morning, our attorneys were contacted from the Court Clerk that the hearing was again postponed..
We have been in this litigation against Vizio since October 2021. Vizio violated both the General Public License (GPL) and Lesser GPL Agreements. Vizio's “Smart” TV products include more than a dozen packages under these copyleft licenses, yet Vizio has continually failed to comply with these agreements in various ways — most notably (and including but not limited to) by (a) not providing complete, corresponding source code, (b) not providing “the scripts used to control compilation and installation of the executable[s]”, and (c) not providing object code necessary for relinking the LGPLv2.1'd works. We were looking forward to our days in Court that week to show the world all the details of Vizio's non-compliance, and to ask the Court to acknowledge (among other things) our right as a third-party beneficiary under the GPL Agreements to receive all the materials that those Agreements require Vizio to give to all consumers who purchase their devices. These devices, BTW, are called “Smart” TVs because what's inside is actually a small (but powerful) computer attached to the giant video display — driven and controlled largely by copylefted FOSS.
Notwithstanding our frustration, our trial was delayed for good reason. Another case — even older than ours — needed more time for their jury trial (and thus had priority over ours). While some criticize the USA for being “too litigious”, we at SFC believe firmly that the civil Courts are the best place where ordinary citizens and small, scrappy non-profit charities like SFC can seek justice when our rights are violated. We also know that there is more injustice in our country these days than anyone would like, and this delay occurred because there are other folks out there seeking justice on other important issues and rights, too.
We understand that we've been waiting for a long time in a very long queue in the California Courts, and while we (like everyone) get frustrated when the line is taking much longer than expected, we also appreciate that Judge Leal is carefully managing her docket to grant all parties an impartial opportunity for justice.
Attorneys for both SFC and Vizio are now negotiating with the Court for rescheduling. We hope the pretrial hearing will be scheduled fairly soon. We will update here and on the Fediverse as we know more.
We'll spend the next few weeks posting the various recent motions and filings in the case, and publishing some retrospective summaries of the last four and a half years of the case for you all to read.
Be sure subscribe to our feed in your RSS readers/aggregators and follow us on the Fediverse (via Mastodon or your preferred ActivityPub software). to receive updates!
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: