Hi, On Mon, Mar 10, 2014 at 03:41:52PM -0700, Vincent Cheng wrote: > On Mon, Mar 10, 2014 at 1:28 PM, <beuc@debian.org> wrote: > > Do we have a wiki page that summarizes the review of Red Eclipse? > > (if that's what we are being polled :]) No, there currently is no poll (unless people want one, but I don't think it's really useful at this point), but the discussion I'm trying to have is about guidelines for how to treat source for artwork in general. It's not about Red Eclipse. > In any case, I believe that we have to look at individual games to > analyze its DFSG freeness (or lack thereof), Fully agreed; every situation is different and must be individually analyzed by the maintainer (that's the entire team, but more specifically the person(s) working on the package and uploading it). > Making a blanket statement that covers all games currently maintained > within the Games team, as well as any future games that may become > packaged in Debian, and that everyone can fully agree with, is going > to be extremely difficult. I don't mean to make binding rules. However, I do want us to agree on the general idea. That's what I hope to get as a result of this discussion. > If there's any doubt on whether a game is or is not DFSG-free, or if > someone disagrees with the uploader's/ftpmasters' analysis, then we as > a team can still review the package after the fact like we're doing > now with redeclipse, When that happens, we want to say "this is how we feel about it, and in this situation I think that means this". We don't want to discuss how we feel every time. We should only need to discuss the specifics of the situation. So I want the "how do we feel about it"-discussion now. On Mon, Mar 10, 2014 at 11:33:16PM +0100, Markus Koschany wrote: > Not sure what you mean by "code without source" but a program without > source is of course not useful at all. You'll have to explain that to Microsoft's or Apple's customers; they seem to be happy with it. > My point was that there is by definition a clear distinction between a > program and digital art (artwork). By definition? Please let's hear the definitions then. I'll give mine: Art: a work that is intended to cause emotions. Program: a list of instructions that can be performed by a machine. These might not be perfect definitions, but they'll do for now. If I write a game, the entire thing, including all code, is art. The code is also a program, and I would argue that the images and audio are as well: they are instructions to show a picture or create a sound wave. The computer is capable (with help of some other programs) to perform these instructions. > The term "source" in regard to programs and digital art is not > unambiguous. Obviously, that's the whole point of this discussion. I think we all agree that we should require source, but if we say "for images and sound, any file is source", then that requirement is useless. So we have to decide what is and what is not source. As I wrote above, I'm fine with rough guidelines that still require each situation to be evaluated separately. But you can't evaluate if you don't know what the target is. > You should also take a look at CC-BY-SA 3.0 unported. You won't find any > mention of the words "program", "software" or "source". Which means that putting this license on a compiled work does not make it DFSG-free. > Another obvious hint that CC-BY-SA was designed as a license for > digital artwork and its demands but not for programmatic works. Since > the ftp-masters accepted CC-BY-SA 3.0 as a DFSG free license we should > also acknowledge that different things, have different needs but they > can still be DFSG compliant. If I write a program to create an image, then I slap a CC-BY-SA on the image and tell people what a nice image I generated with my proprietary program, do you think ftpmasters would let the image into main? I don't think so. Having a free license on a compiled file is not enough. There must be source (which, by the way, is no different from the GPL; I can do the exact some thing there, and Debian will not even be allowed to distribute the image, because we don't have the source, so we can't provide it to the people we would want to distribute it to, and the GPL requires us to do this). > I do also think like Simon [1] that there is value in being less strict > about the "preferred form of modification" I agree with this as well. > because I also see the real risk that packaging games and other > multimedia assets may become extremely difficult if the same rules as > for Red Eclipse apply to all games. But that is not my reason. I think we should be less strict, because we don't lose anything: a png or xcf file give you the exact same information in most cases. If upstream would be happy to edit the png for any change, we should accept it as well IMO. But with blender models, it's quite different IMO. While the rendering is editable to a degree, real changes can only be made with the model. Which means we should require it IMO. > In short we need a better definition of the term source for digital > artwork that works in practical terms and not only in theory. Do you have a suggestion? > >> and that "source code" is something intrinsic to software. > > > > It is? Then what are the gimp and blender scripts that I use to > > generate the gfpoken pngs? I call them source code. > > Yes, source code is a term I expect to read in every definition about > programs or software. I was talking about images though. Those scripts are the sources for them. > I also had a look at gfpoken. Obviously you provide the source code of > your shell scripts that generate some pngs from one blend and one xcf > file. But it seems you don't provide the sources of the other pic*.png > files under your png directory. These are icons, which to the best of my knowledge are edited as pixmaps. These pngs are their own source. > > What sort of problems are the reason it isn't in main? > > I guess you should take a look at Martin's comments in debian/copyright > of the redeclipse-data package and compare the data with other packages > in main. He just writes that he thinks a lot is missing. But what? Blender models? I fully agree that those are source. Audacity files or xcf files? I'm fine with accepting wav or png files instead, in most cases. > And now compare your game with Red Eclipse. Gfpoken, free or non-free, > what do you think? I think gfpoken is clearly free. Since I still don't know what files we're talking about for Red Eclipse, I don't know about it. > > But if you don't agree with me on this, then I'm not sure what I > > think of Red Eclipse. I thought we did agree, and trusted your > > judgement. > > Thanks for trusting my judgment but it's always better to form a > personal opinion. Not really; one reason I like Debian is that I don't have to waste my time on checking licenses, while still being able to get a system with only free software. That only works if I trust the maintainers. > >> I can replace images without touching a single line of source code. > > > > I can replace executables without touching code as well. How is that > > relevant? > > You need the source code of a program to change its programmatic > behaviour I don't. If an application consists of a script which calls other executables, I can replace those executables with other executables (just like RMS originally started the GNU system by replacing every UNIX program with a free replacement). If I have several options for those executables, I can replace them without touching any code. That does in no way mean that they are their own source. > but you don't need e.g. some kind of vector source of a raster image > to make the game look different. It is always possible to make > modifications to a raster image as well. I don't just want to "be able to make modifications"; I want to be able to make any modification that upstream could make. Of course I can use the gimp to give a rendering of a 3-D model a different color, but that's similar to the ability to use a hex editor to change some text in an executable; it is no substitute for having source. > Thanks for creating https://wiki.debian.org/Games/Source. I have updated > the page with some opinions which were voiced in the last threads. Thanks. > I would suggest that we add some more opinions and statements from old > threads there and start to streamline everything after that. Sounds good. We should not let it turn into an endless page though; the idea is that only "state" is recorded there, so it should hopefully remain relatively short. > I wasn't one bit angry back then but I uphold my criticism. I'm always > open for improving the status quo and I'm also willing to help but we > need more than words to achieve a practical solution. Agreed. I've been trying to ask you a few times, because you have said several times that source for artwork is not the same as source for code. Let me be more direct: - What do you consider a practical solution? - What is source for artwork in your opinion? It's clear that you disagree with the guidelines I posted on the wiki, so please state your position: - What guidelines would you suggest? Just saying "it's not the same" doesn't help me as a packager. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature