The chardet relicensing dispute and the launch of the React Foundation

In March 2026, the OSS ecosystem saw two events of very different character in quick succession. One was a dispute that reopened the legal legitimacy of an old licensing decision. The other was an institutional move designed to reduce dependence on a single company.

chardet: the original author claims the relicensing was invalid

On March 4, 2026, Mark Pilgrim, the original author of the Python encoding-detection library chardet, opened GitHub issue #327, “No right to relicense this project”. His argument is that the LGPL -> MIT license change claimed by maintainer Dan Blanchard in chardet 7.0.0 has no legal basis.

Pilgrim is known as the author of Dive Into Python and as the person who ported Mozilla’s C++ Universal Character Encoding Detector into Python to create chardet. He had been silent on the public internet since around 2011, so his sudden return and the scale of the problem triggered major discussion on Hacker News.

Where chardet sits in the ecosystem

chardet is a huge package, with roughly 130 million downloads per month on PyPI. It used to be a mandatory dependency of requests, but requests moved toward the MIT-compatible charset-normalizer because chardet’s LGPL license was seen as problematic. In current versions of requests, chardet is optional and charset-normalizer is the default.

Even so, chardet is still used directly in large numbers across AI/ML frameworks, scrapers, API clients, CI environments, and more.

What the 7.0.0 “ground-up rewrite” actually was

In PR #322, maintainer Dan Blanchard released chardet 7.0.0 as a “ground-up, MIT-licensed rewrite.” Blanchard has handled every release since v1.1 in 2012.

Blanchard’s own explanation in issue #327 boils down to this:

First, a design document was created using Claude (Anthropic)‘s brainstorming features
Work started in an empty repository with no access to the old source tree
Claude was explicitly instructed not to reference LGPL/GPL-licensed code
The results were reviewed, tested, iterated on, and finalized

The repository still contains a design document, 2026-02-25-chardet-rewrite-plan.md, which records the plan for each stage. Claude Opus 4.6 is credited as a co-author on multiple commits, and Claude is formally listed as a contributor to the project.

The new version uses a 12-stage detection pipeline (BOM detection, structural probing, byte-validity filtering, bigram statistical models, and so on). According to the maintainer, it delivers 27-48x speedups over chardet 6.0.0 while achieving 96.6% detection accuracy.

Blanchard also presented JPlag (a plagiarism-detection tool) results for code similarity.

Comparison target	Maximum similarity
7.0.0 vs 6.x (the previous version)	1.29%
7.0.0 vs 1.1 (the last Pilgrim-era version)	0.64%
Between old versions (for example 5.x vs 4.x)	80-93%

If you look only at those numbers, 7.0.0 is a completely different codebase from any previous release.

Pilgrim’s rebuttal and the clean-room question

Pilgrim pushed back clearly.

They do not have that right. This is an explicit violation of the LGPL. If you modify LGPL-licensed code, you must release it under the same LGPL.

He also dismissed the “complete rewrite” argument as meaningless. His reasoning is that the maintainers had already been sufficiently exposed to the original LGPL code, so this cannot be called a true clean-room implementation. He also said that using a code generator does not grant any additional rights.

A clean-room implementation is a method where people who have never seen the copyrighted code build an implementation from the specification alone in order to avoid copyright infringement. Famous examples include Phoenix Technologies and Compaq building IBM PC-compatible BIOS implementations in the semiconductor era. The critical precondition is that the implementers did not touch the original code. Pilgrim’s argument hits exactly that point: Blanchard had lived inside the chardet codebase for more than a decade, so this cannot plausibly be called clean-room.

Simon Willison (creator of Datasette) also pointed out an important fact on his own blog: there are traces suggesting Claude Code referenced metadata/charsets.py inside the chardet repository during the work, and Claude itself was very likely trained on chardet code in the first place.

How far LGPL propagation reaches

How far LGPL obligations propagate is itself an area with competing interpretations.

flowchart TD
    A["Use an LGPL library"] --> B{"How is it used?"}
    B -->|"Dynamic linking<br/>(shared library .so/.dll)"| C["No propagation<br/>your own code can use any license"]
    B -->|"Static linking<br/>(built into the binary)"| D["Must satisfy LGPL conditions<br/>object files or relinking means must be provided"]
    B -->|"Distribute a modified version of the library itself"| E["Modified parts must be released under LGPL"]
    B -->|"Python import"| F["Legally ambiguous territory"]
    F --> G["Often interpreted as close to dynamic linking<br/>but there is no case law"]

In C/C++ practice, there is a rough consensus that dynamic linking does not trigger propagation. The FSF (Free Software Foundation) takes the position that static linking creates a derivative work, but courts have never provided a clear precedential ruling.

In Python, import loads modules at runtime and looks closer to dynamic linking in practice. But scripting languages do not map cleanly onto the concept of linking in the first place, so the legal treatment remains unsettled. In real-world practice, people often treat Python imports as analogous to dynamic linking, but that is convention, not settled law.

The real concern in chardet’s case is software that statically bundles chardet or distributes modified versions of the chardet code itself. If the 7.0.0 MIT license were judged invalid, projects that incorporated it as MIT software could suddenly face LGPL propagation risk.

Similar precedent cases

There are two important precedents around software reimplementation and copyright.

In Lotus v. Borland (1996), Borland independently reimplemented the menu hierarchy of Lotus 1-2-3. There was no source-code copying, but the command names and hierarchy were almost identical. The First Circuit held that the menu hierarchy was a method of operation and therefore outside copyright protection. The Supreme Court split 4-4, leaving the appellate ruling intact but not creating nationwide precedent.

In Google v. Oracle (2021), Google copied roughly 11,500 lines of Java SE API declaration code to build Android. The Supreme Court ruled 6-2 in Google’s favor on fair use. The reasoning focused on the organizational and functional role of the API declarations and deliberately avoided deciding the broader copyrightability of APIs themselves.

Neither case is a direct match for chardet, since both are about reimplementing interfaces or structure. But they do point in the same general direction: purely functional elements receive weaker copyright protection. That makes them useful signposts when thinking about where the chardet dispute could go.

Community discussion

The dispute triggered active discussion on multiple platforms.

Speaker	Position
Simon Willison (Datasette)	“Personally, I’m leaning toward the rewrite being legitimate, but both sides are making entirely reasonable arguments.” He framed it as a preview of what happens when AI coding agents reimplement mature existing code
Armin Ronacher (Flask, Sentry)	In “AI And The Ship of Theseus”, he compared it to the Ship of Theseus paradox: copyleft depends on friction around copyright, and AI could remove that friction enough to undermine the model
Bruce Perens (drafted the Open Source Definition)	Told The Register that this was like smashing the glass and pulling the fire alarm. He warned that AI-based reimplementation could invalidate the license framework as a whole
OSnews	Published “The great license-washing has begun”, naming the practice of feeding copyleft code into AI and redistributing the result under a different license as “license washing”

Issue #327 remains open as of now. It is unclear whether the dispute will reach a legal resolution at all, and that is a separate question from whether it ever turns into actual litigation.

React Foundation: moving React beyond Meta under the Linux Foundation

On February 24, 2026, at the Linux Foundation Member Summit, “The React Foundation” was formally launched as the new home for React and React Native development. Related projects including React, React Native, and JSX are being moved out of direct Meta ownership and into the Foundation.

React is the UI library Meta (then Facebook) open-sourced in 2013. It spread rapidly thanks to its component-based model and virtual DOM, and it remains the most widely used framework-style library in the web frontend world. But for years there had been concern about Meta unilaterally steering its future. That structural problem is exactly what this move is trying to address.

This direction had already been previewed in October 2025 on Meta’s engineering blog, and it became official in February 2026.

Founding members and funding structure

The founding members (Platinum members) of the React Foundation are eight companies.

Company	Position in the React ecosystem
Amazon	Uses React in products such as AWS Amplify
Callstack	A React Native specialist consultancy
Expo	A development platform for React Native
Huawei	Joined after the October 2025 announcement
Meta	The original creator of React / React Native
Microsoft	Uses React Native in many products
Software Mansion	Maintains multiple React Native libraries
Vercel	Maintains Next.js and hosts a large part of the React ecosystem

Meta has committed more than $3 million over five years and said it will continue funding a dedicated engineering team. The scale of contributions from the other companies has not been disclosed.

Governance structure

flowchart TD
    LF["Linux Foundation"] --> RF["React Foundation"]
    RF --> Board["Board of Directors<br/>one representative from each Platinum member"]
    RF --> ED["Executive Director<br/>Seth Webster<br/>former Meta React lead"]
    RF --> TLC["Provisional technical leadership council"]
    TLC --> TG["Formal technical governance body<br/>to be established in the coming months"]
    Board -.->|"Does not directly control<br/>technical direction"| TLC

Seth Webster serves as executive director. He previously led the React organization at Meta and has a long career as an engineering executive.

A key design choice is that React’s technical direction is decided by a body independent from the board of sponsors. For now there is a provisional technical leadership council, which is expected to transition into a formal governance structure over the coming months. The names of the council members have not yet been published.

The official blog states this explicitly: React’s technical direction should be set by the people who contribute to and maintain React, and it is important that no single company or organization is overrepresented.

Comparison with other Linux Foundation projects

For JavaScript under the Linux Foundation, there is already the OpenJS Foundation (formed in 2019 by combining the Node.js Foundation and JS Foundation). The reason React Foundation was created as its own foundation rather than folded into OpenJS is to preserve React-specific governance.

Item	React Foundation	OpenJS Foundation	CNCF (Kubernetes, etc.)
Founded	2026	2019 (merger)	2015
Main projects	React, React Native, JSX	Node.js, jQuery, webpack, etc.	Kubernetes, Prometheus, etc.
Technical governance	Provisional council -> formal body	TSC (Technical Steering Committee)	TOC (Technical Oversight Committee)
Sponsor structure	8 Platinum members	Platinum/Gold/Silver	Platinum/Gold/Silver/End User

Node.js has spent more than a decade under the Linux Foundation and continued developing stably despite shifting priorities among major companies. Kubernetes likewise became less dependent on Google after it moved into the CNCF. The React Foundation is following the same broad path.

Repository migration and upcoming work

Several things are scheduled for the coming months.

Moving the GitHub repositories (currently facebook/react) under a React Foundation-managed organization
Establishing a formal governance body for technical decisions
Moving websites and infrastructure into React Foundation ownership
Kicking off React Conf

Community reaction

Community reaction has been broadly positive, but not without concern. The most repeated concern on Hacker News and Reddit was Vercel’s influence: whether Vercel could effectively dominate React development and push users harder toward Next.js and Vercel hosting. One of the most upvoted Reddit comments framed it bluntly: Vercel already has de facto control over React, and its main interest is funneling users into the Next.js -> Vercel hosting pipeline.

That said, the React Foundation appears to be explicitly designing around that fear by separating technical governance from the sponsor board. Whether that separation works in practice will depend on how the Foundation is actually run.