On Tue, Feb 25, 2014 at 02:33:44PM +0100, Markus Koschany wrote: > > Debian doesn't trust upstream sites to stay around. Therefore we copy > > their tarballs to our own mirrors. The argument that it saves so much > > space would work just as well for any non-art orig tarball, but that's > > not how we do it. > > I was speaking about really large source tarballs, several hundreds of > megabyte and not the casual mini game. See also the data.debian.org > discussion. I know, but I don't see the fundamental difference. data.debian.org is the technical solution to the philosophical standpoint that we do indeed want to provide all source, even for huge files. AFAIK there's no discussion about whether we want it; it's only about how we achieve it. > In case of Naev we seem to have a problem with one single png file. I > think this issue can be resolved by using common sense without putting > the stigma of non-freeness on the whole project. If we are not willing to remove that single file, then we cannot tell our users everything in the packages is free, and it should not go in main. But I agree with you that that is not the best solution: > I would drop the file and replace it with a transparent png or > placeholder png, if this is really the only reason why Naev can't be > packaged for main. That's much better, and doesn't sneak non-free stuff on users. It's also what we usually do with mostly free upstreams: distribute only the free parts. > I'm also not totally convinced that it is really necessary to ship, > e.g. flac files It's not really necessary to ship any other source code either; the binaries will work fine without it, and we can provide a list of links instead. Why is artwork different from code in this respect? Also, flac files are hardly an example of "huge data"... > I think images created with non-free tools can be licensed under a > free license such as CC-BY-SA. The resulting image is then free and > this file becomes the source. They certainly can be; the tool itself doesn't make it non-free. But unless upstream would also use the rendering as new source for making changes (or they would never make changes and just create a new file), it is not source. For example, I redid the artwork for gfpoken, because the original was generated with pov-ray (which is non-free). The art was licensed freely, and the source was available, but it couldn't be compiled with free software. IMO that meant it couldn't be in main. But like you, I want things in main. The way to achieve that is not to ignore the non-freeness, but to remove (and replace) the non-free parts. > If you are not willing to hold a frank and reasonable discussion, then > it is pointless to continue the conversation. It sounds like I offended you, which was certainly not my intention; I'm sorry for not being more clear. I'll try again. Regardless, ending the conversation may be a good idea; I think we understand each other, and I don't expect much change of opinion. I wasn't trying to say that you should care about this. Many people don't really care about main being entirely free, and that is not a problem, and not something we need to "fix". However, some people do care about it, and they are the reason that we have the split between main, contrib and non-free. From your posts, I am guessing that you have contrib and non-free in your sources.list. If a game is not in main, does that make a difference for you as a user? It still show up in your package list, you can still install and play it. My point here is that for those who don't think "everything must be free" (which is a perfectly valid opinion), there is no problem in placing a package in non-free. You seem to want to try to put everything in main, because otherwise people can't use it. But that is not the case; programs in non-free are equally usable for our users as programs in main. They are not used as much, of course. People who take the extreme standpoint of only installing free software will not install it if it isn't in main. They won't even see it. But that's their choice. We shouldn't try to force things onto them that they are trying to avoid. > You do not seem to differentiate between various issues, however I do. It's not that I don't differentiate; it's that I take SC #1 literally: I want no non-free files in main. Not even a single file in a huge package. Of course we sometimes put something like that in by accident, but when we know about it, we must always avoid it, IMO. > Yes, I mean SC 4 "Our priorities are our users and free software". It is not in the interest of our users to put non-free files in main. Not even a single one. For those who don't mind using them, we put them in non-free, so they can get them anyway. For "extremists"[1] like RMS we don't put them in main, so they don't have to see them. (And, because we want main to be feature-rich, we more often remove the non-free parts and put the rest in main, which is great, too.) [1] That sounds negative, but I don't mean it that way; I'm in that group myself. > In short: Think positive, promote the good ones, don't waste too much > time on the bad ones and encourage users to change those "bad" upstreams > by becoming a developer or art creator themselves. I fully agree! Thanks, Bas
Attachment:
signature.asc
Description: Digital signature