Asahi Linux Dropped MIT for GPL After Alleged AI Code Laundering

On November 7, 2026, the project that made Linux run on Apple Silicon Macs announced it was giving up the MIT license. I want to walk through what Asahi Linux actually said, what the license change does, and why the argument landed in the middle of a fight about AI generated code. I also want to be careful about what is established and what is only alleged, because most of the heat online comes from filling in names the report never mentions.

Everything about the alleged copying comes from Asahi’s own words. I could not verify it independently, and nobody has been named. I am not a lawyer, so treat the license discussion as an explanation of public documents and statements, and get a lawyer’s view before acting on any of it.

What Asahi announced on November 7

Asahi published its Linux 7.3 progress report on November 7, 2026. Braindetox’s summary lists the byline as James Calligeros and counts 9 sections, covering upstreaming work, M3 general availability, reverse engineering of the M4 and M5, the M3 GPU, Thunderbolt, games, microphones, Fedora 45 and the license change. The license change sits in the last section, which is titled “Learning from history”.

The core announcement is short. Asahi said it has begun moving all of its repositories to the GNU General Public License version 2 or later, and that going forward all Asahi Linux code will be under strong copyleft licenses only. It’s FOSS reported the move on November 8, and RuntimeWire published the same day. RuntimeWire stresses that the repositories have only “begun” to move, and it gives no list of affected repositories or a completion date. Braindetox’s read of the report agrees on both gaps.

The stated reason is the part that got attention. Per Braindetox, Asahi said it develops in the open, including its finances and development branches, and that it originally chose MIT to encourage participation from the BSDs and other free operating systems. It now considers that approach no longer viable. Asahi said it learned of multiple attempts to use its permissive license to take over the project and monetize Linux on Apple Silicon, and that some in development code was taken from personal forks without attribution or rewritten with LLM help to obscure where it came from. It’s FOSS quotes the report saying MIT “explicitly allows this, and has no carveouts to protect against bad faith actors.”

Asahi did not name anyone, and RuntimeWire notes that the article presents the claims as Asahi’s allegations with no evidence, repositories or copied code attached. RuntimeWire also points out that Asahi has not explained how existing contributor owned code and the earlier dual licensing will be handled.

Why the MIT license left the door open

MIT is one of the most permissive licenses in common use. Anyone can use, copy, modify, sell and relicense MIT code as long as the copyright and permission notice travels with it. SesameDisk’s comparison lays out the difference with GPL v2, which also allows selling but requires anyone who distributes a derivative to provide the source and keep it under GPL v2.

What MIT and GPL v2 each allow. Both licenses let a company sell the code, and only GPL v2 blocks a closed fork. Source: The MIT License, GNU GPL v2, SesameDisk

That one row about closed forks explains the whole decision. Under MIT, a company can take Asahi’s code, close it up and sell a product, and that is legal as long as the notice stays in. Under GPL v2, anyone who distributes a modified version has to release the source under the same license. It’s FOSS makes the practical point that a closed, paid Apple Silicon distribution built on GPL code would be illegal, and that copying becomes easier to detect. Stripping attribution already violates MIT, since keeping the notice is its main condition.

Asahi picked MIT on purpose. Its copyright policy says code written for Asahi itself typically uses a permissive license such as MIT, decided case by case, and that self contained modules such as an entire driver should be dual licensed under a permissive option so they can be reused elsewhere. The policy’s example header marks files as GPL 2.0 or later OR MIT. The page I read is the policy as it stood before the November report, and I could not tell whether it has been updated. The goal was reuse by other operating systems. It’s FOSS notes that OpenBSD’s Apple Silicon support relies on Asahi’s m1n1 bootloader, which shows how real that goal was.

Parts of Asahi were already GPL. The Linux kernel is GPL v2, so Asahi’s kernel work had to be, and SesameDisk reports that m1n1 has been GPL v2 since version 2.0.0. The change matters most for the userspace and tooling repositories that were MIT.

Wine ran the same experiment in 2002

Asahi drew the comparison itself, and It’s FOSS reports the same parallel. Wine, the layer that runs Windows software on Linux, started under the MIT license. Wikipedia’s Wine entry says the project moved to the LGPL as of March 2002 because of concern that proprietary versions would not contribute their changes back. The people involved said so at the time. On February 6, 2002, CodeWeavers’ Jeremy White posted a call for the change to the Wine developer list. In a follow up on February 15 he said the BSD style license encourages forks such as WineX, that competitors can take contributed code without giving anything back, and that CodeWeavers had become unwilling to contribute its code under the current license. He added that he would not release code under a BSD license again.

Wikipedia’s Cedega entry describes the proprietary product by TransGaming, formerly WineX, that forked the last MIT licensed version of Wine in 2002. It is the same shape of problem Asahi describes, a permissive license being used the way it was written. Wine kept going, and today it ships under LGPL 2.1 or later. CodeWeavers sells CrossOver, a supported version of Wine, and contributes most of its Wine code back under the LGPL. Valve works with CodeWeavers on Proton, which is built on Wine.

Two license switches, 24 years apart. Both projects started permissive and moved to copyleft after a dispute about reuse. Source: WineHQ mailing list archive, Wikipedia, Asahi Linux progress report 7.3 via braindetox

The comparison has limits. The Wine forks were openly commercial and visible. Asahi’s allegation involves unreleased code and rewrites that hide their origin, which is mainly a provenance problem. A license answers who may distribute what, and the origin of a rewritten file needs a separate provenance record.

What else was in the 7.3 report

The license change closes a report that is mostly engineering, and the numbers are worth knowing because they show what is at stake. Per Braindetox, the macaudio audio driver and its Devicetree work total about 3,100 lines and reached the kernel mailing list this cycle. The AVD driver is about 13,000 lines, spent about 3 months downstream, and Asahi called it the shortest turnaround yet for a major SoC component. Initial Devicetrees for the M4 Pro, M4 Max and M5 also reached the list, and they only boot the SoC to a text console.

M3 support moved out of the installer’s expert flag and is now generally available, based on almost no issues from early adopters. Enabling the display coprocessor was the most notable M3 improvement, bringing performance and battery gains and allowing sleep. The M3 GPU is still missing. Asahi says a new group is reverse engineering it, and that m1n1 can initialize it and draw a triangle, though Apple’s choices will need significant effort in Mesa.

Thunderbolt works for USB3, XDomain and Thunderbolt Networking, and developer Sven has spent nearly 5 years on it. PCIe and DisplayPort tunneling, which most docks need, is unsupported, and the report adds the word “Yet”. On M5, macOS needs a component called Exclaves, so Asahi now runs the Secure Kernel in a separate virtual machine, and m1n1 spawns 3 VMs so macOS can be studied on the M4 and M5. On games, Asahi puts the penalty of its muvm virtual machine at about 20%, depending on workload, and it shows Wolfenstein: The New Order reaching 144+ FPS on an M2 Max Mac Studio outside it. The Triforce microphone beamformer became almost twice as fast.

That is slow, careful, volunteer paced work, and it is the work the license change is meant to protect.

The Apple Silicon field got crowded in 2 months

The timing makes sense once you line up what happened between September and November 2026. Omarchy announced a dedicated Apple Silicon effort called Omarchy M on September 11. Gravity Linux published an early alpha for the M4 Mac mini on September 18, according to ModelFit. On October 23, Phoronix reported on Borealis, a Vulkan driver from the Aurora Silicon project that is derived from Asahi’s Honeykrisp driver and lives in its own Mesa fork. Asahi shipped Fedora Asahi Remix 45 on November 3, the same day as Fedora 45, which the report calls the first time a Remix release matched upstream’s date. Phoronix reported on November 5 that Omarchy 4.5 had shipped with Apple Silicon support. Asahi’s report followed on November 7.

6 dates behind the license change. The orange dot marks the Asahi announcement. Source: Phoronix, ModelFit, Asahi Linux via braindetox, SesameDisk

Support differs by project, and this is where the pace argument comes from. Asahi’s report says M3 support is generally available, the M3 GPU is still being reverse engineered, and the M4 and M5 are in reverse engineering. Phoronix says Omarchy 4.5 is reported to work on M1, M2, M3 and the MacBook Neo, and that it builds on work by Asahi Linux and others. Braindetox, summarizing Omarchy’s announcement, says M4, M5 and M6 are listed as in development with no schedule. Gravity’s alpha targets the base M4 Mac mini, and Phoronix lists suspend, display output on the USB-C ports and Thunderbolt as not working.

Apple Silicon Linux support by project. Gravity’s alpha reaches the M4, which Asahi has not shipped. Source: Asahi Linux progress report 7.3 via braindetox, Phoronix, ModelFit

Who the report is about

Asahi’s report names nobody, and It’s FOSS says so directly, adding that it supplied the context about Aurora Silicon and Gravity Linux itself. Some readers jumped to Omarchy. I would hold off. The facts I can verify are narrower.

Aurora Silicon’s Borealis driver describes itself in its own pull request as derived from Honeykrisp and as running on the M1 through M5 and the A18 Pro. Phoronix reports that the fork strips Mesa’s AI agent documentation and replaces it with a policy that allows AI contributions, and that the change was co authored by Claude Opus 5.5. That is a public fork that says plainly where it came from, and nothing public ties it to the unreleased code Asahi describes.

Gravity Linux forked from Asahi over the LLM policy. It’s FOSS names Cody Ho and Niklas Sheth as the main drivers and describes the project as open source, selling nothing, crediting its AI use openly and planning to wind down once its driver work lands upstream. Phoronix says it uses OpenAI Codex and Claude Code, and that its release is described as clean room reverse engineering. ModelFit adds that Gravity applies a tainting rule, under which a contributor whose model session has seen Apple disassembly or protected details cannot write the clean room implementation of that component. The 2 developers say in their own write up that they built an OpenGL ES 3.0 compliant driver for the M4 Mac mini in about 1 month, which is a claim about speed that I could not test.

Omarchy’s creator, David Heinemeier Hansson, has been publicly critical of Asahi’s AI policy. Digg’s summary of his post says he respects what Asahi achieved, objected bluntly to the policy, and suggested someone start a new effort using the best agents to finish M3, M4 and M5 support. SesameDisk paraphrases his November reply as saying Asahi rejected upstreaming, that Omarchy had expanded Asahi’s work with Touch ID, M3 GPU, DisplayPort over USB-C, deep sleep and MacBook Neo support, and that the AI policy deserved mockery. Some commentary attributes further claims to him, including a pledge that Omarchy stays free. I could not match those to a primary post, so I leave them out.

SesameDisk also looked at the Omarchy Mac repository and reports that it is MIT licensed, installs Asahi’s kernel and firmware packages through a package list, and does not vendor Asahi’s kernel source. Its grep found no Asahi copyright headers outside the README and a mirrorlist. That is one outlet’s check, and it does not speak to unreleased code either way. Omarchy’s own 4.5 announcement, as relayed by Braindetox, counts more than 740 merged pull requests from more than 180 contributors in 12 weeks.

The AI policy sits underneath all of it

Asahi’s generative AI policy says the use of generative AI tools in any contribution is expressly forbidden, and it promises an immediate and permanent ban for subsequent disregard. Its first stated concern is illegal output, since the popular generators are trained on an enormous corpus of text. ModelFit quotes the policy as broadly forbidding generative AI for material contributions and summarizes the reasons as clean room and legal risk.

That is a coherent position for a reverse engineering project, and a different project can reach the opposite one. The Linux kernel settled on a policy in April 2026 that allows AI assisted contributions with strict disclosure rules. Per Tom’s Hardware, contributors disclose AI assistance with a new Assisted-by tag, AI agents cannot use the Signed-off-by tag, and the human submitter answers for every bug or security flaw. My read is that this gap matters for upstreaming. Asahi wants its work in the mainline kernel, and the mainline kernel now accepts code Asahi’s own rules would reject. That tension will outlast any license.

ModelFit adds a useful caution on the speed argument. It notes that The Register credits coding agents with compressing months of driver work into weeks, and calls it a demonstration with no controlled test of whether Asahi’s policy slowed progress.

What a license switch fixes

I think the criticism of the move deserves as much weight as the defense. SesameDisk makes the cleanest case that the license and the AI policy do different jobs. GPL v2 governs distribution. Its text is silent on AI training, and a clean room contribution rule has to live in a separate policy, backed by contribution audits. Old releases stay available under their old license, and the change applies to new code and new releases.

There is a second objection that is simply practical. If the concern is people who already ignore the MIT license, why would they respect the GPL. A determined bad actor ignores both. It’s FOSS agrees that the GPL cannot stop a determined bad actor, and says its effect is on the commercial payoff, since a closed fork built on GPL code is a license violation with a visible paper trail.

The third objection comes from inside the free software world. OpenBSD developer Bryan Steele criticized the move on November 7 on X, saying that relicensing m1n1 and the drivers seemingly without the consent of all prior contributors was misguided. SesameDisk argues that relicensing old contributions needs that consent, and that the public repositories it checked show no copyright assignment agreement. In its view, if consent was never obtained the relicense is shaky for those contributions, and if Asahi holds consent elsewhere the concern goes away. Another view, which I have also seen argued, is that MIT already permits sublicensing, so a project can distribute the combined work under GPL as long as the original notices stay. I do not know which reading a court would take, and Asahi has not published its process. That paperwork is what I would watch.

It’s FOSS also offers a broader reading. As far as its author can tell, this is the first major open source project to move to copyleft specifically because of AI assisted code laundering, since earlier relicensings mostly targeted cloud resellers. The author expects other hardware enablement and reverse engineering projects might follow. That is a forecast, and I treat it as one.

Where this leaves the 2 camps

Asahi’s policy page and its report point to a project that treats legal exposure as the main threat to a reverse engineering effort, which explains the slow pace and the AI ban. The projects building on its work move faster and say so openly, with AI agents doing a lot of the writing. Both camps depend on Asahi’s reverse engineering, and only 1 of them can send code back, because Asahi will not accept AI assisted patches.

The license settles a narrower question, whether a closed commercial product can be built on Asahi’s new code. After November 7, the answer for new code is no. For code already released under MIT, the answer stays yes.

2 things from this generalize

First, pick a license for the worst reader your project will ever have. A permissive license is a decision to let anyone do anything within a short list of conditions, including things you will hate. If you would be angry to see a closed fork succeed, the license should have said so on day 1, and a relicense later only protects what you write afterward.

Second, keep policy and license apart. A license decides who may distribute your code. A contribution policy decides what you will accept. Asahi has both, and the report shows how much each one can carry. Only 1 of them can say anything about where a file came from.

This week, open the LICENSE file of 1 project you maintain or depend on and write down 1 behavior it permits that you would not want to see. If you find one, decide whether the license or the contribution policy should change.