https://www.eff.org/cases/oracle-v-google
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
I meant to imply that unlike the case with Windows/Wine, there is no reimplementation of the overwhelming majority of macOS APIs. So if you wanted to do this now, you could only do it by copying frameworks directly from macOS (which some people are doing for various reasons), and that does have some potential legal issues.
Theoretically, a reimplementation is possible. It doesn't exist, it's a huge project (far, far bigger than GNUstep), and as someone notes down-thread, it's also a moving target. There are also uncounted numbers of bugs in the current implementation of Apple's APIs, and for many things to work correctly you'd need to implement the bugs too since developers have designed around them.
Yes, Wine exists. But Wine started in 1993. The idea that a bit of hard work by some good developers is going to provide a reimplementation of the macOS frameworks in a year or three strikes me as without any foundation in reality.
And you're right - the Cocoa API continues to evolve, so if the goal is "source compatible with latest and greatest macOS APIs" it's hard to see how a small group of open source devs can out-run the sum totality of every API engineer at Apple.
I have similar feelings about cross-platform tools like Flutter as well - the idea in a vacuum is reasonably sound, but then you run into the basic scale problems of maintaining compatibility with a moving target - a moving target that has >10x more staffing than you do.
That decision only applies in the USA. I think it will be undetermined in many jurisdictions.
IBM hasn't been doing that for decades, despite the supreme court decision being quite recent - I think that was more about clean room reimplementation than APIs.
My point wasn't about ruling differently but the lack of rulings/laws making it explicitly legal creating uncertainty and opportunities for Oracle/Apple to go after people. Some countries have other ways to deal with it too, e.g. NZ allows reverse engineering for compatibility purposes, which seems likely to cover APIs (not sure, haven't needed to know).
As an example of how this works in practice, the disassembler/decompiler Hopper has both MacOS and Linux versions that are compiled from the same code.
Now, how successful they'll be extending the open source frameworks to made this useful in compiling non-trivial software that wasn't written with "dual compatibility" is a fair question, but the starting pieces are there, and patching the compilers and creating a copy of MacOS's filesystem layout would go a long way in making it easier to compile MacOS software on FreeBSD/GNUstep.
And in any event, so far as doing it legally, I don't see why this would be any less legal than Wine's recreation of the Win32 API/libraries. Only difference is Apple might be more litigious than Microsoft, but Microsoft doesn't exactly lie down to software theft...
I was following and trying to use GNUstep 15 years ago, and they were constantly chasing a moving target and were not managing to catch up. (Plus naturally the reimplementation bugs, plus the differences in interpretation of the "spec" which forced the programmer to be very careful and not take shortcuts.)
That's the huge issue when you are trying to reproduce an API which is not under your control by any mean, and is still alive and changing.
It had to be, it was forked from KHtml, which was GPL.
Those frameworks are also a tiny part of the full set that you need to build non-trivial software on macOS.
Audio? Video? so much more stuff that nobody has ever tried to reimplement the APIs for.
Yes, such a reimplementation would be legal,but Wine has been a project for 20+ years and has a huge headstart compared to any idea of doing this for macOS.
But yet, I misunderstood the GP comment, and what I said was not really appropriate in that context.
Why? Things like Wine and Proton exist and Windows is proprietary.
There is absolutely no equivalent for macOS frameworks. GNUStep is a tiny part of the picture, and in addition has not kept up with the fairly radical changes that Apple has introduced to the frameworks that GNUStep does correspond to.
That may have been incorrect.
This is no more menace to them than ReactOS for Microsoft.
Hard to see how this can be done legally. The libraries (sorry, Frameworks) that make up the user-space runtime for macOS are all proprietary. There's no replacement for the most important parts of it.