Game Client License?

[roman_gruber]

https://bugs.gentoo.org/show_bug.cgi?id=548926

 

I highly appreciate when radu can make it clear to the devs for the game license, ty.

[Burn]

(Eh, side note about that thread: I haven't been a moderator for well over a year now. I'm only part of the map editing team... me and Ace, heh. And SUSE builds are just done by me voluntarily.)

 

 

Besides compiling the GIT code, this data pack linked below is needed. The datafiles extracted, the compiled binary placed in the top directory of that (where el.ini is), and any installer should change the el.ini #data_dir path to the path where said binary is placed.

 

http://twinmoons.org.uk/el/rel/194/EL-1.9.4-all-datafiles.zip

 

It includes a license.txt file that should be read. Basically it's free to distribute but there's limitations on artwork usage and such that may not make it "free enough" for some distros.

 

It's not "free enough" for OpenSUSE official repositories for example, thus the use of my unofficial repository for my builds.

 

Bluap runs his own repositories for ubuntu and debian.

 

 

 

But if the only issue is "can it be redistributed" as the dev in your thread is questioning, yes it can (per the license.txt file). The license has not changed so if they were doing it before, they can continue to do it. Just grab the zip pack above.

Edited May 18, 2015 by Burn

[Llywar]

Are those data files legally hosted? The only issue holding up distributing this on Gentoo is the fact that I couldn't find a legally-hosted file containing the data files (maps, artwork, etc) in a form other than the installer. Previously they had been hosted as zip files on the el website.

 

I doubt I'll have any issues building the client once I have them. There is no need for Gentoo to redistribute the artwork as long as it is legally hosted in a zip file, tarball, etc. Gentoo separates the installation scripts from the files to install, so we don't need to redistribute the original files to package them.

 

As far as I can tell, the license itself only gives permission to redistribute the client, not the artwork, and the latter is the problem here.

[Burn]

Well, radu or roja would have to be specific on that.

 

 

But there's quite a few separately distributing them. Myself included via OpenSUSE RPMs.

 

 

 

As for the hosting above, that's bluap's server, who is currently the primary client maintainer (and also separately distributes the files via his ubuntu/debian builds). That package was used for creating the installers on the Download page.

 

The data is technically available in the Macintosh zip (in EternalLands.app/Contents/Resources/data) though yeah, having the plain data available on the DL page for source compilers would be a good idea.

[Llywar]

It actually does look like Gentoo has been mirroring the data files unmodified. I'll go ahead and stick with that - I suspect they don't care since we aren't modifying them, and we're only using them with stock clients (built from source, but only patched to make the build system work). If they have any objection I'll happily take down the mirroring at their request.

 

So, I was able to get the data files packaged without much fuss using your URL. Now the only issue is that the client won't build. I'll need to give that more attention.

 

First error:

x86_64-pc-linux-gnu-gcc -march=native -Wall -Wdeclaration-after-statement -O0 -ggdb -pipe -DLINUX -DELC -Dassume-digests -Dbinpkg-logs -Dbuildpkg -Dcgroup -Dconfig-protect-if-modified -Ddistlocks -Debuild-locks -Dfixlafiles -Dipc-sandbox -Dmerge-sync -Dmultilib-strict -Dnetwork-sandbox -Dnews -Dparallel-fetch -Dpreserve-libs -Dprotect-owned -Dsandbox -Dsfperms -Dsign -Dsplitdebug -Dstrict -Dunknown-features-warn -Dunmerge-logs -Dunmerge-orphans -Duserfetch -Duserpriv -Dusersandbox -Dusersync -Dxattr -D_7ZIP_ST -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -I/usr/include/minizip -fno-strict-aliasing -DDATA_DIR="/usr/share/games/eternal-lands/" -DLINUX -DELC -DCLUSTER_INSIDES -DCUSTOM_LOOK -DCUSTOM_UPDATE -DFUZZY_PATHS -DNEW_SOUND -DPNG_SCREENSHOT -DTEXT_ALIASES -DUSE_INLINE -DBANDWIDTH_SAVINGS -DANIMATION_SCALING -DFSAA -DNEW_NEW_CHAR_WINDOW -DNEW_TEXTURES -DFASTER_MAP_LOAD -DFASTER_STARTUP -DMIDDLE_MOUSE_PASTE -DNEW_EYES -D_7ZIP_ST -MT '2d_objects.o' -MD -MP -MF '.deps/2d_objects.o.pp' -c 2d_objects.c -o 2d_objects.o

<command-line>:0:7: warning: missing whitespace after the macro name [enabled by default]

(... many repeats of this warning ...)

<command-line>:0:9: error: expected ‘;’, ‘,’ or ‘)’ before ‘-’ token

 

Gotta say - has to be the first time I've seen that one on a command-line.

[sgik]

It might have something to do with the fact that you are trying to define macro names containing hyphens (-Dconfig-protect-if-modified, etc.). I think that this stuff is being mistakenly included on the command line because Makefile.linux uses a FEATURES variable, and somehow it's being confused with portage's FEATURES shell variable. (The hyphenated stuff looks like portage features.) I recommend that you add

FEATURES=''

to the make command line.

 

(edit, again)

 

Strike that.

If you look at the 1.9.3 ebuild, it contains code to replace FEATURES with EL_FEATURES in Makefile.linux and make.defaults:

sed -i -e 's:FEATURES:EL_FEATURES:' make.defaults
sed -i -e 's:FEATURES:EL_FEATURES:' Makefile.linux

Edited May 21, 2015 by sgik

[bluap]

Are those data files legally hosted?

roman_gruber pointed me here indirectly, I missed this thread for some reason previously.

 

For the record, the data file linked above is hosted on my server. I obtained permission from Radu (the game owner) to package and distribute the client and data several years ago. That file is used by my Debian/Ubuntu packages.