zdoom (or successors) (re)licensing efforts?

[Jon]

Hey, I've always been interested in efforts to relicense ZDoom to something other than the DSL (for me most interesting would be something considered dfsg free). Now that Randi has retired, I wondered if that had any impact on the likelihood of this happening. Is it being worked on? Is progress being tracked somewhere? Is there a better place to be reading or asking these questions?

When the "GLOOME" project kicked-off I took a look at what they were up to and I was a little concerned about their methodology. I hadn't kept up with progress on that and in the meantime GZDoom-GPL appeared (and possibly others) and I haven't had a chance to look into those either.

Thanks!

[Rachael]

For now - stick with GZDoom-GPL.

It is planned to move GZDoom and child ports to the GPL license, but that is not the highest priority right now. Most of that work is already done with GZDoom-GPL, however.

I think once Graf has a chance to phase out FMOD and the voxel drawer is rewritten, the full switch will follow probably not long after.

[Jon]

Rachael said:

For now - stick with GZDoom-GPL.

It is planned to move GZDoom and child ports to the GPL license, but that is not the highest priority right now. Most of that work is already done with GZDoom-GPL, however.

I think once Graf has a chance to phase out FMOD and the voxel drawer is rewritten, the full switch will follow probably not long after.

One of the reasons for being interested in what work remains to be done is that I might be able to help do it.

Edit: I see that GZdoom-GPL drops the software renderer entirely. I guess that's still present in GZDoom? I have a lot of catching up to do, I've largely ignored Zdoom for the last 18 years (because of the licensing)

[Rachael]

https://github.com/raa-eruanna/qzdoom/blob/master/src/swrenderer/things/r_voxel.cpp

There is this. This is probably the biggest roadblock at the moment.

I've taken a few cracks at it but never got far. What's there is a very basic implementation. Ken Silverman's code is in there also, but it's #if 0'd out for reference.

[Graf Zahl]

Jon said:

One of the reasons for being interested in what work remains to be done is that I might be able to help do it.

Edit: I see that GZdoom-GPL drops the software renderer entirely. I guess that's still present in GZDoom? I have a lot of catching up to do, I've largely ignored Zdoom for the last 18 years (because of the licensing)

Three parts, actually:

- replace the voxel projection function from Build. This one is black magic, nobody here understands what Ken Silverman was doing. It may make more sense to just ask him nicely if he was willing to make an exception for it than trying to rewrite it.

- replace the MUSLib code in the OPL player. The main issue with this is that all replacement code I know is fully GPL and it needs to be function by function to ensure nothing breaks, so some intermediate versions will inevitably violate the license, but I guess it can't be helped.

- phase out FMod and go exclusively OpenAL. Technically this could be done in a day, the main issue here is that we'd lose the built-in MIDI player which as of now is the only one aside from OPL that doesn't need any setup. So having both MIDI players that work out of the box gone is obviously not going to fly.
I had a look at how Eternity solves it but since the remote process uses SDL it's a no-go, I'm not shipping that abomination with GZDoom.

That's really it.

[Rachael]

- About the MIDI stuff, it was suggested before about importing DOSBox code for that since DOSBox is GPL. What are your thoughts on that?

- I'm going to go ahead and try and get in touch with Ken Silverman, myself. (Sent email now, awaiting response)

[Graf Zahl]

The thing is, ZDoom already contains the DosBox OPL core. What needs to be swapped out is the driver code that runs the various cores.

But it's not a simple exchange-A-with-B procedure, because the driver code is heavily relied upon by the main MIDI playing code. So the only chance I see that won't break the MIDI player is to go at it function by function and replace the MUSLib code piece by piece. That requires quite a bit of time and investigation.

Most of the code we are talking about isn't doing much, except sending predefined event codes to the cores which is hard to change anyway, so the only chance I see is to find functionally equivalent code in a free code base to have something to point to if the license is being questioned.

[printz]

AutoWolf uses dbopl.cpp (which must be based on some dbopl.c file) which is inherited from Wolf4SDL which fabian contributed in order to replace the non-GPL fmopl.cpp stuff. Maybe that's useful for you too? Otherwise, too bad you added it. Of course it's too late to remove it now. But otherwise if I wanted OPL sounds, I'd go all vintage and use DOSBox. They don't belong today.

Eternity sounds excellent, and no longer seems to have sound problems. Surely SDL is that bad for sounds? Quasar made sure to write his own software mixer, instead of relying on SDL_mixer (other than init stuff). In my opinion it sounds better, louder and tougher than ZDoom.

[Graf Zahl]

I haven't looked too closely yet at the various options.

About OPL in general, I really do not care but I want to avoid some feature removal for a license change, especially when the other out-of-the-box MIDI option also poses a problem. GZDoom doesn't need to play MIDI well if nakedly installed but it should at least play them.

[Gez]

Anyone knows where Vladimir Arnost could be contacted? Getting him to relicense MUSLIB as BSD, LGPL, or GPL would be a great boon. I don't believe that his fee.vutbr.cz address is still valid because his user page is 404.

[Graf Zahl]

Hardly surprising considering that it's a university address and 20 years have passed on.

[Dragonfly]

I can't even tell if this is the right guy, but a bit of googling pulled this up: https://www.firmy.cz/detail/12838905-vladimir-arnost-klatovy-i.html

[Graf Zahl]

I found that one as well, really hard to say, it's all Greek (sorry, Czech!) for me...

[scifista42]

Can't you use Google translate or similar service? This person's name matches, but the site just says he's a goldsmith, nothing implying connections to IT, and his city is also in a very different part of the state than the city where the previously mentioned university is, so it can't be said for sure that it must be him.

[Dragonfly]

I tried to use google translate and it produced a plain white page for me. It's also not unusual to have a shift in careers.

[scifista42]

I don't say that it's not him, I don't even say that it's unlikely to be him, just that there's no info on that page hinting that it could be him, other than his name. But his email is right there, so feel free to try.

[Gez]

Last time I sought him out, I found out several obviously different Vladimir Arnosts so I had no idea which, if any of them, was the right one.

[RestlessRodent]

Best thing to do is to ask them all the same question.

[dew]

Gez said:

Anyone knows where Vladimir Arnost could be contacted? Getting him to relicense MUSLIB as BSD, LGPL, or GPL would be a great boon. I don't believe that his fee.vutbr.cz address is still valid because his user page is 404.

VUT's Faculty of Electrical Engineering was split in 2002. Arnost's page was migrated to the Faculty of Information Technology. There's even the MUSLIB page there, heh.

I'll make an assumption and claim this is him (via the first comment here), so contacting any of the Vladimir Arnosts in Czechia might be rather pointless. :) Good luck.

[Urban Space Cowboy]

Jon said:

When the "GLOOME" project kicked-off I took a look at what they were up to and I was a little concerned about their methodology. I hadn't kept up with progress on that

GLOOME has been kaput for nearly a year, so now's a good time to get caught up. :) What concerns did you have? Not strictly enough clean-roomed?

There's also Odamex, which is derived from a ZDoom (1.22) fork which was GPL'd with Randy Heit's permission.

[Agentbromsnor]

It's great to see that effort is still being made to make main-line GZDoom GPL (and its child-ports). I have nothing but respect for you guys, and this is why I've been sticking with developing for GZDoom through all these years.

[Jon]

Urban Space Cowboy said:

GLOOME has been kaput for nearly a year, so now's a good time to get caught up. :) What concerns did you have? Not strictly enough clean-roomed?

There's also Odamex, which is derived from a ZDoom (1.22) fork which was GPL'd with Randy Heit's permission.

At the time I looked, the methodology was undocumented, so it was very unclear what they'd actually done besides the obvious to audit the code to ensure it was GPL, it was all a bit too hand-wavy for my liking. When I tried to get in touch I got brushed off which made me think they were more interested in the perception that it was all A-OK, rather than reality.

Kinda related, here's the top 5 contributors to ZDoom. Which of these have said "yup my work is also GPL"? What about the other 69 contributors? I'm sure Graf and Randi have done so, or this whole effort would be pointless ;) but the rest?

  3914	Christoph Oelckers
  2582	Randy Heit
   325	Braden Obrzut
   309	alexey.lysiuk
   288	MajorCooke

[dpJudas]

Jon said:

At the time I looked, the methodology was undocumented, so it was very unclear what they'd actually done besides the obvious to audit the code to ensure it was GPL, it was all a bit too hand-wavy for my liking. When I tried to get in touch I got brushed off which made me think they were more interested in the perception that it was all A-OK, rather than reality.

Strictly speaking, if you accept any pull request from anyone without an explicit statement about copyright you can't assume it is GPL, even if the project itself was licensed as such. In practice, I'm sure you can make a pretty good case in court that any contributed code is implicitly assumed to be following the existing license. What was that license?

In any case I'm pretty sure that certain individuals on Doomworld is far far more concerned about the "legal status" of ZDoom derived ports than the actual copyright holders of said code. The GPL'ed version has existed for long time now, yet nobody holding any copyright seems to have complained. Now why is that?

The truly problematic code has always been the Build code, because here we had a clear case of code explicitly saying it could not be GPL. The good news is Rachael contacted Ken Silverman and got his explicit permission to relicence the borrowed voxel code as GPL. That's why this file is now GPL in QZDoom's repository.

Jon said:

Kinda related, here's the top 5 contributors to ZDoom. Which of these have said "yup my work is also GPL"? What about the other 69 contributors? I'm sure Graf and Randi have done so, or this whole effort would be pointless ;) but the rest?

And you could make the same argument for any port that didn't explicitly fork from the GPL'ed version of Doom. Even those that did you can't be 100% sure there aren't any "surprises" unless you audited the codebase yourself.

[Rachael]

Even if GZDoom goes fully GPL there will always exist the current hybrid DSL/LGPL/BSD licensed code with mixed licenses for all the libraries and dependencies.

Technically, even after GPL'ing, you can always fork at that point if you want a less restrictive license (or more restrictive, depending on the libraries you decide to keep - particularly FMOD).

My biggest issue with GPL is that it does not allow its use anywhere except inside a project that has a 100% compatible license (so technically, Ken's voxel code is still build-licensed, despite the permission I got, and that will remain so until GZDoom goes 100% GPL in which case my special exception will actually take effect).

But that's a double edged sword - that also allows project maintainers to ensure that any forks to their project will always remain 100% open-sourced and that there will be no future ZDaemons and Skulltags with the source closed - at least not unless they want to use very old code.

I think dpJudas is right though. I think there's a lot more concern over copyrights here than there is in the Doom community at large. In of itself that's not necessarily a bad thing - because it does ensure that credit is always given where credit is due - but it becomes harmful when it does actually stifle innovation and then it becomes no different than a case where corporations that have overzealous law teams start sending cease and desist orders to community projects that people actually enjoy. (Arguably you could say that this stance is meant to PREVENT such things from happening - but it's still treading the same ground and the effect is just the same - so one has to decide where to draw the line)

When Graf went LGPLv3 for GZDoom, he asked my permission for what little code I had contributed at the time for it.

For my part, my biggest support for GPL comes from the fact that firstly, it is a very user-permissive license, and secondly that it seems to be pretty popular here. But beyond that, I have little to no interest in it. If we had decided to keep GZDoom the same license as it is now and almost always has been, I would be just as happy.

[Gez]

Code original to ZDoom is under the BSD 3-point license. It doesn't need to be relicensed. For a GPL ZDoom, the license that must be changed is that of the dual-licensed code originating from Doom and Heretic or Hexen, the single remaining bit of Build code that has graciously been dual-licensed as GPL, and the MAME OPL core which is also dual-licensed as GPL.

What remains troublesome is FMOD support and MUSLIB.

All the rest is under GPL-compatible licenses. There's no need to relicense BSD code for the same reason there's no need to relicense zlib code or LGPL code.

Rachael said:

(so technically, Ken's voxel code is still build-licensed, despite the permission I got, and that will remain so until GZDoom goes 100% GPL in which case my special exception will actually take effect)

So why didn't you ask for LGPL or BSD in the first place?

[Rachael]

Gez said:

So why didn't you ask for LGPL or BSD in the first place?

Mistake on my part.

[Graf Zahl]

dpJudas said:

Strictly speaking, if you accept any pull request from anyone without an explicit statement about copyright you can't assume it is GPL, even if the project itself was licensed as such. In practice, I'm sure you can make a pretty good case in court that any contributed code is implicitly assumed to be following the existing license. What was that license?

I think that should be self-evident. If someone contributes to an existing code base one should normally assume that this implies acceptance of the project's license.

And ZDoom's stance on this matter has always been that all original ZDoom code is licensed under BSD 3-clause. ZDoom can certainly be lambasted for not clearly spelling out the license on all affected source files, that will surely be corrected if we change the overall license - but of course we will not relicense any code from external contributors - it will remain available under BSD (that is, if anyone can separate it out...)

Actually, if we are talking about code under unclear terms, there is one such module and that's the bot code. It has no license, no copyright mark, no anything concerning attribution and its creator is only mentioned by nick in the accompanying text files. To make it short, I have no idea whatsoever, what the terms were for it. If something is fishy in ZDoom, that's it.

All the rest is either already GPL compatible, Doom source license (can be relicensed) or Raven license (can be relicensed), with the exception of the MUSLIB code which will have to be replaced when the time comes.
A bigger issue will be some contents in zdoom.pk3, like the crouched player sprite or the big Doom font. That's irrelevant for the binary but not for someone wishing to distribute the engine with their own game.

[Jon]

dpJudas said:

Strictly speaking, if you accept any pull request from anyone without an explicit statement about copyright you can't assume it is GPL, even if the project itself was licensed as such. In practice, I'm sure you can make a pretty good case in court that any contributed code is implicitly assumed to be following the existing license. What was that license?

Assuming you mean " if you accept any pull request from anyone without an explicit statement about copyright you can't assume it [matches the license of your project]", I... I think this is wrong, but I can't articulate a counter-position right now. Let me think about it :)

dpJudas said:

In any case I'm pretty sure that certain individuals on Doomworld is far far more concerned about the "legal status" of ZDoom derived ports than the actual copyright holders of said code.

I can't really speak for anyone else but myself. I'm interested in free software, defined as meaning DFSG-compatible, partly because I am a Debian contributor. ZDoom is an awesome project that I've largely avoided entirely for 18 years because it was not "free software", using that definition. Once this is resolved I'll be first in line to package it up for Debian, at least. But I'm also far more likely to contribute too. I'm really looking forward to trying stuff out that I've only read about for ages, really.

dpJudas said:

The GPL'ed version has existed for long time now, yet nobody holding any copyright seems to have complained. Now why is that?

I'm not sure what point you're making here, please spell it out for me.

The truly problematic code has always been the Build code, because here we had a clear case of code explicitly saying it could not be GPL. The good news is Rachael contacted Ken Silverman and got his explicit permission to relicence the borrowed voxel code as GPL. That's why this file is now GPL in QZDoom's repository.

dpJudas said:

And you could make the same argument for any port that didn't explicitly fork from the GPL'ed version of Doom. Even those that did you can't be 100% sure there aren't any "surprises" unless you audited the codebase yourself.

I'm reasonably happy that Boom is clean, for example, even though I haven't looked into exactly how the sausage was made.

gez said:

Code original to ZDoom is under the BSD 3-point license.

This is a very good point. To be absolutely clear, personally, I'm entirely happy with that, I'm not asking for that to change.

Graf Zahl said:

And ZDoom's stance on this matter has always been that all original ZDoom code is licensed under BSD 3-clause.

I'd forgotten about that. This puts me much at ease.

[dpJudas]

Jon said:

I'm not sure what point you're making here, please spell it out for me.

My point is that when it comes to copyright, only the opinion of the copyright holders truly matters. The less code an individual has contributed, the less it matters because while such a person could theoretically sue you, the more likely scenario will be that he complains, you remove the offending code, end of story. You cannot demand meeelions in damages (and win) if all you contributed was a tiny bug fix in an obscure corner of the codebase.

Of course I'm not a lawyer and this is not legal advice. Luckily after what Graf said about the old license being BSD this doesn't even matter.

[LexiMax]

Rachael said:

My biggest issue with GPL is that it does not allow its use anywhere except inside a project that has a 100% compatible license (so technically, Ken's voxel code is still build-licensed, despite the permission I got, and that will remain so until GZDoom goes 100% GPL in which case my special exception will actually take effect).

But that's a double edged sword - that also allows project maintainers to ensure that any forks to their project will always remain 100% open-sourced and that there will be no future ZDaemons and Skulltags with the source closed - at least not unless they want to use very old code.

Zandronum got around this by using a very slightly modified Sleepycat license for all code post-Carnevil. It does not have the onerous requirements of the GPL and is not viral, and thus can be used in a license minagire like ZDoom. However, it is copyleft nonetheless, which prevents closed-source ZDaemon-style forks, which is by design.