upvote
> concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development

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.

reply
Ah, don't worry about those guys. This is very cool! I love the technical write up -- so interesting: )
reply
At least according to your own accounts on the Asahi IRC rooms, you were very aware of SPTM (which is part of the AS platform) and knew the people working on it: https://oftc.catirclogs.org/asahi-dev/2026-06-04#35383763
reply
The friend I am referring to I met at Stanford around April of 2026 in a dorm event. We've spoken in person exactly once (I use "friend" loosely to describe anyone I've spoken to who I'm not on bad terms with) and at no point did we discuss anything detailed about Apple Silicon. For further context, I left Apple in June of 2025.
reply
Isn't that chat log from 2024?
reply
If you read the page it says 2026-06-04.
reply
Ah. I read the post, but only saw "2024-07-16 04:52 ChanServ changed [...]"

On mobile I didn't see the full URL, and zoomed before I saw the calendar. My bad.

reply
am i crazy or is the date stamp not literally in the link?
reply
Spend enough time in tech and you'll know lots of people who know both technical and business secrets and are under various levels of NDAs. The message you link to explicitly mentions only public info was exchanged. Just talking to someone is not an indication of infringement in any way.
reply
I think this comment is missing the forest for the trees. Obviously, ephemeral interaction is going to happen.

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.

reply
> Asahi Linux folks are clearly more conservative and erring on the side of caution

I mean they are working around and on hardware controlled by a nearly 5 trillion market cap behemoth who has resources on the level of some nation states.

I'd be erring on the side of caution as well if they could hire that many lawyers.

reply
> <StanfordAppliedCyber[m]> one of my friends is a very senior engineer who lead a lot of the sptm work and controls a lot of boot, may talk to him about it (obviously he hasn't told me anything that isn't public)

For the lazy.

reply
You are accusing someone by twisting their own words about their own self disclosed identity against them from a throwaway account created 5 hours ago.

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.

reply
deleted
reply
Do you work for Apple?
reply
Probably not. Clean room RE is serious business, projects like Dolphin have to carefully vet contributors to remain legal.
reply
Everyone says this, and then exactly zero cases are cited in support of or against this creative legal theory known as "clean room RE."

No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.

reply
When you say "case" does that mean you're rejecting the evidence of Phoenix technologies not getting sued along with all the other BIOS clones?
reply
Absence of evidence isn't evidence of absence. "Not getting sued" doesn't validate a legal theory - legal theories are validated in court where they become case law. Until then, they are plainly speculative.

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 almost always settled ahead of trial. This concept is software engineer folklore more than anything.

reply
But there are plenty of successful projects which would probably have been taken down if it wasn't for clean room RE. I mean just look at the clean room IBM BIOS clones from "IBM compatibles" in the early days of the personal computer.
reply
This is the same logic that the TSA uses to justify its existence. "We're so good nobody attempts it!"
reply
there isn't ?? I sorta thought we figured all this out decades ago when SMB and DeCSS were being reversed? I think dosemu or something as well ?

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.

reply
Who volunteers to be the shmuck that fights Nintendo's lawyers in court? Who's funding the defense against Apple?

It's safest to err on the side of plausible deniability, any proximity to OEM software increases liability if things go wrong.

reply
Nintendo doesn't care. There's been proprietary Nintendo SDK code in libogc (open source library for making GameCube homebrew) for years. And more recently the various decompilation process have made recreations of linked code from the SDK that compile match byte for byte. In practice the legal risk of being sued into oblivion for this is not there. If anything there would be a DMCA takedown / cease and desist.
reply
Right, but they are one of the biggest DMCA abusers. They killed many fan projects. They killed game renting in Japan as a concept. They killed Yuzu (a Switch emulator). And they could change their mind at any time.
reply
>They killed Yuzu (a Switch emulator).

For the record Yuzu included code for circumventing Nintendo's DRM they had on game carts. It violated the DMCA.

reply
Would you consider taking all of your learnings and translate them into a concrete specification and publish it on your website, so that we can all do our own clean-room from-spec-only implementation?
reply
Everything that you say can be true, and yet Asahi project may want to avoid needing to prove what you say in a courtroom.
reply
"We don't want to take on the risk of working with a former Apple employee, who could potentially leak trade secrets and expose us to unwanted liability" is a very different statement than asserting that they were banned for deception. The post you're replying to is responding to accusations against their character and behaviour. Clearing those up is an entirely different matter than saying anything about whether former employees should be allowed to contribute to the project.
reply
FFS Linux kernel have tons of patches with "Asahi Lina" specified as "author" even though commiters are real people:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Just call yourself "Idea Llmina" or whatever and let someone else commit it.

reply
deleted
reply
I'm sure Omarchy will appreciate the effort, even if you're snubbed by Asahi -- being able to run Linux flawlessly on Apple Silicon is going to be awesome.
reply
I wouldn't expect "flawless" support for those chips in the next decade, even with AI. The earliest-supported Asahi chips still have missing power management and dark silicon.

The only way to get flawless Linux support is to buy hardware from an OEM that supports Linux well.

reply
I find it extremely ironic that big corp openly steals IP en masse to build their models but hackers are still concerned about using same models for their reverse engineering work.

I think at this point the hacking community needs to grow some balls.

reply
It's because it doesn't matter how copyrighted material ends up in a project. If an LLM reproduces copyrighted material (which is very hard to verify) then the lawsuit from the copyright owner can still sink even robustly funded projects.

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.

reply
> If an LLM reproduces copyrighted material (which is very hard to verify) then the lawsuit from the copyright owner can still sink even robustly funded projects.

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.

reply
In the 90s aircraft manufacturers basically stopped whole segments of the market (anything smaller than a piston twin) due to litigation. I wouldn't be horribly surprised to find we spend the next 10 years fighting about this stuff in court.
reply
I'm fully aware of lots of times powerful companies have used the courts to protect their business. My point is basically all of the powerful companies are elbow deep in LLMs to the extent of some sort of mutually assured destruction if they were to start court cases like this.

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?

reply
It's purely conjecture at this point but my gut feeling is most companies are in high spirits about the costs they can save and the benefits it can bring to their own business. I don't think enough time has passed to see really high profile losers. What happens when Infosys starts losing money or Free CAD becomes the next SolidWorks due to LLM driven improvements?
reply
The lack of modern small airplane designs, especially engines, is the extensive and thus expensive certification process. Most of what is a "new" airplane usually is derived from a very old, grandfathered design.

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.

reply
Why wouldn't it be feasible for Apple, with an unlimited war chest, to go after Asahi? I am not saying they will, but it is certainly possible for them.
reply
Because if it's feasible for any company with a war chest to start a court case about a competitor maybe having a matching line of code to theirs via an LLM, then basically every single company with a warchest would be at war with eachother, because they're all using LLMs.

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?

reply
Heh, sounds like it'd be along the same lines as the SCO Unix kerfuffle back in the day.
reply
Mutually assured destruction is what keeps everyone quiet at the moment.
reply
These are very good observations indeed.
reply
Agree. Especially since even a tainted GPU driver (tainted as in, used former Apple Engineer knowledge) is usefull as we just throw another LLM onto it and tell it "rewrite in rust" and get an untainted version of it (at least that is the current judicial state, and the bigtech argues in this direction).
reply
It's not ironic, it's the flipside of exactly the same reason. Bigcorps can steal with impunity because they have unlimited money to pay expensive lawyers. FOSS projects do not, so they cannot.
reply
No judge I’ve ever met gave a damn how much a party spent on legal resources. With rare exceptions, they care a great deal about achieving justice, and often bend over backwards to help indigent parties avoid prejudicing themselves. Keep in mind that there are no indigent parties in this debate; both major IP rights holders and the frontier AI companies are well capitalized.

(I worked in a federal district court for a while.)

reply
The problem is that money buys lawyers, and you need those to get justice. If the other side spends more, you are likely to lose.
reply
Which of these parties doesn’t have lawyers? (I’m talking about bigcorps stealing from bigcorps here.)

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.

reply
Not everywhere is the US.
reply
The tiniest bit of contamination can get a whole project shut down and the creators heavily fined if the lawyers are aggressive enough. It's not worth the risk to a project like Asahi. Generally the law is going to side with whomever has the most lawyers.
reply
none of this is incorrect, however, how freaking sad is it that in order to get any OS that's not locked down and owned by Apple on the hardware we buy and supposedly own, someone (together with whole open source organizations) has to risk utter financial ruin.

I hate the new system of no ownership and closed everything.

reply
Excited to see what you contribute to open source against one of the richest and most litigious companies in the world.
reply
Nothing. I hope those companies go bankrupt, I'm not underwriting their failure to support their customers with my time and effort.
reply
Cool. Excited to see you on the pitch next time you comment on a football game.
reply
It may not just be about IP but also code quality. As an example, TFA calls the user mode portion "slop" in need of cleanup.
reply
Apple is a huge company with strong silo culture. I only interviewed with them, but it feels to me like different orgs are run almost like entirely different companies. If his work didn't concern Mac, it's quite unlikely he'd have any special insider knowledge about it.
reply
If Apple open sourced its drivers this issue wouldn't exist. AI at last gives the "community" a chance to use the hardware they bought the way they want. It's unreasonable to expect anybody to code this kind of stuff "by hand" when automated tools exist.
reply
Even if this is the case, this is still a valuable contribution to learn upon.
reply
It’s taint. Anyone who looks at it can’t work on a real open source driver because they will have had access to information they’re not supposed to.

It won’t be clean room like the stuff Alyssa did.

reply
Can't this be used to make a clean room implementation? Have someone write a spec then someone else who is unrelated, implement it from scratch?
reply
"Person A was under NDA, so we got them to pass their knowledge to person B, then had person B do the work - that's clean-room, right?"

Judges, as far as I know, do not generally take kindly to such arguments.

reply
Wouldn't B's publication of the information make it by definition no longer a trade secret? It is now public knowledge, regardless of whether the current or former engineers might be liable for the original leak.

Any other interpretation would mean trade secrets have essentially infinite protection/NDAs apply to all of humanity.

reply
> 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.

reply
The point of a clean-room implementation is that the only thing passing from A to B is a detailed specification written from scratch, because functional details cannot be copyrighted.

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.

reply
So what if person a and person b are unrelated and person b found it on their own? There are countries in the global south that never had an industrial revolution and don't speak English and never had factories for export nor made anything in a factory industrially that isn't building material and food and maybe fuel for local consumption so they've never had an IP infringement case
reply
> what if person a and person b are unrelated and person b found it on their own

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.

reply
I mean person b found the work of person a on their own
reply
That’s the most abstract and esoteric argument I’ve ever heard I think
reply
The argument is not esoteric. An Apple employee working on a reverse engineered GPU driver might (intentionally or not) incorporate internal knowledge that they are contractually obligated to keep secret or write an implementation that is too close to proprietary code they had access to, to the point that it could be argued that it is a derived work.

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...

[2] https://en.wikipedia.org/wiki/ReactOS#Internal_audit

reply
Wasn’t that exactly the legal standard Compaq had to prove when they did a clean room implementation of the IBM BIOS?
reply
deleted
reply
I certainly dont care about hiding LLM contributions and all crazy anti-LLM policies, but I really hope author can share process completely so this can be reproduced by someone not working for Apple.
reply
> crazy anti-LLM policies

Weird how justified reasonable policies get the "crazy" label.

reply
Asahi state as one of its goals upstreaming Apple Silicon support into Linux Kernel and kernel does not have similar anti-llm policies.

Imagine what happen if OP submit patches upstream skipping Asahi and they gonna be accepted.

reply
Imagine how crazy it is to be throwing shade at someone for having ethics and holding themselves to a higher than required standard.
reply
Apple offer LLMs, so they are already on board with the LLM arguments.

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.

reply
Anti LLM is not justified, it's crazy. They are digging their own grave.
reply
Why would anyone care about either of these things in a negative sense?

Isn’t that just saying “he uses modern tools and has subject matter expertise”?

reply
deleted
reply
The LLM use wasnt the part that bothered me so much, but having had an Apple contract is bad.
reply
I’m making nothing of this, thanks.
reply