RE packaging, and licensing...

[arand]

Yeah, its THAT guy again... :þ
(Yay! the sampling+ piece was solved in 1.1, neat )

So yeah, reason being, I would like to package and get Red Eclipse accepted in the Debian repositories (and in extension, in derviatives like Ubuntu).
There have also been some discussion before with a Fedora games maintainer (Hans de Goede) also interested in packaging it for Fedora.
(In addition I am interested in doing it without having to resort to sillyness like renaming it to "Blue Eclipse", removing elements from the game, etc. )

First of all, there are a few things in RE which simply stops distribution completely:

redeclipse/src/include/wincompat.h :
Is explicitly "All Rights Reserved" with no mentions of RE or anyone else being able to use or distribute it in any way shape or form.

redeclipse/data/fonts/akashi.ttf :
redeclipse/data/fonts/readme.txt states:

(...)
* All products remain property of Ten by Twenty.
* Products may be used by the licensee in any personal or commercial projects (royalty-free).
* Products may not be resold or redistributed.
(...)

My interpretation is that the akashi.ttf file is the "Product" and that the generated .png files is "Usage".
I.e. redistributing the akashi.ttf file is violating the license, though using and redistributing the .png files are ok.

However, this is unclear enough that it probably wouldn't fly in Debian, some clarification from Ten by Twenty and/or font-reshuffling would be required.

redeclipse/data/fonts/* :
The other .pngs that are generated, which fonts are they taken from, what are the licenses of those fonts?
I think quin said once upon a time that they were bitstream courier, right? In that case, it likely needs an accompanying copyright notice from bitstream.

Now, these files could be removed/replaced specifically for Debian, BUT, the main redeclipse/license.txt states:

(...)
Limited rights are granted to redistribute and/or recompress the entire distribution using different archival/binary formats suitable for your OS (zip/tgz/deb/dmg), any changes beyond that require explicit permission from the developers.
(...)

Which, as I interpret it, means that NO CHANGES can be made to Red Eclipse other than changing the compression format, and possibly reorganising items and adding metadata (although this is not clear).
I.e. I cannot remove these things without asking for specific permission (I did so for my PPA packages, for example).

Setting up exclusive permissions for specific people, or specific distributions to do this is possible, but obviously quite clunky, and likely just a temporary solution.

Two ways in which this could be solved, apart from granting specific permissions as per above are:

1.) Relicensing to something along the lines of:

Limited rights are granted to:
* Redistribute verbatim copies of the entire Red Eclipse Project.
* Redistribute modified versions, plainly marked as such, of the entire
Red Eclipse Project which may be:
- Recompressed using different archival formats (zip/tgz/deb/dmg/...).
- Reorganised in order to conform to the organisation scheme of a target OS
(including splitting the content of the Red Eclipse Project into parts).
- Stripped of items which are not relevant to the target OS.
- Accompanied by patches for the purpose of modifying the Red Eclipse Project
at build time.
- Recompiled, possibly using patches modifying the Red Eclipse Project at
build time, for the target OS.
Any changes beyond this will result in a modified version which:
* Must conform to all individual licenses for the material included.
* Is NOT to be considered the Red Eclipse Project and may not use the Red
Eclipse trademarks.

The Red Eclipse trademarks (name, logos, advertising/promotional material, or
modified versions thereof) may be used by anyone to refer to the Red Eclipse
Project, but does not indicate endorsement by the project.
Use for any other reason is strictly prohibited without express written consent
of the Red Eclipse Team.

(The trademark license is nicked from the Debian swirl)

NOTE: IANAL and this is likely missing important bits, but I think it broadly covers the permissions required for basic distribution and packaging friendlyness´ (and yeah, writing your own copyright license kills kittens).

2.) Just remove the clause, rely on the individual licenses of the material in the project and only use the trademark license.
This will leave the definition of "The Red Eclipse Project" in the air, I'm not sure is this fine or if the definition is needed someplace, in which case the points from suggestion 1.) might be relevant again.

Both these option would, I think, conform to DFSG *in themselves*, wheras the current license, of the whole project, as far as I can tell, does not.

Is there any chance a change like this would be feasible?
What is the intent-proper of the current clause? Are the limitations it imposes intended, and neccessary?

On a side note..
On the subject of DFSG, I think things are a bit more complicated here, since "include source code" is, as far as I've understod things, sometimes interpreted as also meaning "source" for other things, or rather, (as the GPL puts it: "preferred form of the work for making modifications to it"), e.g. original font files for generated png:s, etc.
But I am unsure if this will be an issue with the other data in RE, apart from the things I've mentioned above, and if so it can be worked around by splitting off this piece of the package into the "non-free" (~ redistribution only) section of Debian, but again, this would need splitting into parts, see above.

It would be neat to be able to package the game (in a not-having-to-jump-through-flaming-hoops kinda fashion) in some major linux distributions, since that is one of the ways to get users, and hopefully also contributors, I think that it would be good for RE in general.
So therefore, I think you should consider poking the license towards a more packaging friendly style.

- arand

[fawstoar]

What is this madness.

[orbitaldecay]

Yes, this is a great idea. I think it would be wise to move toward inclusion in the Ubuntu repositories as well, being as that they represent the majority of Linux gamers these days.

[qreeves]

I suggest you have eihrul take a look at this thread too, he's better at this license stuff, and tends to see angles and interpretations nobody else does.

- Accompanied by patches for the purpose of modifying the Red Eclipse Project
at build time.
- Recompiled, possibly using patches modifying the Red Eclipse Project at
build time, for the target OS.

I'm not entirely comfortable with the phrasing of these two, for the reasons I state in my next answer.

What is the intent-proper of the current clause? Are the limitations it imposes intended, and neccessary?

This is designed most specifically to stop people making direct copies of the work and taking credit for it. The other side of the story is, we're a tiny development team, and people distributing modified versions of the game create problems for us, support-wise. I can't be offering help to people using copies of the game that has something in it I know nothing about. I create enough bugs of my own!

On a side note..
On the subject of DFSG, I think things are a bit more complicated here, since "include source code" is, as far as I've understod things, sometimes interpreted as also meaning "source" for other things, or rather, (as the GPL puts it: "preferred form of the work for making modifications to it"), e.g. original font files for generated png:s, etc.
But I am unsure if this will be an issue with the other data in RE, apart from the things I've mentioned above, and if so it can be worked around by splitting off this piece of the package into the "non-free" (~ redistribution only) section of Debian, but again, this would need splitting into parts, see above.

Well, there is nothing GPL in RE for starters, there is no requirement for source code at all in the current licensing. Do you mean that the DFSG has this requirement? It's highly unlikely you'll ever be able to get sources for all the assets, ever.

[L]

I fund it funny you bill your game as free/open and yet cite concerns over people distributing modified versions. I think you could get away with enforcing the trademark so that modded versions can't call themselves red eclipse, and tell anyone using them to contact the downstream guys for support instead of you.(or is there something I'm missing here?)

Also, I don't think you have to worry about people taking credit for your game for the most part as the content portion has a legal requirement to properly attribute the artists, and anyone claiming credit is also claiming copyright anyway.

And even if it does become a problem I'll gladly expose any lying scoundrels who claim all the credit for this great game!

[qreeves]

I fund it funny you bill your game as free/open and yet cite concerns over people distributing modified versions.

It's purely logistics. You can download it for free, and do almost whatever the hell you want with it, so long as you don't call it Red Eclipse or claim we endorse it (without our approval). This way we have some semblance of quality assurance in our product, and only have to maintain our own image, rather than doing damage control because of awol mods. I'll give you an example of what I mean by support issues too.

I was sitting in the IRC channel one day when someone entered saying that Red Eclipse was not saving their configuration. They were on Linux, and no ~/.redeclipse was even being created. We spent quite a long time trying to debug the problem, ranging from creating the directory ourselves to checking permissions, etc. Then I asked them to paste the contents of redeclipse.sh - it took us a while to find where it ended up (/usr/bin/games/redeclipse I think it ended up being) and it was totally unrecognisable. It turned out, some guys over at PlayDeb had grabbed the package, modified it for system-wide installation under Ubuntu without us knowing, and had no idea what they were doing when setting up the shell script. It wasn't even setting the home directory, so RE was likely using the current working directory, whatever that happened to be at the time. I wasted hours working under the assumption they were using our packages, which would never have exhibited that problem.

[arand]

This is designed most specifically to stop people making direct copies of the work and taking credit for it. The other side of the story is, we're a tiny development team, and people distributing modified versions of the game create problems for us, support-wise. I can't be offering help to people using copies of the game that has something in it I know nothing about. I create enough bugs of my own!

The issue of false crediting is, in my opinion, addressed by almost all common licenses, including the ones used currently (and if you end up wanting to actually drag a case into some form of scrutiny, having a common, well known license helps immensely):

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.

It's purely logistics. You can download it for free, and do almost whatever the hell you want with it, so long as you don't call it Red Eclipse or claim we endorse it (without our approval). This way we have some semblance of quality assurance in our product, and only have to maintain our own image, rather than doing damage control because of awol mods. I'll give you an example of what I mean by support issues too.

I would guess that awol mods happen regardless of the license, and that if the author cares little enough to make a crappy mod, heir is likely not going to care about the license either, thus it seems unnecessary to impose restrictions on people who do take note of the license, just in order to get to folks who don't read it anyways.
And again, if you end up escalating these kinds of issues, it tends to help if one is using a common license, rather than a homemade one.

The Debian counterpint of this is DFSG#4 (although not striving for full DFSG-compatibility, this is one of the point that I think is key for packaging friendlyness):

Integrity of The Author's Source Code

The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)

This is the reasons for me using the wording

(...)
* Redistribute modified versions, plainly marked as such, of the entire
Red Eclipse Project which may be:
(...)

And this is the common case, e.g.

(...)
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
(...)

You could claim that this would for example require changing this string accordingly

{l Code}: {l Select All Code}

#define ENG_RELEASE         "Supernova Edition"

to say

{l Code}: {l Select All Code}

#define ENG_RELEASE         "Supernova Edition [Foobar Respin]"

And to refer to it as "Red Eclipse for/by Foobar" whenever appropriate.

Or even, although this is what I am personally trying to avoid, restrict the trademarks specifically:

The Red Eclipse trademarks (name, logos, advertising/promotional material, or
modified versions thereof) may be used by anyone to refer to the Red Eclipse
Project, but does not indicate endorsement by the project.
"The Red Eclipse Project" Being defined here as the unmodified project, as distributed by the Red Eclipse Team.
Use for any other reason is strictly prohibited without express written consent
of the Red Eclipse Team.

This would enforce renaming for any modifications whatsoever, i.e. any packaging whatsoever, something which I do not like personally, although it would mean that it is at least stated with far less ambiguity than it currently is, (if used in conjunction with removing the "Limited rights are granted to redistribute and/or recompress (...)" statement)

Most major distributions do have their own bugtrackers, for this very purpose, and states it plainly:

Don't file bugs upstream

If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.

The issues you describe are not uncommon, but they have mostly been adressed as well, I think, in the organization of every sane distro, where the package maintainer for that distro is the stated path of blame.

Also to note, in my mind, PlayDeb seems to have a rather "Have at it! It works!" kind of attitude to packaging (which is kind of good for throwing stuff over the wall quickly, I guess), and, they do not have an advertised bugtracker, and hence no obvious path of blame, so what I'm saying is, please don't judge others by their example

And in addition, users are always going to create support issues, you could simply have a given policy that for you to give any form of support, require them to download the official version form the homepage and reproduce there, otherwise simply "That's not supported here, bring your problem to Foobar". Similarly to how the answer to most bugs are "try the SVN version, does it persist?"

- arand

[qreeves]

I have absolutely no problem with that, and I agree, I'd rather not resort to the modified name setup. I am a strong believer in the open source way; it, and the people within its communities, taught me everything I know today. Red Eclipse is my way of giving back. I suppose now that we have our forums and tracker setup, the support issues are (or can be) shared, or at least less of a strain on me (psst, use the bug tracker people, its a great way of doing collaborative development). I'm pretty much the only one doing development on the actual game side of things, and it is usually my responsibility to manage the project and do support alone. eihrul has been great filling in for my absences, but I wouldn't ask him to take the extra load in an ongoing basis, considering years of work with Sauer likely burned out his support pathways

[arand]

I have absolutely no problem with that, and I agree, I'd rather not resort to the modified name setup. I am a strong believer in the open source way; it, and the people within its communities, taught me everything I know today. Red Eclipse is my way of giving back. I suppose now that we have our forums and tracker setup, the support issues are (or can be) shared, or at least less of a strain on me (psst, use the bug tracker people, its a great way of doing collaborative development). I'm pretty much the only one doing development on the actual game side of things, and it is usually my responsibility to manage the project and do support alone. eihrul has been great filling in for my absences, but I wouldn't ask him to take the extra load in an ongoing basis, considering years of work with Sauer likely burned out his support pathways

So this would mean that you would be ok with removing the "recompression-only" clause and instead clarifying the usage of the trademarks to something like?:

The Red Eclipse trademarks (name, logos, advertising/promotional material, or
modified versions thereof) may be:
* Used by anyone to refer to the Red Eclipse game or a "modified version of
the Red Eclipse game".
* Redistributed by anyone along with the Red Eclipse game or a "modified
version of the Red Eclipse game"

To qualify as a "modified version of the Red Eclipse game" a project must:
* Be plainly marked as a modified version, including (but not limited to):
- Changing the ENG_RELEASE variable,
example: "Supernova Edition [Foo Modification]"
- Refer to itself as a different version of the Red Eclipse game in
documentation,
example: "Red Eclipse for Foodistro is an FPS game..."
[are those clear enough, are more conditions relevant? ^]
* Only contain changes which are:
- Recompression using different archival formats.
- Reorganisation in order to conform to the organisation scheme of a target
Operating System (including splitting the content of the Red Eclipse
Project into parts).
- Removal of items which are not relevant to the target Operating System.
- Inclusion of patches for the purpose of modifying the Red Eclipse game
at build time.
- Recompilation, possibly using patches modifying the Red Eclipse game
at build time.
[i.e. all changes to code should be reviewable ^]
- Addition, removal or modification of non-code data files.
[allow or disallow mods?, basically ^]

Use of the Red Eclipse trademarks for any other reason is strictly prohibited
without express written consent of the Red Eclipse Team.

I'm not particularly happy with this, it's convoluted, relies on permitting specifics, (and is written by me >_<,) which likely will end up missing something important, one way or another, also, it intermixes trademark and copyright licensing, and the image file of the logo is obviously not under a particularly free license in itself.

Another alternative, which in my opinion seems favourable, is to use the examples given by Nathanael Nerode[1][2] in this matter, which would mean something like (there are numerous iterations and variations of this, I've picked the one from the wiki[2]):

The Red Eclipse name and Red Eclipse logo are trademarks, representing the Red
Eclipse game. We grant blanket permission to anyone to use the trademark
(or derivative marks) in any way except one:

alt 1.)
You may not use it to falsely represent something else as being the Red
Eclipse game. This means that you may, for instance, use "Based on Red
Eclipse" to indicate a modified version; you may use it to indicate that you
distribute copies of Red Eclipse or software based on Red Eclipse; you may
use it to indicate that you provide a service related to Red Eclipse or for
the benefit of Red Eclipse users; you may use it to express an opinion about
Red Eclipse; you may use it as an abstract artwork; but you may not use it
as the name for your entirely independent, unrelated software project.

alt 2. {remade list-style})
You may not use it to falsely represent something else as being the Red
Eclipse game. This means that you may, for instance:
* Use "Based on Red Eclipse" to indicate a modified version
* Use it to indicate that you distribute copies of Red Eclipse or software
based on Red Eclipse
* Use it to indicate that you provide a service related to Red Eclipse or
for the benefit of Red Eclipse users
* Use it to express an opinion about Red Eclipse
* Use it as an abstract artwork
But you may not use it as the name for your entirely independent, unrelated
software project.

In addition, the Red Eclipse logo is covered by copyright. The trademark
restriction above only applies to the trademark and confusingly similar
marks: so if you create a very different-looking modification of this logo,
you may use that as the logo for your unendorsed software based on Red
Eclipse or other project. We grant a license to the copyright of this work
as follows; the following license is not a trademark license.

The Red Eclipse logo is Copyright (C) 2009-2011 Red Eclipse Team
Creative Commons Attribution ShareAlike 3.0 License (CC-BY-SA)
http://creativecommons.org/licenses/by-sa/3.0/

This one would mean the the RE logo would be freely licensed, BUT, as soon as it is used in a trademark setting (and still resembles the current logo sufficiently), to represent a product, the trademark restrictions would kick in. Thus separating the trademark and the rest in a much more distinct way.

This gives, I think, a more general setup, whilst still retaining most of the restriction, albeit now implied instead of explicit. It may, obviously, be slightly more liberal than the previous suggestion in that it is unspecific. Is this a problem? Is the permissions given still within the scope of what you would feel comfortable with?

- arand


[1] http://lists.debian.org/debian-legal/20 ... 00071.html (and threeeead :/ )
[2] http://wiki.debian.org/ProposedTrademar ... ael_Nerode

[qreeves]

Sounds good at first glance, I'll take another look at it when I get some time and I'm not half asleep

[arand]

I looked around a bit more, and got some suggestions (with the common caveats, etc.) from a guy on SFLC on the matter, amongst other things, he pointed out that the SFLC and The Document Foundation has some useful documentation and policy which can be useful.

Hence, I've reworked the whole thing again based mainly on that, the result is available at https://sourceforge.net/apps/mediawiki/ ... ark_Policy
Feel free to edit away if you see anything you think could be better (or couldn't possibly be worse...).

It's much more clearer, I think, albeit lengthy *sigh*, but I guess that's the price when you want something a bit more useful than WTFPL...

What do you think?

@Quin: When you have spare time to look at it, obviously, I know you're a bit swamped currently