Hacker News Reader

Comment by maccard | Hacker News Reader

You need to remove all the calls to the SDK too.

Absolutely untrue. It's legal to reimplement a third party API, as upheld by the highest courts in both the US and the EU.

So of course you don't need to remove your lines of source code which call into an API.

Probably true, but that is probably also against the license agreement (even if unenforcable). Most companies don't want to take this risk (and potential legal costs) just to release code that won't bring them any (direct) revenue.

That's not the same thing - one is redistributing the API (which is what we're talking about here) and the other is implementing an API.

To be clear we are talking about releasing code which calls into an API. Agreed you can't redistribute somebody else's SDK without permission.

To use bullet physics as a hypothetical example, if my game was the hello world example [0], I would expect that practically that entire file would be un-distributable.

[0] https://github.com/bulletphysics/bullet3/blob/master/example...

Surely that part of the code is AT LEAST fair use? Or one has to be at the wrong part of THAT historical argument (not necessarily pointing at parent)?

(Yes, I would argue that this is exempt following the ‘functional’ argument)

"Oracle would like to know your location."

https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America....

Why is that?

Wouldn't the calling code be written (and thus copyrighted) by the company that wrote the game rather than the one that created the SDK?

Depends, if it’s code calling a console SDK API then you are bound by terms of the NDA to not publicly share it — forever. Even just function names!

More realistically, a drop of source code is basically painting a big target on your company to get sued by a troll. I’ve wanted to release my game’s source but am terrified of this.

Perhaps you could just rename the function names, structure fields, etc, to something different but similar?

e.g. instead of ps3_fly_up(...) you'd rename to something a bit more generic like sdk_float_up(...) or something like that.

It could require a bit of creativity and some work but with a sufficiently-intelligent IDE it'd just be a one-time rename per function name + structure name + field name.

A console game will have hundreds if not thousands of API calls, particularly in the io/gfx code

A good IDE can rename thousands of calls in a single command.

And all of the parameter types, e.g. btVector3 needs to become a new non-sdk specific name.

> It could require a bit of creativity and some work but <...>

Honestly, you can stop there. This is why it's not done - the value is small, it requires creativity and work and...

> just be a one-time rename per function name + structure name + field name.

https://sgringwe.com/2019/10/10/Please-just-stop-saying-just.... In this particular case "what about legal" pretty much stops the "just" dead in it's tracks.

> Depends, if it’s code calling a console SDK API then you are bound by terms of the NDA to not publicly share it — forever. Even just function names!

This is not true. API itself (function names and parameters) does not hold copyright. Otherwise you wouldn't have open-source applications on any proprietary OS, since they have the function calls of proprietary APIs inside.

What can be copyrighted are the header files itself: these you can't redistribute, as you can't redistribute the binary that is linked to the executable. Of course without these you wouldn't be able to compile and run the software, but you can reverse engineer the API from the function names and parameters and even the binary executable (because for an EU law reverse engineering for the purpose of substituting proprietary parts, that is this case, is allowed) and build a replacement for sure.

> What can be copyrighted are the header files itself: these you can't redistribute, as you can't redistribute the binary that is linked to the executable.

Note that while the exact header file is covered by copyright, the "information"/"facts" the header file describes (e.g. said function names, parameters, constants, etc) is not - at least as far as EU is concerned anyway (BTW the case you most likely have in mind wasn't for substituting proprietary parts but for interoperability between parts - i.e. it would still be valid for substituting one proprietary part with another proprietary part). This is also why different compilers for Windows have a "windows.h" (or language equivalent) with each having its own copyright but describing the exact same API.

(obviously this is for unsubstitutable fact-like information a header file contains and does not apply for any code like macros or inline methods like in C++ classes/templates)