Recently, it has come to light that all Parallel Realities games were knowingly
using and including non-free content (graphics, audio, etc).
Accordingly, we need to block these packages from Fedora:
Tom "spot" Callaway <tcallawa(a)redhat.com>
Some time ago, I wanted to package  a fork of the Python library
Soya3D called PySoy . They were releasing it under GPLv3 until now,
but they have relicensed it as AGPLv3  right now. We have had a
debate in debian-legal  about the possible consecuences of
accepting AGPLv3 as DFSG-free  and, even though it's not totally
closed, it seems that we won't be able to consider it free. Of course
the final decision is to be made by ftpmasters and they haven't
answered yet .
According to Arc, main developer for PySoy, Mark Shuttleworth believes
in the freeness of AGPLv3, so they will have all that stuff in their
Ubuntu universe/main repositories, even though the MOTU (Masters Of
The Universe, the Ubuntu team that manages universe/multiverse
repositories) doesn't seem to think the same. It makes sense that
Ubuntu considers that because my feeling is that Ubuntu and FSF are
getting along really well and very close to each other.
In any case, i wanted to know, mostly out of curiosity, what is the
point of view about Fedora regarding AGPLv3, and whether you consider
it free or not.
Thanks and greetings,
Some other relevant links:
AGPL stands for GNU Affero General Public License and it's a slightly
modified GPLv3 license with the extra restriction (clause 13): "if you
modify the Program, your modified version must prominently offer all
users interacting with it remotely through a computer network (if your
version supports such interaction) an opportunity to receive the
Corresponding Source of your version by providing access to the
Corresponding Source from a network server at no charge, through some
standard or customary means of facilitating copying of software"
As some of you probably already know a few blender artists and crystalspace
developers have been working fulltime on this new completely FREE (both art and
code) game called Apricot:
They are now almost done and are looking for people to package it up for
various distro's. I've offered todo that, but I'm currently suffering from a
serious -ENOTIME situation, so I was hoping there are other people here who are
willing to pick this up. If you do you can mail me for help any time!
Apricot uses crystalspace and needs a special svn snapshot, you do not need to
worry about parallel installability with the regular crystalspace, as that has
no users in Fedora so you can just upgrade the current crystalspace package to
the "blessed" svn snapshot:
Apricot also uses CEL, same story:
For apricot itself just use the latest svn.
Thanks & Regards,
I know most of us (fedora-games-list subscribers) have grown from game
packagers to contributors also doing more "serious" Fedora work.
Still Games are fun and having good Games support in Fedora is important and I
know we are all still working hard to keep our game packages in top notch state.
Given that we have all these top notch state game packages its really a shame
that we've not done a Games Spin for F-9, and we might miss the boat for F-10
too. So I'm looking for someone to pull and coordinate the efforts needed to
get a Games Spin for F-10, as always I'm willing to help but:
Is taking almost all my time so I have no time to take the lead on this one, so
any takers? The first task would be to fill in the details of:
And ask for the spin to be approved.
Thanks & Regards,
I am a new package contributor to Fedora, and I currently only have my
first package, milkytracker, in Fedora. I am now looking forward to
package another program that I use and that is not available in
According to the Fedora Games Packaging guidelines, the data files of
Crrcsim should end up in /usr/share/crrcsim, not in
/usr/share/games/crrcsim. While I agree with the guideline, Crrcsim's
configure script doesn't (yet) support this and it always wants to put
files under the games directory.
Would someone have any pointers on solving the situation?
The one solution I have thought of is to manually mv the data
directory into the right place after make install. After this, I would
need to create a wrapper script that would cd to the data directory
(Crrcsim searches the current directory, in addition to some
presumably hard-coded paths) and then run the actual binary
executable. In this case, should I put the binary into /usr/libexec?
For future releases, it would probably be wise to work with the
upstream developers to make the simulator easier installable in
various directory configurations.
### Copyright Information
C O N Q U E S T (VAX/VMS Ratfor)
Copyright (C)1983-1986 by Jef Poskanzer and Craig Leres
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that this copyright notice appear in all copies
and in all supporting documentation. Jef Poskanzer and Craig
Leres make no representations about the suitability of this
software for any purpose. It is provided "as is" without express
or implied warranty.
Unix/C specific porting and supporting code Copyright
(C)1994-2006 by Jon Trulson <jon(a)radscan.com> under the same
terms, conditions, and restrictions of the original copyright by
Jef Poskanzer and Craig Leres.
(1/28/99) Due to a little prodding from Sunsite, I've decided on
the ARTISTIC LICENSE (see the LICENSE file) for Conquest.
With best regards!
Quake 3 mod. Pretty interesting. Anyone wants to package?
"Since the release of the Quake 3 engine source code in summer 2005 a
lot of modifications and spin-offs have emerged. One such spin-off,
Smokin' Guns (formerly known as Western Quake 3), is all about classical
Wild West themes: big rifles and revolvers, wailing steel guitars, bank
robberies, and smooth talking. It's a game you don't want to miss"