On Sun, 4 May 2008 16:01:28 +0200 Francesco Poli wrote: > On Sun, 04 May 2008 18:37:06 +0800 Wen-Yen Chuang wrote: [...] > we seem to actually have the > preferred form for making modifications (== source code). This has been confirmed in conversation with James 'Ender' Brown of the ScummVM team: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478898#25 > > However, we seem to lack a DFSG-free editor (included in Debian main) > for making modifications to the game data. > So it seems that the _letter_ of Debian Policy [2] is not violated, > since the package does not require anything outside of main for > *compilation* or *execution*. > It requires something outside of main for *modification*, which is a > different activity, though. > > [2] http://www.debian.org/doc/debian-policy/ch-archive.html#s-main > > On the other hand, I am not sure about the _spirit_ of Debian Policy. > I'm almost beginning to think that Policy should be amended in order to > include "modification" among the activities that must be feasible > without anything outside of main... After some thought, I've come to a different conclusion. As I say in the already cited http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478898#25 the lack of "good" editors is not a DFSG-freeness issue. It's impossible to mandate that modification tools are "easy" and "comfortable" enough, because that's subjective. _Some_ modification tools are always available: at worst, you could always use a text editor or a hexadecimal editor to modify the data. It could be overly difficult for many people, but, if upstream maintainers do not have any better tool, I think it's acceptable, even though sub-optimal... Hence, I withdraw my comment on the possible Policy amendment. My conclusions are: * if those logo images are indeed non-free, we need to remove the logos from the game data (no tricks with the interpreter, please!) * developing an editor for the game data format would be _really_ useful and appreciated (ScummVM developers are probably the most qualified people to do that, since their interpreter is at least capable of _reading_ those data) Once again, my disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgp7lTTIHSjzd.pgp
Description: PGP signature