On Jun 20, 2004, at 19:50, Matthew Palmer wrote:
Let me ask you this: if there was an image viewer, which only viewed
one
format of images, and there were no images out there in that format,
would you
want to see that in Debian?
Well, it's hard to see there being an image viewer which views no
images whatsoever: How, for example, did its authors test it? Why did
they bother to write it?
What if there were images in that format, but
in order to get them you'd have to break copyright law?
We don't seem to exclude software that some people can't use (legally).
Certainly, some people could legally obtain those copyrighted images.
From a legal standpoint (which is what this list should take, I think),
if there are non-infringing uses --- enough that we would be able to
claim protection under the Betamax(?) case --- we shouldn't object.
That second case is pretty much where we stand with a *lot* of game
console
emulators out there -- the only way to get data to use with them is to
break
the law. Wonderful.
Is it illegal if I own a game cartridge, and dump it? That part
probably isn't; US copyright law, at least, give me permission to make
a backup copy.
US caselaw also lets me do things like copy my CDs to tapes to play in
my car. I've even seen stereo systems with features especially made for
this.
I don't see why I couldn't legally copy my cartridges to my computer to
play them. Is there any relevant caselaw?
This is very, very different to the case with your average image
viewer or
script interpreter -- you can create some images yourself, or write a
script
to be run.
I can write a console game myself, too. Sure, a console game (at least
one anyone would want to play) takes more effort, but I don't see why
its an unreasonable use.
There's likely to be thousands of the damn things out there
already, for you to use.
I assume this is an 'or', not and 'and', so it'd be ok if you can use
it to create your own, or to use other people's material you can
legally obtain. Otherwise, a free compiler for a new language would be
excluded.
Therefore, we can make a reasoned guess that users
will be able to use this software freely.
If you mean freely as in DFSG-free software with DFSG-content, then
should we get rid of mpg321? What about mmix? (I think that's the name
of the emulator for Knuth's made-up machine.)
The Depends field should be used if the depended-on package is
required for
the depending package to provide a significant amount of functionality.
The litmus test here is "a significant amount of functionality", not
"will
refuse to work at all without it", although that's a fairly good
description
of a console without a ROM.
It is also a fairly good description of a Java compiler without a
source file. Since this is a description of the Depends: field, I think
your reading of it must be wrong.
Neither interpreters, emulators, nor compilers should depend upon the
data they interpret, emulate, or compile.
Your attempted analogy to a python interpreter is flawed, too. I can
type
things in at the >>> prompt and get python to do something. Can I
reasonably be expected to type things in to a console emulator's dead
prompt
and expect to be able to use the emulator for the purpose for which it
was
intended? I would imagine not.
javac just gives an error message if you don't give an input file. I
think gcc might, too.
While you can't give an input at the error message output (just like
javac) you can certainly write a ROM image to run, just like you can
write a source file for javac.
And, indeed, the emulator will be an invaluable resource in getting
your free ROM image to work.
If you can't practically use a console emulator without resorting to a
non-free image, then we're violating the social contract if it's in
main.
OK, you *are* making that argument. Why, then, should mpg321 stay in
main? Honestly, how many people play DFSG-free mp3s? I think I've
personally played maybe 1 (because it was in the public domain...)