ZDoom/GZDoom/Zanondrum license compatible with commercial software?

[mmx]

I'm interested in creating my own game on top of the Zanondrum codebase, but i'm not sure if i'm allowed to. I assumed Doom was under GPL, which would be perfect: i want to release the source-code, but i will sell the game data (my own art, music, etc.) and compiled binaries.

However, i've noticed that the licensing is quite a mess: There's the BUILD license, the DOOM license, + FMOD license. Is there any engine that is 100% GPL?

[Gez]

Right now, the Build license is no longer an issue: all the Build code was removed except for one voxel drawing function, which Ken Silverman agreed to allow to relicense as GPL; so GZDoom will be able to switch to the GPL license eventually.

What's the holdup, then? There are two:

• FMOD. Removing FMOD and using only OpenAL would remove that obstacle, though.
  
• OPL emulation. The MUSLIB code is under an annoying licens and it needs to be replaced by something else. In addition there's an OPL core under the MAME license but I've heard that MAME code was now dual-licensed as GPL so that one is no longer an issue.
  
• Not a holdup: the Doom Source License code from Doom, Heretic, or Hexen is already dual-licensed as GPL.

So basically, all that's needed is removing FMOD support and replacing the MUSLIB code and you can switch the Doom, Build, and MAME code to GPL and have GZDoom fully GPL-compatible.

In the meantime: look at Nash's GZDoom-GPL fork. It removes the code under incompatible licenses and so can be used for commercial projects under the terms of the GPL.

[Graf Zahl]

The main obstacle is MUSLIB. We need OPL to have at least one out-of-the-box MIDI software synth that doesn't require an additional download.

Removing FMOD is just flipping a switch in the project and removing one source file and a few settings to setup linking to FMOD, i.e. a 10 minute job.

Of course once the switch is made I'll make sure that there will be some drop-in solutions for better MIDI quality that the engine will automatically detect if present.

Of course I have no idea what may happen to Zandronum if GZDoom changes its license and later incorporates some GPL-only code.

[Rachael]

I'm guessing they'll have to change too, in order to keep up.

Maybe a future project for me will be to see what music libraries I can get working with Nash's project. Ideally it should be possible to rebase that onto GZDoom once the license changes. I'm hoping it will not be as difficult and as invasive as my other two recent major projects have turned out to be...

[Graf Zahl]

It's not so much about getting a music library to work. I don't really think that this needs work, ZDoom already got enough MIDI synths.
Including Fluidsynth into the distribution is not an issue, it's the sound fonts that would inflate it.

[Jon]

mmx said:

I'm interested in creating my own game on top of the Zanondrum codebase, but i'm not sure if i'm allowed to. I assumed Doom was under GPL, which would be perfect: i want to release the source-code, but i will sell the game data (my own art, music, etc.) and compiled binaries.

So, this is all great news (the stuff others have posted). For your needs, you could probably disable or remove the remaining trouble bits if you are in a hurry, or wait for the cleanup to finish.

mmx said:

However, i've noticed that the licensing is quite a mess: There's the BUILD license, the DOOM license, + FMOD license. Is there any engine that is 100% GPL?

Most of the other (non-zdoom derived) source ports are GPL: Doom Legacy, Prboom, Prboom+, Boom, MBF, Eternity, Chocolate Doom, Crispy Doom, Doom Retro, Doomsday, ReMooD, Risen3D, Odamex off the top of my head.

[LexiMax]

The OP asked about Zandronum specifically. Since it uses an older version of ZDoom (2.5.0), the answer is likely more complicated than for more recent versions.

However, is building a new game on top of (G)ZDoom is necessarily a good idea? On one hand, the engine is capable of quite a bit, considering what it was built on top of. But there's just SO MUCH in the engine that is specific to the 90's Doom engine games that seems like it would be of dubious value to developers. ACS? Old map and content formats? All those compatflags? Some of those dmflags too (jumping, freelook, etc.)? Pass-the-inputs multiplayer? The dozenss of domain-specific definition files?

This is an actual question, not a rhetorical one.

[VGA]

Well if you release your own game, you will fork the source port and provide your own executable. So you can hardcode whatever settings you want and allow the rest to be changed by options like a more modern game.

So the user does not need to have any idea about all that you mentioned, he just runs the game, there are some basic video, sound and control options.

[Rachael]

AlexMax said:

However, is building a new game on top of (G)ZDoom is necessarily a good idea? On one hand, the engine is capable of quite a bit, considering what it was built on top of. But there's just SO MUCH in the engine that is specific to the 90's Doom engine games that seems like it would be of dubious value to developers. ACS? Old map and content formats? All those compatflags? Some of those dmflags too (jumping, freelook, etc.)? Pass-the-inputs multiplayer? The dozenss of domain-specific definition files?

For indie developers, none of those are a huge issue. It would not be the first time an engine was heavily modded to suit someone's needs. And more importantly - a person has a habit to create on what they know.

Is there better out there? Of course. A game on UE4 will sell a whole lot better than any game on GZDoom ever would but that does not mean a GZDoom-based title will never be successful. In the end it really comes down to the amount of effort you're willing to put in to make the experience of playing it a positive one. But that comes with a huge caveat: outside of the 2.5D mapping scheme that GZDoom supports, doing pretty much anything else with any other engine is really a whole lot easier. In fact, arguably, it's almost more worth it to take a Doombuilder-based map and simply convert it to a 3D format that is supported by a more modern engine and just run with it.

But the fact that people don't do that is actually a positive thing, in my opinion, and I think we may yet see some titles that will be endearing and fun to play. The Doom engine has proven time and again that Doom will never be the end-all-be-all of idTech 1, and that more can still possibly come. It is what we make of it.

[Death Egg]

In the meantime, if you are interested in checking out other GPL ports, you could check out Eternity Engine. It's been growing leaps and bounds the last couple of years, I could easily see it becoming the breakthrough popular port in another five years or so, tied with 3DGE.

[Lollie]

Maybe of interest, there's a team making a new game with the Build engine, to be published by 3D Realms. Good number of screenshots on their Twitter page.

Good luck with your project! It's always cool to see new games built on (or made to emulate) classic game engines.

[chungy]

Jon said:

Most of the other (non-zdoom derived) source ports are GPL: Doom Legacy, Prboom, Prboom+, Boom, MBF, Eternity, Chocolate Doom, Crispy Doom, Doom Retro, Doomsday, ReMooD, Risen3D, Odamex off the top of my head.

Mind that most ports tend to not be cautious about being clean of non-free components. PrBoom(-Plus) contains a few resources from or derived from Wolf3D and Doom, Eternity does the same, and I can't speak for most of the rest of the list -- I'd guess Chocolate, Crispy, and Odamex are the best candidates for being 100% DFSG-compatible.

[Gez]

There's a distinction to make between code and data. The non-free stuff is data such as the MBF dog sprites from Wolfenstein and font characters (for the ports' custom menus and such like).

I believe PrBoom+ has alternative free replacement graphics that can be used to comply with terms such as those of the DFSG.

And if you make your own game with your own data, you can just remove them altogether as you will not need them at all.

[Danfun64]

Gez said:

I believe PrBoom+ has alternative free replacement graphics that can be used to comply with terms such as those of the DFSG.

Yep. When compiling PrBoom-Plus, you need to do "configure --disable-nonfree-graphics" in order to produce DFSG compliant executables/data wads (despite the name, it disables more than just graphics)

[Agentbromsnor]

AlexMax said:

The OP asked about Zandronum specifically. Since it uses an older version of ZDoom (2.5.0), the answer is likely more complicated than for more recent versions.

However, is building a new game on top of (G)ZDoom is necessarily a good idea? On one hand, the engine is capable of quite a bit, considering what it was built on top of. But there's just SO MUCH in the engine that is specific to the 90's Doom engine games that seems like it would be of dubious value to developers. ACS? Old map and content formats? All those compatflags? Some of those dmflags too (jumping, freelook, etc.)? Pass-the-inputs multiplayer? The dozenss of domain-specific definition files?

This is an actual question, not a rhetorical one.

If you're making a Doom-like FPS game, it's probably your best bet as an indie developer.

Unreal Engine 4 and the like can make modern games look cool, but they rarely provide the level of control that you would have as a player in Doom.

I would also argue that once you get the hang of creating sprites in (G)ZDoom using DECORATE / ZScript, it's hard to go back. The fact that it is frame-based will probably be seen as a limitation by most people, but from a modding / developer perspective it makes it a breeze to create actors and set their frames and behaviour accordingly. Quite unlike a typical modern engine where creating actors is largely a chore.

[Edward850]

Agentbromsnor said:

Unreal Engine 4 and the like can make modern games look cool, but they rarely provide the level of control that you would have as a player in Doom.

Uhh... what? UE4 is a complete engine pipeline with a combination of both source code and scripting. You have absolute control over how it functions, and arguably more so than any Doom sourceport could provide.
You could make whatever you damn want in UE4. It's designed to be that from the ground up.

Also what you said doesn't even make much sense on reflection. "level of control that you would have as a player" is irrelevant when talking about development, so either you typoed catastrophically or you seem to have missed the context of this thread.

[Agentbromsnor]

Edward850 said:

Uhh... what? UE4 is a complete engine pipeline with a combination of both source code and scripting. You have absolute control over how it functions, and arguably more so than any Doom sourceport could provide.
You could make whatever you damn want in UE4. It's designed to be that from the ground up.

Also what you said doesn't even make much sense on reflection. "level of control that you would have as a player" is irrelevant when talking about development, so either you typoed catastrophically or you seem to have missed the context of this thread.

I was talking about player-control on the level of input. I've played UE 4 games, and they all suffer from input-latency. GZDoom doesn't have this, or at least not on this level.

Edward850 said:

"level of control that you would have as a player" is irrelevant when talking about development

What the fuck are you babbling about? How the player controls is absolutely fundamental to creating a memorable game. If the controls don't feel tight, it can potentially ruin the game experience.

[Edward850]

Considering Unreal Engine 4's flagship game is Unreal Tournament 4, and if such a problem with that game existed that would be be critical issue numero-uno, your issue with input latency is either misinformed or independent of the engine itself.

It's not without credibility that games using UE4 have had issues, but this is down to how the developer themselves handles the issue. Doom is a remarkably bad comparison in terms of input timing issues due to how cheap the playsim is to run, and it's not as if people haven't reported things like input-latency in ZDoom and GZDoom before, or other things like floaty mouse controls or GZDoom's general instability on ATI/AMD GPUs.

[Agentbromsnor]

Edward850 said:

Considering Unreal Engine 4's flagship game is Unreal Tournament 4, and if such a problem with that game existed that would be be critical issue numero-uno, your issue with input latency is either misinformed or independent of the engine itself.

I've been playing Unreal Tournament 1 for many years, and I've played it with both friends and tournament-players who all agree with me. Try playing either the first UT and 2004, and then try Unreal Tournament 4. If you can't tell the very obvious input-latency in the controls of UT 4, I don't think anything will convince you.