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

Re: megaglest package

On Mon, 2011-12-19 at 11:33 +0000, titus tscharntke wrote:

> I still don't understood how to handle the copyright the right way.

My comments about copyrights/licenses were unrelated to the upstream
stuff, but about the Debian documentation of the MegaGlest copyrights
and licenses. Debian documents the copyright holders for every package
and the licenses that those copyright holders have granted to Debian and
Debian users.

As far as upstream stuff goes, all the licenses you use thus far are
compatible so that is fine. Some license combinations that are not
compatible are:

GPL-2-only + GPL-3+

I did not see any GPL-2-only code in MegaGlest.

GPL-any + OpenSSL

In Debian we build MegaGlest against the non-OpenSSL version of curl to
avoid this issue, not sure if you are doing that also.

More info here:


Unless one writes all the code in a project themselves or gets explicit
re-licensing permission from every contributor, there is no way that all
the code used by a project will be under the same license.

In the case of MegaGlest a number of files are taken from external
projects and so have different licenses.

The MegaGlest binary is a effectively a derivative work of all of the
code compiled into the binary and also (if you ask the FSF) all of the
libraries dynamically linked to the binary. Therefore to distribute
MegaGlest, Debian simply has to comply with all of these licenses rather
than just GPL-3. Our default practices keep us in compliance with them
all so that part is easy.

> So what can we do? ( Or did i got the whole problem wrong here ? )

There is no problem on the MegaGlest side, just on the Debian side, we
need to properly document your copyrights and licenses.

> font/flag: we don't distribute debian only ;-) and not even linux only

Not sure what you mean here.

In any case I'm not complaining about your binary packages
(installers/etc) for platforms without proper robust repository and
dependency systems (like Windows/MacOS/etc), what you do on those
platforms is none of Debian's business. On those platforms you basically
have no choice but to have copies of external libraries/fonts/flags/etc.
On Linux distributions like Debian, Fedora, Gentoo etc we have proper
robust repository and dependency systems so those copies just introduce
headaches for us. As a result, for distribution-friendly projects the
source package and especially the version control system (SVN) should
not contain any externally-maintained code, fonts, flags etc. More tips
about how to be distribution friendly are available, please take a look
at these pages and the links on the first page:


> source: I think this was needed becasue we(more softcoder) modified it
> and or the version handling was very bad and things like this.
> We did not copy things for fun ;-D .

Generally its a good idea to contribute your improvements back to the
projects that need fixing rather than hoarding those fixes in embedded
code copies. There is a cost to going it alone:


> Its really ok to provide the blender files for the models but
> automated generation from blend files will for sure never come as it
> is nearly impossible! Blend files are not this kind of source as
> sourcecode is!
> some reasons:
> - As far as I know .blend format is no real standard and can change !
> - .blend is not a format to hold models! Its a format which holds
> everything blender can do.
> - not all our models are available in .blend format, because we either
> don't have them, or they were made with other tools! (3dsMAX ad I
> heard of a google tool too!)
> - the blend files don't contain every bit of information needed. For
> example I just scaled or rotated a tree to get a different look inside
> the game without saving before exporting ...
> - animations don't have begin/end frames stored in our blend files.
> You have to look in blender where it starts and stops.

Thanks for the information here, very interesting. I am not generally
aware of the challenges of game development wrt 3D stuff. I think it is
a bit sad to give up on being able to have a sane build data process.
Just imagine if compiling C code with GCC were this problematic,
maintaining Linux and other projects would be a complete nightmare.

For an example of a non-code project with a completely automated build
process, check out The Adventures of Boris Munchausen animation project,
their build process involves Blender also:


> Just one word on streflops:

Yes I understand why you use streflop. For now Debian is leaving the
embedded code copy in place, but we would prefer to only have to do
bugfixes and updates to it once, instead of once per package that uses
it. Version 0.3 has bug fixes. If some more bugs are found and version
0.4 is released, currently Debian will have to update both Spring and
MegaGlest instead of just streflop, it is a waste of our developer and
CPU time to do things twice instead of once. The embedding of streflop
is blocking Spring from entering Fedora, I guess this will apply to MG:




Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: