We don't use AI to help write code due to copyright concerns, it's against our policy. We obviously need to be very careful with what we're doing, and we can't be sure it hasn't seen Apple docs or RE'ed Apple binaries etc (which we have very careful clean-room policies on) in its training data. It also can't be guaranteed that the generated code is GPL+MIT compatible (as it may draw inspiration from other GPL only drivers in the same subsystems) but we wish to use GPL+MIT to enable BSD to take inspiration from the drivers.
Given that literally no one is enforcing this it seems like a moral rather than a business decision here no? Isn’t the risk here that your competitors, who have no such moral qualms, are just going to commit all sorts of blatant copyright infringement but it really doesn’t matter because no one is enforcing it?
I don't see open source as having "competitors". If someone wants to make a fork and use AI to write code (which I also think wouldn't be very useful, as there's no public documentation and everything needs to traced and RE-ed), they are welcome to. We're interested in upstreaming though, which means we need to make sure the origin of code and licence is all compatible and acceptable for mainline, and don't want to infringe on Apple's copyright (which they may enforce on a fork with less strict rules than ours).
AI wouldn't work here. The OP task was converting one open source driver in to another one for FreeBSD. Since Mac doesn't have open source drivers to start with, a person still has to do the ground research. At least until you can somehow give the AI the ability to fully interact with the computer at the lowest levels and observe hardware connected to it.
Someone else here suggested having an AI write a filter driver to intercept hardware communications on Windows and try to write a driver based on that, I presume macOS can also be coerced into loading such a driver?
That approach could work, though it'll require a lot of brute-forcing from the AI and loading a lot of broken kernels to see if they work. Plus, if audio drivers are involved, you'd probably blow out the speakers at least once during testing.
Still, if you throw enough money at Claude, I think this approach is feasible to get things booting at the very least. The question then becomes how one would reverse-engineer the slop so human hands can patch things to work well afterwards, which may take as much time as having humans write the code/investigate hardware traces in the first place.
We don't use AI to help write code due to copyright concerns, it's against our policy. We obviously need to be very careful with what we're doing, and we can't be sure it hasn't seen Apple docs or RE'ed Apple binaries etc (which we have very careful clean-room policies on) in its training data. It also can't be guaranteed that the generated code is GPL+MIT compatible (as it may draw inspiration from other GPL only drivers in the same subsystems) but we wish to use GPL+MIT to enable BSD to take inspiration from the drivers.
Given that literally no one is enforcing this it seems like a moral rather than a business decision here no? Isn’t the risk here that your competitors, who have no such moral qualms, are just going to commit all sorts of blatant copyright infringement but it really doesn’t matter because no one is enforcing it?
I don't see open source as having "competitors". If someone wants to make a fork and use AI to write code (which I also think wouldn't be very useful, as there's no public documentation and everything needs to traced and RE-ed), they are welcome to. We're interested in upstreaming though, which means we need to make sure the origin of code and licence is all compatible and acceptable for mainline, and don't want to infringe on Apple's copyright (which they may enforce on a fork with less strict rules than ours).
1 reply →
Who is a competitor for Asahi? What would that even entail?
> Given that literally no one is enforcing this
Presumably Apple's lawyers would enforce it.
2 replies →
Morals seem like a very good reason to not join those infringers.
AI wouldn't work here. The OP task was converting one open source driver in to another one for FreeBSD. Since Mac doesn't have open source drivers to start with, a person still has to do the ground research. At least until you can somehow give the AI the ability to fully interact with the computer at the lowest levels and observe hardware connected to it.
Someone else here suggested having an AI write a filter driver to intercept hardware communications on Windows and try to write a driver based on that, I presume macOS can also be coerced into loading such a driver?
That approach could work, though it'll require a lot of brute-forcing from the AI and loading a lot of broken kernels to see if they work. Plus, if audio drivers are involved, you'd probably blow out the speakers at least once during testing.
Still, if you throw enough money at Claude, I think this approach is feasible to get things booting at the very least. The question then becomes how one would reverse-engineer the slop so human hands can patch things to work well afterwards, which may take as much time as having humans write the code/investigate hardware traces in the first place.
This is like complaining Delorean didn't make spare parts for your homemade time machine.