Re: Distribution of media content together with GPLv2 code in one package?
(as I was not subscribed, I manually wrote the In-Reply-To header - I hope the
thread is properly connected. I am subscribed now.)
Francesco Poli wrote::
> On Sat, 3 Apr 2010 14:28:43 +0200 Rudolf Polzer wrote:
> > 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...
The whole reason why this seems to be so problematic, is that there are not
many artists who want to share all the data they make. Thus, to be ABLE to get
good quality art, the only way seems to be to use non-free art, or
CC-BY/CC-BY-SA licensed artwork (CC-BY-SA v3.0, and thus CC-BY v3.0, is
accepted as DFSG compliant, and has no source requirement).
However, this would require packaging CC-BY(-SA) content together with GPL
code, which again seems like it may not be legally possible. The code does not
"link" to the content using a dynamic linker - but can e.g. just loading a
texture file for displaying it, with the code referencing it by the file name,
constitute "linking"? Can a single download - e.g. a zip file containing the
whole game - even HAVE different licenses on different parts of it?
In Debian packaging, this sort of can be circumvented by splitting into two
packages, one with the GPL content and one with the CC-BY(-SA) content. But
even then, the question would remain for non-Debian-using end users, who of
course should only be presented one single download and not two separate ones.
> 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.
Sure - a lack of consensus in our own game team is the very reason why I am
asking.
> > 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...
Depending on the edit, you would either use the one form or the other. If you
e.g. want to change how the fade-out at the end is done, you'd do that from
Audacity. If you want to change a note, you need the Rosegarden project.
For yet another kind of edits, you don't need either of the two projects, but
simply work on the finished (uncompressed) wav file. For that reason, many
artists don't even save the Audacity project, as it doesn't provide much more
information than the finished wav file if all that is being done is
single-track audio editing.
Which is then "the source form"? The finished file (as you can do, e.g.,
perform equalizer and reverb effects on it)? The Rosegarden file, which then -
when it is to be used - requires quite a lot of manual steps in audacity
repeated to get the same result? The aggregate of both of them?
> 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.
But so does the sound of the physical piano become part of the work. Yet still,
that thing is then typically seen as the "compiler", and thus exempt from the
source code requirement.
Why should the following situations differ at all, legally:
a) actual physical piano (possibly encumbered by patents)
b) "electronic piano" (used as black box, internally performing FM synthesis
using non-user-modifiable parameter sets)
c) "electronic piano" (used as black box, internally performing wavetable
synthesis using non-user-modifiable commercial sample banks)
d) electronic synthesizer (used as black box, using the (non-free) samples that
came with it)
e) electronic synthesizer (with non-free samples uploaded by the user as part of
a firmware upgrade)
f) electronic synthesizer (with non-free samples willingly uploaded by the user)
g) software synthesizer application using non-free samples that came with it
h) software synthesizer application using non-free samples that the user obtained
However, we sure can agree that using the actual physical piano is DFSG
compliant.
Where to draw the line in the other cases, is not clear to me.
For example:
a) and b) only differ in the form of the device, but not much in the way the
tone is generated, as FM synthesis models how an instrument works.
b) and c) do not differ from the view of the user - the user presses a key and
it plays a note. How the tone is generated, is unknown to the user
and often not even easy to find out.
c) and d) are essentially the same thing, apart from the name of the device and
the number of instruments it can simulate
d) and e) might differ legally, as the user actually obtained the samples -
without knowing so
e) and f) might cross the line, as the user explicitly installed the non-free
sample pack
d) and g) are essentially the same thing, the only difference is on which chip
the processing takes place
g) and h) see "e) and f)"
However, when arguing that way, shouldn't the use of a commercial application
together with the samples that came with it be fine, DFSG-wise?
In case of f) - what if the samples were added to the synthesizer by plugging a
black-box "sample module" into the synthesizer? Shouldn't two physical devices,
plugged together, still have the same legal effect as one single device?
> > 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...).
Yes, but typically these devices have no influence over the "compilation
process" and the outcome. The CPU may change the speed of compilation, but not
the binary.
However, which kind of piano was used, can be crucial to the quality of the
result. Also, see above, what if it is an "electronic piano", which actually is
a synthesizer with only one sample bank?
> 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.
One problem here:
One cannot, from the outside, know which form the author actually uses for
editing. How can the project then know whether it actually is fulfilling the
conditions of the GPL?
This question also applies to code. What if someone designed a programming
language in the style of HQ9+ http://en.wikipedia.org/wiki/HQ9%2B with extra
commands:
W - Performs the necessary actions to qualify as a word processor application
X - Performs the necessary actions to qualify as a spreadsheet application
P - Performs the necessary actions to qualify as a presentation application
The compiler for it be non-free.
Now, if I compile the source code file just containing a "W" using this
"compiler", I get a full-fledged word processor. What exactly makes it NOT
possible for me to then claim "the file that just contains a single W is the
source code of this application"? Wouldn't that word processing app qualify for
"contrib" in Debian? Its source code is provided, it should otherwise be DFSG
compliant, and the compiler for it is non-free, thus contrib.
What makes it worse: nothing in the GPL or the DFSG requires that the compiler
is actually publicly available. Wouldn't this be a convenient way to hide the
"actual" source code, and still license under the GPL?
Of course - anyone would clearly see that this would be just an evasion
technique and I bet this won't stand in court. But it may shed light to the
general issue of "what EXACTLY is source code".
> > 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?
The file is a (lossily) compressed OggVorbis file. Even if no music notation
(or tracker) file was ever made for this one, wouldn't one prefer at least the
uncompressed WAV file for e.g. adding effects to the track?
> > 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?
Yes. The included COPYING file contains just the GPL, and no hints of other
licenses being used for other content can be found in the source distribution.
> Is this "referencing" something that would be considered like the
> linking of a program with a library?
Maybe. It is a Lua script containing the file name. Image files are created
from the font for use by the game.
> And so forth...
> I think you should discuss this issue separately, in a different thread
> or in an appropriate bug report.
Well, this case may be not a violation for the .deb package, as copyright on
fonts commonly does NOT extend to rendered/printed text, and from this I assume
that Enigma only uses the pre-rendered image file. Thus, if anything, only the
source package would be in violation
> > 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...
As PNG is lossless, this may actually be the case.
> Other debian-legal regulars will probably answer with their, possibly
> different, opinions.
I am looking forward to that, as I know opinions will vary on all of this.
Best regards,
Rudolf
Reply to: