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: http://en.wikipedia.org/wiki/License_compatibility http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses 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: http://wiki.debian.org/UpstreamGuide http://www.freedesktop.org/wiki/Games/Upstream http://spot.livejournal.com/308370.html > 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: http://blogs.gnome.org/bolsh/2011/09/01/the-cost-of-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: http://munchausenproject.wordpress.com/ https://github.com/morevnaproject/munchausen/blob/master/README > 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: https://fedorahosted.org/fpc/ticket/105 -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part