Landmark Decision in Doe v. GitHub AI Court Battle

The Ninth Circuit’s decision this week in Doe v. GitHub, Inc., No. 24-7700 (9th Cir. Sept. 16, 2026) marks a milestone in the biggest pending case about AI coding, and a potentially big win for defendants in AI training cases.

The GitHub Copilot class action was one of the earliest AI cases, at the head of a wave that now includes over 50 pending cases. It was filed November 3, 2022 in the Northern District of California against GitHub, Microsoft, and OpenAI. The initial complaint alleged violations of the Digital Millennium Copyright Act (DMCA), breach of GitHub’s terms of service, unfair competition, fraud, unjust enrichment, and other claims, seeking damages exceeding $9 billion. Notably, it was not a copyright infringement action, though many observers have treated it as a proxy for a copyright infringement action, and it was followed by a spate of copyright cases alleging similar facts about AI training.

As the case progressed, the court considered several amended complaints and motions to dismiss. The court finally dismissed the DMCA claim, but because the ruling presented, in Judge Tigar’s words, “substantial ground for difference of opinion,” he certified it for interlocutory appeal to the Ninth Circuit under 28 U.S.C. § 1292(b). This is an unusual step where a specific issue is appealed while the case is still ongoing in trial court.

No DMCA Claim

On the appeal, Plaintiffs argued two theories for how Copilot violates the DMCA, 17 U.S.C. § 1202(b). Under the “input” theory, they argued that GitHub stripped that information when it used licensed code for Copilot’s training data. Under the “output” theory, they argued Copilot strips that information each time it produces code resembling a training example without the attribution that accompanied the original.

The Ninth Circuit panel did not reach the input theory. It held plaintiffs forfeited the argument by failing to assert it clearly in the district court.

The Ninth Circuit opinion stated:

At the hearing on defendants’ first motion to dismiss, the court asked whether the act of copying training data into Copilot
violated the attribution requirement of open-source licenses, and plaintiffs’ counsel answered, “Perhaps it doesn’t.” The court then observed that the “complaint is not about training. It just isn’t.”

This is somewhat ironic because other AI training claims have had the most success on the input aspects of training (as in Bartz v. Anthropic, where the award of damages was based on using input from pirate sites). However, an “input” claim based on training might be a stretch, given open source licenses freely grant use of the software for any purpose. GitHub elected to train its AI on material available under open source licenses, presumably because this was clear the input step under a license defense. The notice and source code sharing conditions of open source licenses are triggered only by re-distribution of the licensed code, not by the internal use that training would probably represent.

As to the output claim, essentially the plaintiffs lost on the merits. The Ninth Circuit opinion held that Section 1202(b) requires the removal or alteration of the copyright management information (CMI) attached to an existing copy of a work. It stated:

The statutory definition of CMI reinforces this reading. CMI is “information conveyed in connection with copies . . . of a work,” not in connection with excerpts or derivative works. 17 U.S.C. § 1202(c) (emphasis added).

The court did not go so far as affirming a so-called identicality requirement.

The district court and defendants characterize this principle as the DMCA’s “identicality” requirement. But “identicality” is something of a misnomer because the DMCA does not require literal identicality between the plaintiff’s work and the allegedly infringing work. The concept of “identicality” is best understood as a gloss on the statutory terms “remove,” “alter,” and “copies” rather than
an independent (and atextual) element of a section 1202(b) claim.

The court cited New York Times Co. v. Microsoft Corp., 777 F. Supp. 3d 283 (S.D.N.Y. 2025), saying that “Minor cosmetic changes will not necessarily
protect a defendant who substantially or entirely reproduces
the protected work and removes CMI.” But it nevertheless held that the plaintiff in the case at hand had failed to state a claim.

DMCA Versus Fair Use

When this case was filed, many observers were surprised that it was not a copyright infringement claim. Reading between the lines, there are two problems with bringing class action AI lawsuits as copyright claims. First, copyright claims require a copyright registration, and few software authors register their copyrights. This would have made shepherding a plaintiff class into cohesion difficult. Second, plaintiffs’ lawyers had strong incentives to find a theory that bypassed the fair use defense of copyright. Many commentators believe that AI training is fair use, and in fact, the DOJ recently filed a statement of interest to this effect in another, significant pending AI training case.

Fair use may be not only a doctrinal weakness, but a practical one. It is an extremely costly defense to litigate (such as Oracle America, Inc. v. Google LLC, 141 S. Ct. 1183 (2021), in which the legal fees reportedly reached over $100 million over a 10-year period). That made Section 1202(b) a tempting alternative vehicle for a class action. While the DMCA is part of the US copyright law, it is not a copyright infringement claim to which the fair use defense would apply. Also, its statutory damages run up to $25,000 per violation under 17 U.S.C. § 1203(c)(3). $25,000 is not enough for a single plaintiff to litigate, but with a large plaintiff class, those damages would add up. Class action counsel is always looking for cases with high-value aggregated damages. Interestingly, the DMCA seems to be rarely used for the purpose for which it was enacted–essentially large scale piracy of works like CDs and DVDs with copy protection.

The Ninth Circuit rejected the DMCA claim, saying, “We decline plaintiffs’ invitation to transform run-of-the-mill copyright-infringement claims into DMCA claims.”

DMCA is Out, but Other Claims Stay

The court reserved judgment on whether Copilot’s output, where it resembles code in the training corpus, could support an ordinary copyright infringement claim–though no such claim is before the court in this case. Indeed, other cases alleging infringing nature of the output of AI have not fared well.

The claim that using the code was a violation of open source license terms (i.e. a claim of breach of contract) remains pending before the district court. So while this decision does not resolve whether AI training or AI output infringes the copyrights in the underlying code–and it says nothing about the fair use question that will likely decide that issue more broadly–it likely forecloses the DMCA end-run around copyright infringement claims. Not all courts in the US are bound to follow the Ninth Circuit, but this opinion will likely carry significant weight even in jurisdictions where it is not precedential.

However, this decision does not solve the spate of litigaiton about AI training, by any means. Software code is not the same as more conventional works of authorship such as books, movies, or audio. Copyright infringement in software is a harder case to make for a plaintiff, due to the functional nature of software, and the tendency of coding to mix and match snippets of code. This causes copyright claims to run headlong into defenses of merger and idea/expression dichotomy limitations. But plaintiffs in AI cases for other kinds of works might still be eyeing this decision with dismay.

Training LLMs on Copyrighted Works Is Fair Use, Says the DOJ

On September 1, 2026, the U.S. Department of Justice filed a Statement of Interest in the consolidated copyright litigation against OpenAI and Microsoft that is pending before Judge Sidney Stein in the Southern District of New York. This multi-district litigation case combines the claims of the New York Times and other news-publishers with an Authors Guild class action.

The government’s position is that training a large language model on copyrightable text is most often fair use.

This filing is not a customary amicus brief. The DOJ exercised a right to participate based on 28 U.S.C. § 517, a statute that allows the federal government to appear in any court proceeding to represent the interests of the United States. The Statement of interest claims a US security interest in the case’s outcome: “Rules of law that make it significantly more difficult to develop a robust AI industry in the United States … threaten national security and give a competitive advantage to foreign adversaries who are not so encumbered.”

The Fair Use Argument

Those who have been following the 50+ ongoing cases on AI and copyright infringement will not be surprised at the DOJ’s argument. The brief separates the act of training AI models from the possibly infringing nature of their output in using the models–as have many of the cases on this topic. The Statement of Interest outlines the four statutory fair use factors and lands heavily on the side of the AI developers for training:

Transformative Purpose (factor one, usually). This has typically been the most important factor in recent fair use analysis. The DOJ describes training as transformative (citing Bartz v. Anthropic PBC, 787 F. Supp. 3d 1007, 1021 (N.D. Cal. 2025), which described it as “transformative–spectacularly so.”). This is because the model does not use the copied text for the purpose for which the text was created (informing or entertaining a reader). An AI model converts the text into statistical representations to learn patterns of language. The brief cites Google v. Oracle and the Second Circuit’s Authors Guild v. Google (the Google Books case) for the proposition that copying in service of a new technological function–search, indexing, or here, model training–can be transformative even in cases of extensive copying.

Market Effect (factor four). Plaintiffs in these cases have argued a “market dilution” theory: that even if no single output reproduces a protected work, a model trained on an author’s entire body of work can generate stylistically similar content that competes with, and dilutes the market for, that author’s work generally. DOJ calls this theory “deeply flawed” and specifically the criticizes Kadrey v. Meta Platforms‘ fourth-factor analysis for accepting a version of it. The DOJ’s argument is that training, by itself, does not make any protected expression available to the public, so there is no market substitution. Any harm for the outputs of AI, the DOJ argues, has to be assessed separately, under the Supreme Court’s recently enunciated Warhol framework. (“The same copying may be fair when used for one purpose but not another,” Andy Warhol Found. for the Visual Arts, Inc. v. Goldsmith, 598 U.S. 508, 533 (2023).)

Will This Filing Change Litigation Outcomes?

Statements of interest under § 517 may carry persuasive weight because they come from the government, but they are not binding, and judges are free to give them as much or as little deference as they choose. Techdirt and Above the Law both ran pieces recently arguing DOJ’s position is not disinterested because the Trump administration is reportedly negotiating an equity stake in OpenAI. But regardless of the brief’s ultimate influence on the outcome, the filing is a well-organized statement of the fair use argument for AI training, and therefore may be used as a playbook for other defendants, or for courts, to analyze the issue.

On the other hand, the political polarization of our country may mean that some judges will view the position of the brief negatively, merely because of its source–and the Trump administration’s track record of pushing the envelope on intervening in court process. But it is not clear this is a red versus blue issue. While the brief gravitates toward strong language about national security interests, its substance on fair use is probably what most intellectual property lawyers expect in the analysis of this issue.

The AMA Must Defend its Paywall on CPT Codes

On August 12, 2026, a legal action was filed, called PatientRightsAdvocate.org, Inc. v. American Medical Association (N.D. Ill.). Declaratory Judgment Action re: Copyrightability of CPT Codes. In my view, this case has deep public policy implications.

Once, many years ago, I helped a client in the health care software business negotiate a license for the use of Current Procedural Terminology (CPT) codes. I had never heard of CPT codes before that time. What I learned during that negotiation left me amazed and dismayed, and now, over a decade later, I am pleased to see that an advocacy organization has brought a legal action to remedy the situation.

PatientRightsAdvocate.org, Inc. (PRA), a nonprofit healthcare-transparency advocate, filed a declaratory judgment action to confirm that it may freely publish the CPT codes on its website without liability for copyright infringement. The case is a Declaratory Judgment (DJ) action–not asking for damages for a plaintiff as in a typical lawsuit, but asking the court to make a statement of the absence of liability, on behalf of the party filing the action (and is at risk as a defendant in a potential lawsuit). The DJ action has asked the court to confirm that (1) CPT is not copyrightable, (2) even if it is protected by copyright, posting it would be fair use, and (3) the AMA’s copyright, even if valid, is unenforceable due to copyright misuse.

CPT’s Liberation Matters To Everyone in the US

CPT is a set of five-digit codes and descriptions that the AMA has published since 1966 to classify medical procedures and services. The AMA revises CPT annually, asserting a new copyright in each annual revision, and sells access to it. The access fees are significant. A physical copy costs about $140, and end-user license agreements for electronic use (such as in software) require royalties on a per-user or per-member basis. For a moderately sized health technology business, this can run to hundreds of thousands, if not millions, of dollars. In 2025, the AMA reported $296.4 million in revenue from books and digital content, netting $267.5 million in profit–apparently largely from licensing CPT.

Consider that a moment: over a quarter of a billion a year for licensing codes. Nice work if you can get it, but no one should be able to get it.

The problem is that healthcare businesses are required by law to use CPT codes. In 1977, Congress directed the predecessor of the Centers for Medicare & Medicaid Services (CMS) to create a uniform medical procedure coding system, which led to the creation of CPT. According to the DJ action, a 1983 license agreement requires the government to adopt and use CPT for Medicare and Medicaid and to publicly endorse it, while the AMA controls the editorial panel that revises the codes. That means every medicare claim must be coded with CPT codes.

HHS regulations implementing HIPAA designate CPT as the mandatory code set for electronic healthcare billing transactions. 42 U.S.C. §1320d-2(c). According to the DJ action, at least 45 states also require the use of CPT via their own regulations, and at least 15 expressly incorporate it by reference into their administrative codes.

The AMA is primarily a lobbying organization. The AMA has donated between $1.6 million and $3.4 million in election cycles between 1990 and 2020. According to the logic in the DJ action, most of that money comes from licensing CPT codes.

The DJ Action’s Claims

PRA contends that because CPT has been hard-coded (pun intended) into federal and state law, and because CMS historically held a voting seat on the AMA’s CPT Editorial Panel, the CPT set falls outside copyright protection under the “government edicts” doctrine–under which the text of laws are not protected by copyright. This, in turn, is based on the idea that access to the text of the law should be available to everyone.

The AMA, for its part, has long defended CPT as its private intellectual property — including an amicus brief in ASTM v. UpCodes, Inc. (3d Cir. 2026) arguing incorporation into law does not defeat copyright and that posting such codes online is not fair use.

What is a CPT Code?

Here are some examples, so you can assess the copyrightibility of this work of authorship on your own. Remember that copyright law protects expression, not facts.

And by the way, my friendly AI refused to pull examples for me, because they are paywalled. So the following examples are not precisely CPT codes: they are HCPCS Level II codes. The distinction between CPT codes and HCPCS codes, however, is subject matter, not form. The CPT consists of codes for what physicians and clinicians do, and the HCPCS codes are codes for ancillary products and services (such as supplies, equipment, ambulance transport, and non-physician services). Together, the two make up the full HCPCS system CMS requires for Medicare and Medicaid billing.

  1. A0425 — Ground mileage, per statute mile
  2. A0428 — Ambulance service, basic life support, non-emergency transport (BLS)
  3. E0114 — Crutches, underarm, other than wood, adjustable or fixed, pair, with pads, tips and handgrips
  4. E1130 — Standard wheelchair, fixed full length arms, fixed or swing away detachable footrests
  5. G0008 — Administration of influenza virus vaccine
  6. J1885 — Injection, ketorolac tromethamine, per 15 mg
  7. Q0091 — Screening papanicolaou smear; obtaining, preparing and conveyance of cervical or vaginal smear to laboratory

Ah, the beauty and expressiveness of this work of authorship overwhelms me! What poet came up with “Administration of influenza virus vaccine”?

This is factual material and deserves no copyright protection at all. And to the extent it might, the fact that these codes are legally mandated for use–as factual material–should mean, as a matter of policy, there can be no liability for copying them.

Why This Matters

So to be clear: Your healthcare providers are required by the government to use CPT codes. They pay high royalties to the AMA to do so. The AMA uses that money to fund campaigns and gain influence with the government.

It’s time to end this vicious circle. Good luck to the plaintiff here.

IBM’s $5 Billion Bet on Open Source Security

Project Lightwell aims to become the security backbone of enterprise infrastructure

Open source software runs the world. It powers cloud platforms, AI frameworks, data pipelines, and enterprise applications that Fortune 500 companies depend on every day. For years, its security has been cobbled together largely by volunteer maintainers, community goodwill, and corporate donors via not-for-profit foundations. But problems with open source security persist: almost every week there is a news story finding new vulnerabilities and claiming open source project security is unsustainable.

IBM, whose business has benefitted hugely from open source tools like Linux, has just put $5 billion on the table to fix open source security, once and for all. On May 28, 2026, IBM and Red Hat announced Project Lightwell, a commitment to build an AI-powered security clearinghouse for open source code. The initiative pairs the use of cutting-edge AI tools with a team of more than 20,000 engineers to detect, validate, and patch vulnerabilities at an unprecedented scale.

The Problem: An Expanding Attack Surface

According to Black Duck’s 2026 Open Source Security and Risk Analysis, open source vulnerabilities embedded in enterprise applications surged 107% year over year, reaching an average of 581 vulnerabilities per codebase. Open source components now appear in 98% of audited applications. That’s not news, exactly–just confirmation of what we all knew, that open source is everywhere.

The same report found that 65% of surveyed organizations suffered a software supply chain attack in 2025 alone. And while it’s tempting to lay this at the door of open source, the fact is that open source vulnerabilities have burgeoned as the use of open source itself has become ubiquitous. So, it’s not open source licensing that is the problem; it’s the sustainability of underfunded open source projects.

The culprit is partly AI-assisted development. Code generation tools let developers ship faster, but they pull in open source dependencies at a rate that security teams cannot track. The traditional security model, built for a world where humans wrote code at human speed, is not keeping up.

The threat is not just theoretical. Kaspersky researchers found approximately 14,000 malicious packages in popular open source registries by the end of 2024, a 48% year-over-year increase. Sonatype’s figures for 2025 were even more alarming, detecting over 450,000 malicious packages in that year alone. These packages target developer credentials, CI/CD pipelines, and production servers.

The threat is also accelerating. Trend Micro’s 2026 security predictions note that a single flaw in an open-source package, inference engine, or third-party library can now cascade across industries, disrupting services and eroding trust at a scale that would have been impossible a few years ago.

The OpenSSF (Open Source Security Foundation) has also been sounding alarms. Its CTO, Christopher Robinson, predicted at the start of 2026 that a major AI-driven cyberattack on open source infrastructure is not a possibility but an inevitability. The combination of accelerating AI capabilities, financial incentives for attackers, and resource-constrained maintainers creates conditions where a major incident is statistically likely before the end of the year.

Project Lightwell

IBM and Red Hat are positioning Project Lightwell as a trusted enterprise clearinghouse: a centralized layer that sits between the open source ecosystem and the enterprise software supply chain. The clearinghouse uses AI to validate and test vulnerability fixes across an unprecedented volume of open source code, then delivers those fixes to enterprises through commercial subscriptions.

According to IBM’s official press release, enterprises using the clearinghouse will be able to do three things:

  • Report and resolve vulnerabilities by responsibly sharing sensitive security issues discovered in active software versions within a trusted intermediary framework.
  • Deploy validated patches optimized for production environments, spanning both Red Hat offerings and independent community code.
  • Coordinate upstream disclosures by sharing fixes upstream so that open source communities can include them in long-term maintenance.

The symbiosis is obvious. Enterprises get secure patches they can integrate directly into existing software supply chains with enterprise-grade validation and lifecycle management. IBM and Red Hat monetize the expertise they have built over decades in the open source world.

Early adopters of Project Lightwell include many top fintech companies, such as Bank of America, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, State Street, Visa, and Wells Fargo.

The initiative also addresses geopolitical concerns. According to IBM, Project Lightwell is specifically designed to reflect government priorities around securing digital infrastructure and critical systems, a nod to the increasing policy attention on software supply chain risk from regulators in the US and EU.

AI as Both Threat and Fix

Perhaps it’s ironic to use AI to defend against vulnerabilities that AI creates. But IBM is leaning into it.

Anthropic recently reported that its Mythos Preview model identified nearly 3,900 high- or critical-severity vulnerabilities in open source software alone. The same AI capabilities that let attackers find and exploit vulnerabilities faster can, in theory, let defenders patch them faster too. Project Lightwell’s bet is that IBM can deploy that capability at enterprise scale before attackers use it to cause widespread damage.

Cisco’s State of AI Security 2026 report describes this dynamic precisely: AI vulnerabilities and exploits conceptualized in research labs have already materialized in real-world attacks. Agentic AI systems introduce new risk surfaces, from prompt handling to inference servers to MCP integrations. The attack surface is not just growing, it is changing shape.

The open source dimension matters most for the growing general use of AI. Every major AI framework, from PyTorch to Hugging Face, is built on open source foundations. An enterprise deploying AI at scale is implicitly trusting thousands of open source packages it has never audited. Project Lightwell is designed to close that gap.

IBM’s Strategic Position

This is a strategic pivot for IBM, and the market has noticed, though not uniformly in a positive way. IBM’s software revenue hit $7.1 billion in Q1 2026, up 11.3% year over year, and retail investor sentiment around the stock has been described as extremely bullish. IBM also recently closed its acquisition of Confluent to strengthen data streaming for AI workloads. Still, the stock is down over 12% year to date, suggesting the market is still pricing in execution risk.

The $5 billion commitment is large enough to signal genuine intent–it rivals IBM’s entire annual R&D spend. Deploying it specifically on open source security is a bold strategic choice, one that positions IBM less as a product vendor and more as a trusted intermediary in the software supply chain.

That framing matters. Open Data Science noted that if open source layers remain vulnerable, enterprise AI adoption carries hidden operational risk. IBM is positioning itself as the party that removes that risk, at a price. It is a subscription-based trust model, and the companies best placed to pay for it are exactly the large enterprises already running Red Hat OpenShift and IBM’s hybrid cloud stack.

Unintended Consequences (Or Intended Ones)

Lurking within this effort may be a strategy to further cement Red Hat’s already dominant sales pipeline. A clearinghouse model routes enterprise use of open source through IBM and Red Hat’s validation and lifecycle management infrastructure, via commercial subscriptions. Companies that rely on those validated patches will become dependent on IBM’s blessing before deploying fixes.

The whole point of open source, though, is that no single company controls it. IBM is essentially saying “trust us to curate what’s safe,” which is philosophically at odds with the distributed, community-driven ethos that makes open source so attractive. That having been said, this may be a case where a gatekeeper is a necessary evil, or cyberattacks will cause open source users to flee the ecosystem in favor of proprietary solutions. Companies running Red Hat would naturally favor IBM’s validated packages. That could slowly tilt enterprise purchasing decisions in IBM’s direction in ways that go beyond security.

And open source has always been a gold mine for harbingers of doom. Black Duck, IBM and Red Hat profit more when enterprises are nervous about using open source. Whether this becomes a monopolistic chokepoint or a useful trust layer probably depends on how much of the work IBM does in the open, and whether other organizations can credibly participate in the market for open source solutions.

The Bottom Line

Open source security has always been a collective action problem. Everyone benefits from secure software infrastructure; few have the resources or incentives to pay for maintaining it. Project Lightwell is IBM’s attempt to turn a public good into a commercial service, using AI to do at scale what no army of human maintainers–no matter how well-intentioned–could do alone.

Whether it works depends on execution. The engineering resources are real, the AI tools are getting sharper, and the demand from enterprise security teams is not going away. The bigger question is whether IBM can deliver patched, validated, production-ready fixes fast enough to stay ahead of the attackers using the same AI tools on the other side. The counterbalancing question is whether the Linux ecosystem can truly remain vendor-independent.

Sources and Further Reading

IBM Newsroom — IBM and Red Hat Commit $5 Billion to Redefine the Future of Open Source in the AI Era (May 28, 2026)

Red Hat — Project Lightwell Press Release (May 28, 2026)

DevOps.com — AI-Fueled Development Pushes Open-Source Risk to Extremes: Black Duck OSSRA Report (Feb 2026)

Techzine — Why open source faces its biggest security threat in 2026 (May 2026)

Help Net Security — IBM and Red Hat are betting $5 billion that open source needs a security guard (May 28, 2026)

Kaspersky — Risks emerging when developing or using open-source software (2026)

Trend Micro — The AI-fication of Cyberthreats: Security Predictions for 2026

Cisco — State of AI Security 2026 Report (Feb 2026)

Open Data Science — IBM And Red Hat Launch Project Lightwell To Secure Open Source AI Infrastructure (May 28, 2026)

Yahoo Finance / StockTwits — IBM Wants To Become The ‘Security Layer’ For Open Source AI Infrastructure (May 28, 2026)

Announcing COSSmology – the definitive source for COSS business data

Over the last two decades of advising commercial open source (COSS) companies, I’ve seen the ecosystem mature from a handful of pioneers into a foundational pillar of the modern software industry.

When I wrote From Project to Profit, my goal was to provide founders with a handbook for navigating that journey.

But as the COSS model has exploded in popularity, I realized something was missing: a comprehensive map of the ecosystem itself. Investors, founders, and developers were all operating without a centralized source of truth.

Today, I am thrilled to announce that Chinstrap Community is changing that.

We are launching Cossmology — the definitive directory of the COSS universe. We have cataloged over 1,000 commercial open source companies, complete with structured data on their key people, core OSS projects, funding history, and the latest news headlines.

We’re also launching COSS Weekly — a free newsletter that delivers the most important COSS news, funding announcements, and new startups directly to your inbox every week. If you want to stay current on the companies and trends shaping the future of open source software, this is the easiest way to do it.

Explore the directory and subscribe to COSS Weekly at https://cossmology.com. We’ve also mirrored the data on GitHub: https://github.com/Chinstrap-Community/Awesome-OSS-Companies.

A huge thank you to my co-founder Sabir Ibrahim for architecting the platform that makes this possible.

Patent Trolls in the Grocery Aisle: Aldi Takes on Intellectual Ventures

In April 2026, Aldi Inc., the no-frills German discount grocer beloved by bargain hunters across America, filed a preemptive declaratory judgment lawsuit against Intellectual Ventures (IV). (That link may be paywalled, so here is the docket information: Case 1:26-cv-00461-UNA, filed 4/21/26 in the District Court for Delaware.) This is not the first “man bites shark” case against a patent troll, and not even the first in the open source software landscape, but it’s an interesting data point in a trend.

Revenue-Based Targeting

According to Aldi’s DJ action, IV’s patent assertions accuse Aldi’s use of “common, third-party, open-source software platforms” like Docker, Kubernetes, Apache Kafka, and Apache Spark. In its filing, Aldi alleges that “IV’s monetization model is not tied to any good-faith infringement analysis,” because IV has made no defendant-specific assessment of actual infringement prior to threatening patent lawsuits. Instead, the complaint characterizes IV’s campaign as targeting companies based merely on their market presence and revenue.

Patent-Trolling and the Open Source Problem

Intellectual Ventures was founded in 2000 and is now one of the largest patent portfolio holders in the United States. Its business model of buying patents, aggregating them, and licensing them under the threat of litigation, has earned it the questionable accolade of “patent troll public enemy #1” (from IPWatchdog). IV has always contested this kind of characterization, positioning itself as a defender of individual inventors. (As all patent trolls do.) And it is true that the original model of IV was less troll-like, because its early activities included funding of innovation as opposed to mere monetization of the innovation of others via patent acquisition. But over the years it has matured into a quintessential patent trolling business.

The collision between software patents and open source licensing has been a long, deep, but slow-motion war. Richard Stallman wrote in GPLv2 in 1991 that “any free program is threatened constantly by software patents.” Decades later, the threat still exists, but it has not taken the form that the free software community expected. Operating entities almost never bring patent lawsuits accusing open source software (setting aside the opening salvos in the Oracle v. Google war). This is because asserting patents against open source users is spectacularly unpopular, and any operating entity that does so risks a huge blow to its business reputation.

However, patent trolls have no business reputation to lose. So today, patent lawsuits targeting open source software are effectively limited to patent trolls. The threat to open source is exacerbated by the fact that open source software usually has no vendor with a duty to defend patent claims, so it is usually left to the users–particularly large users–to mount their own defense.

The Declaratory Judgment Gambit

Aldi’s decision to file a DJ action rather than wait to be sued is part of a broader trend. DJ actions are lawsuits brought by potential defendants who have been threatened with legal action, asking the court to declare there is no basis for the lawsuit.

Patent trolls come in all shapes and sizes. IV and Sound View are two of the more professional examples, but there are thousands of single-purpose trolling entities that use scattershot claims, bargain-basement counsel, and generally low-quality advocacy to bring nuisance claims and see what they can monetize. The trolls usually buy patents from failed companies, so they have no relation to the innovation–real or rhetorical–that formed the basis of the patent. Their scattershot approach to trolling has given defendants–who often have access to better advocacy–the opportunity to flip the script, and they have done so in various ways.

A DJ action is one anti-trolling tactic, and it is neither new, nor specific to open source related claims. In early April 2026, for example, three major insurance companies–The Hartford, Travelers, and Hanover–filed their own coordinated declaratory judgment complaints against IV. The Hartford’s complaint described how IV had been reaching out since late 2023, slowly escalating pressure that culminated in a $3.5 million licensing demand.

The choice of Delaware for these DJ cases is worth noting. Delaware courts would have venue over many large corporate defendants due to Delaware being the go-to domicile for corporations (other than Tesla, of course). Delaware is the third most popular patent litigation venue in the US, but that may simply be because so many companies are domiciled there, rather than it being a “rocket docket” for patent trolling. The Eastern District of Texas leads patent infringement cases with about 28% of cases filed in 2025, followed by the Western District of Texas at around 12%. Delaware sits at roughly 11%. For defendants, claiming venue with a DJ action in Delaware may be a strategy to avoid the Texas Two-Step of patent dockets.

Anti-Trolling Laws and Claims

But DJ actions are not the only recourse. Victims of patent trolls have taken the offensive in other, creative ways. Unfortunately, many of these strategies are expensive and difficult to execute. The main hurdle is the Noerr-Pennington doctrine, a First Amendment-based immunity doctrine that protects parties from antitrust liability for petitioning the government, including by filing lawsuits. This plaintiff-favorable doctrine extends to non-antitrust claims as well, though its exact scope is quite complex. But the upshot is that anti-trolling lawsuits by defendants based on claims like racketeering can easily fail. (See, for example, Cisco Systems, Motorola Solutions, and Netgear v. Innovatio (N.D. Ill. 2013), in which three major WLAN manufacturers filed a 55-count complaint against patent troll Innovatio alleging its patent assertion campaign was, inter alia, a violation of RICO, but the case was dismissed.)

Possibly as a response to this doctrine, many states have specific laws against bad faith patent assertion. Vermont passed the first such law in 2013, the Bad Faith Assertion of Patent Infringements, 9 Vt. Stat. Ann. §§ 4195–4199 (2013). The Vermont statute includes a list of factors to determine what constitutes bad-faith patent assertion, including sending assertion letters that fail to identify the patent at issue, the owner, or exactly how the target’s product infringes the patent; demanding an unreasonably fast response or unreasonably large license fees; and making false or deceptive statements. Fast forward to today, and over 30 states have such laws, including Wisconsin, Oregon, Washington, and Illinois. These state laws allow for claims brought by the state Attorney General, or by the defendants being pursued by the trolls, or both.

One of the most interesting pending cases in this area is Micron Technology v. Longhorn IP, which is testing the line of demarcation between federal patent claims and state anti-trolling laws. Patent law is entirely federal law, and patent cases are heard exclusively in federal court. So there are unresolved questions about whether the state anti-trolling actions are preempted by federal law. The Federal Circuit on December 18, 2025 dismissed Longhorn’s appeal for lack of jurisdiction, leaving this constitutional question unresolved. But it seems likely that states will continue to advance anti-trolling statutes–well, other than Texas, for which patent trolling remains a healthy (but IMO, shameful) cottage industry.

Good Luck, Aldi

Unfortunately, there is no Aldi around me–the chain is notably absent from the SF Bay area. But I am sure many of us in the tech world still wish it success against IV, in no small part because the universe of companies that use Docker, Kubernetes, Apache Kafka, or Apache Spark is just about all companies.

The Chardet Controversy: Open Source and the AI Clean Room

In early March 2026, a dispute broke out over a Python library that most developers use every day. Chardet, a character encoding detection tool that powers a large portion of the Python ecosystem, became the unlikely center of a licensing debate. At its core, the controversy asks: can an AI rewrite of copyleft-licensed software be legally released under a more permissive license?

A Library, a License, and Lags

Chardet was created by Mark Pilgrim in 2006 and released under the GNU Lesser General Public License (LGPL). The project was a port of a Mozilla’s universal charset detection library. Then, in 2011, Pilgrim’s various online projects began returning 410 errors. A 410 status code (Gone), unlike a 404 (Not Found), a signals that a resource has been permanently removed. Then he deleted his social media accounts, apparently unplugging from the online world entirely. After this, various maintainers stepped in, most notably Dan Blanchard, who has been maintaining Chardet for over a decade.

Chardet is a very popular, basic library for Python, but due to licensing issues, it is not an official Python standard library. Being in the standard library means the library ships with every Python installation, and is implicitly endorsed by the Python core team as the canonical solution to a problem. According to Python policy, inclusion in the Python standard library requires permissive licensing, in order to maximize integration possibilities.

If your code is going to end up in Python or the standard library, the PSF will require you to: License your code under an acceptable open source license. These currently include only the Academic Free License 2.1 … and the Apache License 2.0…. https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq

Of the two choices, the Apache license is much more common, and the likely choice.

This made Chardet’s LGPL terms an obstacle to the goal of getting Chardet accepted into Python’s standard libraries. In 2015, Chardet was considered for inclusion in the Python standard library, but the effort died because the LGPL license turned out to be a gating item.

Blanchard wanted to fix that, and also address some performance problems with the library. But his efforts to do so encountered some serious backlash.

The Rewrite and the Relicensing

On March 2, 2026, Blanchard released Chardet 7.0.0–a “ground-up, MIT-licensed rewrite” with the same package name and the same public API as prior versions of Chardet. The rewrite was apparently a success, with huge increase in speed. Blanchard’s detailed notes on how he accomplished the rewrite are here. These notes are both thoughtful and transparent. To show that he had not copied the code, Blanchard provided the results of a plagiarism-detection analysis showing that version 7.0.0 shared less than 1.3% structural similarity with any prior release, suggesting that nothing protectable from the old codebase had been retained.

Just two days after the release, however, Pilgrim suddenly resurfaced. He opened GitHub issue #327, entitled “No right to relicense this project,” identifying himself as the original author and calling for licensing under LGPL.

“Their claim that it is a ‘complete rewrite’ is irrelevant, since they had ample exposure to the originally licensed code (i.e. this is not a ‘clean room’ implementation). Adding a fancy code generator into the mix does not somehow grant them any additional rights.” GitHub

Legal and Community Questions

The issue on GitHub quickly escalated into a controversy. In typical open source fashion, what followed was a war of words among many commentators, who–shall we say–did not engage in the tenor of analysis favored by those who actually know the law.

The best practices for a clean-room development to manage copyright issues requires a separation between two teams of developers: one that creates the specifications and another that writes the reimplementation. The reimplementation developers are blocked from access to the original source code, creating a “clean” environment.

Blanchard, however, had spent over a decade maintaining Chardet’s codebase. His knowledge of the library could not be cleansed. This is an issue endemic to all open source reimplementation projects: there is no way to completely insulate any developer of exposure to public code. In this case, the issue applied in spades.

Nevertheless, using AI to perform clean room development can help manage this issue by interposing a neutral actor–the AI–between the reimplementation developer and the specification developer.

Richard Fontana, an expert on open source licensing, commented that he saw no current basis for concluding that Chardet 7.0.0 was required to be released under the LGPL, noting that no one had identified copyrightable material from earlier versions in the new code. This is probably the right legal analysis with respect to copyright. Still, the controversy raged on, probably because it was only partly about copyright and also about open source community expectations.

Blanchard later switched the license from MIT to 0BSD (a permissive license with no notice requirement) in an attempt to deflect the question of whether AI-generated code is copyrightable in the first place. As a side note, neither MIT nor 0BSD seem to be expressly approved by PSF for standard libraries in the FAQ quoted above, though it would make sense if such permissive licenses posed no hurdle to adoption. But all of this is a red herring for the infringement issue surfaced by Pilgrim.

Takeaways

The Malus Question. What makes this controversy significant is the larger question of AI-assisted clean room rewrites. The same technique could theoretically be applied to any open source project: feed a copyleft-licensed codebase to an LLM, ask it to rewrite the functionality, and publish under a permissive license. Open source advocates point out that if such a technique is legal, the entire copyleft model has begun to disintegrate. That’s an interesting question, and if you want to read more about it, you should read my post about MALUS, the not-quite-April-Fool’s-joke posted recently about using clean room implementations to avoid copyleft. Spoiler: I agree that copyleft is moribund, but I think it’s demise has been a slow, lingering malaise rather than a sudden death.

Clean Room is Rarely a Real Solution. Moreover, in my view, a clean room development undertaken solely to avoid copyleft will usually create a lot of technical debt. Engineering around copyleft effectively creates a fork to the project. Whether that fork is free of the copyright burden of the original is one question. The bigger question is whether anyone will trust a fork enough to use it. And everyone knows that maintaining a fork is almost always more expensive and difficult than complying with open source licenses. However, compared to the average clean room effort, the reasons for the Chardet rewrite were more complex: avoiding a stringent licensing policy and improving performance.

Naming Issues. There is one aspect of the Chardet controversy that most people miss.

That’s the mistake – not the rewrite, not the AI. Not even the license change in isolation. The mistake is claiming your code is “an independent work, not a derivative” while simultaneously shipping it as the next version of the thing you say it’s independent from. –https://shiftmag.dev/license-laundering-and-the-death-of-clean-room-8528/

A key issue here was that the clean room reimplementation used the same project name and API, which could cause confusion with the prior version. Although this may have been a strategic misstep, perhaps we should cut Blanchard some slack for the many years he put into maintaining the project. Naming conventions in open source are usually considered trademark issues. Trademark is, in turn, about the source, nature and quality of products. What constituted Chardet in 2026 may be as much Blanchard’s doing as anyone else’s, so perhaps he effectively controls the name. Other than that, this clean room effort is one of the more conscientious ones I have seen.

The Great Open Source Wealth Transfer. This controversy also raises the familiar (but largely unaddressed) issue of what happens when the original authors of open source code–or their heirs–start to exert what the law calls “dead hand control” over their intellectual property. There is a tension between the right to enforce licenses based on old copyright interests, on one hand, and the need to keep projects useful, secure, and up-to-date, on the other. The truth is that copyright duration–which is largely dictated by the lobbying of the media industry–is just too long for the world of software. As the first generation of open source developers goes to software heaven, goes “410” or just hands the baton to other maintainers, their interests diverge from the community of active users. And worst of all, as they die, their copyright interests will pass to their heirs–who might well have apathy, or even antipathy, for the open source community. Today, we stand at the brink of a “great wealth transfer” of copyright interests from this Boomer generation, and we have not done enough to address it. This dispute, between an ostensibly retired developer and a current maintainer, is a portent of things to come.

The Schisms of Open/Libre/Only Office

A governance crisis at LibreOffice and a licensing war over OnlyOffice have resulted in the biggest threat to open source office software since Oracle nearly killed the whole Open Office project back in the early 2010s.

The open source office software world rarely makes headlines. Spreadsheets and word processors are the workhorses of desk work–useful and unglamorous. They tend to walk a fine line between feature bloat and obsolescence, and none of them are very beloved. But recently, this quiet world erupted into two simultaneous forking upheavals, each with implications for open source governance and corporate stewardship over community software.

StarOffice to OpenOffice

The story begins in Germany in 1985, when Star Division developed a proprietary suite called StarOffice. In 1999, Sun Microsystems acquired it for $59.5 million–reportedly because it was cheaper than licensing Microsoft Office for Sun’s thousands of employees.

(Think about that for a moment: the cost of buying an entire company was less than an enterprise license from Microsoft for off-the-shelf software.)

Sun then made a fateful decision: on July 19, 2000, at the O’Reilly Open Source Convention, it announced it would release the software as an open source project. OpenOffice.org 1.0 shipped on May 1, 2002 and quickly became the free alternative to Microsoft Office across most Linux distributions of the time.

This start was rocky, though. The original OpenOffice was functional but had real problems: sluggish startup times (the infamous “splash screen wait”), a bloated memory footprint, inconsistent Microsoft format compatibility, and an awkward user interface.

When Oracle acquired Sun in January 2010, matters deteriorated rapidly. Oracle slashed its developer headcount, and by September 2010 the community was foundering. The project was given over to The Document Foundation, which launched the re-branded LibreOffice in January, 2011. Every major Linux distribution adopted it almost immediately.

The project also gained renewed interest as its quality improved. TDF cleared out a large backlog of patches that had been sitting unmerged for years,
and started an aggressive cleanup of the codebase. After a while, the product became more useable and stable.

The Document Foundation Turns on its Own Builders

LibreOffice’s main support at the time was Collabora Productivity, a UK-based company whose developers accounted for roughly 80% of all commits to the LibreOffice codebase. But this relationship was always uneasy, because Collabora both contributed to the free suite and sold a commercial version of their own.

Enter geopolitics: LibreOffice became a darling of open source-focused European governmental groups: users in Germany, Italy and Denmark adopted LibreOffice as part of a transition away from Microsoft. While this was outwardly touted as a move toward open source, it was just as much an attempt to elude the hegemony of US software interests.

Then the uneasy partnership between LibreOffice and Collabora fractured in spectacular fashion at the end of March 2026. TDF’s Membership Committee ejected over 43 contributors who were Collabora staff and partners, citing a newly approved bylaw barring contributions from employees of companies involved in legal disputes with the foundation. The expelled contributors included seven of LibreOffice’s ten most prolific committers, including Michael Meeks, Collabora’s general manager for the project and one of LibreOffice’s original architects. But this was apparently only the divorce after a long and tempestuous marriage; according to Collabora, several of TDF’s own founders had already quietly departed membership in the preceding years.

Then, in a public statement, Michael Meeks announced plans to launch a new Collabora Office product built from a cleaner codebase. The company did not formally create a fork, but its intention to supplant LibreOffice was clear: “We seem to be back where we were fifteen years ago,” Meeks wrote. OSNews summarized it bluntly: “The end result seems to be that Collabora is effectively forking LibreOffice.” Government IT departments across Europe then faced a choice between a foundation-stewarded codebase with little momentum, and a corporate fork. That put them, in a way, back to their original dilemma of being reliant on a foreign corporate steward.

Euro-Office and the OnlyOffice Drama

At the same time, another forking drama was unfolding in the world of OnlyOffice, a web-based office suite developed in Russia by Ascensio System and licensed under the GNU Affero General Public License (AGPL). This product is “dual-licensed,” with the vendor offering alternative commercial licenses. OnlyOffice was not based on LibreOffice, but was widely considered its most competitive substitute. In late March 2026, Nextcloud and the German cloud provider IONOS announced Euro-Office: a fork of OnlyOffice touted as a European-controlled alternative to both Microsoft 365 and OnlyOffice. The project’s rationale was explicit–OnlyOffice’s development is centered in Russia, and European organizations increasingly viewed that as a geopolitical risk.

OnlyOffice did not react well to the fork. The company suspended its eight-year partnership with Nextcloud, alleging that Euro-Office violated the AGPL by stripping required attribution,* branding, and logos from the code– additions OnlyOffice appended to the standard AGPL terms. The company also accused Nextcloud of attempting to poach its employees.

The Deeper Pattern

Both crises expose the same underlying fault line: what happens when the entity that governs an open source software parts ways with the people who actually build it? With LibreOffice, The Document Foundation holds the trademark and the governance apparatus, but Collabora holds the engineering talent. With Euro-Office, Nextcloud holds the distribution channel and the political narrative; OnlyOffice holds the code and the licensing leverage. In neither case does the formal authority align with the practical power.

Open source governance has always struggled with this tension. The Apache OpenOffice story, after all, ended with a foundation holding a brand nobody wanted to develop. The risk now is that LibreOffice, the suite on which European governments bet millions in anti-Microsoft savings, had fractured at the worst possible moment: just as those governments, struggling with economic woes, need it most.

This illustrates that neither corporate control nor non-profit control are panaceas for the challenge of open source sustainability and community cohesion. Good governance requires resources, but also commitment, and when either fails, projects suffer.

*The AGPL violation question is interesting, but beyond the scope of this post.

“Malus”: Is Copyleft Dead?

I can’t tell you how many times I have heard people predict the death of open source software over the years. Each time some new tech trend arrives–crypto, source available licensing, SaaS–people predict the death of open source. Lately, people have been predicting the death of open source because of AI code generation, and while some of the facts they cite are undeniable, their conclusions are not supportable.

This week, many people sent me the link to the Malus “Clean Room as a Service” announcement. I don’t think I’ve ever had so many people send me a single link. Now, this website is fake, but you have to wade into it a bit to figure that out. No real company would be foolish enough to represent anything as “legally distinct,” for example. The name “Malus” suggests a bad actor, and I guess it’s a pun on Manus, a popular AI agent. So, it seems site is a troll.

(And to the trademark lawyers: Gentlemen, start your engines.)

The Malus post says:

Finally, liberation from open source license obligations. Our proprietary AI robots independently recreate any open source project from scratch. The result? Legally distinct code with corporate-friendly licensing. No attribution. No copyleft. No problems.

The implication is clear: AI coding agents are bad actors that are killing free software.

I wrote about the AI use case of clean room development nearly a year ago. I didn’t cast it as a catastrophic prediction of the death of open source, so no one got excited. But it’s interesting to look beyond the political theater and analyze what is really going on here.

Copyleft Has Died Many Deaths

There are two kinds of open source licenses–the permissive and the copyleft. Permissive licenses don’t require you to do much, so nobody would ever bother re-engineering software that is available under a permissive license. Ergo, the Malus website is about copyleft. Copyleft licenses require you to share source code when you share binaries. Copyleft licenses like GPL were the original free software licenses, and were extremely popular in the early days of the free software movement.

The death of copyleft has been predicted for a long time, and in fact it is already dying. Copyleft as a licensing paradigm has been experiencing a steady decline over the past two decades. This is because of licensor choice, not an international conspiracy to kill copyleft. Over time, more and more software has been released under permissive licenses instead. The software under permissive licenses has become more and more important in computing. All that happened long before the advent of AI coding.

Why did it happen? In a way, copyleft became a victim of its own success. Back in the late 1990s, copyleft was a catalyst. The only way to get large organizations to collaborate on developing software was by forcing them to do so with a legal mechanism. That mechanism was GPL. It compelled them to share their source code, under threat of copyright infringement lawsuits. Before the early 2000s, large technology organizations would never have voluntarily shared their improvements, rather than keeping their improvements secret and proprietary. But over time, technology companies learned the value of collaboration. As developers decided to voluntarily share their improvements over time, the legal threat of GPL became an artifact.

The truth, I think, is that we’ve been living in a post-copyleft world for quite a while. Copyleft licenses are expensive and difficult to enforce, and in fact are rarely enforced. Almost all enforcement in the open source world is done via moral suasion and education about the benefits of collaboration.

“We view legal action as a last resort, to be initiated only when other community efforts have failed to resolve the problem.”–From the Linux kernel enforcement statement, which was signed by over 100 major kernel contributors.

Overall, voluntary collaboration has worked extraordinarily well; open source software is ubiquitous. Proprietary software, in this sense, is like cigarettes. In the 1960s, smokers were everywhere and smoking was cool. Now, smoking is considered trashy. That was a huge shift in attitude. And yes, there were laws that supported that change: workplaces and public buildings became non-smoking. But that wasn’t what make the change so successful. It was a collective realization that smoking was a really bad idea.

Similarly, there was a flurry of enforcement of GPL in the 1990s and early 2000s, but then it tailed off. Simultaneously, the Linux Foundation grew into a $300 million-a-year organization, with all the world’s biggest companies supporting collaborative development. We are now so accustomed to that “new normal” that we have have forgotten what a sea change it represents. That sea change didn’t happen because these companies feared the legal might of GPL. It happened because they figured out that it made more sense to collaborate on infrastructure than to individually re-invent the wheel.

Some free software advocates argue there’s a great deal of noncompliance for copyleft licenses. That’s true, but that doesn’t mean open source is not working. It just means it’s not working perfectly–and nothing works perfectly. In fact, today, compliance with open source licenses is better than it ever has been. It took many years for the culture of compliance to permeate the industry. It did so because open source devotees grew their ranks in private industry, and because license compliance goes hand-in-hand with security management. Meanwhile, the killer app for copyleft, the Linux kernel, is extraordinarily successful–to the point that it has eclipsed all other operating systems. And open source now runs everything.

Don’t Embarrass Yourself by Celebrating the Opportunity to Fork

The Manus hoax imagines developers celebrating their freedom from open source license requirements. Let’s take an extreme case for illustrative purposes. Imagine a fictional developer who is faced with the task of developing an operating system for an embedded system. Most developers would start with the Linux kernel. It’s freely available, it’s high-quality, and there are lots of engineers in the talent pool who are familiar with it. That reduces the developer’s cost in important ways. Easier recruiting. Less debugging. Community support. Better security.

But it’s licensed under GPL, and GPL has requirements.

Now, suppose this developer decides that it needs to keep its customizations proprietary–which would violate GPL. So it does a clean room implementation of the Linux kernel using an AI coding tool. Would that be a good idea?

Seriously?

That would be a terrible idea. Once you reimplement in order to avoid the license, you have essentially created your own fork of the project. Everyone knows it’s a terrible idea to create custom forks of open source projects. Your maintenance cost increase. Your security costs increase. Your talent recruitment and training costs increase. You have earned yourself a mountain of technical debt. The Linux Foundation recently released a timely report estimating the technical debt for maintaining private forks to “an average of 5,160 labor hours, or $258,000, per release cycle.” That’s a lot of expense.

Only ignorant and sub-optimizing tech managers–or maybe tech investors–would think it’s a good idea to incur those kind of costs in order to “protect” their IP. These are the same people who sit in board meetings parroting fears about IP value instead of figuring out how to build good products. They have the mindset of patent trolls, not innovators. No self-respecting developer would fall for this thinking error.

Copyleft is not dead–at least, no deader than it already was. Forking projects is too costly, and complying with open source licenses is too easy. Yes, there will be scofflaws and there will be those who want to re-invent the wheel in order to hold onto their perceived IP advantage, but they can travel their own path, and see their businesses struggle as a result. The rest of us will be whistling as we keep traveling on on the open source road.

What Truly Dies Without Copyleft?

There is one thing that truly is threatened by the putative death of copyleft, and that is the pure dual licensing business model.

Dual licensing, which was pioneered by MySQL in the 1990s, is a business model where you release something under GPL, then sell alternative licenses to those who can’t comply. In the open source world, this is sometimes referred to as selling exceptions. It only works when the project steward has the right to choose alternative licenses, either because it owns all the copyright in the project, or uses contribution licenses to clear rights in outside contributions.

In fact, true dual licensing has become quite rare in the last decade. Almost all businesses today that use the threat of GPL enforcement are owned by private equity, and the others who build businesses around open source have morphed into open core models. Open core provides a core of open source software for free, then sells enterprise features like compliance certifications, collaboration features, managed SaaS, or SSO. And almost all these businesses use permissive licenses, not copyleft licenses. So, the death of copyleft is not even a blip to them.

A Post Copyright/left World

Taking the long view, AI coding might mean that we are in a post-copyright world. But copyright was always an awkward fit for software. Copyright protects expression, not function, and the value of software is that it is functional, not beautiful.

It was always possible to clean-room software to avoid its copyright. It just used to be labor-intensive, and now it’s not. But I invite you to consider that this is not such a bad thing. Software now needs to prove its value proposition the way other products do, rather than via threats of IP infringement.

And the threats have been a drag on software development. The last few decades have seen developers spend millions of dollars on open source compliance, down to the level of trying to ferret out 5-line snippets from Stack Overflow in their code. Who really benefitted from that, other than Black Duck? The Malus site says that companies doing development “spend millions on software composition analysis tools like Snyk and Black Duck.”–and that is entirely true. This is what the legal threat of copyleft bought us: decades of unnecessary remediation and negotiating draconian open source terms in deals to allocate the risk for a specter of copyleft enforcement.

This waste of energy came from over-emphasis on threats of enforcement, which, over the years, came to be a goal itself, instead of a way to educate developers on the benefits of collaboration. Over time, the free software community seemed to convince itself that GPL as a legal weapon is the goal of free software, not just a tool to support open development models. Proprietary software developers and free software advocates alike have sown Fear, Uncertainty and Doubt (FUD), and derailed what should have been the lesson of the open source movement: that collaboration produces better code.

People love open source software not because it’s free, but because it is open. That openness brings all sorts of benefits. Fear of lawsuits has skewed the discussion toward the cost of acquisition: Is it better to buy proprietary software or incur the cost of GPL compliance? But the much more interesting conversation is about the benefits, and the benefits of open source software have proven themselves, so repeatedly and decisively that they hardly bear explaining anymore.

Death, or Afterlife?

I find it curious that people seem to enjoy constantly predicting the death of all good things. Anyone who reads the news today can’t help but be appalled by the predictions of apocalypse that bombard us at every turn, all to garner clicks and views and waste our day with doomscrolling. It’s a shame that so much of our society today is about generating fear via misinformation. It’s also a danger, because focusing on doom derails the conversation from the right focus–like how can AI help generate and refine software so we can do more and better things with it. We will accomplish nothing with visions of HAL 9000 dancing in our heads.

It is not so easy to kill something like open source. Free and open paradigms are self-actuating. The invisible hand of the market makes them so. Too many people benefit from these paradigms to let them die, and humans are very clever at protecting what works for them.

Copyleft will survive, to the extent it deserves to survive, and open source is stronger than ever.

The Great Subscription Pivot of January 2026

Every new year is an opportunity to reassess our priorities. This January, I took a hard look at my monthly software subscriptions. They say that the defining characteristic of Baby Boomers is a dozen paid-for but unused app subscriptions. I always like to play against type, and so I’m pretty good at cancelling them, but it still surprised me how much things had changed in only one year.

Goodbye Receipt Platform, Hello Claude

This was the easiest cut to make. Every January, my thoughts turn to doing my taxes, and that involves gathering a lot of information. Being self-employed is great, but it makes doing one’s taxes a slog. I long ago figured out that I should have a dedicated credit card for business (preferably one with a nice, high fee that I can deduct), but it’s not always possible to use that card, and only that card, for business expenses. So, I dutifully make scans of my receipts. Last year, I found a dedicated receipt tracking platform, and I was happy that it scanned and categorized receipts for me. I got a year’s subscription, in anticipation of this year’s tax homework.

But this year I did an experiment, and sent copies of receipts to Claude, asking it to extract the information, and organize it into a spreadsheet that I can sort by date and vendor. It did a great job.

The receipt platform cost me $6/month. That may not sound like much, but Claude does it better for free (or as part of my Claude Pro subscription, which I was already using for a boatload of other things).

Ingesting my receipts on Claude did have a glitch: I hit my compute limit. But I solved that by waiting a few hours and then changing my prompts to eliminate unnecessary aspects of the output, like categorization, which cost extra compute cycles.

My only regret is that I am now getting less use out of my beloved Keychron number pad, which I customized with colored keycaps, and for which I have a deep and abiding attachment. 

Adobe’s Value Proposition Failed

This is another specialized software suite that got gobbled up by the general LLMs. I’ve been a relatively happy customer of Adobe for a while, but by the end of last year, as my needs changed, the main thing driving my Creative Cloud subscription was Firefly. For quite a while, it was the best-of-breed image generator. But it got blown out of the water by Gemini in the last few months.

I mostly use image generation for slide decks, or articles like this one. So, for an upcoming talk, I asked Gemini and Firefly to produce an image for “the marriage of open source and AI” depicting a penguin marrying a robot.

[Apologies for this, but the Adobe image, which I originally posted here, disappeared somehow.] The Adobe one was not awful, but it had some creepy elements. What is up with the dolphin? Are those a regular sight at weddings these days? “Open hearts & source code” not only contains a misused ampersand, it sounds like a bad translation on a Japanese T-Shirt. The bride looks so miserable she might be the victim of wife stealing, and her dress is slit up to her non-existent private parts.

The Gemini image got the message across, without out any extraneous dolphins or wardrobe malfunctions.

I cancelled my Adobe subscription the next day.

Microsoft Office Is Now Google Workspace!

Just kidding! Both Google and Microsoft are notorious for rebranding, but this was a sea change in requirements, not names.

I held onto my personal Microsoft 365 subscription for over a decade, mostly out of fear of that one moment when a client would call with a hair-on-fire demand that required me to run a redline on my cell phone. But when I examined my workflow, I realized Google Docs and Sheets, supplemented by Libre Office, could do everything I needed. The real-time collaboration in Google Drive is great, the mobile apps are excellent, and the interface is clean. Microsoft Office used to be the only tool that could reliably produce redlines. But now Google’s apps do this, too.

Plus, I consolidated my storage needs in the process. These days, it’s nearly impossible to go without a cloud storage service. Yes, I have friends who run their own private cloud server, but most of us mere mortals can’t be bothered. If you have more than one that you use regularly, you can more easily get lost in the hellish landscape of trying to find your documents. To me, Google Drive works best mainly because–surprise!–its search feature is the best. When you are thinking, “I know I wrote a thing about that thing once, what was that thing called?” and try to find it in Outlook or One Drive–forget it.

Becoming a Paid Prifina User 

This one’s new. I’ve been using Prifina for a while. I love the digital twin concept. If you are worried about AI taking your job, you might consider that knowledge work is kind of like figure skating: the success of work product is about half performance and half reputation. With a digital twin, you can train your own AI on whatever you like. Prifina respects your personal data, and its training dashboard is drag-and-drop. So when my free account expired last year, I put money behind it. The idea of having a digital twin that I actually control—that learns from my data and lets me control my personal branding—is the right kind of AI for me.

You can check out my bot COSSMO here: https://chinstrap.community/ask-cossmo/. It’s trained on most of my writing.

Spotify? YouTube Music? Amazon Music? CD-ROMs?

I seriously do not understand how people deal with their music anymore. This is one of those areas where the available tech is getting worse and worse.  

Now, perhaps that’s because I’m an eccentric dinosaur. I want music, not music-as-a-service. I’m a musician, so I record some of my own music. None of the music services can deal with that, and none of the few remaining players are good at it, either. Next, I choreograph dance routines, and for those, I need to download the music and cut it in my digital audio workstation. That requires access to local digital copies. Next, I like to listen to music on planes, where streaming doesn’t work. (Who doesn’t? I guess, people who don’t travel?) Last, I have no desire at all for the latest hits, because, true to my dinosaur self, I don’t think more than a dozen good songs have been released since the music industry died, which was sometime around 1992. So I don’t care about what any platform thinks I want to listen to (because they’re wrong). 

I want my 2004 iPod mini back! But you can’t go home again: iTunes is awful these days, and Apple Music is like putting your music in jail. I have to admit that I don’t get the point of Spotify, and YouTube Music has re-branded so many times that I have no idea what it’s called this week, or which of my music is there, or where it resides. I get access to Amazon Music Unlimited via my prime subscription, so I’ve taken the path of least resistance.

This decision got tabled until next year–again.

General Purpose AI

As I mentioned, I have settled on Claude for my main paid LLM subscription, but Google Gemini is getting hard to ignore, particularly for image processing. I’m guessing that, sometime this year, I will be upgrading my Google subscriptions for access to its AI. But meanwhile, Claude writes code like a superhero.  

Password Manager

I have been paying for Dashlane for years, while also having access to password management through both Google and Apple. I still don’t entirely get passkeys, and authenticator apps require you to have your mobile devices surgically attached so you can access them at all times. I am probably not the only person who has tried to access an online service while on the road, only to have it demand that I authenticate on another device–which is currently in another country. So, I’m not ready to let go of Dashlane quite yet.

I suspect this special purpose app will eventually get eclipsed as well. But mainly, it is a good way to share access with my husband. Until you have to access a loved one’s accounts in an emergency, you don’t know how important this is. I’m keeping my passwords platform-independent for now.

The Bottom Line

All told, I have only saved, at most, $50 a month on my subscription costs by making these updates. (Over half of that was Adobe.) Given I use most of them for my work, that’s not a lot. But pausing to re-evaluate them was useful. My key insight from this year is that many of the specialized tools I was paying for are being superseded by more general, more powerful AI assistants and integrated platforms.

The lesson isn’t that specialized tools are bad—it’s that the landscape has shifted dramatically in the past year, and will continue to do so in the next years to come. AI assistants can now handle tasks that used to require dedicated apps. Cloud platforms have matured to the point where they can replace entire software suites. 

I am mindful that this situation is probably not sustainable. The general AI platforms are hemorrhaging money, and I am not confident they can be made profitable without drastic increases in fees–which in turn may drive users back to specialized platforms. But I have always looked at the massive losses of unicorns as a wealth transfer from venture investors to users, and that’s fine with me, at least for now.