Even if you assume APIs aren't copyrightable, I don't think anyone cared to implement CUDA itself except for Nvidia. There is really no point in proliferating such APIs, since there are OpenCL / Vulkan already which are open to begin with.
What someone could try implementing though, is translating CUDA into OpenCL (if that's possible). That would be useful to break lock-in.
What you miss is there is a reason why OpenCL didn't get traction and lack of tools translating CUDA to OpenCL is not one of them. OpenCL 2.0+ is lot better than previous versions but it is too little to late.
Legacy CUDA software would exist if OpenCL ecosystem was better. This is not the case. Code translation from CUDA to OpenCL is solution looking for a problem.
Ecosystem depends on CUDA, it doens't care where it's translated to, no? So it would work with translation, until it's properly rewritten to use open APIs. It's a solution for lock-in that limits your hardware choices, which is a problem. You don't need to look for the problem, it's pretty obvious.
> I thought the result of Oracle v. Google is that APIs can’t be copyrighted?
The result—not final yet—is that the Federal Circuit ruled APIs are eligible for copyright, but that ruling didn't create binding precedent that applies outside the Oracle v Google case. So future cases are still likely to produce the result that APIs can't be copyrighted, unless those cases also include the patent claims necessary to get them into the Federal Circuit for appeals.
