[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Licensing Issues for Proprietary Game Assets



On Thu, 02 Mar 2017 at 09:41:30 +0200, Kyle Robbertze wrote:
> Is it possible to package this for Debian with the asset license as is?

Probably not. This sounds like a job for game-data-packager to me:
it downloads and repackages proprietary game assets, or reads them
from a non-distributable GOG or Steam package or a CD-ROM or whatever,
and produces and installs a .deb that is not redistributable. Have a
look at iortcw to see how that typically works (data/rtcw.yaml in
game-data-packager is the corresponding description of the proprietary
assets).

game-data-packager was originally for game assets that are sold commercially
and are not legally distributable at all, but freely downloadable assets with
an unclear or otherwise unacceptable license are also in-scope.
If the proprietary assets are downloadable in an automated way using standard
tools (game-data-packager uses Python's built-in HTTP support), then
game-data-packager will be able to create empty-epsilon-data entirely
automatically, like it does for several games in the Zork series.

If the engine that will interpret those assets is Free Software, it can
go in contrib[1]; if not, but it is distributable separately from the assets,
it can go in non-free.

If you go this route, please do your packaging with the assumption that
data files will go in /usr/share/games/empty-epsilon or similar, install
them there manually for now, and open a 'wishlist' game-data-packager bug
with details of the files that need to be packaged. Patches welcome (the
YAML format should be reasonably self-explanatory), or we can use the
output of "game-data-packager make-template /usr/share/games/empty-epsilon"
as a starting point for the necessary information.

You can also use the game-data-packager launcher (game-data-packager-runtime)
if you want to avoid having to have your own handling for missing data files
like iortcw does. It's a simple Python + GTK wrapper around the real
executable, which checks that the required files and engine are present,
and execs the real executable if everything looks OK. Examples of its use
so far include Quake I, II and III (Free engines, proprietary data), and
Quake IV and Unreal (proprietary but freely downloadable Linux binaries,
proprietary data).

    S

[1] I'm assuming there isn't an alternative set of Free assets that would
    allow it to be in main, like OpenArena for the Quake III Arena engine?


Reply to: