Removing these proprietary parts can actually be a lot of work or potentially impossible without a major refractor, especially if they're foundational to gameplay, like a physics engine.

It can just “ERROR file physicslib.h not found”. Nobody says open source code must compile or work.

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

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)

> you are bound by terms of the NDA

> This is not true.

You usually have to follow contracts you sign.

Not where the law says such terms are unenforceable.

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....

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...

Why? You just ship the code that you wrote without the third part libraries. I don't think you did copy/paste the library code inside your own, it's probably linked to the executable in some form. Of course it would be impossible to compile the program without it, but as it's said, the component may be recreated by the open-source community, or sourced form the closed-source game in some other ways.

That's gojng to be a hell of a lot of effort, unless the third party libraries were abstracted out in the first place.

I've worked on games before. We ported our game to havock between versions. That took 8 months for one dev. The code review was 3 weeks. Ripping ours out was a month by itself. There were several libraries like that. The sound system was similar and we had to upgrade it every game which was similar work to havock. Heck there was a really simple font to bitmap lib/utility we used and that would have taken several months to replace. A month to rip out.

I moved us from PlayStation 3 to PlayStation 4 for our debugging UI and literally just removing all the calls to the old debugging UI system was something like 2 weeks my only goal there was to get it to not compile. Wiring up all 3,900 debug UI connection points to the engine with access to all the rest of the game engine library and having written parts of both systems in the engine and the debugging library and the new UI library still took me almost 2 weeks I did it with both systems working at the same time which was actually easier than doing a full rip out. The studio I worked at tried really hard not to use proprietary libraries and it was a big deal for us using havoc but we needed to they ended up going back for the next title. They also wrapped literally every library with shims to make it easier to Port but things like physics engines are just basically impossible to wrap fully as our sound engines and font libraries the implementation details leak into everywhere.

The suggestion you're making is a very large amount of work probably on the level of several engineers for several years on a Triple-A title now you're talking like a million dollars for the company to open source it and locking up some good devs for a year or more. There's literally no economic trade off in doing that unless you can come up with a way to make one.

Porting would be an okay economic trade off there.

Thanks for taking your time to answer my suggestion in detail. I was just trying to suggest something very simple - just don't include the files that you don't have the rights to - so in your case just don't publish those font and physics library files. No need to completely rip out all references to it.

The resulting code will be broken, but if the community cares enough, they can fix it up.

I don't think this would be a huge effort to do - do you see any issues (legal or otherwise) with this approach?

We did have our code mostly sorted into 3p and 1p... However I'm not a lawyer and not sure how the taint might leak up. I forget where Google/oracle landed on apis being copyright but havock ids and other concepts leak into your code everywhere. Heck even proprietary details might or algos. It would still be hard and the lawyers would be skeptical. You'd need a business case besides goodwill to get over those humps.

I bet a ton of companies don't follow those best practices. And there's also the fact that you've now exposed yourself to litigation where some dev violated copyright of previous companies or libraries or whatever and put it in the wrong place or copied it. Before open sourcing you were fine. After you have essentially incriminated yourself.

The doom/quake case is kinda an exception. In that you likely (I'm guessing) had Carmack who is a founder/owner, deeply understand the tech base, understands cost and estimates, likely understands licensing quite well, able to go do the work, but also able to make the cost benefit tradeoff and override objections in some cases. That's not common in many companies.