Blzut3 said:
Sounds like a case of this. The answer there seems to indicate you would need permission from id software to grant the exception to link to fmodex in the GPL version of Doom. (Note "whole program.")

IANAL of course.

No. The reason being because Doomsday is not dependent on FMOD Ex and is just as capable using DirectSound on Windows and SDL_mixer on Mac OS (as-capable being somewhat debatable in the case of SDL_mixer...).

My earlier post lists all the key reasons why I believe we are not in violation of the GPL.

Anyway, it is clear to everyone that we actually take the issue seriously. So how you can pick holes in our approach given the unstable ground you stand on I don't know.

DaniJ said:
Anyway, it is clear to everyone that we actually take the issue seriously. So how you can pick holes in our approach given the unstable ground you stand on I don't know.

What unstable ground? Our bug tracker does not contain open reports of license violations. The only thing I've seen is the assertion that distribution rights to the Doom license are vague, but in practice the intent of id software has been clear.

I'm trying to argue that the GPL contains "asinine restrictions" in particular on linking. From my point of view linking dynamically to non-free software would be violation of the GPL unless an exception is granted by all right holders. You believe there is a way around that, and that's fine if you're willing to stand by it. I could add more about why I think the GPL's linking restrictions are "asinine," but I don't think it will really add to the discussion.

As it is, this should be an important matter as if linking dynamically to fmodex can indeed allow a GPL program to use fmodex the possibility of ZDoom switching to the GPL becomes FAR more likely as only the build code would remain an issue.

By the way, what would stop us from packaging the build voxel code into an optional library to use that in a ZDoom GPL edition? Ignore the other build code for the purposes of this discussion.

Blzut3 said:
What unstable ground? Our bug tracker does not contain open reports of license violations.

That may be so but I am given to understand that ZDoom's current license state is rather murky, with code originating from dozens of sources, many of which under conflicting licenses. Though I admit that I've not exactly been keeping track so I may be misinformed.

However, the presence of Build code automatically violates your license ecology because of the license under which it was released is already unsound.

I'm trying to argue that the GPL contains "asinine restrictions" in particular on linking. From my point of view linking dynamically to non-free software would be violation of the GPL unless an exception is granted by all right holders. You believe there is a way around that, and that's fine if you're willing to stand by it. I could add more about why I think the GPL's linking restrictions are "asinine," but I don't think it will really add to the discussion.

In my opinion this is not a way of "getting around" the problem, it is simply a way to achieve compliance given unfortunate license terminology and to honour the intent of the authors.

If FMOD Ex could not be used by a GPL project then there is little worth in the FMOD Non-Commercial License.

As it is, this should be an important matter as if linking dynamically to fmodex can indeed allow a GPL program to use fmodex the possibility of ZDoom switching to the GPL becomes FAR more likely as only the build code would remain an issue.

Indeed it is and yes it could. Now, IANAL either but Doomsday is already packaged and available in various *nix repos, not least of which being Debian. Knowing how strict those guys are says to me that this is OK.

By the way, what would stop us from packaging the build voxel code into an optional library to use that in a ZDoom GPL edition? Ignore the other build code for the purposes of this discussion.

As far as I'm concerned, Build code is out of bounds regardless because of the fact its license situation is unresolved.

printz said:
What about QuickTime? If I'm not wrong, PrBoom uses QuickTime for the music.

Doomsday also uses QuickTime on Mac OS for music as its (apparently) much better than SDL_mixer.

DaniJ said:
That may be so but I am given to understand that ZDoom's current license state is rather murky, with code originating from dozens of sources, many of which under conflicting licenses. Though I admit that I've not exactly been keeping track so I may be misinformed.

Well, I have no intention to actually verify that. Particularly given the number and variety of licenses involved. I'll just assume ZDoom has done the "math" and it is indeed OK as far as that project is concerned.

DaniJ said:
If FMOD Ex could not be used by a GPL project then there is little worth in the FMOD Non-Commercial License.

Indeed it is complicated. It doesn't help that in this case it is obvious that Firelight would not care about the matter (their license doesn't explicitly forbid linking with the GPL as far as I know). The issue here is that the GPL doesn't allow linking it with it, dynamically or otherwise. Now you can argue that none of the Doomsday team care (as in they would grant the exception), and that id software likely doesn't care either. That's perfectly fine to me.

I think you understand what I'm saying, but I'll reiterate it for the sake of the thread: I'm merely pointing out what I find to be an "asinine" feature of the GPL. Which is why I don't really care to support it anymore. The LGPL seems like a better license to me since it removes the linking restrictions and focuses on keeping the code within free (as it should) instead of infecting everything it touches.

DaniJ said:
not least of which being Debian. Knowing how strict those guys are says to me that this is OK.

I assume by dynamic linking you use dlsym or something so that fmod is not needed during the compilation process? If that's the case it's possible they are not aware that Doomsday may link to fmod.

I've sent an email to the FSF regarding the issue (no project names mentioned of course) since it may help ZDoom become GPL (or, as I would prefer, dual licensed). As it is, we have been lead to believe our inability to replace fmod (short of providing no sound at all or a significantly reduced feature set) is the reason we need to use the original Doom license. The build code could be replaced with relative ease, should someone be motivated to do so.

Blzut3 said:
I think you understand what I'm saying, but I'll reiterate it for the sake of the thread: I'm merely pointing out what I find to be an "asinine" feature of the GPL. Which is why I don't really care to support it anymore. The LGPL seems like a better license to me since it removes the linking restrictions and focuses on keeping the code within free (as it should) instead of infecting everything it touches.

Yeah I get your point and to an extent I agree. In our case however there was no other license conflicts at play and it made sense to do it this way (prior to that the only conflicts were those due to the aggravating Raven EULA, before we switched those to GPL when we could).

I assume by dynamic linking you use dlsym or something so that fmod is not needed during the compilation process? If that's the case it's possible they are not aware that Doomsday may link to fmod.

By default it's not even built (it must be explicitly enabled via qmake CONFIG before any binaries are produced). Yes we do link to it dynamically using an equivalent to dlsym.

EDIT: Know what, never mind. No matter what I say I come out looking like the asshole even though all I want is to put fucking voxels in Eternity. To do that I need an implementation I can freely study, and understand. Until somebody wants to step up and help make that a reality, there's no use me mentioning it again. I'm through here.

Actually there's little reason to adapt Build's code. it's not practical, legal, or even desirable. It would probably be easier (guessing here) to change a Doom port in such a way as to allow ACS to be read without compiling, the same way decorate is. Not that it would be "easy" to do by any means, just simpler and probably more legal in the end.

Actually there's little reason to adapt Build's code. it's not practical, legal, or even desirable. It would probably be easier (guessing here) to change a Doom port in such a way as to allow ACS to be read without compiling, the same way decorate is. Not that it would be "easy" to do by any means, just simpler and probably more legal in the end.

I'm a big advocate of that myself. Runtime-compiled ACS would be great. It does require a new compiler, however, which is being worked on in the ZDoom camp currently (licensing issues, yet again, thanks to Raven 9_9).

This is one reason EE's Aeon had to be a language that is compiled to bytecode at runtime :>

Quasar said:
EDIT: Know what, never mind. No matter what I say I come out looking like the asshole

No one thinks that, Quas. Even those of us who know little to nothing about the complexities of licensing can still tell it's like trying to win at tic-tac-toe and usually ends up with an impossible stalemate.

Blzut3 said:
I've sent an email to the FSF regarding the issue (no project names mentioned of course) since it may help ZDoom become GPL (or, as I would prefer, dual licensed). As it is, we have been lead to believe our inability to replace fmod (short of providing no sound at all or a significantly reduced feature set) is the reason we need to use the original Doom license. The build code could be replaced with relative ease, should someone be motivated to do so.

And the response I got pointed me to this section of the faq. Seems to confirm my stance regarding the issue. Without permission from id and raven there's no way to link to fmodex with the GPL release.

As far as Doomsday is concerned: Since the use of fmod has to be explicitly enabled at compile time I do not believe there is a violation unless Doomsday is compiled with that option on. At which point I believe it is the responsibility of the person who compiled that binary. To me this is no different than using DVD decryption software or the S3TC library.

For ZDoom, our stance remains the same as it was. We basically need the OpenAL branch to be complete in order to dual license as GPL. Otherwise the GPL version would not be able to have sound.

Personally I believe there IS one way that you can use FMod in a GPL program.

First you write an abstract base class for your sound "HAL" which is dual-licensed GPL/BSD.

Write an implementation of that abstract base class for interfacing with FMod which is BSD-licensed. Write it so that it loads the DLL at runtime if it is found and fails over to a different implementation otherwise.

And then finally the part you're not going to like. It isn't legal to distribute a copy of FMod with ZDoom. So you're not going to. Instead offer an optional download of FMod as a separate package, or together, as an uncompressed zip inside the larger ZDoom 7z file - invoking "mere aggregation" clause), and allow the end-user to create the combination of FMod and ZDoom only on their end system.

Why this works:

A copyrighted work must have "form or permanence" by US law. This is something more than just a temporary optional runtime linking at the will of the end user.

And the most important part - the terms of the GPL only kick in when a program is *distributed* in a certain state. The end user is allowed to do wtfever they want. They could link ZDoom with proprietary code, modify it til they're blue in the face without giving you any of their source code, whatever. As long as they don't distribute their fucked up copy, they have not violated the GPL. There's no way I can see that an end-user-instigated temporary runtime linkage does NOT meet this criterion.

By providing an alternate implementation (SDL_mixer or what have you), you are not binding your program irrevocably to the proprietary library. This would at the least severely weaken anyone thinking they had a case against your use of the GPL with simultaneous provision of a module which only links to a proprietary library at the direction of the end-user.

Unfortunately Randy had a different idea and 'didn't want to jump through hoops' (original quote) so he integrated FMod too tightly.

I untangled a large portion of it a few years ago but it's still not cleanly separated to make it an isolated module.

The biggest obstacle right now is that there's no decent sound library that could serve as a replacement. OpenAL seems closest but it's doing some thing so weirdly, in particular streaming (OAL has no callback functionality at all which makes a clean streaming implementation a major chore), that nearly everybody giving it a try has lost patience and what's there currently was done by a Linux guy and can't be made to work on Windows easily.

Honestly, if someone could fix that stuff I'd celebrate because I finally could rid GZDoom of the licensing chaos and I think someone could be found to un-BUILD ZDoom.

Right, so all we have to do is change the license of Doomsday's audio_fmod.dll and we're done.

Blzut3 said:
And the response I got pointed me to this section of the faq. Seems to confirm my stance regarding the issue. Without permission from id and raven there's no way to link to fmodex with the GPL release.

Note that there is virtually nothing left of DOOM in the engine itself. The games are also implemented in additional libraries which themselves are dynamically loaded at runtime (when you open the console and enter say "load doom2", your current game library is unloaded). Also note that it is possible to use Doomsday without any game library loaded in so-called "ringzero" mode.

You know, I've seen quite a few times where people bring up a dual Doom/Duke Nukem 3D source prt( Which I would love to see but seems like it'd be too much trouble sadly) but what hurdles would have to be jumped to make a dual Doom/Wolfenstein 3D engine source port?

Also, wow, didn't know about ZDoom being able to load Duke 3D levels. That was fun to look around, even if it was untextured and nothing worked.

As long as the whole is non-commercial and open-source, and that copyright notices in the source code are not modified or removed, the terms of all licenses are complied with.

It's at least a little more complicated than that:

BUILDLIC.TXT:
Any derivative works based on my Build source may be distributed ONLY through the INTERNET.

That means it can't be burnt onto Debian CDs. It means it can't ship on consoles, handhelds or phones.

===

I want to soapbox about the "asinine" GPL. The GPL restriction that you can't link against a non-free library is intended to ensure that software remains free. Imagine if the Apache devs suddenly decided that you needed to link against libpoison.so in order to run their webserver, and the source to that library is closed. That sucks, I hope it doesn't root my machine. I hope there aren't security vulnerabilities. I hope there aren't bugs.

Essentially it means GPL software can't be held hostage to non-free software.

It's also worth mentioning that libraries don't have to be GPL, just GPL compatible. That's why BSD libraries (generally) are OK.

I can understand being aggravated that GPL projects can't use cool whiz-bang non-free libraries, but that's really not the GPL's fault. Rather, it's because those libraries aren't GPL compatible, and in the grand scheme, open source == good, closed source == bad.

So if anything is "asinine", it's developers releasing closed-source libraries, and popular projects like ZDoom only exacerbate the problem by relying on them; this pressures competing projects to take the same shortcuts, and before you know it your whole community relies on closed source software. Not at all great.

How so? All of these devices can connect to the internet nowadays. Your PC can connect to the internet. You can copy the engine from your PC to your device (that doesn't count as distribution). What the Build license stops in its tracks that the GPL doesn't is bullshit like this:

Doesn't BSD work around that by allowing works to be copied into proprietary programs, while the originals remain free? Or does that NOT happen in practice (i.e. big company steals your code, then sues you if you continue using it, even if it's BSD)?