TEXTURE1 copyright

[myk]

boris said:
What kind of copyright issues are there? You mean resources or Freedoom as a name and the game's content resembing Doom?

Mainly the texture definitions (instructions taken right out of id's IWADs). It's also what moves Freedoom contributors to ape DOOM in their work, as it needs to be designed to fit wads that were designed to fit DOOM.

[boris]

myk said:

It's also what moves Freedoom contributors to ape DOOM in their work, as it needs to be designed to fit wads that were designed to fit DOOM.

What do you suggest to do? After all, the goal for Freedoom is to be compatible to Doom, and without textures with the same proportions that's not really possible.

[myk]

boris said:
What do you suggest to do? After all, the goal for Freedoom is to be compatible to Doom,

It has two goals, which I don't see as really fitting together; a free Doom game, and compatibility with DOOM (patch) wads. I'd change the focus to a free Doom (engine) game, and a new game of its own (a true TC), spawning its particular set of addon wads.

[andrewj]

myk said:

Mainly the texture definitions (instructions taken right out of id's IWADs).

The TEXTURE1 and PNAMES lumps are not the same as the ones in id's IWADs, because they contain all the textures (definitions) from both Doom 1 and Doom 2 (FreeDoom is a superset of them).

If you're talking about the arrangements of patches in each texture, that's a extremely minor thing. By your logic all pwads in the archives are infringing since they all contain map lumps in the same order as the iwads (MAPxx, THINGS, LINEDEFS, SIDEDEFS, etc). Silly.

Making something that just replaces something else (eventually mechanically) is not encouraging to creative people, and wads need creativity

I agree with you here. I think changing the focus of FreeDOOM to making a true 'TC' makes sense. With an active maintainer, people would (hopefully) get interesting in contributing again. We obviously shouldn't deviate too far from a "Doomish" theme, otherwise we'd have to throw out some of the quality stuff that people have already made. Hence "pwad compability" could still be kept as a lesser goal.

[CODOR]

Ajapted said:
The TEXTURE1 and PNAMES lumps are not the same as the ones in id's IWADs, because they contain all the textures (definitions) from both Doom 1 and Doom 2 (FreeDoom is a superset of them).

I think I've argued this before, but I don't think PNAMES is copyrightable since it's merely a list of patches present (and a list isn't original enough to be considered a creative work). TEXTURE1 and TEXTURE2 I'm not sure about, since they're a set of instructions on combining patches into textures. (And even a combined Doom and Doom II list would be derived from both of them. Are Freedoom's textures supposed to be compatible with Doom's? That is, are they made up of the same patch names in the same locations?)

[leileilol]

Janitor said:

i like this idea, as it opens up more possibilities (deh/bex patches, a real storyline, etc...)

I don't. It'd end up being worse and more hated by purists in the end. I like how Freedoom is organized and compiled as it is.

If myk is so concerned and doesn't like the way Freedoom is currently ran why not he just make a fork then to make his 'original tc idea no doom lump names' happen then?

[myk]

leileilol said:
myk is so concerned

If it's nonfree anyone should be concerned, because it becomes useless for its prime purpose (i.e., avoiding problems with restrictive copyrights and being eligible to be placed in free software packages and distributions). Also, I'm not under any obligation to do anything, and even if I were to do something, it's no substitute for stating my opinions or observations.

CODOR said:
I don't think PNAMES is copyrightable since it's merely a list of patches present

I'm not so sure it can be isolated, because it is an essential part of the texture definition instructions, at least in the context of a wad in the particular PNAMES formatting (unlike just listing the same patch names in a text file). It appears that the exception for lists refers to lists by themselves but contexts may change that. An example is given here for recepies.

Just because a wad is divisible into lumps it doesn't mean they should be taken in such a fragmentary way.

[boris]

myk said:

I mean the whole thing; the set of instructions that help display the patches in the way we see them in DOOM and DOOM II wads. I'd even go as far as to say that what defines the instructions as such is their ability to make wads for DOOM function, at least under their "TEXTUREx" format. You can shuffle it around, mix it up, add or take a bit, but it's still derived from what id designed for their wads so that they would work the way they do.

I don't see the problem. From that point of view any text is infringing copyrights, after all they are just rearrangements and multiples of words from a dictionary.

CODOR said:

Are Freedoom's textures supposed to be compatible with Doom's? That is, are they made up of the same patch names in the same locations?)

Yes, that is one of points of Freedoom.

[Enjay]

boris said:

Copyright issues could be checked out there, too (like, the Cacodemon death sound strongly reminds me of some sound in a radio play I used to listen too, though I doubt Enjay would bring any copyrighted material to Freedoom).

I certainly didn't consciously bring copyrighted sounds to FreeDoom. The sounds I contributed came from a very old reel-to-reel tape (I'm sure it pre-dates "Predator") that was owned by a relative. It was my understanding that the sounds belonged to that relative (now dead) and so I transferred them to a digital format in good faith.

leileilol said:

I recognized Enjay's sounds as well from being from hollywood stock libraries (one of the sounds were even from Predator) and they weren't his own creative works anyway and they are already removed from the repository. He had no issues with it removed.

For info, leileilol pointed out to me (very tactfully by PM) that the sounds probably weren't as legit as I thought and that doubt was enough for me to be happy to have them removed, as leileilol suggested, rather than compromise the project.

[myk]

boris said:
From that point of view any text is infringing copyrights, after all they are just rearrangements and multiples of words from a dictionary.

I think you misinterpreted my post. By DOOM (in capital letters) I was referring to the games specifically, not the "Doom engine format".

Not just any texture definition infringes copyrights, but only the ones directly assimilating instructions from copyrighted sources. Similarly, not just any text infringes copyrights, but only those that evidently take from existing copyrighted work.

[leileilol]

hey that must mean the doom source is illegal it contains lump names for the original sprites.

[KuriKai]

So freedoom needs good quality textures that look like the ones from doom?

oh, and where can I get that giant skull from (the one that replaces the doom2 boss)?

[Guest DILDOMASTER666]

All this talk about TEXTUREx and PNAMES basically is saying that every Doom/Doom2.exe and/or Boom/RockDoom* compatible WAD ever designed is breaking copyright law; as far as I know, you are required to include all patch names and TEXTUREx data from the original IWAD in addition to your own custom stuff, or else... Well, you know. All the guys at FreeDoom did were include an "original" set of patches with the same names as in the original DOOM/DOOM2 IWADs. As far as those names go, I'm not so sure id is in their right minds to try and copyright a list of 8-character names.

* = RockDoom, an open-source build of Boom designed for iPods, iRivers, and other miscellany MP3 players that are capable of running the RockBox firmware.

[Jon]

Ok first question. Where did the data in the TEXTURE? lumps in freedoom from? Were the patch offsets copied verbatim from doom or re-implemented in some fashion? I don't have the means to check this right now, which is why I ask. If someone looked at a texture definition and "guessed" the patch composition offsets and wrote those into the freedoom lumps, there would be no problem. If the definitions were copied directly, we might have an issue. One question then is whether that data is copyrightable or not. Consider http://www.softwarefreedom.org/resources/2007/ath5k-code-analysis.html for example (a code analysis of a driver in Linux derived from some code that was in one of the BSDs). This document (prepared by software copyright law experts) covers the various types of stuff in the .c and .h files, and seems to conclude that some things, like register offset definitions and the like, are not. Quoting

This file is primarily an arrangement of constants, storage structures, and the like for the Atheros cards. The extent to which this type of work is copyrightable is debatable.

The file primarily includes constants and structures related to the card. Again, the copyrightability of such work is minimal

and

It should be noted, however, that a table of constants, such as that found in ath5k_reg.h, is not necessarily within scope of copyright.

The implication from a further paragraph suggests that to be copyrightable the code must be a "novel and creative work".

So, I'm not sure what relevance this has but it's some food for thought.

[andrewj]

Jon said:

Ok first question. Where did the data in the TEXTURE? lumps in freedoom from? Were the patch offsets copied verbatim from doom or re-implemented in some fashion?

Comparing the deutex texture1.txt files, FreeDoom vs Doom II, all the multipatch textures I see are indeed identical, so I'd be very surprised if this was not a straight copy of the definitions from the IWAD.

In my opinion this data is not copyrightable, like the 256 colors in the DOOM palette or the lump names in pwads it is needed for interoperability. But I guess opinions differ on that.

One way to deal with this "problem" would be to simply make all textures use a single patch with the same name as the texture (or a minimalistic patch arrangment, the switch textures are an obvious case where patches are useful).

However that would cause incompatibility with certain pwads that add their own textures by simply adding patches (without use TEXTURE1/2 or PNAMES). I do this in my program OBLIGE because if you add a TEXTURE1 lump, it needs to contain the definitions for _all_ used textures. Now Oblige doesn't matter, I can fix its "FreeDoom" mode, but I wonder just how many pwads in the archives would break when a new arrangement.

[myk]

Jon said:
The implication from a further paragraph suggests that to be copyrightable the code must be a "novel and creative work".

Keep in mind that the specific TEXTUREx arrangements are what define how the graphics are displayed in the game, and as such, how are they not an integral part of the design as much as the graphics they arrange?

In cases where something seems to be unclear or borderline, it may also be relevant to see whether the original author would attempt to enforce copyrights over that thing. As I see it from how id deals with PWADs, I gather they would take the "derived" TEXTUREx info as a point of contention, as it contradicts their claims directly.

Fisk said:
All this talk about TEXTUREx and PNAMES basically is saying that every Doom/Doom2.exe and/or Boom/RockDoom* compatible WAD ever designed is breaking copyright law

You don't have to use the specific sets defined in id's IWADs, and id Software approves wads that do include their particular sets (or modified offshoots) if they are released as derivative of their copyrighted work.

[Stilgar]

You know, I think an important question to ask here is how attainable the goal of being compatible with PWADs for "real" Doom really is. If it's a PWAD that just defines a map, then sure. But what about the ones that have graphics which are based on Doom's? Obviously, they're going to have been designed to blend in with the Doom graphics, and not with Freedoom's where they're likely to stick out unpleasantly. You can't really offer those maps in an appealing way without actually being Doom.

[Fredrik]

TEXTUREx is a data compression format designed to save space and speed up rendering. There's nothing artistic about a particular TEXTUREx lump; its data can be generated automatically. Think of the Doom 2 TEXTURE1 lump as a programming API, relied upon by PWADs for programmatic generation of renderable texture data.

That said, I do think it's a mistake to copy the palette. It is easy to create an essentially compatible palette that does not use the same hues as Doom does.

[andrewj]

Fredrik said:

There's nothing artistic about a particular TEXTUREx lump; its data can be generated automatically.

Do you mean: someone could write a program which analysed all the images, found the common parts and split the images into patches?

If so, perhaps that's what we should do, and if the results just happen to match the original TEXTURE1/2 lumps then that is just a happy coincidence.

Same for the palette: a program could analyse all images and extract all the used colors and put them in an order that matches Doom's palette (allowable for interoperability) and if, lo and behold, the result is the same then that is just another happy coincidence.

[myk]

Fredrik said:
TEXTUREx is a data compression format designed to save space and speed up rendering. There's nothing artistic about a particular TEXTUREx lump; its data can be generated automatically.

Maybe you could expand on the bearing of your point, as TEXTURE1 wasn't itself generated "automatically" even if you could devise a way to do so afterwards by analyzing the original one. TEXTUREx is a notation of how the artwork is displayed in the game, and as such, a specific one isn't really separable from the creative design any more than the specific levels are. It comes from that design, and thus using it can be called derivative. A specific TEXTUREx is developed thus as a result of creative work and requirements.

Think of the Doom 2 TEXTURE1 lump as a programming API, relied upon by PWADs for programmatic generation of renderable texture data.

Even if you do, copyright restrictions may still apply on top of that, which is evidently id's position.

[Jon]

Hi. I haven't forgotten this, nor am I ignoring it, but I haven't had time to think about it much further. I'm not convinced in either direction with regards TEXTURE1, which means I need to think about it and discuss it more. Trying to divide-and-conquer the problem, are we all in agreement that

* single patch-to-texture definitions are in effect a mapping of identifiers
* identifiers are not copyrightable

therefore

* single patch texture1 entries are not copyrightable?

The breakdown of number-of-patches-per-texture is

      1 11
      1 12
      1 18
      1 19
      1 20
      1 32
      1 33
      1 40
      1 64
      1 9
      2 10
      4 8
      5 6
     10 5
     23 4
     30 3
     96 2
    248 1

Which leaves 180 entries that need further discussion.

[andrewj]

Well if it helps get FreeDoom out of the doldrums, then I'm in favour of replacing most multi-patch textures with single-patch textures, except for switches (and possibly a handful of other obvious cases) where using two patches makes more sense.

[myk]

Another thing I noticed recently and might be worth considering. I had thought GENMIDI was just a "list of instrument sounds", but specifically it's a set that includes notation that tells an FM card how each instrument sounds, and you can completely change the sound of each by editing the entries in the lump. What's "standard" is the set of (MIDI) instruments, but the particular sound can be variously defined. It's not just a list but the simple equivalent of a set of instrument patches (such as GUS patches). See an example of a lump modified about 50% of the way here. Is the lump from some publicly usable source or was it made by the guys working for id? Paul Radek, Dave Taylor and Bobby prince all worked on sound and music stuff and may have written it or contributed to it. I wouldn't be surprised, as various games with FM support sound relatively unique.

In any case, it appears this is only used by the FM synth, which source based engines don't seem to use, as they rely either on system dependent MIDI sounds, hardware, or external patches. I'm guessing it could even be removed from the wad?

[printz]

To stay safe, GENMIDI maybe yeah could be deleted. Not sure how would it run with vanilla or chocolate Doom.

Back to TEXTURE1, TEXTURE2 and PNAMES, I don't think that a collection of eight-letter acronyms and numbers is worthy enough to be patented.

Patches are positioned there for good reason: switches and skulllamps on middle of tiles, horizontal masses slightly superimposed as in SHAWN2 to fit 128x128 and look symetrical, combined patches for a larger texture. I doubt such moves are original enough to be id's property.

[CODOR]

printz said:
Not sure how would it run with vanilla or chocolate Doom.

Not a problem, since Freedoom requires (I think) a Boom-compatible port.

Back to TEXTURE1, TEXTURE2 and PNAMES, I don't think that a collection of eight-letter acronyms and numbers is worthy enough to be patented.

Simple lists like PNAMES can't be copyrighted. I'm not so sure about TEXTURE1/TEXTURE2, since they contain instructions on how the patches are to be arranged into textures and are therefore more than just lists.

I doubt such moves are original enough to be id's property.

This makes sense for switches. There's only so many ways to produce them. Not sure if the lawyers would agree, though...

Is it possible to distribute Freedoom with "flattened" single-patch textures, then have someone provide a non-Free add-on WAD including the original (or very slightly different) TEXTURE lumps and Freedoom's original patches for use with WADs that include replacements for only certain patches?

[myk]

printz said:
Back to TEXTURE1, TEXTURE2 and PNAMES, I don't think that a collection of eight-letter acronyms and numbers is worthy enough to be patented.

No one's talking about patents here. And "worthy enough" is not an attribute of copyright. It's not like you can say "I think this poem is lame, I don't think is merits copyright protection". It only matters whether its a written (or equivalent) part of the creative work which isn't public already in some way. So to address why it's not copyright worthy you'd have to point out how it's free to use or not part of the creative work.

What's with that seemingly trollish "myk is so concerned" sig, anyway? It's ironic in any case, since I'm "concerned" about the situation of a community project or with community aspects, whilst you are (apparently) concerned about my (personal) concerns. And what are you trying to say, that copyright matters and issues should be ignored?

[myk]

CODOR said:
Simple lists like PNAMES can't be copyrighted.

Keep in mind copyrights apply to works as a whole, not parts or chunks. Otherwise we could take "words and pixels aren't copyrightable" in the same way, and just imagine where that would lead. If the list appears in a context it may constitute copyrighted content in some situations. A situation to consider would be in another wad. A lump in the IWADs isn't a separate work, unless perhaps it was released separately somehow.

[andrewj]

The FM patches in Doom's GENMIDI is truly an excellent set of patches, perhaps the best set of General Midi patches around. I'm pretty sure the ones in FreeDoom were based on a free source, the two main sources being Allegro and PlayMidi, which are both quite inferior to the Doom patches.

I see no reason to delete the GENMIDI from FreeDoom, it's very small (11K) and it's not doing any harm, even if nothing is using it (and it's quite possible something out there does need it).

[myk]

Ajapted said:
I'm pretty sure the ones in FreeDoom were based on a free source, the two main sources being Allegro and PlayMidi, which are both quite inferior to the Doom patches.

Well, looking at it in XWE it seems to be a modified version of the one from DOOM II. In fact, as I noted just now searching for previous comments on GENMIDI, cph uploaded (to the Freedoom archive) the one I linked above, which clearly states that it is derived from id's in the text file. I compared Freedoom's lump with GenMid01's using frhed and it told me the lumps match exactly.

[leileilol]

printz said:

To stay safe, GENMIDI maybe yeah could be deleted. Not sure how would it run with vanilla or chocolate Doom.

No FM music if that happens.

a GENMIDI.IBK can be generated by Voyetra Sequencer. The one in FreeDOOM doesn't sound very Doom, it sounds more piffy.