On 12.03.2014 06:14, Bas Wijnen wrote: [...] >> In my opinion raster images are modifiable and thus source. > > Always? Any raster image is always source? [...] > So what about renderings? Would you consider a raster image which is > rendered using Blender to be source? The whole discussion about source for artwork certainly shows that there is no absolute definition of source which holds true under any circumstances. So no, raster images are not always source. An absolute and clear definition of source for artwork would be: Every raster image (png,jpg,gif,bmp,etc) must be accompanied by a higher source form such as Gimp xcf files, a vector image, blend files etc. This would be an unambiguous definition, absolute, but also obviously not a good general law because it ignores derivative works that only used a "lesser source form" of the original artwork and the possibility that the artists didn't have access to some sort of higher form. As the creator of artwork for gfpoken you should be aware of the issue and that artists decide what is source for their artwork. In your case the sources are png files. If you agree that gfpoken is a free game, then you also have to grant all other artists and projects the same view on their artwork. >> 1. Assume good faith [...] > As a user, I want to trust the maintainer, as I said before. That means > that as a maintainer, I must not blindly trust upstream. There are > people who want to hurt Debian, and some of them probably try to sneak > stuff into the archive that we don't want. It is the maintainer's job > to check upstream and detect such bad faith. I'm under the impression that all creators of free software games develop them mostly for fun. Nobody I'm aware of starts with creating a game to "hurt Debian". On the contrary I believe those artists and developers enrich the whole FOSS community by distributing their content under libre licenses. However "Assume good faith" doesn't mean you should blindly accept everything. See also point 2 and 5. [...] > Let me rephrase this to make sure I understand. You're saying that if > upstream has a different definition of "free software" than Debian, we > should ignore our own definition and instead use theirs, because if we > don't they'll be disappointed in us? This sounds very negative, and I > realize you don't mean it that way, but is this the general idea? Assume good faith is neither a general justification to include everything nor is it an invitation to abolish Debian's definition of free software. It it intended to be as a _positive_ mission statement. We believe in the advantages of freely licensed artwork. We believe it's good to promote free software games and communities. We believe in the good will of contributors. The first rule simply embodies a positive attitude which is sometimes quickly overlooked in this discussion. Rule 1 is a "fallback rule". It is especially aimed at ill-advised bug reporters who report serious bugs against alleged artwork "without source" when there is no indication that this is true. >> 2. Talk with upstream >> >> The best approach to find out about upstream's intentions is to talk to >> them. > > I agree. But I disagree that their intentions should override our own > rules. [...] > for example with raster images, I agree they > can be source (as those pngs in gfpoken), but sometimes they aren't > source (as those pngs in gfpoken. ;-) ). If you tell me, as the original artwork creator, that your pngs are source then they are the source. Otherwise you lied to me. See point 5 for what happens then. >> 3. Definition of source for different kinds of digital art >> >> We add an appendix and define for the most common art assets what would >> be a reasonable form for modifications. Since it seems we can agree on >> raster images as a reasonable form for modifications, I believe we can >> find consensus for other assets too. That should cover most games in the >> archive already. > > I think this is a good idea. But you seem to think that this is a > simple list of file formats, and if a file is using that format, it is > ok. [...] >> 3D Models and everything that gets rendered is a different story. >> However I would argue that a rendered image can be the source as well. >> It very much depends on the game itself. > Can you give an example when it would be source? According to your > guidelines above, "if upstream says they are"? I think point 3 should be a complete list with concrete examples of games that are already in main and why they are in main and how different file formats relate to them. A good example for small games with raster images: The Gfpoken developer and artist confirms all images in the source tarball are source. There is no sign in the VCS or elsewhere that this is not true. Modifications are possible with common applications such as Gimp or mtPaint. The game is freely licensed and it complies with the DFSG -> it must be in main. The whole point is meant as a guide for packagers for enabling them to compare how digital artwork is handled in existing packages in main and to come to a conclusion for their own package. Rendered images can also be source when the resulting image is the basis for subsequent creation steps for digital artwork. Imagine a rendered image for a cube that is preprocessed in Gimp for re-colorization, not only once but hundreds of times. Instead of rendering each cube over and over again with different colors, you feed the resulting image to Gimp which is obviously time saving. >> 4. Talk about your game: special cases should be discussed on >> debian-devel-games >> >> We should find solutions on a case-by-case basis for complex games >> and/or rare games with special requirements. > > Yes, we are in full agreement about this. > >> 5. When game data should be in non-free >> >> A good reason for moving a game to non-free is when the creators of the >> game's artwork refuse to share a higher form and do so deliberately, say >> they sell the game with vector images but provide only jpg files both in >> the source tarball and in the VCS. > > I agree with this as well. Fine. It would be great if we could at least agree on points 1,2,4 and 5 to begin with. I'm happy to discuss point 3 in more detail. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature