456
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 12 Jan 2024
456 points (97.7% liked)
RetroGaming
19537 readers
77 users here now
Vintage gaming community.
Rules:
- Be kind.
- No spam or soliciting for money.
- No racism or other bigotry allowed.
- Obviously nothing illegal.
If you see these please report them.
founded 1 year ago
MODERATORS
Hi, Android dev here. This is a different issue albeit a tangential one. But ultimately it has no bearing on the matter.
The Oracle v Google case revolves around Google's reimplementation of the Java APIs on the Android platform. This is key. Back when Android started, they used Apache Harmony to provide the Java API set on Android. Harmony was an open source implementation of the Java API set. Sun (the creator of Java) didn't care, they held the copyright to the Java implementation, but made their money in different ways, so they let the Harmony project live.
Fast forward a decade. The Apache Harmony project is dead. Android is stuck at Java 6 level APIs because of it, Android devs are annoyed they can't even get Java 8 features. And Oracle bought Sun, and is monetizing the shit out of Java. They started charging money for the official Java SDK. Google didn't want to pay Oracle, so they started reimplementing the newer Java APIs into Android, to pick up where Harmony had left off. Oracle saw this, found some code in Google's reimplementation that was similar to the official implementation from Oracle (which is out in the open in the openjdk project) and sued the shit out of them looking for the payday they didn't get when Google refused to pay Oracle a license.
Ultimately, the SCOTUS ruling says that APIs themselves are not copyrightable (ie you can't copyright the .toString() function name). But you can copyright the implementation of that function. Ultimately Oracle still won a bit, because they found something like 6 function reimplementations that Google could not successfully defend as clean room implementations.
Why this is irrelevant to the Portal64 issue, is because the dev is not using the open source reimplementation of the Nintendo APIs. He's literally using the Nintendo owned implementation of the APIs. That's why he says he needs to switch to open source libraries. Those open source libraries have the same functions within them, but the implementation of said functions aren't the same as the Nintendo ones (or they are and Nintendo just hasn't sued the project into oblivion yet, I have no idea about the details).
I like tech history. Loved your explanation about the Google vs Oracle legal battle.
Then the people here using the term "API" should have rather used "libraries" or "frameworks" or whatever. I cannot look myself because the Github repo is private now.
Well, libraries are collections of APIs and sdks are usually collections of libraries. So they're unfortunately kind of interchangeable when discussing them. But I agree with you the correct thing would be to say they're using Nintendo's proprietary libraries.
An API is a specification of what functions are called and how they behave. See for example "Microsoft Windows provides the Win32 API" and "WINE provides the Win32 API on Linux" and also "Photoshop provides an API to write plugins" and "Affinity Photo provides the Photoshop API to support Photoshop plugins".
When people, who don't even know that finished the Portal64 ROM uses original Portal PC art assets copyrighted by Valve, try to lecture me about Valve acting as a henchman for Nintendo because of Nintendo APIs, I obviously dismiss them because they clearly have no clue about anything, even if by pure luck they may have a point regarding your definition of API use.