On Tue, Feb 25, 2014 at 01:42:30AM +0100, Markus Koschany wrote: > > multilayer raster images. These are included in the upstream VCS but > > not in the tarball. > > I think one argument against having everything in the release tarball is > size. Complex games with a lot of art assets tend to ship a lot of art > assets that can occupy precious storage space and bandwidth. Personally > I wouldn't mind to mirror this data or upload a second tarball with > additional source files. However I think we should find a balance > between providing every source file that upstream provides and not > overworking Debian's infrastructure. I find it reasonable to mention the > additional sources in README.source and link to the upstream VCS because > everything is just a click away and in reach for the user. 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. Source packages are not used by many users (so the bandwidth isn't as much of a problem), but those who download them do expect full sources, not a list of links to where they were originally found and hopefully still are. In other words: no, we don't want a balance here. We want to give our users access to every source file (for what we distribute) that we can get our hands on. > I think as long as the resulting image is freely licensed and in a > modifiable form and the rest of Naev is also free software, we should > find a compromise to allow users to enjoy the game, to work with the > sources and to give them a chance to resolve the remaining issues. Non-free is the name of that compromise. As long as we haven't solved the issues, the game is not free and doesn't belong in main. You're suggesting that you're doing people who chose not to install non-free software a favor by letting them play this game anyway. But in fact you aren't: if they would like that, they would have non-free in their sources.list. Keeping *all* non-free software out of main is actually a great feature of Debian. I think you don't appreciate that feature, which is fine. But others do, and it's Debian's mission to provide it. No other major distribution allows users to only see free software in their package list. Those who don't care about this put contrib and non-free in their sources.list, or use a different distribution. For those who do care, it is our duty to give them what they ask for: only really free software. Not "almost entirely free". > I think that's what DFSG 4 reminds us to do. Trying to solve this > issue alone will probably take far too long. DFSG 4 says that we may accept software as free even if we need to go through some trouble to use that freedom. It doesn't say we should treat software as free even if it isn't. > [...] > > The source for beneath-a-steel-sky and similar point-and-click > > adventures were "lost" a long time ago and are not meaningfully > > modifiable so various glitches cannot be fixed. > > I suppose most users are quite happy to play the game just as it appears > with all its glitches and shortcomings Users like Linus: yes. Users like RMS: probably not. Linus will have non-free in his sources.list, so he can still play it if it is not in main. Think of it this way: how is your argument different if there would be an active upstream, who has the original source code, and uses it to make modifications? The users you talk about would probably still be happy to play the games "as they appear". But there is no doubt that in that case they wouldn't belong in main. > which wouldn't be possible without ScummVM. Not sure why you mention this; you seem to be defending that ScummVM is free software. AFAIK there is no disagreement about that. > I think the benefits outweigh the disadvantages by far > and nobody prevents anybody from writing an editor. I don't like it > either but there is simply nothing better that can be called source. > BASS's README.Debian explains this a lot better. I've read it, but I don't really agree with it. Regardless, the GR I cited earlier clearly says that a case like this is acceptable for main, so I'm not trying to get it removed. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature