Dealing with Incomplete Copyleft Source That Doesn't Correspond

by Bradley M. Kühn 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):

• Redistribution of pure source code is always permitted.

  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.

• Running and deploying binaries — even those lacking CCS — on your own computer is always permitted.

  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.

• The Object Code and other non-source forms of the software that you receive are themselves licensed under the copyleft license.

  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 difficulty¹ 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 redistribute² 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.

---

Footnotes

¹ 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).

² 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.)

[permalink]

Tags: conservancy, GPL, law, licensing