5 ms·

I'd be fine if they put up their code with the proprietary parts removed. They can just include a FIXME stating that the physics engine/video player etc. is mis

I'd be fine if they put up their code with the proprietary parts removed. They can just include a FIXME stating that the physics engine/video player etc. is missing. If the community picks up the code, they can just replace the missing parts.

ironSkillet 3y ago
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.
- skrebbel 3y ago
  It can just “ERROR file physicslib.h not found”. Nobody says open source code must compile or work.
  - maccard 3y ago
    You need to remove all the calls to the SDK too.
    - someplaceguy 3y ago
      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?
      - hesdeadjim 3y ago
        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.
        someplaceguy 3y ago
        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.
        cobalt 3y ago
        A console game will have hundreds if not thousands of API calls, particularly in the io/gfx code
        someplaceguy 3y ago
        A good IDE can rename thousands of calls in a single command.
        maccard 3y ago
        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.html 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.
        alerighi 3y ago
        > 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.
    - plank 3y ago
      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)
      - mostthingsweb 3y ago
        "Oracle would like to know your location." https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America....
    - orra 3y ago
      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.
      - kevincox 3y ago
        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.
      - maccard 3y ago
        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.
        orra 3y ago
        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.
        maccard 3y ago
        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/examples/HelloWorld/HelloWorld.cpp https://github.com/bulletphysics/bullet3/blob/master/example...
- alerighi 3y ago
  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.
maccard 3y ago
That's gojng to be a hell of a lot of effort, unless the third party libraries were abstracted out in the first place.
grogenaut 3y ago
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.
- torginus 3y ago
  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?
  - grogenaut 3y ago

ironSkillet 3y ago

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.

skrebbel 3y ago
It can just “ERROR file physicslib.h not found”. Nobody says open source code must compile or work.
- maccard 3y ago
  You need to remove all the calls to the SDK too.
  - someplaceguy 3y ago
    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?
    - hesdeadjim 3y ago
      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.
      - someplaceguy 3y ago
        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.
        cobalt 3y ago
        A console game will have hundreds if not thousands of API calls, particularly in the io/gfx code
        someplaceguy 3y ago
        A good IDE can rename thousands of calls in a single command.
        maccard 3y ago
        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.html 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.
      - alerighi 3y ago
        > 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.
  - plank 3y ago
    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)
    - mostthingsweb 3y ago
      "Oracle would like to know your location." https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America....
  - orra 3y ago
    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.
    - kevincox 3y ago
      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.
    - maccard 3y ago
      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.
      - orra 3y ago
        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.
        maccard 3y ago
        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/examples/HelloWorld/HelloWorld.cpp https://github.com/bulletphysics/bullet3/blob/master/example...
alerighi 3y ago
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.

maccard 3y ago

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

grogenaut 3y ago

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.

torginus 3y ago
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?
- grogenaut 3y ago