Bug 210775 - Review Request: Eternal Lands - a free MMORPG
Review Request: Eternal Lands - a free MMORPG
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
: Reopened
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2006-10-14 16:58 EDT by Karen Pease
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-17 11:20:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Karen Pease 2006-10-14 16:58:21 EDT
Spec URL: http://www.daughtersoftiresias.org/progs/el/eternallands.spec
Spec URL: http://www.daughtersoftiresias.org/progs/el/eternallands-music.spec
SRPM URL: http://www.daughtersoftiresias.org/progs/el/eternallands-1.3.2.0-1.src.rpm
SRPM URL: http://www.daughtersoftiresias.org/progs/el/eternallands-music-1.3.2.0-1.src.rpm
Description: 

"Eternal Lands is a free MMORPG (massively multiplayer online role playing
game) currently under development. The game is now in beta stage, and is
fully playable.  We are constantly adding more things to do, more items to
make, monsters to fight, and improving the systems."

Build notes:

Eternal Lands has a somewhat nonstandard build process, in that there are few fixed "releases", and some of the files have no tarball that contains them.  Rather, there is a "base", and changes (models, textures, etc) are pushed through updates or special update packages that don't contain the whole base.  As such, I had to set up my own tar-building process that takes a recent binary dir and a recent source tree and combines them into a tarball that can be distributed.  You'll also note that the permissions in directories that can have content pushed to them are less restrictive.  No binaries or libraries are ever pushed.

As the music is so large, as is common with games, eternallands is split up into binary and music packages.  The music package is optional.
Comment 1 Michał Bentkowski 2006-10-14 17:32:00 EDT
Maybe I'll make a review tommorow (but I'm not sure), but I see a few faults
here, in spec file.

 1) Why do you use "-n eternallands-%{version}" parameter to %setup macro?
By default, rpm tries to change directory to %{name}-%{version}.

 2) I think that inclusion wrapper as an another source would be better than
creating it in spec file (only imho).

 3) data files shouldn't go into %{_datadir}/games/%{name}, but
%{_datadir}/%{name}. Read http://fedoraproject.org/wiki/Extras/SIGs/Games
for further information.

 4) post scripts look wrongly (read http://fedoraproject.org/wiki/
PackagingDrafts/ScriptletSnippets)

And the last thing: creation of your own tarball may be a problem to a reviewer.
I think you should include all tarballs as sources and make any required
modifictions in %prep section and/or patches.
Comment 2 Michał Bentkowski 2006-10-14 17:41:35 EDT
Uh... Well it looks like this package cannot be approved in Extras.
I have read the license and it doesn't look like a license might be approved
in Extras.
Comment 3 Michał Bentkowski 2006-10-14 17:57:01 EDT
Now, I am sure.
Sorry, but this package cannot be approved. Its license is bad.
I wanted to make me sure on irc channel:
<tibbs> Clause 4 is definitely bad.
<tibbs> Freedom to modify is essential so that you can do things like fix 
security issues.
<tibbs> Clause 3 is probably bad as well.

So I have to close the review.
Comment 4 Karen Pease 2006-10-14 19:58:31 EDT
Now this is frustrating.  Because, according to this page: 
 
http://fedoraproject.org/wiki/Packaging/Guidelines 
 
"The goal of The Fedora Project is to work with the Linux community to build a 
complete, general purpose operating system exclusively from open source 
software. In accordance with that, all packages included in Fedora must be 
covered under an open source license.  
 
We clarify an open source license in three ways:  
 
* OSI-approved license. You can find the list of OSI approved licenses here:  
http://www.opensource.org/licenses/ " 
 
So, I went to http://www.opensource.org/licenses/, and I see this: 
 
http://www.opensource.org/licenses/qtpl.php 
 
What is up with this?  I just spent a couple hours packaging this because it 
looked like this license was acceptable.  Now you tell me that it isn't? 
 
Looking into it more, it seems you're talking about the restrictions to the 
license as opposed to the license itself.  For number 4, this RPM is a piece 
of client software.  Just because a server choses not to allow modified 
clients to connect doesn't mean that you can't modify the client.  You can 
modify this client to your heart's content -- you'll just need your own server 
if you want to connect legally. Any security changes that don't go straight 
into the EL tree or have EL permission should, responsibly, change the address 
that the server points to, just to make sure that users realize that it's a 
modified client.  If this is unacceptable to Fedora, then Fedora will *never* 
be able to have a MMORPG in with it, because modified clients are the bane of 
MMORPGs, as they allow botting.  EL is actually nicer than most -- you can use 
modified clients, so long as you register them and they're not obscenely 
cheating, and they're very good about accepting patches. 
 
As for #3, the first part is implicit in all licensing agreements.  You're 
never allowed to use other peoples' trademarks without their approval, whether 
their code is Open Source or not.  Is the second part a problem?  Right now, 
I'm looking at the LGPL, and it's little different: "You must cause the files 
modified to carry prominent notices stating that you changed the files and the 
date of any change." 
 
Oy.  Is there a way to get preapproval or anything so that this doesn't happen 
again in the future? 
 
Anyways, as to the other stuff: 
 
<I>1) Why do you use "-n eternallands-%{version}" parameter to %setup macro? 
By default, rpm tries to change directory to %{name}-%{version}.</I> 
 
I based this on the nethack-vultures specfile, which Ville built the framework 
of. 
 
<I>2) I think that inclusion wrapper as an another source would be better than 
creating it in spec file (only imho).</I> 
If you'll notice, part of the wrapper depends on the installation directory.  
Since it's so short, I figured this was cleaner than having a separate source 
that I'd have to sed to customize. 
 
<I>3) data files shouldn't go into %{_datadir}/games/%{name}, but 
%{_datadir}/%{name}. Read http://fedoraproject.org/wiki/Extras/SIGs/Games 
for further information.</I> 
 
Can do.  Once again, however, the nethack-vultures spec installed in there.  
So it must be wrong as well. 
 
<I>4) post scripts look wrongly (read http://fedoraproject.org/wiki/ 
PackagingDrafts/ScriptletSnippets)</I> 
 
This is also straight from nethack-vultures, and is code I was given from 
Ville.  What is the issue with what you see, out of curiosity -- is it the 
lack of an "if"? 
 
<I>And the last thing: creation of your own tarball may be a problem to a 
reviewer.  I think you should include all tarballs as sources and make any 
required modifictions in %prep section and/or patches.</I> 
 
But there are no tarballs except the initial and one update, which has been 
heavily modified over time by additional files (they're zips, not tarballs, 
but that's not important).  There are no up-to-date original tarballs, so 
there is no option but to create a new one each time.   
 
Comment 5 Karen Pease 2006-10-14 20:00:31 EDT
In short, what I'm saying is: tell me what needs to happen to make this 
approvable, and I'll work on getting those things done.  
  
Comment 6 Christopher Stone 2006-10-14 20:13:17 EDT
I'm sure there is a lot of interest in this game.  Please be very certain the
license is not acceptable before closing the bug.

If this is the case, we can always package it for Livna or Dribble.  But most of
us would prefer it in Extras if possible.

The license looks okay to be, but I am not a lawyer.  Perhaps we can bring it up
on the fedora extras mailing list if there is a question.
Comment 7 Christopher Stone 2006-10-14 20:14:52 EDT
Karen:  You might want to list this bug on the Games SIG page:
http://fedoraproject.org/wiki/Extras/SIGs/Games
Comment 8 Christopher Stone 2006-10-14 20:26:38 EDT
4. If you want to [re]distribute this game, you are NOT allowed to modify
anything. You can, however, distribute some txt/doc/etc file, with information
about you, etc.

Okay, this definately is no good for Fedora.  Please submit package to Livna or
Dribble.
Comment 9 Karen Pease 2006-10-14 21:57:48 EDT
Chris: Where are you seeing that?  I just searched through 
eternal_lands_license.txt, and that text is not there.  The game is QTPLed, 
with a few restrictions.  QTPL is, according to Fedora Extras's docs, and 
acceptable license.  So the only issue should be the restrictions. 
 
As per the security modifications issue: From entropy, one of the lead EL 
developers: 
 
"If they discover a security issue, they should submit a patch and a 
description to us, and we will include it right away in the CVS. 
Alternatively, they can just ask for our approval to distribute their own 
changes in the Fedora package, and if it's only a security issue that doesn't 
create any cheating, we will grant them the permission." 
 
Comment 10 Karen Pease 2006-10-14 22:03:53 EDT
Hmm, I see it: the "plain language" license differs strongly with the real 
license.  I'll point out the contradiction to the developers. 
 
Comment 11 Karen Pease 2006-10-14 22:13:13 EDT
I've posted the contradiction to them.  This should be fixed soon. 
 
Christopher: https://bugzilla.redhat.com/bugzilla//process_bug.cgi says that 
it's an "immutable page".  I can't edit it to add this link there. 
 
Comment 12 Christopher Stone 2006-10-14 22:27:18 EDT
Karen: That's good news about the license.  I think the license that actually
comes with the software would override the one on the web site.  We should
definately confirm with upstream developers, but this is good news!

I added this bug to the Games SIG page for you.
Comment 13 Karen Pease 2006-10-15 11:19:39 EDT
Bad news: It looks like the developers went with the "Quake" model here: that 
is, all of the code is under a free, open license, but all media (artwork, 
sounds, models, levels, etc) are not.  Now, if it were only "some" of the 
media that wasn't open, we could take the whole xmms/mp3 route and ship a 
partially crippled product.  However, since it all isn't open, all we'd be 
left with is something which doesn't do anything on it's own.  It'd be a valid 
code base for others to tweak, but as it stands, it wouldn't do anything. 
 
I withdraw the package, unless anyone thinks that there's a workable solution 
here.  I'll try taking it over to one of the other repos -- perhaps ATrpms.  
I'll have to look into how you become a developer there.  ;) 
 
Comment 14 Karen Pease 2006-10-15 13:18:42 EDT
Well, I suppose that I closed it prematurely.  Lets just make sure: if the 
code is OSS, but the artwork isn't allowed to be modified, it's not allowed, 
right?  Or is it? 
 
Comment 15 Karen Pease 2006-10-15 13:20:39 EDT
Er, isn't allowed to be included in other projects.  They'd allow  
Comment 16 Christopher Stone 2006-10-15 13:59:38 EDT
You could possibly seperate the artwork from the software, but if the software
is useless without the artwork this doesn't make much sense.

ATrpms is not compatible with Fedora (despite what they claim) and using this
repo will only mess up your system.

You should use either Livna http://rpm.livna.org/ or Dribble http://dribble.org.uk
for software that cannot go into Extras.
Comment 17 Karen Pease 2006-10-15 14:30:37 EDT
I've never actually heard of Dribble, and I use a fair number of repos.  I 
could go with Livna. 
 
I use ATrpms on my home system and have never had any problems.  What problems 
have you had? 
 
Comment 18 Christopher Stone 2006-10-15 14:52:58 EDT
ATrpms overrides official Fedora RPMs and basically you end up destroying your
system.  I have seen countless people come in #fedora with their messed up
systems and every time its because they have ATrpms packages installed.  If your
system hasnt messed up yet, then you have been very lucky.  You should
immediately remove all ATrpms you have installed on your system and replace them
with offical Fedora rpms from one of the repos mentioned above.  I do not use
ATrpms so I have never had any problems myself.  If there is an ATrpms package
that is not available on any of the "official" repos listed above, let us know.
Comment 19 Axel Thimm 2006-10-15 18:10:24 EDT
It's people like Chistopher Stone and their aggressive FUD that creates the
chasms between repos.
Comment 20 Christopher Stone 2006-10-15 18:30:38 EDT
It's not just me Axel, it is the _entire_ Fedora community.

You should not EVER replace, upgrade or obsolete any packages found in Core or
Extras.  Period.

If you no longer do this, then correct me, and I will apologize.
Comment 21 Axel Thimm 2006-10-15 18:41:16 EDT
Placing yourself as the frontman of the community doesn't make your FUD more true.
Comment 22 Christopher Stone 2006-10-15 18:55:21 EDT
Hey, if you dont believe me, why don't you subscribe to the fedora-extras (or
fedora-maintainers or fedora-packaging) mailing list and ask the community yourself.
Comment 23 Axel Thimm 2006-10-15 19:18:07 EDT
Thanks for the advice, I'm on all of these lists and in very good contact with
all parts of the community.
Comment 24 Christopher Stone 2006-10-16 02:00:41 EDT
Okay, for those who did not follow the discussion on the mailing list, here is
the summary:

- ATrpms contains packages which update or replace packages in core
- These replacements make debugging problems more difficult
- Telling a user to remove those packages is a valid mechanism for
simplifying a problem.
- People who use ATrpms no longer have a "Fedora" system.  They have a
"Fedora/ATrpms hybrid" system.
- Comments made by myself were not "unacceptable".

Let me reiterate what was stated in comment #20:
A repository should never replace, upgrade or obsolete any packages found in
Core or Extras.  Period.
Comment 25 Axel Thimm 2006-10-16 04:51:46 EDT
Now, how can you be summarizing a still ongoing discussion? And the way you
censor off all the unpleasant parts of it, that's really amazing!

The truth is that I have reported Christopher Stone's misbehaviour (FUD) on
fedora-maintainers. Furthermore Christopher suddenly "remembered" that contrary
to comments made here he has used ATrpms before, even several times and even
recently.

The current status is that after two board members having called Chistopher back
to reason (his bugzilla comments were labeled as "too much
invective" and having no place here) his facts suddenly started to melt down -
currently they have become unspecific "potential breakage".

But don't trust either side of summarizing:
https://www.redhat.com/archives/fedora-maintainers/2006-October/msg00097.html
Comment 26 Christopher Stone 2006-10-16 05:04:16 EDT
Right, you reported what could be construed as inappropriate comments made by
me.  And I will admit that I was not tactful, and some of the things I said
could have been stated better.

However, this is not what I asked you to ask the community.  I stated that a
repository should never override base packages and you called this "FUD" and yet
you never asked the community about this.  Instead you concentrated on a *much*
more irrelevent issue by focusing on my comments.

Let me state once again.  A repository which overrides base packages essentially
forks Fedora and creates its own distribution.  This is *far* more damaging to
the community than any comments made by a single individual.

So, let me say that I apologize for my comments and I am sorry they made you so
upset.  But there is a greater issue here, and that is ATrpms is overriding
Fedora core packages.

I will give a sincere apology to you in front of the entire community if you
remove these packages that are already in FC/FE, but judging from your actions
so far, I don't think this will happen.
Comment 27 Axel Thimm 2006-10-16 05:20:59 EDT
You're still mispresenting the discussion.

a) I called FUD your comments on ATrpms breaking every system, not what you're
   trying to put in my mouth
b) Fudding around like you do is not irrelevant, in fact it either splits the
   community or creates short-minded thought-to-be solutions like
   partial/selective repository enablement which generates the true bugs.
c) You judge too much
d) This discussion is off-topic here, I escalated this to fedora-maintainers where
   it belongs. Please keep this package submission FUD and rage free and let it
   return back to its own topic. See you on fedora-maintainers.

Comment 28 Karen Pease 2006-10-17 11:20:14 EDT
Well, since nobody has posted that they think there's a way to include this 
package, and since it's way off topic now, and since it's now in ATrpms, I'm 
going to go ahead and re-close this thread. 
 
Comment 29 Christopher Stone 2006-10-17 14:15:06 EDT
Karen: Since ATrpms forks Fedora and makes life difficult for everyone in the
community I will use your RPMs and add them to Dribble since I already have an
account there.

AT: Since you will never make any effort to stop forking the distribution and
you are far more concerned about people telling other people to not use your
damaging repository I will continue to encourage people to not use your repo.

Note You need to log in before you can comment on or make changes to this bug.