[8bpp] Graphics Replacement Project - OpenGFX License

[charlieg]

Matthijs' post is a must-read for anybody who wants to know why and what the ramifications are of GPL licensing for both source and output for OpenGFX.

I would just note that a license with a non-commercial clause (e.g. the CC-NC) for the distributed content (i.e. the GRFs etc in with the game) would prevent inclusion of OpenTTD in Linux distributions, on magazine cover CDs, and other such methods of distributing OpenTTD where the carrier has some form of commercial interest (i.e. most distributions are backed by companies). Most distributions are very picky because of this.

[LordAzamath]

I would just note that a license with a non-commercial clause (e.g. the CC-NC) for the distributed content (i.e. the GRFs etc in with the game) would prevent inclusion of OpenTTD in Linux distributions, on magazine cover CDs, and other such methods of distributing OpenTTD where the carrier has some form of commercial interest (i.e. most distributions are backed by companies). Most distributions are very picky because of this.

If it didn't struck you yet, we are at GPL (atleast for authors who have agreed..)

[Benny]

Why is OpenGFX a part of trunk now? I dont want it.
And does OpenGFX contain that grf that makes the map borders water instead of empty space?

[CommanderZ]

OpenGFX ain't part of trunk. Check your common folder if it appears in the game and you don't want it.

[Benny]

What?
I dont have any "common" folder.

[FooBar]

And does OpenGFX contain that grf that makes the map borders water instead of empty space?

It did, but that feature has been removed in the release that was made available six days ago.

Please read here if you want to disable or remove OpenGFX: http://wiki.openttd.org/wiki/index.php/ ... ng_OpenGFX

[planetmaker]

Using BaNaNaS to download OpenGFX makes them your default. On how to change that, read this:
http://www.tt-forums.net/viewtopic.php?p=758475#p758475

[Rubidium]

Why is OpenGFX a part of trunk now? I dont want it.

Then don't select everything you in see the content list to be downloaded. I've NOT added a "Select All" button exactly to prevent people from easily selecting everything and complaining about the fact that they downloaded it.

[CommanderZ]

I dont have any "common" folder.

OpenTTD looks for data into "My Documents/OpenTTD" on windows, for other OSes there are similiar locations independet on where you OTTD really is installed.

[Benny]

@FooBar: Thanks.

@Rubindum: Can you make bananas a option rather than just adding it?
I am sick of those updates that makes it impossible to play OpenTTD like I used to.

@CommanderZ: Still cant find any folder called "common". But it's not needed anymore, I got rid of OpenGFX now.

[FooBar]

@Rubindum: Can you make bananas a option rather than just adding it?

How about not clicking the 'download content' button?

[Benny]

It is too tempting.. =P
But yes, you have got a nice point there. ^^

[Roujin]

It is too tempting.. =P
But yes, you have got a nice point there. ^^

well, selfowned

about the common folder:
It's not called "common". It's just "My documents (or something similar in your language)\OpenTTD" for windows, or somewhere else for other OSes.

[Benny]

Ah, ok.
I am not using that folder other than for the latest nightly though.
For the rest I have got seperate OpenTTD.cfg files.

[Core Xii]

Where it does get strange, is when Ken, also working for EvilCorp makes
the changes to the blender files, then provides the changed files to
Ingrid (and Ingrid only) which creates GRFs, but can argue she is not
obliged to distribute the changed blender files (which she might not
even have received from Ken in the first place!).

I'm confused. If Ken modifies the blender files and distributes them, don't they have to be licensed under the GPL? How could Ingrid argue she's not obliged to distribute the changed blender files when the license directly states so?

So, we've found a way to make modifications to the artwork and release
them without the changed blender files. Even when section 3 is supposed
to prevent exactly this! Now, how is this possible? It is in fact caused
by the muddy distinction between source and binary. If we would somehow
label the pcx files as "executable" as well, we could indeed prevent the
above scenario. However, since it is not uncommon (AFAIU) to edit pcx
files directly, this would be again cause problems. In general, our
problem is not only that we have multiple source formats, but some
formats can be both a source and a "destination" format (which is a
slightly better term than "executable").

I don't see how this distinction is muddy in any way. Clearly, a file is considered binary ("executable") if the original source file cannot be recreated from it in its perfect and original form. If you make a model in blender and render it to a raster graphic format like PCX, it's obvious that the original source model cannot be reconstructed in its original form from the raster image, because information is lost and compiled into a very specific subset, whether or not the intention is to optimize performance or restrict use. Note that it's also not uncommon to edit executable files directly, yet that causes no confusion; Clearly the original source code cannot be recreated from the executable, because information is lost (variable names, comments, etc.).

Now, you might also think that the PCX is in fact also a source file, since it's included in the NewGRF somehow. I don't know enough about the NewGRF format to state this with 100% reliability, so someone correct me if I'm wrong, but doesn't a NewGRF contain all of the information present in the PCX? That is to say, isn't it possible to recreate the original PCX file from the NewGRF, perfectly and in its original form?

[DaleStan]

doesn't a NewGRF contain all of the information present in the PCX? That is to say, isn't it possible to recreate the original PCX file from the NewGRF, perfectly and in its original form?

In fact, no.

The NewGRF contains all data that is part of a sprite, but none that is not, and no information about the arrangement of those sprites. The PCX may originally have been arranged such that certain sprites are located in the same place, and there may be significant information that is not part of a sprite at all. Neither of these are stored in the grf.

However, Ingrid might argue that only the pcx and nfo files are used for creating the grf and provide only those.

This argument holds about as much water as the argument that only the object files are used for creating OpenTTD, and so the C and C++ sources don't need to be distributed.

[LordAzamath]

However, Ingrid might argue that only the pcx and nfo files are used for creating the grf and provide only those.

This argument holds about as much water as the argument that only the object files are used for creating OpenTTD, and so the C and C++ sources don't need to be distributed.

What about people (like me sometimes) who actually DO use only pcx and nfo as sources

[Zephyris]

As do I :s

[DaleStan]

Well, if you write the object file by hand, then it is the source. If you generated the object file from something else, that something else would be the source.

s/object/pcx/g, and it still holds.

The confusion here stems from using as an intermediate form a file format that is reasonably possible to use as a primary form.

[Eddi]

i think this discussion is superfluous, as everything has been stated previously.

all the points raised here that the license left open can be clarified by making "house rules" for accepting sprites into the project (by the project leader, which you should have). mainly: "if you have a blender file that you used to create the pcx, then include that blender file as source code"