Hello, On Wed, Mar 12, 2014 at 12:57:24AM +0100, Markus Koschany wrote: > >> - What do you consider a practical solution? > >> - What is source for artwork in your opinion? > [...] > >> - What guidelines would you suggest? > > First of all I believe we agree that we need to differentiate between > different forms of artwork. > In my opinion raster images are modifiable and thus source. Always? Any raster image is always source? I disagree with that, just like I don't think that every text file is source (optimized javascript is a counterexample). Yes, raster images are modifiable, and thus can be source. > I agree that player models should be accompanied with e.g. blend or > md2 files So what about renderings? Would you consider a raster image which is rendered using Blender to be source? > 1. Assume good faith I very very much disagree with this one. Maintainers are the gatekeepers of Debian. Our users depend on our judgement. If we say "I didn't check anything, because upstream said it was good", we are hurting our users. 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. > We are dealing here with open source / free software / libre projects. > They aren't always perfect but projects like Red Eclipse, which release > assets under libre licenses and sustain a community acting in the same > spirit, deserve a credit of trust. If the following suggestions don't > help with finding an answer for "what is source", then please take a > look at this point again. 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? (This is also not hypothetical; I've seen exactly that happen.) > 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. > 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. I disagree with that; 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. ;-) ). > Non-exhaustive list of files that may be acceptable: > > Raster images (png,jpg,gif,bmp), > Music files (wav, ogg, xm) > Models (blend, md2, md3, obj) > > 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"? > 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. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature