That's not even so much what I meant. The "game" isn't the engine; and so the "game" is open source. You're free to modify and redistribute everything that constitutes the game. To play the game, you need the game engine, similar to how running a program requires a machine (real or virtual) with a compatible ISA. But there's nothing forcing you to use a closed-source implementation of the game engine. If an open-source implementation of the engine doesn't exist, you're always free to write one.
Nobody ever says that a program being written for closed-source hardware necessarily implies that the program can't be open source. Because, of course, you can just write your own open VM for that same hardware. Saying that e.g. Gameboy Advance home-brew is all closed source, because the reference implementation of the hardware is closed source, is nonsensical. People are free to write, modify, and run GBA home-brew. Doing the last one just requires an emulator for most people, which is an everyday tool for programmers (given that many languages target abstract machines like the JVM or Erlang's BEAM, where the resulting bytecode ISA is only reified as an emulator.)
I think it's dishonest and unexpected to consider the engine to not be part of the game. When I buy a game, I expect that it comes with an engine, in addition to the art and the business logic. I buy with the expectation that it'll run on the stated hardware platform, e.g. Windows and some specific version of DirectX.
In that particular case, DirectX is a set of APIs provided by the OS vendor to develop games on their OS. It's part of Microsoft's platform.
In the GBA's case, Nintendo's platform is the hardware and their SDK. If I'm remembering correctly, there's an open SDK to replace Nintendo's, because the latter isn't (legally) available to homebrewers. But, the libraries linked from the SDK are universally distributed with the game. If someone wrote homebrew on the Nintendo SDK, I'd say it's impossible for it to be "open", because not everything that is distributed as part of the game is open.
Going another direction, with a specific example: The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format. Just have to write the engine, right?
If someone wrote homebrew on the Nintendo SDK, I'd say it's impossible for it to be "open", because not everything that is distributed as part of the game is open.
I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
Consider, as a contrasting example, C#. Microsoft's official SDK is closed source. Mono is open-source. But Mono's runtime libraries are ABI-compatible with the official runtime libraries.
In the case of the GBA, you'd expect/require a binary release to be "shipped with" the official runtime libraries linked in. But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format.
I would say that this is open-source, yes. Consider the case where someone uploaded, say, the "business logic" (and assets) of an RPG Maker game, back when ASCII/Enterbrain's own runtime was the only one available. Now there are plenty of open, ABI-compatible interpreters. So this is at least open-source code now, no?
Or, for another example, consider original-Doom .wad files. If you released one of those back in 1993 under a GPL license, it might not mean much—but today there are open DOOM clones for literally everything. One difference here is that those interpreters don't have Doom's original IP (asset packs) included in them; they expect you to add them in. But does that make the .wad file itself less open as a product? Not everything needs to be standalone. You could have an open-source expansion or mod for a closed-source game. You can interpret a level or level-pack in just such a manner.
I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
I think it comes down to the fact of SDK libraries being statically, and inextricably, linked into the ROM.
[about DF2:JK] I would say that this is open-source, yes.
I'd say it isn't. First, the license is just as closed as the rest of the code. Second, it's not "the game" unless there's an engine to pair the data+code elements with. And since there's no open engine to go with the closed-but-readable code, I wouldn't use the words "open source" with any part of it.
So this is at least open-source code now, no?
If an open engine is available, then the combination of the open game logic and open game engine would be open. Otherwise you could say "An Open engine for X" or...well, a nicely-packaged way to describe open game assets on a closed engine would be called "a mod for X" or a "total conversion", I suppose.
But does that make the .wad file itself less open as a product?
The .wad itself could be open, but it's not "a game". It's a set of game assets. Pair it with an engine, and it's a game. Pair it with a different engine, and the same assets might be a significantly different game. The whole wad+engine game couldn't be open until at least late 1997 when the Doom source was released.
But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
Right. C#, Java, etc are expected to have an external, completely separate runtime as a dependency. When there isn't an open runtime available, it's the situation that used to be called something like "the Java trap".
If an open-source implementation of the engine doesn't exist, you're always free to write one.
This is a very strange interpretation.
When a piece of software that is released under a free license has a crucial non-free dependency, it is effectively non-free. As the software only works with the non-free dependency, but that dependency cannot be conveyed along with the free part, the whole thing cannot legally be distributed and thus is non-free.
The reason I take that view, is that the ability to use the software isn't actually a part of what makes software open source! As long as people have all the code, and can modify it, and can redistribute their modifications, the code is open-source... whether or not you can run it.
Consider: there are also hardware platforms that have effectively ceased to exist over the years. If you wrote a program for one of these platforms, and it was open-source, would you now consider the program closed-source, because—given that the platform hardware doesn't exist any more—you can't run the software any more?
No. Why not? Because open source is about the source, not about the binary. The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
Why not? Because open source is about the source, not about the binary.
If you have the platform and the source, but you can't run the program, then I wouldn't consider it "open source". At least not in the usual sense of FOSS. It's not just about the source; it's about the freedom to study and modify the source, produce improved versions of the original binary, and distribute that binary and the source that created it.
The division between game and platform is lower in the stack than the engine.
The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
I agree with that statement, but it's a different argument than you were making before.
Comments
That's not even so much what I meant. The "game" isn't the engine; and so the "game" is open source. You're free to modify and redistribute everything that constitutes the game. To play the game, you need the game engine, similar to how running a program requires a machine (real or virtual) with a compatible ISA. But there's nothing forcing you to use a closed-source implementation of the game engine. If an open-source implementation of the engine doesn't exist, you're always free to write one.
Nobody ever says that a program being written for closed-source hardware necessarily implies that the program can't be open source. Because, of course, you can just write your own open VM for that same hardware. Saying that e.g. Gameboy Advance home-brew is all closed source, because the reference implementation of the hardware is closed source, is nonsensical. People are free to write, modify, and run GBA home-brew. Doing the last one just requires an emulator for most people, which is an everyday tool for programmers (given that many languages target abstract machines like the JVM or Erlang's BEAM, where the resulting bytecode ISA is only reified as an emulator.)
I think it's dishonest and unexpected to consider the engine to not be part of the game. When I buy a game, I expect that it comes with an engine, in addition to the art and the business logic. I buy with the expectation that it'll run on the stated hardware platform, e.g. Windows and some specific version of DirectX.
In that particular case, DirectX is a set of APIs provided by the OS vendor to develop games on their OS. It's part of Microsoft's platform.
In the GBA's case, Nintendo's platform is the hardware and their SDK. If I'm remembering correctly, there's an open SDK to replace Nintendo's, because the latter isn't (legally) available to homebrewers. But, the libraries linked from the SDK are universally distributed with the game. If someone wrote homebrew on the Nintendo SDK, I'd say it's impossible for it to be "open", because not everything that is distributed as part of the game is open.
Going another direction, with a specific example: The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format. Just have to write the engine, right?
I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
Consider, as a contrasting example, C#. Microsoft's official SDK is closed source. Mono is open-source. But Mono's runtime libraries are ABI-compatible with the official runtime libraries.
In the case of the GBA, you'd expect/require a binary release to be "shipped with" the official runtime libraries linked in. But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
I would say that this is open-source, yes. Consider the case where someone uploaded, say, the "business logic" (and assets) of an RPG Maker game, back when ASCII/Enterbrain's own runtime was the only one available. Now there are plenty of open, ABI-compatible interpreters. So this is at least open-source code now, no?
Or, for another example, consider original-Doom .wad files. If you released one of those back in 1993 under a GPL license, it might not mean much—but today there are open DOOM clones for literally everything. One difference here is that those interpreters don't have Doom's original IP (asset packs) included in them; they expect you to add them in. But does that make the .wad file itself less open as a product? Not everything needs to be standalone. You could have an open-source expansion or mod for a closed-source game. You can interpret a level or level-pack in just such a manner.
I think it comes down to the fact of SDK libraries being statically, and inextricably, linked into the ROM.
I'd say it isn't. First, the license is just as closed as the rest of the code. Second, it's not "the game" unless there's an engine to pair the data+code elements with. And since there's no open engine to go with the closed-but-readable code, I wouldn't use the words "open source" with any part of it.
If an open engine is available, then the combination of the open game logic and open game engine would be open. Otherwise you could say "An Open engine for X" or...well, a nicely-packaged way to describe open game assets on a closed engine would be called "a mod for X" or a "total conversion", I suppose.
The .wad itself could be open, but it's not "a game". It's a set of game assets. Pair it with an engine, and it's a game. Pair it with a different engine, and the same assets might be a significantly different game. The whole wad+engine game couldn't be open until at least late 1997 when the Doom source was released.
Right. C#, Java, etc are expected to have an external, completely separate runtime as a dependency. When there isn't an open runtime available, it's the situation that used to be called something like "the Java trap".
This is a very strange interpretation.
When a piece of software that is released under a free license has a crucial non-free dependency, it is effectively non-free. As the software only works with the non-free dependency, but that dependency cannot be conveyed along with the free part, the whole thing cannot legally be distributed and thus is non-free.
The reason I take that view, is that the ability to use the software isn't actually a part of what makes software open source! As long as people have all the code, and can modify it, and can redistribute their modifications, the code is open-source... whether or not you can run it.
Consider: there are also hardware platforms that have effectively ceased to exist over the years. If you wrote a program for one of these platforms, and it was open-source, would you now consider the program closed-source, because—given that the platform hardware doesn't exist any more—you can't run the software any more?
No. Why not? Because open source is about the source, not about the binary. The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
If you have the platform and the source, but you can't run the program, then I wouldn't consider it "open source". At least not in the usual sense of FOSS. It's not just about the source; it's about the freedom to study and modify the source, produce improved versions of the original binary, and distribute that binary and the source that created it.
The division between game and platform is lower in the stack than the engine.
I agree with that statement, but it's a different argument than you were making before.
And you won't get far with source modifications if you can't run the program.
That would make all GPL-licensed Windows software non-free. Not even the FSF thinks that's the case.