Fact that a person who was not previously driver developer can achieve this in a few weeks is pure wonder. No matter what tools are used.
Leave legal questions to Linux Foundation laywers or whoever is responsible to accept or not accept the patches.
If Apple actually wanted to prevent any of this from happening they can just lock bootloader. They not just gonna do it now because someone used fancy text generator to make working GPU driver.
Attacking a person who spent their personal time and money on making walled garden black box hardware more usable, more privacy friendly and further away from landfill is a crime against the future of humanity.
> The author was banned from Asahi Linux for hiding his extensive use of LLMs from us in another attempted contribution, and (more importantly) for concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development. Make of this what you will.
This is false. I am a former Apple engineer. I did not conceal it (it's the top item of my resume and my LinkedIn and I made my PR from my public Github with my name attached, as opposed to a pseudonym which is expressly allowed by Asahi policy). I also had no exposure, at all, to any internal information or code about macOS, SPTM, or Apple Silicon during my time there.
I also don't have connections to people involved in Apple Silicon development (and I'd add that this does not mean someone cannot contribute, the question is were they exposed to tainted information, which is absolutely not true in my case). I have many friends who work for Apple (I'm a Stanford alum) but none in Apple Silicon directly.
I disagree with the phrasing of this entire thing, but this statement is demonstrably false.
On mobile I didn't see the full URL, and zoomed before I saw the calendar. My bad.
The author’s blogpost is sloppy and has some signs of being AI written. This kind of bleeds into the main point I’m going to make.
Asahi Linux folks are clearly more conservative and erring on the side of caution, so, this means that the glibness with which the author is treating any of this is probably sufficient cause to refuse his entries. It is unclear if LLMs should be considered a toxic waste dump in terms of trying to maintain a clean room. We have not established a standard. It is clear the author doesn’t think this is a big deal, so that’s one conflict. The other conflict is that it is not clear what their exact interactions with Apple Silicon folks is and their glibness of it doesn’t clarify anything.
If you take a group that is trying to be very careful about the potential legal landmines a still nascent technology has and you get someone that espouses a general glibness about those concerns wanting to merge code…why on earth would you expect that group to accept them as a contributor?
This is not to say this isn’t really cool and a neat use of LLMs, but it is totally understandable why Asahi Linux won’t accept the fruits of this kind of development. If it turns out that Apple can identify its non-OSS code in this, it’ll be a mess.
For the lazy.
And they say irony is dead.
I say this from an anonymous account but at least it isn't a throwaway. And at least I have the good taste to feel a little shame for my hypocrisy.
No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.
This "clean room RE" fabrication is also not something so obviously compelling that nobody would ever attempt to challenge it - it's just that nobody has cared to put dollars behind it. IP provenance cases are enormously difficult to prove and are always settled ahead of trial. This concept is software engineer folklore more than anything.
I seem to recall DeCSS being the 'hot button' as it was RE'd in a 'non clean' way, the code released, and then a 'clean room' RE could be made from the 'public' info ??
edit: actually, at the time I think there was German law allowing RE for 'interoperablity' or some such. But that was a long time ago so my memory might be off.
It's safest to err on the side of plausible deniability, any proximity to OEM software increases liability if things go wrong.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Just call yourself "Idea Llmina" or whatever and let someone else commit it.
The only way to get flawless Linux support is to buy hardware from an OEM that supports Linux well.
I think at this point the hacking community needs to grow some balls.
The fact is, open source has much more liability than closed source software does. If copyrighted material ends up inside a private code base it'll be nearly impossible for the owner to discover that and sue.
Do you have many examples of this actually happening that you could share?
I really don't see how this issue is going to be feasible for courtrooms to deal with in a world where big tech are bragging about large percentages of all their code being produced by LLMs.
LLMs have been firing out a lot of code for a year or 2 now at least, so I would have thought we'd start seeing some court cases by now?
The only real innovation for small planes is in the electric flight area - when you gotta do a full certification anyway as you're piloting an entirely new drivetrain, you can financially afford to be much more innovative on other parts of the design.
Business and code production would grind to a halt whilst basically every big tech company shares it's entire codebase with every other tech company for discovery. It's basically MAD.
And if it was feasible, given we've had a couple of years of all the big tech companies heavily using LLMs, there should be some notable court cases by now, surely?
(I worked in a federal district court for a while.)
In a case where both parties have lawyers, having more and more expensive lawyers is not necessarily predictive of a case’s outcome. There are diminishing returns.
What having more resources tends to do is force the poorer party to settle quicker. But that’s not necessarily a loss. Judges still have to approve settlements in the interest of justice.
I hate the new system of no ownership and closed everything.
It won’t be clean room like the stuff Alyssa did.
Judges, as far as I know, do not generally take kindly to such arguments.
Any other interpretation would mean trade secrets have essentially infinite protection/NDAs apply to all of humanity.
The NDA doesn't apply to people who haven't signed it, but copyright law does. If you know the material you're receiving is under copyright (eg proprietary source code), and you publish work based on that copyright material, the fact that it's now widely available is not an effective defense against claims of copyright violation.
Person B in this scenario hasn't violated the NDA, but they could be sued for copyright infringement.
Which I think you know, so I don't understand your argument.
You said in another comment "However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer."
It being proprietary and/or secret information doesn't affect the copyright of the clean-room output. If there's trade secret implications those are worth discussing, but as a separate issue.
That's what's referred to as a "clean room implementation" further up the thread.
However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer.
Legally speaking, a clean room implementation has much better defenses from claims of copyright violation.
This sort of thing has always been a concern for projects that re-implement some existing piece of software, e.g. there were concerns early on during development of the GNU project about people contributing after having been exposed to Unix source code. Similarly, it is an ongoing concern for the Wine project[1], as well as ReactOS. The later even had a code freeze and internal audit in 2006, after allegations came forward that code had been derived from disassembled Windows binaries[2].
[1] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
Weird how justified reasonable policies get the "crazy" label.
Imagine what happen if OP submit patches upstream skipping Asahi and they gonna be accepted.
I have many frustrations with LLMs, mainly around the type of user whos brain shuts down, but Apple would be walking a very fine line if they offer a service that they also will sue you for using.
Perhaps they should have used the Foundation Models to build their code. Really put Apple in a difficult position.
Isn’t that just saying “he uses modern tools and has subject matter expertise”?
I mean you can get good stuff out of it if you know what you are doing and guide it, but if you just say “here’s a regression suite. Write an implementation that passes” you will get something that works for a while but ages quickly and will need to be thrown away.
Apple releases the M15, and using everything leaned while building drivers for the M4 - M14, the LLM just does the whole job and we have the drivers a day later.
However, Asahi Linux has a strictly no-AI policy [1]. So this great work can't be upstreamed. I expect to see a bunch of AI-assisted forks that get things working smoothly on newer hardware to dominate as most people just care about getting stuff working, while only a handful of purists stick to the non-AI version running on ancient hardware.
This may never end up working like that, considering how complicated installation is, comparatively speaking, and how macOS is still pretty much required to be installed.
There's also ongoing issues around Codex for this sort of thing, given Apple is suing OpenAI over stolen trade secrets[2]. And nobody knows whether training data in other models is similarly tainted.
[1]: https://codyho.dev/documents/cody_ho_resume.pdf
[2]: https://www.theguardian.com/technology/2026/jul/10/apple-sue...
Basically, aren’t we facing a situation where LLM-assisted knowledge laundering is becoming a thing?
Nobody has been held accountable for AI selecting a grade school as a bombing target on the first day of America and Israel’s strikes on Iran. 100+ school girls killed, and no accountability.
Exactly how does that equate to knowing details of Apple's GPU implementation? Apple is a massive company.
So if I worked as a janitor at Apple, I couldn't contribute anymore?
Ignoring the idiocy of Imaginary Property is how China is winning.
It's time we caught up and then leap ahead. Everything is a derivative work.
The problem with this driver is not licensing or code quality; I assume it's under a threat of receiving C&D letter, or maybe also a legal suit for breaking some NDA.
Including the proprietary GPU drivers. If this MacBook driver end up out of tree, so be it.
It may also be legal to do the following: 1. Have an llm read all the code these people have written and produce extensive documentation. 2. Have another llm consume that documentation and write another working driver. I am not a lawyer but I think this may fall under fair use, because reverse engineering is allowed for interoperability.
I didn't mean that I understand the actual intricacies of the legal situation.
Sorry for my confusing wording.
Apparently. But Apple should be ashamed of themselves for that fact. What are they so afraid of? That Mac OS is so inferior to Linux that if they publish specs so that a driver can be made, that everyone will wipe Mac OS off their disks like it's Windows ME??
Once again, modern Apple is allergic to competing on their product's merits, clinging to force as though it's the only way anyone will choose them. Which is insane to me given how loyal their following is. I'm typing this shit on Mac OS right now.
Apple comes off like the most insecure corporate culture in history.
these two things have absolutely nothing to do with each other whatsoever
I guess author can cleanup the code and try upstream it themself. Then let's see what Linus thinks of it.
I assume I’ll get used to it, but my mental model of what’s possible hasn’t been fully rewired yet.
AFAIK Nvidia drivers are proprietary and AMD has a tendency to drop support quickly
There plenty of us not working at Apple who can reuse the same approach for M5 and next generations of hardware.
I just think one good part of Marcan's work is that they streamed a lot of their workflow with all kind of problems occured along the way and you could see how to solve them.
And please so not let anti-llm crowd discourage you. People like me who want to use good hardware and already choose to pay for Apple one just need drivers that work good and feature complete - code purity and "quality" is secondary.
https://codyho.dev/blog/hypervisor-macbook-neo/
tl;dr you reboot the device with `macvdmtool`, you install m1n1 as the boot object, you talk to the m1n1 proxy over a python shell. I'm documenting the process as I go also (see: the blog posts, also my github repos) both so others can do it and as record of the clean room nature, but this really is just GPT go brrrrr
I guess its a good reason to try it with M6 mac mini or Vision Pro then (yeah I know AVP has locked bootloader). Thanks.
- During my time at Apple I never saw any of the macOS source code, at all, even for userspace components. I had not even heard of things like SPTM.
- I have not worked there since June 2025
I don't believe that there's any risk due to my former Apple employment. As another example, WINE does not ban all former Microsoft employees, they just ban anyone who has ever looked at the Windows source code. If I felt there was even a chance that my employment at Apple may have exposed me to relevant internal secrets, I would refrain from contributing to community projects.
It's an interesting example given that Wine considers deriving code from traces of original components (like hypervisor traces) tainted and also bans LLM contributions for legal considerations: https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
[1]: https://github.com/Rust-for-Linux/linux Rust for Linux
[2]: https://android.googlesource.com/kernel/common/ Android OS linux kernel
[3]: https://github.com/openzfs/zfs OpenZFS kernel module
[4]: https://github.com/awemorris/linux-pc98 Linux pc98 / 32 bit x86
[5]: https://github.com/OpenDingux/linux Linux on retro gaming device
[6]: https://github.com/AsahiLinux/linux Linux on older apple silicon M1/M2/M3 chip
[7]: https://github.com/microsoft/wsl2-linux-kernel Linux on Windows
> Dj is writing the GPU drivers, and got Touch ID working by talking directly to the Secure Enclave
It's also interesting to see all this work seems adjacent to Asahi's own.
I'm surprised you worked with Niklas on this. I'd have assumed you'd think he was competent, given he went to Binghamton and not Stanford.
1. We want to guarantee our work is not a "derivative work" of anything Apple wrote.
2. If we look at any Apple binaries, there's no way prove that our code didn't borrow from Apple.
3. Since we didn't look at any Apple binaries, then there's no way our work can be a derivative work-- we didn't even look at their stuff.
The legal framework around all this is way too immature to make a definitive statement one way or the other. Anyone who says otherwise is speculating.
The only way to clarity will be legislation or court cases, because it really could go either way.
It's not okay to ban tool use when a person is honest about it. The only thing you can achieve with a ban is that people will learn to lie about it and conceal it better.
But they do objectively exist in many desktop Linux projects. If you are the sort of person that sees software as "dead in the water" from AI prohibition, desktop Linux will feel like a mausoleum compared to macOS or Windows.
So many people are clinging to practices that are rapidly becoming antiquated. Even Linus had to put his foot down and had to stop the ideologues from attempting to stop AI use in the linux kernel.
Perhaps before Astra was nerfed. It is now the dumbest model right after Gemini. Sol still holds up.
Furthermore, given that Asahi Linux, the biggest game in town when it comes to running Linux on Apple silicon, is trying to be cleanroom, it is incredibly rude of you to not mention LLMs until after showing a page full of LLM-derived firmware ABI. This is a trap for anyone who's trying to be cleanroom.
Are you claiming models were trained on proprietary Apple code? How would that even be possible?