Final Attempt to Get Heretic/Hexen GPL'd

[RTC_Marine]

So.............................................

What is happening?

[Graf Zahl]

Obviously.....................


nothing.

[Csonicgo]

Activision couldn't be THAT evil to sue our butts into the ground. The only reason we seem to be doing this is the possibility of pissing off GNU zealots- The same zealots that pointed out that PrBoom was Non-GPL due to some dumb issue (something to do with a dog sprite or some other nickbakery) and was discussed to be deleted off the Debian repositories. This is why we cannot move forward. I can name several people (some on this forum, imagine that) that would froth at the mouth and "tattle" or raise a stink for their own disgusting satisfaction if someone used Raven code in a GPL project, and a big "fuck you" goes to them.

[Quasar]

Being legal is important, since GPL code should be able to be used by any project. The Debian issue is an important one, since by distributing copyrighted material, the people behind that distribution could be exposed to liability. Let's say that id Software was bought out by some evil publisher in the future. Let's say that publisher goes bankrupt somehow, and their seedy lawyers are looking for ways for them to recoup losses. They happen to notice that a major commercial Linux distribution is including portions of Wolfenstein 3D, which is now one of their properties. They wouldn't bother sueing us because we don't have any money, but the makers of a commercial Linux distrib do. Big trouble.

Anyway, the letters will be going out REALLY soon. After that, there's really nothing else that can be done. Nobody is willing to help fund the other options discussed and so I will not be persuing them (chiefly, taking out a full-page ad in the newspapers local to the target areas in hopes of catching attention).

[Graf Zahl]

Quasar said:

Being legal is important, since GPL code should be able to be used by any project.

... which it can't due to the restrictions in the license.

[myk]

Graf Zahl said:
... which it can't due to the restrictions in the license.

By the context I can see he's referring to applicable projects (GPL or GPL compatible); if the license is broken, being supposedly under the GPL, but not validly, GPL projects, projects newly adopting the GPL, or other similar free software projects would not be able to properly use the "contaminated" code.

[Quasar]

Yeah I figured that was implied, sorry.

[Scuba Steve]

Quasar said:

Nobody is willing to help fund the other options discussed and so I will not be persuing them (chiefly, taking out a full-page ad in the newspapers local to the target areas in hopes of catching attention).

When have you ever asked for donations?

[Csonicgo]

Yeah, I know many in this community would love to get this straightened out, and if money donations will help, then why not?

Sadly, my reason is to make Deep eat it, but hey, to each his own.

[smite-meister]

Quasar said:

Anyway, the letters will be going out REALLY soon. After that, there's really nothing else that can be done.

Technically there is, namely a common effort of reverse-engineering and rewriting the legally troublesome (non-free) parts of Heretic and Hexen code that remain necessary from scratch, and making the results public domain. IMO these include
- state/mobjinfo tables (could be distributed e.g. as DECORATE files, outside the official source port distributions if need be)
- action functions (maybe fix some of the most stupid "features" while we're at it)
- ACS interpreter and compiler (didn't ZDoom do this already?)

The rest of the Raven code is probably already fully rewritten in most ports.

[Graf Zahl]

smite-meister said:

- state/mobjinfo tables (could be distributed e.g. as DECORATE files, outside the official source port distributions if need be)

Having it out of the EXE should be enough. I think the GPL is quite clear that it doesn't extend to data used by a GPL'ed executable.

- ACS interpreter and compiler (didn't ZDoom do this already?)

Yes but there may be some problems combining this code with non-C++ ports because it makes heavy use of C++ features. But with some work it should be doable to change it so that it works with C code without changing it itself.

The rest of the Raven code is probably already fully rewritten in most ports.

Most of the Raven code is fragments here and there that are more or less hard to separate from the rest of the code. How are you supposed to rewrite single lines of code? ;)

But the 2 biggest chunks are ACS and polyobjects and for both a free implementation already exists.

[smite-meister]

Graf Zahl said:

Having it out of the EXE should be enough. I think the GPL is quite clear that it doesn't extend to data used by a GPL'ed executable.

You still have to bind the states to the proper action funcs somehow, and I happen to like the new-style DECORATE...

Graf Zahl said:

Most of the Raven code is fragments here and there that are more or less hard to separate from the rest of the code. How are you supposed to rewrite single lines of code? ;)

We-ell, you could change the variable names if you like:). Anyway, these small Raven code fragments are mostly trivial extensions of the (now GPL) Doom engine, and most likely non-copyrightable in themselves. I myself have rewritten significant parts of the core engine logic in Legacy, just reproducing the Heretic/Hexen functionality, not using old Raven code directly. I can think of no legally or ethically valid arguments against considering the result GPL-compliant.

Edit:

Graf Zahl said:

But the 2 biggest chunks are ACS and polyobjects and for both a free implementation already exists.

Where? By free, do you mean GPL? We certainly could use those, even though our polyobj implementation is largely independent from the Raven one already.

[Graf Zahl]

smite-meister said:

Where? By free, do you mean GPL? We certainly could use those, even though our polyobj implementation is largely independent from the Raven one already.

ACS: ZDoom
Polyobjects: Eternity. And if you have done another one there's 2. ;)

[Quasar]

Eternity now has a GPL ACS interpreter implementation too. However, I'd say the biggest chunk of Hexen code that is problematic is the enemy AI routine module. As I've mentioned before, that stuff is nearly impossible to do in any other way. Even if you start totally from scratch, your code will end up looking like you just rearranged Raven's slightly, and that is an unacceptable issue to me.

[smite-meister]

I agree, the hardest part to reverse-engineer "fairly" is the AI (action functions and state tables). However, it could be possible to separate them into a DLL plugin which could be distributed under a different license. A bit like what Doomsday does, but simpler.

[Quasar]

That is unsatisfactory for various reasons, however. Not the least of which is that the port is now limited to building for targets which support dynamically linked libraries. Eternity also makes all of its action functions available to all game modes. If it separated the code into game modules, this would not be possible any more.

I've solved some of the problems by creating and using those generic, parameterized pointers that Eternity supports, but much of the logic just needs to be hard-coded to be done in an efficient and authentic manner.

The snail mailing will begin today or tomorrow (as soon as I can get the letters stamped and into a mail box). I will mail Raven first in order to give them time to respond on their own. If there's no action from them within about a week's time, I will send the mails to the Activision board members as well. Once this avenue is expended, we can consider this effort finished as far as I'm concerned, at least until somebody shows up that cares enough to help fund the other possibilities. They are too much to expect me to do on my own.

EDIT: I would be up for a "Chinese firewall" sort of setup. The goal would be to take Chocolate Doom and produce from it a "Chocolate Heretic" and "Chocolate Hexen" which reproduce the respective games' behaviors as closely as possible. Where available, already existing GPL implementations could be used, such as Eternity's polyobject code and ACS interpreter. Where not, as much EXE behavior as possible could be documented through empirical methods (testing, testing, testing). What could not be obtained through these (exact state timings etc) could be "Chinese firewalled." One team of people who are not involved in the coding could examine the Heretic/Hexen sources and document their behaviors as exactly as possible in a text document. The programming team would then implement code on their own, with zero reference to Raven's sources, that does the same thing. I believe this would result in a legally GPL-able codebase.

The question is, who here would step up and become a part of this project? So far my efforts to find willing persons have fallen flat. I've already discussed this with several programmers in the community and none of them have the time.

[andrewj]

Quasar said:

EDIT: I would be up for a "Chinese firewall" sort of setup. The goal would be to take Chocolate Doom and produce from it a "Chocolate Heretic" and "Chocolate Hexen" which reproduce the respective games' behaviors as closely as possible.

I might be up for that as well (as a programmer). But... aren't you pretty much doing that already with Eternity?

[RTC_Marine]

Andrew, James: if you guys want, you can discuss it in the doom tech channel on oftc

[smite-meister]

Quasar said:

Not the least of which is that the port is now limited to building for targets which support dynamically linked libraries. Eternity also makes all of its action functions available to all game modes. If it separated the code into game modules, this would not be possible any more.

Come on now, nowadays there are no sensible targets which do not support dynamic linking. You could just as well add support for tape drives in case a possible target system does not support random access storage:)

Legacy also makes all states and action funcs available in all game modes, but I fail to see how this would prevent using DLL libraries which introduce additional action funcs, states which use them and mobjinfos that use those states. All you have to provide is the DLL-to-engine interface, which is admittedly hard and tedious to design. Which is exactly why I'm not really advocating this option.

Quasar said:

One team of people who are not involved in the coding could examine the Heretic/Hexen sources and document their behaviors as exactly as possible in a text document. The programming team would then implement code on their own, with zero reference to Raven's sources, that does the same thing. I believe this would result in a legally GPL-able codebase.

If this is somehow more legal than reading the original code and rewriting its functionality yourself, I have lost all faith in the western legal systems :D
Is it? Are there any precedents?

Besides, moral considerations aside, the key point here is verifiability. If there is no way to prove that the programmers either have or have not read the original code, what's the difference?

Edit: Oh yeah, I would certainly be willing to participate in the AI recoding project to some extent, if it comes to that. A game that is almost-but-not-quite like Hexen is better than no Hexen at all.

[Mordeth]

smite-meister said about "chinese firewalling":
If this is somehow more legal than reading the original code and rewriting its functionality yourself, I have lost all faith in the western legal systems :D
Is it? Are there any precedents?

I've heard about this before, but applied to hardware. One team describes the specs of a to-be-copied product and another team designs their own product solely based on those specs. It's deemed legal, since the new product is designed based on specs made from observation and not derived directly from the original product nor its components. It's deemed illegal to examine the original product's components and to copy those directly.

Example: somebody invents the airbag. You copy this by reading the spec "An inflatable bag pops out on impact, cushioning the driver" without actually having seen the original design. You know the function only, not the technical specs or any technical know-how of the to-be-copied product.

I doubt the same thing flies here, when you design these new specs based on actual source code. It's akin to copying a products' components with self-made molds. "Chinese firewalling" this in our case would be describing game functions based on observations made in-game and a programming team coding stuff based on those observations; this without any team having access to the original source code.

So James, you don't need another programmer to provide the specs for you. You need players and playtesters, preferably people who can design (test)levels. They need to describe all game functions (triggers, monsters) based on their in-game observations, while you design code based on the specs they provide. Example: to determine how "random rolls" are calculated, eg, "this monster has a 4/256 chance of entering his pain state when damaged" you would probably need to setup a controlled testlevel with a particular monster and gather data on this by counting how many times that monster enters his pain state while damaged a few thousand times. Another example: to determine the spread of a shotgun blast you need to put player at a certain distance from a wall and make a screenshot when the tracers hit the wall and then measuring the spread in pixels; also for a few dozen sessions.

The only way you can know you got it right is when your new code is able to flawlessly playback original demos :)

And for the programmer team: any Doom programmers are by definition excluded. You'll need a programmer who has never seen Heretic / Hexen source code.

[RTC_Marine]

Mordeth said:

And for the programmer team: any Doom programmers are by definition excluded. You'll need a programmer who has never seen Heretic / Hexen source code.

Is this for the whole "tainted by the doom source" thing? I'm pretty sure someone who has worked on doom before can adapt to writing different code that functions the same but looks/operates differently to the original code. (if they cant, then they're not really programmers)

Sure, a new coder wouldn't have this "tainted" problem, but that doesn't mean they have experience with programming doom-engine games, so that could be an issue, but its a learning thing in the end.

Overall, if something like chocolate-heretic/hexen does start, I could lend a hand to writing parts of the low level subsystem (video/sound/input)

[andrewj]

Mordeth said:

I've heard about this before, but applied to hardware

The case I heard about was cloning the IBM BIOS (making possible the "IBM compatible" computers). That's software.

And for the programmer team: any Doom programmers are by definition excluded. You'll need a programmer who has never seen Heretic / Hexen source code.

That would be the ideal, but it doesn't seem very likely to find a programmer outside of this community with both the skill and the will to work on such a thing.

[entryway]

I don't understand the problem. Heretic and Hexen are totally unpopular games in comparison with Doom. We don't have even thousandth from Doom's popularity. We have no wads and we'll have no wads. If they do not want to do a step to community, forget them. Do not spend your time in vain. Support of these games will take more time from the programmer, than it will be played by all. The game is not worth the candle.

[Graf Zahl]

You know what:

I'd bet that the people involved in this discussion do care about these games. I happen to play them on occasion; not as much as Doom but I still find them enjoyable. And you can be sure that others agree.

[Mordeth]

RTC_Marine said:
Is this for the whole "tainted by the doom source" thing? I'm pretty sure someone who has worked on doom before can adapt to writing different code that functions the same but looks/operates differently to the original code.

I just meant that most Doom programmers here have already taken a look at the H/H source, and therefore not eligible to take part in a "chinese firewall" approach. You would need "untainted" programmers to fullfill the requirements.

[entryway]

the people involved in this discussion do care about these games

It's just care for the sake of care status IMO

I happen to play them on occasion

1:1000 in comparison with Doom I think

[Quasar]

I love both Heretic and Hexen, but I also want their features for my Doom port. Consider that. I also don't appreciate people making this more difficult than it needs to be.

[kristus]

Quasar said:

I love both Heretic and Hexen

Quoted for truth.

[Graf Zahl]

entryway said:

It's just care for the sake of care status IMO

1:1000 in comparison with Doom I think

Fine if you don't care. But I'm with Quasar. I like to play both games - and I like to have their features at my disposal. Don't forget that much that ZDoom stands for is actually taken from these games.

[myk]

Mordeth said:
I just meant that most Doom programmers here have already taken a look at the H/H source, and therefore not eligible to take part in a "chinese firewall" approach. You would need "untainted" programmers to fullfill the requirements.

By these standards releasing a source seems to imply a safeguard against "chinese firewall" approaches. Once you've got the results, how can you ever prove you haven't studied the source, if it's publicly available for anyone to see?

This conception makes releasing sources, but not granting rights to their modification, more restrictive than not releasing them at all. So, Raven released the sources to protect (and get a fuller hold over) its copyright over the games?

I don't see who this should hold, as there's no clear line to what defines a derivative work if the resulting work only references the first as a starting point and never copies or even quotes it, unless Raven and Activision had a patent over the Heretic and Hexen game inventions, which they don't.

Nonetheless, I do see the legal dangers this could bring, immersing projects using the a code in such gray area discussions (about derivation) that could affect free software (GPL) interests.