Asahi vs. Omarchy: License Fight Explained
On November 7, Asahi Linux published its Linux 7.3 progress report and used it to announce a license change. The project is moving its repositories from MIT to GPLv2-or-later. The report cites repeated attempts to exploit the permissive license, including code taken from personal forks and published without attribution, and code rewritten with LLM assistance to hide its origin. Asahi does not name Omarchy in the report.
Within hours, David Heinemeier Hansson responded on X. He said Asahi had rejected upstreaming and that Omarchy had been expanding Asahi’s Apple Silicon work with TouchID, M3 GPU, DisplayPort over USB-C, deep sleep, and MacBook Neo support. He also mocked Asahi’s AI policy.
Both statements describe the same conflict from different sides. The licenses explain why both can be true.
What happened
| Date | Event |
|---|---|
| Sept 11, 2026 | Omarchy announces Omarchy M: Linux on Apple Silicon, built on Asahi, with the line “Let’s finish what Asahi started.” |
| Nov 3, 2026 | Asahi ships Fedora Asahi Remix 45 the same day Fedora 45 lands. |
| Nov 4, 2026 | Omarchy ships 4.5: the first big release since Quattro, with Mac support for M1, M2, M3, and Neo. DHH says M4–M6 are next. |
| Nov 7, 2026 | Asahi’s 7.3 report lands with M3 GA, two drivers upstreamed, partial Thunderbolt, and the GPLv2 switch. |
| Nov 7–8, 2026 | DHH responds. The argument goes public. |
The technical work on both sides is real. Asahi’s report describes roughly 3,100 lines of macaudio driver work and 13,000 lines of AVD driver work going upstream, M3 support moving out of the expert flag, and a Thunderbolt patchset that currently covers USB3, XDomain, and Thunderbolt Networking but not PCIe or DisplayPort tunnelling. Omarchy 4.5 shipped real work: it reportedly merged more than 740 pull requests from more than 180 contributors.
What Asahi changed
The Linux 7.3 report is the primary document. It covers the usual progress: M3 support is now generally available, the macaudio and avd drivers are on the upstream list, Thunderbolt is partially working, Fedora Asahi Remix 45 shipped on release day, and the Triforce microphone beamformer is almost twice as fast.
Then it turns to licensing:
Some time ago, we were made aware of multiple attempts to exploit our permissive licensing to hijack our work, with a direct view to replacing the project and aggressively monetising Linux on Apple Silicon. In some extreme cases, in-development feature code was being lifted straight out of our personal forks and published without attribution or lazily rewritten with LLM assistance to obfuscate its origin. The MIT licence explicitly allows this, and has no carveouts to protect against bad faith actors.
Asahi says it is beginning the process of moving all repositories to GPLv2-or-later. The transition is a process. Asahi’s kernel was already GPLv2, and m1n1 has been GPLv2 since version 2.0.0. The change matters most for the userspace and tooling repositories that were MIT.
The report’s key sentence is the one about MIT: “The MIT licence explicitly allows this.” Asahi is acknowledging that the reuse was legal under the old license. The complaint is about the behavior around the license: attribution stripped, unpublished code taken, LLM rewriting used to hide origin. Those are separate problems from the license itself.
Asahi also has a Generative AI policy that broadly forbids LLM use for material contributions. It says enforcement varies, from closing an LLM-drafted issue to issuing a warning, and that a contributor found to have concealed extensive LLM use can be banned. That policy explains why AI-heavy patches would be rejected. It is a contribution rule, separate from the license change.
What Omarchy did
Omarchy M’s own README describes the product as “Asahi Alarm + Omarchy, installed in one command.” It tells users to run the Asahi Alarm installer first, then install Omarchy on top. The Omarchy Mac repository is MIT-licensed. Its package list installs Asahi kernel and firmware packages. It does not vendor Asahi’s kernel source. A grep of the current repository finds no Asahi copyright headers outside the README and a mirrorlist.
The grep shows a desktop and installer layered on Asahi’s stack, with Asahi components installed as packages. It says nothing about clean-room provenance. That is how most Linux distributions work: the distro’s own glue carries one license; the kernel, firmware, and drivers keep theirs.
The accurate complaint is about reciprocity. Omarchy built a product on Asahi’s work. DHH says Asahi rejected upstreaming. Asahi’s AI policy explains why AI-assisted patches would be rejected. That is a governance dispute. It becomes a license dispute only if specific code was copied without its notice, or code that had not been published was taken.
What MIT permits
MIT grants permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software. The condition is that the copyright notice and permission notice must be included in all copies or substantial portions of the software.
MIT allows proprietary and differently licensed derivatives. That is the license working as intended. A company can put MIT code into a closed product, provided the notice travels with it.
The MIT question is narrow. Did Omarchy keep the notices? If yes, it complied. If no, it violated MIT. If it used code that had not been published under MIT yet, it had no license at all. Asahi’s report says attribution was stripped in some cases. If that is true, Asahi has a real claim. The report does not name the project.
What GPLv2 requires
GPLv2 regulates distribution. It requires source code for distributed binaries, GPL licensing for derivative works, and no extra restrictions on recipients. It permits commercial sale, private use, and separate programs. A distro can ship a GPL kernel and an MIT desktop; that is aggregation.
| License | What it lets you do | What it requires |
|---|---|---|
| MIT | Use, copy, modify, merge, publish, distribute, sublicense, sell | Keep the copyright and permission notice |
| GPLv2 | Use, copy, modify, distribute, sell | Provide corresponding source, license derivative works under GPLv2, add no further restrictions |
GPLv2 does not clearly regulate AI training. Training is not distribution. A model that learns patterns from code is not automatically a derivative work. If the output reproduces protected expression, copyright law may attach, but that is a fact-specific inquiry. GPLv2 cannot enforce a clean-room policy.
GPLv2 also cannot revoke MIT rights for old releases. The last MIT snapshot remains available. The license change affects new code and new releases.
Does GPLv2 stop a company from doing what DHH did?
Shipping an MIT desktop with a GPLv2 kernel: no. That is normal Linux distribution practice. The kernel is GPLv2; the desktop can be MIT. The distributor must comply with the kernel’s source obligations. It does not have to relicense its own code.
Copying GPLv2 source into an MIT-only repo: yes. That would violate the GPL. The public Omarchy repo does not show that. It consumes Asahi as packages.
Training a model on GPLv2 code: no clear prohibition. GPLv2 does not mention training. Model output can raise copyright issues, but that is a separate analysis.
Forking the last MIT release: no. MIT is irrevocable for code already released. Asahi can stop publishing new MIT code. It cannot take back the old snapshot.
Who is right
On the law: both sides used their licenses as written. Asahi is right that MIT allowed the reuse. Omarchy is right that a distro can be MIT while shipping GPL components. The argument is about fairness. The legality is settled.
On attribution: Asahi has the stronger claim if notices were stripped. MIT’s notice requirement is enforceable. If unpublished code was taken, that is outright infringement.
On process: Asahi needs consent from contributors to relicense their code. The public repos I checked do not include a copyright-assignment CLA. The report says “we made the difficult decision,” not “we obtained permission from every contributor.” If Asahi has that permission elsewhere, the concern goes away. If it does not, the relicense is legally shaky for those contributions.
On AI: Asahi’s policy governs contributions. The license governs distribution. GPLv2 cannot enforce the policy. If Asahi wants clean-room provenance, it needs contribution audits and discipline, with copyleft as a backstop.
On governance: Asahi can reject AI-heavy patches. Omarchy can build its own distro. Neither side owes the other upstreaming.
What to watch
- Asahi’s relicense paperwork. The contributor-consent trail matters more than the announcement.
- Omarchy’s attribution audit. A NOTICE file and a provenance review would settle the factual questions.
- Whether Omarchy upstreams fixes, and whether Asahi accepts any of them.
- Whether GPLv2 changes AI behavior. It probably will not; the AI policy does that work.
- Whether users care about governance as much as they care about a working Mac install.
The Asahi–Omarchy dispute is a tradeoff between adoption and reciprocity. Asahi chose MIT for adoption and got reciprocity problems. It is choosing GPLv2 for reciprocity and will get adoption problems. That is the cost of the choice. The license text is clear; the hard part is deciding which community you want.
Legal note: this analysis covers the public licenses and public statements only.
Sources
- Asahi Linux: Progress Report: Linux 7.3
- Asahi Linux: Generative AI Policy
- Asahi Linux: Copyright & Reverse Engineering
- Omarchy: Introducing Omarchy M
- Omarchy: 4.5 release
- Omarchy Mac repository
- DHH on X: Asahi rejects upstreaming
- DHH on X: response to Asahi AI policy
- Fedora Asahi Remix 45
- The MIT License
- GNU GPLv2
- m1n1 license history