A New CUDA-on-AMD Project Walks Into Nvidia's Legal Minefield

A GitHub user going by Speedstu published a project on Sept. 13, 2026 called CUDA-for-AMD-Windows: a compatibility layer that routes calls from CUDA-targeted Windows software through ZLUDA into cuBLAS, cuSPARSE and cuFFT wrappers, then down into AMD's rocBLAS, hipBLASLt and HIP runtime on the GPU itself. The validated reference stack is narrow and written plainly in the readme: ZLUDA v6-preview.69, AMD's HIP SDK 6.4 and LibTorch 2.3.0 built against CUDA 11.8, tested on a single card, the Radeon RX 9060 XT. Other AMD GPUs are listed as unverified candidates, and cuDNN, NCCL and TensorRT are flagged as likely to fail outright.

The repository is hours old at the time of writing and already carries 58 stars. GitHub's own license detector lists the repository as unspecified, even though its readme licenses the project's own scripts under MIT; the third-party pieces it stitches together, ZLUDA, ROCm and CUDA itself, keep whatever terms their own maintainers set, which is precisely where the legal exposure sits.

The clause this project runs straight into

That exposure is not hypothetical. Nvidia's own CUDA end-user license agreement, in section 1.2's list of limitations, says: "You may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements for the purpose of translating such output artifacts to target a non-NVIDIA platform." The clause has sat in Nvidia's online terms since roughly mid-2021 and was folded into the EULA shipped inside the CUDA 11.6 installer itself, meaning anyone who has installed CUDA since has already agreed to it, whether or not they read it.

That is the exact activity CUDA-for-AMD-Windows performs: translating CUDA output to target AMD's non-Nvidia platform. Nvidia has never sued a translation-layer developer over the clause directly, and nothing here suggests it plans to start with a 58-star personal repository. But the clause exists precisely to deter the class of project that just shipped, and the project's own dependency, ZLUDA, already has a documented case of a much larger company deciding the risk was not worth carrying.

Why AMD backed away from the exact same idea

ZLUDA's history is the cautionary tale sitting one dependency below the new project. Andrzej Janik started building it in 2020, initially targeting Intel GPUs while he worked at Intel. AMD later funded the project's CUDA-on-AMD-GPU work, then stopped financing it in early 2022. Janik kept the code dark until February 2024, when he resumed public development, believing a contract clause let him release it as open source once AMD's interest lapsed.

That belief did not survive contact with AMD's legal department. On Aug. 9, 2024, The Register reported that AMD demanded Janik take the ZLUDA source down from GitHub, despite what he said was prior approval by email: "The code that was previously here has been taken down at AMD's request. The code was released with AMD's approval through an email. AMD's legal department now says it's not legally binding, hence the rollback." Janik told the outlet Nvidia itself never threatened him directly; the pressure came from AMD's own lawyers, weighing exposure under Nvidia's EULA against the benefit of a compatibility layer for a rival's software stack.

Janik rebuilt from a pre-AMD codebase rather than litigate, and by Oct. 4, 2024 he wrote on the project's own blog that an undisclosed backer was funding a restart aimed at machine-learning workloads: "We are targeting for llm.c, llama.cpp, PyTorch, TensorFlow and others," naming Q3 2025 as the target for matching the pre-rollback project's feature set. He declined to name the sponsor, writing only, "We don't want to disclose everything just yet."

Date	Event
2020	Janik starts what becomes ZLUDA, initially for Intel GPUs
Early 2022	AMD stops funding the CUDA-on-AMD-GPU work
Feb. 2024	Janik resumes public development on his own
Aug. 9, 2024	AMD's legal team orders the code taken down
Oct. 4, 2024	Restart announced, funded by an undisclosed backer
Sept. 13, 2026	CUDA-for-AMD-Windows ships, built on ZLUDA v6-preview.69

The denominator here is legal risk, not compute

Most coverage of CUDA compatibility layers frames the story as a technical one: does the translation lose performance, does cuDNN work, how close is it to native. Those questions matter, and CUDA-for-AMD-Windows already answers several of them against itself, disqualifying cuDNN and flagging TensorRT and NCCL as unreliable. But the technical ceiling is not the binding constraint on whether a company the size of AMD ever ships an officially supported CUDA-compatibility layer of its own. The constraint is that Nvidia's EULA makes the output of its own compiler toxic to touch for exactly this purpose, and AMD has already shown, in writing, that it will not carry that risk even for a project it had been funding.

An individual publishing a personal repository does not face the same calculus. Speedstu has no shareholders, no enterprise customers relying on a support contract, and nothing Nvidia could meaningfully extract even in the event of a claim. That asymmetry, not the code itself, is the reason a Windows CUDA-on-AMD layer can exist as a weekend project in 2026 while no CUDA-compatible AMD product line exists on any GPU vendor's actual roadmap. The moat here is not silicon. It is the fact that only parties with nothing to lose can legally afford to build the bridge.

What would change this read is Nvidia actually enforcing the clause against someone, rather than merely holding it in reserve; a single cease-and-desist against a ZLUDA-adjacent project would tell every downstream developer, including whoever is anonymously funding ZLUDA's current restart, exactly how far the deterrent extends. Until that happens, the clause is doing its job purely by existing, which is a cheaper strategy than litigation and, on the evidence of AMD's own retreat, an effective one.

For more on the economics behind Nvidia's position, see how Nvidia's equity stakes in its own customers reshape who can afford to compete with it, and on the quantization side of the same GPU-memory squeeze, a Riemannian-optimization technique that shrinks Qwen3.8-27B's memory footprint.