[bug#35234] gnu: Add the-dark-mod.

Message ID 20190411181644.21661-1-mail@ambrevar.xyz
State Accepted
Headers show
Series [bug#35234] gnu: Add the-dark-mod. | expand

Checks

Context Check Description
cbaines/applying patch fail Apply failed

Commit Message

Pierre Neidhardt April 11, 2019, 6:16 p.m. UTC
* gnu/packages/games.scm (the-dark-mod): New variable.
---
 gnu/packages/games.scm | 142 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 142 insertions(+)

Comments

Ricardo Wurmus April 11, 2019, 7:40 p.m. UTC | #1
Hi Pierre,

> * gnu/packages/games.scm (the-dark-mod): New variable.
[…]
> +      (synopsis "Game based on the Thief series by Looking Glass Studios")
> +      (description (format #f "The Dark Mod (TDM) is stealth/infiltration game
> +based on the Thief series by Looking Glass Studios.  Formerly a Doom III mod,
> +it is now released as a standalone.
> +
> +The game data must be fetched manually by running @command{tdm_update}.
> +The ~a environment variable specifies the location where the game data is
> +saved (defaults to ~a)."
> +                           the-dark-mod-env-var-name the-dark-mod-env-var-value))

Is this actually free software?  Does it depend on the proprietary Thief
game data to be playable?  What is the purpose of tdm_update?

The value of the description field must be a plain string.  It should
not be a format expression to allow for translations.
Pierre Neidhardt April 12, 2019, 9:39 a.m. UTC | #2
Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Pierre,
>
>> * gnu/packages/games.scm (the-dark-mod): New variable.
> […]
>> +      (synopsis "Game based on the Thief series by Looking Glass Studios")
>> +      (description (format #f "The Dark Mod (TDM) is stealth/infiltration game
>> +based on the Thief series by Looking Glass Studios.  Formerly a Doom III mod,
>> +it is now released as a standalone.
>> +
>> +The game data must be fetched manually by running @command{tdm_update}.
>> +The ~a environment variable specifies the location where the game data is
>> +saved (defaults to ~a)."
>> +                           the-dark-mod-env-var-name the-dark-mod-env-var-value))
>
> Is this actually free software?  Does it depend on the proprietary Thief
> game data to be playable?  What is the purpose of tdm_update?

It is: I added a comment in the license section: all the data fetched by
the "tdm_update" executable is under CC.  tdm_update is the in-house
package manager.  It's sad the game data is not versioned, but I don't
see a way around it at  the moment.

We have quite a few game engines in our repository that
depend on proprietary game data to be playable.  But The Dark Mod is not one
of them.

> The value of the description field must be a plain string.  It should
> not be a format expression to allow for translations.

Hmm... I really liked that I could make the environment variable
customizable, but I guess I'll have to hard-code it in the description then.

Thanks for the review!
Ricardo Wurmus April 12, 2019, 11:22 a.m. UTC | #3
Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Pierre,
>>
>>> * gnu/packages/games.scm (the-dark-mod): New variable.
>> […]
>>> +      (synopsis "Game based on the Thief series by Looking Glass Studios")
>>> +      (description (format #f "The Dark Mod (TDM) is stealth/infiltration game
>>> +based on the Thief series by Looking Glass Studios.  Formerly a Doom III mod,
>>> +it is now released as a standalone.
>>> +
>>> +The game data must be fetched manually by running @command{tdm_update}.
>>> +The ~a environment variable specifies the location where the game data is
>>> +saved (defaults to ~a)."
>>> +                           the-dark-mod-env-var-name the-dark-mod-env-var-value))
>>
>> Is this actually free software?  Does it depend on the proprietary Thief
>> game data to be playable?  What is the purpose of tdm_update?
>
> It is: I added a comment in the license section: all the data fetched by
> the "tdm_update" executable is under CC.  tdm_update is the in-house
> package manager.  It's sad the game data is not versioned, but I don't
> see a way around it at  the moment.

I’d prefer not to recommend the use of tdm_update and create a package
for the game data instead.  Under what URL can the game data be
downloaded?  Can we use a web.archive.org URL or host the data
somewhere?

> We have quite a few game engines in our repository that
> depend on proprietary game data to be playable.  But The Dark Mod is not one
> of them.

First: what game engines do we provide that can only be used with
proprietary game data?

Second: The Dark Mod source repository contains a README with this text:

  This source release does not contain any game data, the game data is still
  covered by the original EULA and must be obeyed as usual.

  https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/README.txt

What is that EULA?  Is this README incorrect?  Or this misleading as it
would only apply to Doom 3?

--
Ricardo
Pierre Neidhardt April 12, 2019, 12:02 p.m. UTC | #4
Ricardo Wurmus <rekado@elephly.net> writes:

> I’d prefer not to recommend the use of tdm_update and create a package
> for the game data instead.  Under what URL can the game data be
> downloaded?  Can we use a web.archive.org URL or host the data
> somewhere?

There are a bunch of official mirrors, not of which versions the data.
I think it'd be nice to discuss this with upstream though.

>> We have quite a few game engines in our repository that
>> depend on proprietary game data to be playable.  But The Dark Mod is not one
>> of them.
>
> First: what game engines do we provide that can only be used with
> proprietary game data?

OpenMW, Arx Libertatis, OpenRCT2, off the top of my head.
Maybe some forks of the Doom 1 & 2 engines too.

> Second: The Dark Mod source repository contains a README with this text:
>
>   This source release does not contain any game data, the game data is still
>   covered by the original EULA and must be obeyed as usual.
>
>   https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/README.txt
>
> What is that EULA?  Is this README incorrect?  Or this misleading as it
> would only apply to Doom 3?

Absolutely, the README is a left-over of the Doom 3 GPL source.
(Many files haven't been updated properly.)
Ricardo Wurmus April 21, 2019, 2:13 p.m. UTC | #5
Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
[…]
>> First: what game engines do we provide that can only be used with
>> proprietary game data?
>
> OpenMW, Arx Libertatis, OpenRCT2, off the top of my head.

Hmm, that’s not good then.  I think we should take a closer look at them
to decide whether they should be removed.

The description of Arx Libertatis says this:

   Arx Libertatis is a cross-platform, open source port of Arx Fatalis,
   a 2002 first-person role-playing game / dungeon crawler developed by
   Arkane Studios.  This port however does not include the game data, so
   you need to obtain a copy of the original Arx Fatalis or its demo to
   play Arx Libertatis.[…]

Aside from the “open source” mention I don’t think it’s right for us to
recommend that users obtain a copy of a proprietary game.

> Maybe some forks of the Doom 1 & 2 engines too.

I think these are fine, because there are numerous games based on these
engines

--
Ricardo
Ludovic Courtès April 21, 2019, 4:18 p.m. UTC | #6
Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
> […]
>>> First: what game engines do we provide that can only be used with
>>> proprietary game data?
>>
>> OpenMW, Arx Libertatis, OpenRCT2, off the top of my head.
>
> Hmm, that’s not good then.  I think we should take a closer look at them
> to decide whether they should be removed.
>
> The description of Arx Libertatis says this:
>
>    Arx Libertatis is a cross-platform, open source port of Arx Fatalis,
>    a 2002 first-person role-playing game / dungeon crawler developed by
>    Arkane Studios.  This port however does not include the game data, so
>    you need to obtain a copy of the original Arx Fatalis or its demo to
>    play Arx Libertatis.[…]
>
> Aside from the “open source” mention I don’t think it’s right for us to
> recommend that users obtain a copy of a proprietary game.

The “you need to obtain a copy…” bit is problematic because it refers to
non-free software.

However, I believe it’s really talking about “non-functional data” in
FSDG terms:

  https://gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data

So, rephrased to suggest obtaining the non-free _data_, the sentence may
be OK per the FSDG.  The problem is that it’s maybe not that simple to
obtain the data without the non-free game…

Thoughts?

Now, I would hope that the free game engine could serve as the basis for
a free game, with free game data as well.

Ludo’.
Pierre Neidhardt April 22, 2019, 9:02 a.m. UTC | #7
Ludovic Courtès <ludo@gnu.org> writes:

> Thoughts?
>
> Now, I would hope that the free game engine could serve as the basis for
> a free game, with free game data as well.

Absolutely.  Technically all those engines can be re-used for
fully-free game development.

There is a blurred line however between the means and the ends here.
For instance, lots of packages we have in Guix can be used to deal with
some proprietary data, from web browsers to video players, you name it.

My take at this issue is that free game engines are a first step towards
liberating the video game industry further.  If we don't allow the
opportunity for free game engines in the first place, free game data
will never be worked on.

Guix stands mostly (but not only) for free software.  Game data is a
whole different battle though, and I'm not sure it's the role of Guix to
fight this one.  If we can encourage freedom, however, by supporting the
first step towards "free game data," then it's a win for freedom in my
opinion.  The reverse could be more damaging to the users' freedom in
the long run than protecting it.

The Dark Mod is fully free, the game data is under some CC, so I'll
commit the package if there is no objection.
Ricardo Wurmus April 22, 2019, 9:19 a.m. UTC | #8
Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Thoughts?
>>
>> Now, I would hope that the free game engine could serve as the basis for
>> a free game, with free game data as well.
>
> Absolutely.  Technically all those engines can be re-used for
> fully-free game development.
>
> There is a blurred line however between the means and the ends here.
> For instance, lots of packages we have in Guix can be used to deal with
> some proprietary data, from web browsers to video players, you name it.
>
> My take at this issue is that free game engines are a first step towards
> liberating the video game industry further.  If we don't allow the
> opportunity for free game engines in the first place, free game data
> will never be worked on.

This is a separate issue.  There is no objection to providing free game
engines.

This is how we got here:

--8<---------------cut here---------------start------------->8---
>>> First: what game engines do we provide that can only be used with
>>> proprietary game data?
>>
>> OpenMW, Arx Libertatis, OpenRCT2, off the top of my head.
>
> Hmm, that’s not good then.  I think we should take a closer look at them
> to decide whether they should be removed.
>
> The description of Arx Libertatis says this:
>
>    Arx Libertatis is a cross-platform, open source port of Arx Fatalis,
>    a 2002 first-person role-playing game / dungeon crawler developed by
>    Arkane Studios.  This port however does not include the game data, so
>    you need to obtain a copy of the original Arx Fatalis or its demo to
>    play Arx Libertatis.[…]
>
> Aside from the “open source” mention I don’t think it’s right for us to
> recommend that users obtain a copy of a proprietary game.

The “you need to obtain a copy…” bit is problematic because it refers to
non-free software.
--8<---------------cut here---------------end--------------->8---

The package claims to provide a game, not a game engine.  As a user I
would install this only to be told that I need to obtain proprietary
software (i.e. the game or the demo) to play this.  This is steering
people to seek out and use proprietary software.

We should change the package so that it conveys the right message,
either by making it clear that this is not a game but the game engine,
or by including the game data.  Even if the data are non-functional they
must be redistributable.  If they are not then we cannot include the
game data and it would be highly misleading to call the package after
the game.

> The Dark Mod is fully free, the game data is under some CC, so I'll
> commit the package if there is no objection.

Please hold off on pushing this package until we reach an agreement.  My
original objection was this:

--8<---------------cut here---------------start------------->8---
> * gnu/packages/games.scm (the-dark-mod): New variable.
[…]
> +      (synopsis "Game based on the Thief series by Looking Glass Studios")
> +      (description (format #f "The Dark Mod (TDM) is stealth/infiltration game
> +based on the Thief series by Looking Glass Studios.  Formerly a Doom III mod,
> +it is now released as a standalone.
> +
> +The game data must be fetched manually by running @command{tdm_update}.
> +The ~a environment variable specifies the location where the game data is
> +saved (defaults to ~a)."
> +                           the-dark-mod-env-var-name the-dark-mod-env-var-value))

Is this actually free software?  Does it depend on the proprietary Thief
game data to be playable?  What is the purpose of tdm_update?
--8<---------------cut here---------------end--------------->8---

I don’t think it’s good to have people run the tdm_update tool, because
this smells like the anti pattern seen for many games in other
distributions where you really only install a downloader, which then
fetches the (potentially non-free) game data.

The game data are free in this case, but since this is provided by an
unversioned URL it might not be when a user runs the command.  I prefer
to include a snapshot of the game data.

--
Ricardo
Adonay Felipe Nogueira April 22, 2019, 9:40 a.m. UTC | #9
Em 21 de abril de 2019 11:13:47 BRT, Ricardo Wurmus <rekado@elephly.net> escreveu:
>Hmm, that’s not good then.  I think we should take a closer look at
>them
>to decide whether they should be removed.
>
>The description of Arx Libertatis says this:
>
>   Arx Libertatis is a cross-platform, open source port of Arx Fatalis,
>   a 2002 first-person role-playing game / dungeon crawler developed by
>  Arkane Studios.  This port however does not include the game data, so
>   you need to obtain a copy of the original Arx Fatalis or its demo to
>   play Arx Libertatis.[…]
>
>Aside from the “open source” mention I don’t think it’s right for us to
>recommend that users obtain a copy of a proprietary game.

As far as I know including game engines is fine as long as they (not the game data) can be provided as FSDG-compliant (this is a litter further than simply being free/libre because GNU FSDG may require removal of third-party repositories - depending on their policy).

These software are useful since one can develop free/libre games to work with them.

What I do think must be done is have a policy not to do a full copy-paste to the description from the original project in the package's metadata, this way we can foster a better compliance with the GNU FSDG in regards to not referencing non-free/non-libre functional data or nonfunctional ones that forbid unlimited sharing and selling.

This "avoid full copy-paste" policy would be similar to what we have in the Free Software Directory[1] - not equal since the motive would be different.

The next challenge would be making sure that the software and documentation don't mention stuff that isn't FSDG-compliant.


[1] https://directory.fsf.org/wiki/Free_Software_Directory:Workflow .
Pierre Neidhardt April 22, 2019, 9:42 a.m. UTC | #10
Makes sense, understood.
Adonay Felipe Nogueira April 22, 2019, 10:01 a.m. UTC | #11
Em 21 de abril de 2019 13:18:15 BRT, "Ludovic Courtès" <ludo@gnu.org> escreveu:
>The “you need to obtain a copy…” bit is problematic because it refers
>to
>non-free software.
>
>However, I believe it’s really talking about “non-functional data” in
>FSDG terms:
>
>https://gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data
>
>So, rephrased to suggest obtaining the non-free _data_, the sentence
>may
>be OK per the FSDG.  The problem is that it’s maybe not that simple to
>obtain the data without the non-free game…
>
>Thoughts?

As a plus, if we were to include the [assumed] nonfunctional data as package definition, we would have to attest whether that could be shared and sold unlimitedly.

As for simply mentioning it or referring to a repository containing it, considering the fact that it's been 6 months since I last read the GNU FSDG thoroughly, I do think that the guidelines need to be updated so as to officially address these two cases. Perhaps we all need to question FSF to do that?

A reminder however, that maps with scripted events are also functional data since they can misbehave. Whether the game referenced by the engine uses those is yet to be proven.
Ricardo Wurmus April 22, 2019, 11:56 a.m. UTC | #12
Adonay Felipe Nogueira <adfeno@hyperbola.info> writes:

> What I do think must be done is have a policy not to do a full
> copy-paste to the description from the original project in the
> package's metadata, this way we can foster a better compliance with
> the GNU FSDG in regards to not referencing non-free/non-libre
> functional data or nonfunctional ones that forbid unlimited sharing
> and selling.
>
> This "avoid full copy-paste" policy would be similar to what we have
> in the Free Software Directory[1] - not equal since the motive would
> be different.
>
> The next challenge would be making sure that the software and
> documentation don't mention stuff that isn't FSDG-compliant.

This is usually addressed during patch review.

--
Ricardo
Ludovic Courtès April 22, 2019, 4:50 p.m. UTC | #13
Ricardo Wurmus <rekado@elephly.net> skribis:

> The package claims to provide a game, not a game engine.  As a user I
> would install this only to be told that I need to obtain proprietary
> software (i.e. the game or the demo) to play this.  This is steering
> people to seek out and use proprietary software.
>
> We should change the package so that it conveys the right message,
> either by making it clear that this is not a game but the game engine,
> or by including the game data.  Even if the data are non-functional they
> must be redistributable.  If they are not then we cannot include the
> game data and it would be highly misleading to call the package after
> the game.

I agree.

Pierre, can you look into implementing one of these two options?

>> * gnu/packages/games.scm (the-dark-mod): New variable.
> […]
>> +      (synopsis "Game based on the Thief series by Looking Glass Studios")
>> +      (description (format #f "The Dark Mod (TDM) is stealth/infiltration game
>> +based on the Thief series by Looking Glass Studios.  Formerly a Doom III mod,
>> +it is now released as a standalone.
>> +
>> +The game data must be fetched manually by running @command{tdm_update}.
>> +The ~a environment variable specifies the location where the game data is
>> +saved (defaults to ~a)."
>> +                           the-dark-mod-env-var-name the-dark-mod-env-var-value))

(As a side note: do not use ‘format’ here, or wrap the format string in
‘G_’ to allow for i18n.)

> Is this actually free software?  Does it depend on the proprietary Thief
> game data to be playable?  What is the purpose of tdm_update?
>
> I don’t think it’s good to have people run the tdm_update tool, because
> this smells like the anti pattern seen for many games in other
> distributions where you really only install a downloader, which then
> fetches the (potentially non-free) game data.
>
> The game data are free in this case, but since this is provided by an
> unversioned URL it might not be when a user runs the command.  I prefer
> to include a snapshot of the game data.

+1.  The download script looks like giving upstream blanket permission;
even from a technical standpoint, it goes counter our reproducibility
mantra.

(We would disable phone-home mechanisms, and automatic download of game
data goes even a step further.)

Ludo’.
Pierre Neidhardt April 22, 2019, 5:42 p.m. UTC | #14
Any suggestion on how/where to snapshot the game data?
We could ask upstream, but I'm not very optimistic this will help much.

Patch

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 2afe5b58ba..4895c0e361 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -113,6 +113,7 @@ 
   #:use-module (gnu packages libunwind)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages lua)
+  #:use-module (gnu packages m4)
   #:use-module (gnu packages man)
   #:use-module (gnu packages maths)
   #:use-module (gnu packages mp3)
@@ -141,6 +142,7 @@ 
   #:use-module (gnu packages textutils)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages upnp)
+  #:use-module (gnu packages version-control)
   #:use-module (gnu packages video)
   #:use-module (gnu packages vulkan)
   #:use-module (gnu packages web)
@@ -6765,3 +6767,143 @@  a procedurally generated world, the player can explore thousands of rooms in
 search of powerful artifacts, tools to help them, and to eventually free the
 Orcus Dome from evil.")
     (license license:gpl3+)))
+
+(define-public the-dark-mod
+  (let ((scons-flags
+         (string-append "TARGET_ARCH="
+                              (match (%current-system)
+                                ("i686-linux" "x86")
+                                ("x86_64-linux" "x64"))))
+        (the-dark-mod-env-var-name "THEDARKMOD_PATH")
+        (the-dark-mod-env-var-value "~/.local/share/darkmod"))
+    (package
+      (name "the-dark-mod")
+      (version "2.07")
+      (source (origin
+                (method url-fetch)
+                (uri (string-append "http://www.thedarkmod.com/sources/thedarkmod."
+                                    version ".src.7z"))
+                (sha256
+                 (base32
+                  "1lhqwl0qnddzbh9na9c73aqg923ixyrr5ih12p4y9v5nis9b3kyy"))))
+      (build-system scons-build-system)
+      (arguments
+       `(#:tests? #f                    ;no test
+         #:scons ,scons-python2
+         ;; BUILD=release makes Scons strip the executable, which fails because
+         ;; "strip" is not found in the path.
+         #:scons-flags (list ,scons-flags)
+         #:phases
+         (modify-phases %standard-phases
+           (replace 'unpack
+             (lambda* (#:key source #:allow-other-keys)
+               (and (invoke "7z" "x" source))))
+           (add-after 'unpack 'fix-build-flags
+             ;; TODO: By default, -no-pie is passed because of the assumption
+             ;; that -fPIC was used to build ffmpeg.  This does not work with
+             ;; out default gcc-5.  This package does not seem to build with
+             ;; gcc>5.
+             (lambda _
+               (substitute* "SConstruct"
+                 (("BASELINKFLAGS.append\\( '-no-pie' \\)") ""))
+               #t))
+           (add-after 'build 'build-updater
+             (lambda _
+               (with-directory-excursion "tdm_update"
+                 (apply invoke "scons"
+                        (append (list "-j" (number->string
+                                            (parallel-job-count)))
+                                (list ,scons-flags))))
+               #t))
+           (replace 'install
+             (lambda* (#:key inputs outputs #:allow-other-keys)
+               (let* ((out (assoc-ref outputs "out"))
+                      (mesa (assoc-ref inputs "mesa"))
+                      (bin (string-append out "/bin/thedarkmod"))
+                      (bin-real (string-append out "/bin/.thedarkmod-real"))
+                      (updater (string-append out "/bin/tdm_update"))
+                      (updater-real (string-append out "/bin/.tdm_update-real"))
+                      (apps (string-append out "/share/applications"))
+                      (icons (string-append out "/share/icons")))
+                 (mkdir-p (string-append out "/bin"))
+                 (copy-file ,@(match (%current-system)
+                                ("i686-linux"
+                                 '("thedarkmod.x86"))
+                                ("x86_64-linux"
+                                 '("thedarkmod.x64")))
+                            bin-real)
+                 (copy-file "tdm_update/tdm_update.linux" updater-real)
+                 (with-output-to-file bin
+                   (lambda _
+                     (format #t "\
+#!~a
+export LD_LIBRARY_PATH=~a/lib
+~a=${~a:-~a}
+cd \"$~a\"
+exec -a \"~a\" ~a \"$@\"\n"
+                             (which "bash")
+                             mesa
+                             ,the-dark-mod-env-var-name ,the-dark-mod-env-var-name
+                             ,the-dark-mod-env-var-value
+                             ,the-dark-mod-env-var-name
+                             (basename bin) bin-real)))
+                 (chmod bin #o555)
+                 (with-output-to-file updater
+                   (lambda _
+                     (format #t "\
+#!~a
+~a=${~a:-~a}
+mkdir -p \"$~a\"
+## tdm_update outputs a log in its current working directory.
+cd \"$~a\"
+~a --noselfupdate --targetdir \"$~a\" \"$@\"~%"
+                             (which "bash")
+                             ,the-dark-mod-env-var-name ,the-dark-mod-env-var-name
+                             ,the-dark-mod-env-var-value
+                             ,the-dark-mod-env-var-name
+                             ,the-dark-mod-env-var-name
+                             updater-real
+                             ,the-dark-mod-env-var-name)))
+                 (chmod updater #o555)
+                 (mkdir-p apps)
+                 (mkdir-p icons)
+                 (install-file "tdm_update/darkmod.ico" icons)
+                 (with-output-to-file
+                     (string-append apps "/darkmod.desktop")
+                   (lambda _
+                     (format #t
+                             "[Desktop Entry]~@
+                     Name=The Dark Mod~@
+                     Comment=The Dark Mod~@
+                     Exec=~a~@
+                     TryExec=~@*~a~@
+                     Icon=darkmod~@
+                     Categories=Game~@
+                     Type=Application~%"
+                             bin)))))))))
+      (inputs
+       `(("mesa" ,mesa)
+         ("libxxf86vm" ,libxxf86vm)
+         ("openal" ,openal)
+         ("libxext" ,libxext)))
+      (native-inputs
+       `(("p7zip" ,p7zip)
+         ("m4" ,m4)
+         ("subversion" ,subversion)))
+      (home-page "http://www.thedarkmod.com/")
+      (synopsis "Game based on the Thief series by Looking Glass Studios")
+      (description (format #f "The Dark Mod (TDM) is stealth/infiltration game
+based on the Thief series by Looking Glass Studios.  Formerly a Doom III mod,
+it is now released as a standalone.
+
+The game data must be fetched manually by running @command{tdm_update}.
+The ~a environment variable specifies the location where the game data is
+saved (defaults to ~a)."
+                           the-dark-mod-env-var-name the-dark-mod-env-var-value))
+      (supported-systems '("x86_64-linux" "i686-linux"))
+      (license (list license:gpl3       ; idTech 4 engine
+                     license:bsd-3 ; Portion of the engine by Broken Glass Studios
+                     ;; All other non-software components: they are not
+                     ;; included in the Guix package, but the updater fetches
+                     ;; them.
+                     license:cc-by-sa3.0)))))