Packaged emulators specifically refer to the case where you're selling your own game and wrapping it in an emulator to do so. For example, all the old iD games on Steam are wrapped in DOSBox.
In that specific case, the player has access to all the game files, and it's trivially easy to extract DooM out of the wrapper and play it somewhere else. I would agree that the GPL's "mere aggregation" language probably covers this particular use case - but I use the weasel word because the FSF's FAQ[0] about it is uncertain. This particular sentence comes to mind:
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Pretty much any program whose responsibility it is to host other programs (either OS kernels or emulators) is offering up interfaces that will carry intimate details of the host into the guest. In fact, this is precisely the reason why emulator development is a never-ending rabbit hole of implementing other people's bugs to get games to work. Another example of 'intimate communication' would be something like io_uring, where the OS kernel and user program are writing into ring buffers and trading ownership over subordinate data buffers around.
While the FAQ says a judge would ultimately decide each case on its own, practically speaking judges are going to defer to the guidance of the people who wrote the license unless there are facts to the contrary (e.g. an emulator developer said it's OK to aggregate game and emulator this way and then tried to change their mind). If Stallman says "sharing intimate details of execution constitute combination" then judges will take his side.
Another potential argument comes about if we swap out Steam for, say, the iOS App Store. Apple doesn't provide any ability to extract resources from iOS apps[1], nor do they allow shipping unpackaged emulators[2], so the user cannot meaningfully disaggregate the emulator from the game program as it has shipped on the App Store. Why would this specific case not be combining two programs into one?
[1] They aren't encrypted per se, but you don't have full filesystem access as the owner of the device, so...
[2] Apple doesn't want users downloading third-party code. This actually has nothing to do with the GPL - you ARE allowed to ship GPL code, if you provide custom EULA language that says that the GPL prevails over the App Store EULA.
Interesting how differently how one can view things.
I'd say, emulators are the easiest to defend. First and foremost, they emulated something which existed before. And the fact that there are different hardware and software emulations, several of them completely different to one another internally, proves that the program does not the intimate details of execution. Also, I read somewhere that especially if something existed before is a big difference when judging a GPL program. If a GPL program clones a previously existing behaviour, how can you with a straight face say an aggregate is derivative?
(Of course, there can be other things like GUI integration which muddies things up.)
In that specific case, the player has access to all the game files, and it's trivially easy to extract DooM out of the wrapper and play it somewhere else. I would agree that the GPL's "mere aggregation" language probably covers this particular use case - but I use the weasel word because the FSF's FAQ[0] about it is uncertain. This particular sentence comes to mind:
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Pretty much any program whose responsibility it is to host other programs (either OS kernels or emulators) is offering up interfaces that will carry intimate details of the host into the guest. In fact, this is precisely the reason why emulator development is a never-ending rabbit hole of implementing other people's bugs to get games to work. Another example of 'intimate communication' would be something like io_uring, where the OS kernel and user program are writing into ring buffers and trading ownership over subordinate data buffers around.
While the FAQ says a judge would ultimately decide each case on its own, practically speaking judges are going to defer to the guidance of the people who wrote the license unless there are facts to the contrary (e.g. an emulator developer said it's OK to aggregate game and emulator this way and then tried to change their mind). If Stallman says "sharing intimate details of execution constitute combination" then judges will take his side.
Another potential argument comes about if we swap out Steam for, say, the iOS App Store. Apple doesn't provide any ability to extract resources from iOS apps[1], nor do they allow shipping unpackaged emulators[2], so the user cannot meaningfully disaggregate the emulator from the game program as it has shipped on the App Store. Why would this specific case not be combining two programs into one?
[0] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htm....
[1] They aren't encrypted per se, but you don't have full filesystem access as the owner of the device, so...
[2] Apple doesn't want users downloading third-party code. This actually has nothing to do with the GPL - you ARE allowed to ship GPL code, if you provide custom EULA language that says that the GPL prevails over the App Store EULA.