On Sat, 3 Apr 2010 21:28:35 +0200 Rudolf Polzer wrote: [...] > 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.
That's unfortunate, but it should *not* be a reason to lower Free
Software standards, IMHO.
Please also note that this problem is not really artist-specific: many
programmers are not willing to share the programs they write, as well.
Maybe the lack of Free-Software-friendly artists is more serious
than the lack of Free-Software-friendly programmers, but this is a
quantitative difference, not a qualitative one.
> 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).
CC-by-v3.0 and CC-by-sa-v3.0 are accepted by FTP Masters (even though I
personally disagree with them, since I think these two licenses fail to
meet the DFSG, but that's another story).
However, it is my opinion that works with unavailable source do not
comply with DFSG#2, regardless of the license.
Using non-free parts is obviously not an option, if the goal is
creating a DFSG-free work...
>
> However, this would require packaging CC-BY(-SA) content together with GPL
> code, which again seems like it may not be legally possible.
The problem is not packaging the two things together.
The problems that I see are the following ones:
(a) linking (or mixing) the two things with each other, since CC
licenses are GPL-incompatible
(b) distributing things without making source available, since that
fails DFSG#2
(c) distributing works under non-free licenses
Point (a) is usually not an issue, when a game is organized as a "game
engine" that loads and uses "game data". The two parts ("engine" and
"data") may be licensed in an incompatible way, since they are not
mixed or linked together.
Of course, this should be tested in court, in order to be sure there
are no legal troubles due to the incompatibility between the two
licenses.
Hence, it is far safer when the two licenses are compatible with each
other (even simpler, they could be the same license!).
Point (b) is to be taken into account: source has to be made available,
in order for a work to be Free, regardless of the adopted license.
Point (c) is an important issue: as I said, I don't think CC licenses
meet the DFSG, but the FTP Masters disagree with me and seem to accept
CC-by-v3.0 and CC-by-sa-v3.0.
> 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"?
I don't think it does, but I am not a lawyer and I am not aware of
court cases where this is clearly decided.
> Can a single download - e.g. a zip file containing the
> whole game - even HAVE different licenses on different parts of it?
I think it can, and it is normal: even the GPL explicitly allows "mere
aggregation" without any restriction on the other merely aggregated
works.
[...]
> > As always, the preferred form for making modifications to it.
[...]
> 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.
When there is a number of forms, each one preferred for different
kinds of modifications, I think the source is the form from which you
can re-obtain the other potentially preferred forms.
[...]
> > > 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.
I don't think the sound of a note produced by an acoustic (or even
electric) instrument is subject to copyright.
I mean: the sound of the third string of a guitar, played with a finger
on the second fret, is not copyrighted (to the lawyers listening: is
that correct?).
[...]
> Why should the following situations differ at all, legally:
[...]
This is tricky.
I am under the impression that the line is to be drawn where we switch
from the "natural" sound of a musical instrument to the use of samples
(as long as those samples are creative enough to be copyrighted and they
are not DFSG-free).
But I am not sure.
[...]
> > 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 is exactly the same problem you may have with programs.
How can you be sure that the author is not distributing obfuscated
code, rather than the actual source (for instance he/she could strip
most comments from the source code)?
See for instance this long thread about NVidia's nv driver:
http://lists.debian.org/debian-legal/2005/02/msg00309.html
I think the reasonable course of action is trusting the author, unless
something smells wrong, and until new facts are discovered.
>
> 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:
[interesting example...]
> Wouldn't that word processing app qualify for
> "contrib" in Debian?
Maybe, I don't know...
[...]
> > > 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?
Not necessarily: maybe the WAV files are so huge that one would prefer
modifying the Ogg Vorbis form, which is more practical to handle and
carry around...
Sometimes the size of the uncompressed form may influence the choice of
the preferred form for making modifications.
[...]
I hope this helps.
--
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
pgpMqVPvvbZk8.pgp
Description: PGP signature
