On 22.02.2014 01:09, Bas Wijnen wrote: > On Sat, Feb 22, 2014 at 12:02:17AM +0100, Markus Koschany wrote: >> On 20.02.2014 17:12, Simon McVittie wrote: >> [...} >>> Free software that requires non-free software is exactly what contrib is >>> there for. I think the original statement on this is SC §1, "We will >>> never make the system require the use of a non-free component". >> >> Right, but residualvm doesn't require non-free software, neither for >> compilation nor for execution. > > Policy 2.2.2 doesn't use the technical term "execution", but the more > subjective "which require software outside of the distribution to either > build or function". I don't think this is a mistake. I was referring to § 2.2.1: "must not require or recommend a package outside of main for compilation or execution" I think we all agree so far that residualvm fulfills this requirement. However we seem to disagree with the first sentence of § 2.2.2. "The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require *software* outside of the distribution *to either build or function*." > An interpreter is useless without a script. If there are only non-free > scripts, and it doesn't look like that is going to change any time soon, > and the purpose does not seem to be that the user writes their own > scripts (for example, because there is no usable editor for the script > format), then that means the interpreter is useless without "software > outside of the distribution". If it is useless, that means it does not > function. Bas Wijnen also wrote: > If I look for example at beneath a steel sky, I see only generated files > and a complicated instruction for how to regenerate one of them (which > doesn't even seem to be the most important). Also, that instruction > includes "download these binary files from elsewhere". There is no > editor for the format. I cannot see how this fits in main, even if I > try really hard. For the sake of completeness I'm quoting this paragraph from another e-mail of yours. Beneath a Steel Sky and Lure of the Temptress were both developed by Revolution Softare Ltd. in 1993 respectively 1989 on the AMIGA platform and later for MS-DOS. That was long before the svg or png data formats were even invented. Thanks to the makers of ScummVM, who reimplemented the engines, it is now possible to play these games on various platforms. Basically they preserve classical games for future generations. Since ScummVM is licensed under the GPL, those adventure game engines are also free software now. What you are referring to are the data files. Although I would definitely appreciate vector images for every scene and high quality artwork from 2014, I still can't get my hands on it because it never existed and the formats that did exist are useless for us nowadays and are lost. It is better to think of ScummVM as a highly specialized interpreter for data files comparable to an image viewer who interprets GIF files. If you want to change the game you have to change the source code of the game engine in ScummVM. If you want to change the data files, you need to write an editor. The developer of the Lure engine confirmed to me this is possible but not trivial. Since the license of the game data allows modifications and is DFSG free, everyone has the right to modify the games. Hence both of them fit perfectly well into main. The same goes for ScummVM's sister project ResidualVM. You can install and run residualvm without any problems. The program functions and will display a graphical user interface. I know that you will insist that residualvm is not fully functional without data files but have a look at § 2.2.2 again where the policy talks about software not data. I agree this is a controversial topic otherwise I wouldn't have brought it up for discussion. But as I said before what concerns me the most is the fact, that we are inconsistent when it comes to the question of "main vs. contrib". If we can accept scottfree and quakespasm in main, residualvm should be tolerable, too. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature