On Sat, 3 Apr 2010 14:28:43 +0200 Rudolf Polzer wrote: > Hello, Hi! > > speaking for a new game that will aim to be included in Debian, I wonder how > certain media content can be legally distributed together with GPLv2 in one > package. In various ways, I would say: some of them are the Right Thing To Do™, some other ones should be avoided. There are probably also ways that lie somewhere in between these two extremes... Warning! This is a somewhat flammable topic, you will probably find very different opinions, depending on who you ask to. I will try to explain my own personal opinion on the subject, but there does not seem to be strong consensus on every point. > > The main problem is that applying the GPL to certain types of media seems quite > unclear, especially because of the question > > What exactly is source code? I am convinced that the GPL definition of source code is pretty robust and flexible. Granted, it requires human judgment and some wisdom, but you can always figure out what is source code, in any practical situation. Quoting the GNU GPL v2, section 3., the definition is: | The source code for a work means the preferred form of the work for | making modifications to it. The GNU GPL v3, section 1, includes an almost identical definition. In the two GPL license texts, you can find some clarifications for special cases, but the basic definition is just the one quoted above. Any work that can potentially be distributed by the Debian Project in a deb package consists of digital information, and is thus (technically) modifiable, in one way or another. When more than one form of the work exist or may be obtained, one of them will be the preferred form for making further modifications to the work itself. That form is the source code. In some special cases, a set of N equivalent forms will be equally preferred. Any of these equivalent forms may be considered source code, in such cases. Please note that a work may change source code form, when it gets modified by someone. Example: I can find a program written in Pascal and released under the GNU GPL v2 and decide that I want to first translate it into, say, C++ and then go on modifying it for my needs. The source code for the original work is Pascal code. The source code for my modified version is C++ code. > > E.g.: > > Textures usually are edited destructively, in applications like GIMP. Typically > further editing is done based on the last saved finished version. That means that, in such cases, the source is the "last saved finished version", since it is the preferred form for making further modifications to the work. > However, > sometimes they may even be based on screenshots from a (free) game and possibly > custom content for it, which afterwards is edited in various ways. Also, a > typical manual destructive editing steps is retouching. These seem to be other cases where the editing causes the source to change form. As always, source is what is preferred for further editing. If the author/modifier destroys the previous forms, then (s)he clearly prefers the form (s)he keeps, for making further modifications. > > Music is typically done using a large range of applications, also using > destructive editing steps. A typical pipeline might be: > 1. handwritten musical score on paper > 2. playing that on a MIDI keyboard into a notation application (e.g. Rosegarden) > 3. quantizing and edits in that notation application > 4. export to MIDI format from the notation application > 5. rendering to an audio file by MIDI synthesizer applications, or even > external hardware devices > 6. editing that audio file with a wave editing application (e.g. Audacity) > What is to be considered the source code here? As always, the preferred form for making modifications to it. Whoever has made the last modifications to the work, should ask himself/herself: if I have to make further modifications, where would I start from? The answer is basically the source code form. Would he/she start from the file saved by Rosegarden? That is the source, then. Would he/she use the file saved by Audacity? That is the source, then. And so forth... > Is it allowed to use a > commercially bought MIDI synthesizer application The question is not: commercially bought or not. The question is: DFSG-free or not. Using a non-free MIDI synthesizer application in order to create DFSG-free music, may be like using a non-free compiler to create DFSG-free programs or like using a non-free initial code generator, depending on the case. If you need the non-free MIDI application in order to translate source into the final form, and there's no suitable DFSG-free replacement for the non-free application, then your music may, at most, be packaged for the "contrib" section of the Debian archive. At least, this is how I read the Debian Policy (see sections 2.2.1 and 2.2.2 in version 3.8.4.0 of the Debian Policy Manual [1][2]). [1] http://www.debian.org/doc/debian-policy/ch-archive.html#s-main [2] http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib If you just need the non-free MIDI application in order to create the initial version of the music file and then any further modification/compilation may be made with DFSG-free tools (in Debian main), then your music may go in Debian main, as long as it is DFSG-free and complies with the other requirements for Debian main. > and samples, Using non-free samples may be problematic. They become part of the resulting work, as far as I can tell. Hence, the resulting work becomes non-free, I would say. > or a physical > device (like an electronically controlled piano) for the recording? I fail to see a problem in using physical devices. Everything in Debian main is created by using physical devices (monitors, mouses, keyboards, hard drives, CPUs, motherboards, and so forth...). > > Basically, in both cases the big problem is destructive editing steps. Just > changing a note of the music is simply not possible without repeating all the > editing steps after it. Which is something the author would not even remember, > and most likely do a different way next time. Changing a note is one possible type of modification. In some cases, it could be a difficult modification to make. There can be difficult modifications for programs, too. One that requires a complete redesign of the program, for instance. As always, you should ask yourself: what is the preferred form for making modifications to the work? If the author is keeping one form for making modifications, but only distributes another form, then the source is not being distributed. On the other hand, if the author or modifier himself/herself distributes what he/she uses for making further modifications, then I think the source is actually being made available and everything is fine. > > So, as the GPL raises a big uncertainty on what exactly constitutes source for > non-code assets, I don't think it does. > I wonder whether it would be wiser to instead choose a different > license for these assets. I don't think it would: I recommend adopting the GPL for any kind of work, whenever a copyleft is desired. When a copyleft is not wanted, I mostly recommend the Expat license. [...] > On the other hand, many games that have been accepted in Debian "main" contain > music and textures without accompanying source code for these assets. This may be true, in some cases. And my own personal opinion is that it should *not* have happened. > For > example, a similar case can be found in Frozen Bubble - the directory snd/ of > the source distributiion contains multiple opaque (source-less) audio files, > including introzik.ogg and frozen-mainzig-1p.ogg. Yet still, the game is > licensed under the GPLv2. What evidence do you have that those files are not the preferred form for making further modifications? They may or may not be source code, depending on which other forms exist and on which form is preferred for making further modifications. > > Furthermore, Enigma is released under "GPLv2 or later", and contains, in the > directory data/ of the source distribution, a file models-2d.lua that > references DejaVuSansCondensed.ttf, which actually is provided in the > data/fonts/ directory. The Deja Vu fonts come with a license restriction that > is not GPL compatible: > > The Font Software may be sold as part of a larger software package but no > copy of one or more of the Font Software typefaces may be sold by itself. This may or may not be a GPL violation, depending on various specific aspects. Is models-2d.lua itself licensed under the GPL? Is this "referencing" something that would be considered like the linking of a program with a library? And so forth... I think you should discuss this issue separately, in a different thread or in an appropriate bug report. > > Also, for none of the graphics any more than a PNG file is provided. Again, PNG may be the form of the source code or just be object code, depending on which is the preferred method for making further modifications to those images... [...] > Therefore, I am asking - how can a game contain GPL code, but still use "more > artist friendly" assets (especially because the source code requirement is NOT > clear, as often there IS, because of manual destructive editing steps, no such > thing as "complete corresponding machine-readable source code" source as the > GPL demands)? I think I answered to this question with the above explanations. I hope I clarified my own personal opinion on the matter. Other debian-legal regulars will probably answer with their, possibly different, opinions. Bye. -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpRzkO3DzEuR.pgp
Description: PGP signature