Re: Visualboy Advance question.
On Mon, Jun 21, 2004 at 11:53:31PM +0200, Francesco Poli wrote:
> On Mon, 21 Jun 2004 09:50:35 +1000 Matthew Palmer wrote:
>
> > On Sun, Jun 20, 2004 at 06:36:42PM +0200, Francesco Poli wrote:
> > > I think that DFSG-free emulators should be in main as long as they
> > > don't*depend* on non-free packages.
> > > Usefulness is, IMHO, a completely different matter.
> >
> > Because, of course, more useless software in main is exactly what we
> > want. I don't think that's an argument you want to be pushing too
> > hard. <grin>
>
> Well, I thought that useless software is maybe not worth to distribute
> at all. You seem to imply that a free, but useless package must be
> placed in contrib rather than in main...
I implied nothing of the sort.
> > 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? What if there were
> > images in that format, but in order to get them you'd have to break
> > copyright law?
>
> Cannot someone create some free image in that format in the near future?
> Why should Debian wait for one such image to *be packaged* before moving
> the viewer from contrib to main?
Please quote back to me the part where I said that such content needed to be
packaged in order for us to consider it. *Nowhere* did I make that claim.
I'm only talking about whether such content exists *at* *all*. For most of
these emulators, the only source of 'data' for them is ripping lock-in games
from their cartridges. Whilst that isn't necessarily breaking the law, it
is DFSG-non-free, and if the emulator is significantly impaired without one
of them, I believe it falls under SC#1.
> A real example: prboom is in contrib (at least in Woody). It's free
> (under the GNU GPL license). It doesn't depend on non-free packages. It
> can be installed without pulling in non-free packages and can execute
> the FreeDoom IWADs that are free[1] (under a 3-clause BSD license), but
> not packaged for Debian. But that doesn't stop me from downloading the
> IWADs into my home directory and typing:
>
> $ prboom -iwad ~/doom/freedoom-0.2/doom2.wad
>
> That still seems to me very similar to
>
> $ eeyes ~/images/myart/drawmadewithgimp.png
>
>
> Neither FreeDoom, nor the hypothetical (but possible)
> drawmadewithgimp.png are packaged for Debian.
> Both are free (let's say the image I could create would be released
> under the... mmmh... X11 license).
>
>
> Why Electric Eyes is in main, while PrBoom is in contrib?
Buggered if I know. What was your point? That the maintainer of prboom
isn't me? Holy cow, you're right!
> > 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. There's likely to be thousands of the
> > damn things out there already, for you to use. Therefore, we can make
> > a reasoned guess that users will be able to use this software freely.
> > No such reasoned guess can be made for console emulators for which no
> > free ROM images exist.
>
> Wait, Mutella is in main: someone could argue that we cannot make a
> reasoned guess that users will be able to use a P2P network client
> without breaking the law.
> I know that P2P is not illegal per se. And I know that legal uses of P2P
> networks are *possible*. But someone could argue that the *principal*
> use would be in violation of copyright laws...
> So what should we do? Move it to contrib?
No. I'm not arguing from a "legal use" standpoint (I'll leave that to the
RIAA, TYVM). I'm arguing from a "useful only with Free stuff" angle. P2P
clients are useful without non-free software -- they are (in general) bit
pattern agnostic. So as long as you've got a free bit pattern (and we've
got lots of those), Mutella is main-suitable.
If an emulator has no suitable free bit-pattern, then it is not suitable for
main, because there is no way to use a significant portion of it's
functionality. SC#1.
> > So, if a program is free itself, but cannot be used in a free manner,
> > where does it go? Contrib. Where are the console emulators in
> > question? Contrib. Hmm...
> >
> > Or, to take it another way entirely: Policy has the following to say
> > (in part) about the use of dependencies:
> >
> > 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. But I would *certainly* say
> > that doing anything other than sitting around asking for a ROM image
> > would count as "a significant amount of functionality".
> >
> > 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.
>
> I could begin to write free software for the emulated hardware.
> It would be perhaps much more difficult than writing a Python script,
> but that's a difference in quantity, not in quality.
And when you have, let the maintainer know and it might be moved, if he
feels so inclined.
> > Console emulators are in contrib for good reason -- because they have
> > no use that we can see without a dependence on non-free material.
> > SC#1 says "We
> > will never make the system require the use of a non-free component".
> > 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.
>
> I've always interpreted the "require" as "depend on", in the sense of
> the "Depends" field.
> And I've always saw the dependences as not related to usefulness (a
> program cannot depend on its input data).
>
> Of course, I may be wrong...
I think you are. To re-quote policy, "The Depends field should be used if
the depended-on package is required for the depending package to provide a
significant amount of functionality." Usefulness is a function of
functionality. No functionality, no utility (usefulness). For an emulator,
no ROM, no functionality, no utility. If there's no free ROM, then we go
through the chain again, ending at "not in main".
- Matt
Reply to: