Re: Visualboy Advance question.
Glenn Maynard wrote: On Mon, Jul 12, 2004 at 01:46:08AM -0400, Nathanael Nerode wrote: Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. If so, please name them; they must be removed. http://www.debian.org/devel/wnpp/unable-to-package Software that can't be packaged 8hz-mp3, bladeenc, etc -- patent problems with Fraunhofer Institute. (yes, this includes LAME, see archived discussion) (link: http://lists.debian.org/debian-devel/2000/06/msg01213.html) All MP3 encoders are non-free. Oh, this is one of those bogus patents, isn't it. :-P Oops, silly me, didn't do my research. Sorry, I was wrong. I guess all programs which play *nothing* but MP3s should be in contrib. Every MP3 player I've seen so far in Debian plays something else as well. -- There are none so blind as those who will not see.
Re: Visualboy Advance question.
On Mon, Jul 12, 2004 at 07:10:46PM +1000, Matthew Palmer wrote: On Mon, Jul 12, 2004 at 02:05:16AM -0500, Branden Robinson wrote: OTOH, as you're sure to note, an easy way around this is that a package can be completely useless in main as long as what it depends on isn't a package. Maybe that *was* your point. Not exactly. I'm not a fan of useless software on the whole, so I don't believe that your work-around is a winner. Good, because I don't actually advocate that view. :) I prefer to fall back on the last sentence of the first clause of the social contract: We will never make the system require the use of a non-free component.. Providing a piece of software which can only use non-free content is requiring the use of a non-free component, IMO. That sounds like a reasonable litmus test to me. That would be a waste of archive resources. Er, before heading down this road, I think you should attempt an objective demonstration that we seem to give a damn about wasting archive resources in the first place. We don't give a damn? That's a pity. I am not asserting that we don't give a damn; I invited you to demonstrate that we do. Translation: IMO there's a lot of crap in main, contrib, and non-free alike. I only really object to this phenomenon when the crap is used as rheortical ammunition to bolster arguments that presumably wouldn't be strong enough if grounded solely on packages that are well-maintained and in wide usage. Lest people like I'm just flaming, I posit that xtrs (in contrib) might be crap by this definition, and I maintain it. I think it is well-maintained[1], but I strongly suspect it has staggeringly few users. Consequently, I don't try to characterize it as some sort of precious jewel that illustrates why we, say, MUST, *MUST*, keep distributing the contrib section. The only occasions I've had to even mention xtrs in the past year, in fact, have been in the context of discussions about the packging of emulators. [1] It hasn't had a Debian bug report in quite some time and the upstream author/maintainer has a big brain and writes solid code. But let's be honest -- the fate of empires does not hang on whether Debian distributes a package of it. -- G. Branden Robinson| What influenced me to atheism was Debian GNU/Linux | reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://people.debian.org/~branden/ | -- J. Michael Straczynski signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Mon, Jul 12, 2004 at 05:24:12PM -0700, Josh Triplett wrote: Nathanael Nerode wrote: J.B. Nicholson-Owens wrote: Matthew Palmer wrote: 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. Would one ROM cut it, then? Yes, in a word! Or, indeed, a compiler designed to create such ROMs. Given that many ROMs are written/modified in machine code with a hex editor, I would go as far as to say that if we have a reasonable belief that even one person will ever use the emulator for the purposes of running a hand-written ROM, then the emulator should go to main. I lean the other way. If it's so easy, we should be able to package a trivial one for demonstration purposes. We could even ship it as part of the emulator package itself. Again, this is not really a DFSG or debian-legal issue, it's a Debian Policy issue. -- G. Branden Robinson| Never attribute to malice that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by stupidity. http://people.debian.org/~branden/ | -- Hanlon's Razor signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Mon, Jul 12, 2004 at 02:08:06AM -0400, Nathanael Nerode wrote: I think every program in Debian is held to the standard of being useful. Please, s/is held/should be held/. If you're like me, you should fear the counterexamples that could be brought to the fore. -- G. Branden Robinson| Good judgement comes from Debian GNU/Linux | experience; experience comes from [EMAIL PROTECTED] | bad judgement. http://people.debian.org/~branden/ | -- Fred Brooks signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Mon, Jul 12, 2004 at 10:34:56PM +0200, Francesco Poli wrote: On Mon, 12 Jul 2004 01:56:45 -0400 Nathanael Nerode wrote: It seems like this belongs in main. But why hasn't anyone packaged any of the free IWADs? I really don't know. Perhaps no DD has enough time to package two files that don't even need any actual installation: you just have to download them and you are ready to feed prboom. Very similar to downloading a DFSG-free mp3 audio file and feeding mpg321: does a free-mp3-collection package exist? This can't be the case; witness the abuse of the people on this list when we *dared* to find the IETF's RFC license non-free[1]. Somehow, not shipping (some of) the RFCs in main made them inaccessible, and infeasible to access. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=92810msg=5 ...is just one of many examples -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Wed, 14 Jul 2004 04:24:14 -0500 Branden Robinson wrote: On Mon, Jul 12, 2004 at 10:34:56PM +0200, Francesco Poli wrote: On Mon, 12 Jul 2004 01:56:45 -0400 Nathanael Nerode wrote: It seems like this belongs in main. But why hasn't anyone packaged any of the free IWADs? I really don't know. Perhaps no DD has enough time to package two files that don't even need any actual installation: [...] This can't be the case; witness the abuse of the people on this list when we *dared* to find the IETF's RFC license non-free[1]. Somehow, not shipping (some of) the RFCs in main made them inaccessible, and infeasible to access. ROTFL! Take into account that I am one who would like to have (almost) everything packaged, as long as it's DFSG-free and useful. But, oddly enough, I don't have the ability to *generate* DDs or to *clone* existing ones... ;-) IANADD, either... :p If no DD is willing to package something, I cannot do anything more than filing a RFP: I cannot force anyone, I'm not a dictator! ;-) -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 | and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpmE32PtXhXR.pgp Description: PGP signature
Re: Visualboy Advance question.
* Josh Triplett: Nathanael Nerode wrote: Edmund GRIMLEY EVANS wrote: Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. Debian main does not contain any MP3 encoders. The licensing terms of the patent on MP3 require a royalty payment on encoders (but not decoders), You have to pay royalties for decoders, too: http://www.mp3licensing.com/royalty/index.html
Re: Visualboy Advance question.
Josh Triplett wrote: In this situation, either MP3 decoders should be removed, or if not, then MP3 *en*coders should be packaged as well, since there does not appear to be any distinction between the two except for the amount of the royalties. There has been active enforcement against mp3 encoders, but little or none against decoders. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Visualboy Advance question.
Edmund GRIMLEY EVANS wrote: Branden Robinson [EMAIL PROTECTED]: I put xtrs in contrib because without the ROM (or a DFSG-free OS for the TRS-80 Model 4P, which doesn't exist or at the very least isn't packaged), the only thing it will do is display an error message that no ROM was found. My thinking is that we need to not be pulling any bait-and-switches on our users. If I were to apt-get install xtrs from main, I'd expect it to do something more than throw up an error message. In summary, the decision to put emulators that are largely or completely inoperable without supplementary materials (from non-free, or not provided by Debian at all), is not wholly compelled by the 100% Free Software portion of the Social Contract. It's also motivated by the We will be guided by the needs of our users part. Could you explain how you think the emulator and ROM situation is different from the media player and media file situation, if you think it is? Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. As for bait-and-switch, why not include a warning in the package description that you will need a ROM image to use the emulator? Seems awfully 'contrib' to me. Remember that everything in 'contrib' is free software; it's just unusable without non-free software. -- There are none so blind as those who will not see.
Re: Visualboy Advance question.
Francesco Poli wrote: On Mon, 21 Jun 2004 09:50:35 +1000 Matthew Palmer wrote: snip 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? Maybe. If so, go ahead. If it is in fact extremely difficult to create images in that format (yes, you could have an image format which is easy to read but very hard to write even with source code for the reader available), then maybe the answer is no. Why should Debian wait for one such image to *be packaged* before moving the viewer from contrib to main? Oh, it doesn't need to be packaged. If it is, however, it proves that such an image exists. 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. 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. It seems like this belongs in main. But why hasn't anyone packaged any of the free IWADs? -- There are none so blind as those who will not see.
Re: Visualboy Advance question.
Lewis Jardine wrote: snip Emulators work perfectly correctly without software to emulate. NO$GMB does the same thing with no image loaded that my gameboy does with no cartridge in the slot. It has 'no significant functionality'. Pacifist (I assume) does the same thing with no BIOS that a real Atari ST does if you pull out its BIOS chips*. Many emulators are for systems that are well-documented (indeed, a Free emulator is a good source of documentation in and of itself), and can be used as a basis for developing one's own software, regardless of whether Free software for the platform has yet been written, or packaged in Debian. Well, if the emulator is suitable for that purpose, then certainly I would say that it doesn't depend on non-free software for that fucntionality, and therefore can go in main. (Of course, it should go in the 'dev' section if that's its primary function.) In addition, emulator components can be used in writing ones own emulator, perhaps to prototype some embedded system. That's not an 'end-user' use. Back in the day, for many 8 and 16-bit era consoles and computers, the preferred form for modification was the ROM image itself, or rather rudimentary assembler (indeed, many spectrum games were written on paper, and assembled by hand). Debian already provides a development environment comparable to this. Well, if you have an emulator for such a system, then great, it belongs in 'main'. The policy requires packages to list as a dependency other packages which are necessary for it to operate correctly, not other packages that are necessary for it to behave in manner entertaining to an end user. In my opinion, an emulator bundled with a development environment depends on nothing else to work correctly; for most systems emulated to date, Debian provides an environment that can be used to develop software. The requirement to find/write and package an arbitrary Free program for Not package. Just find/write. the platform strikes me as a ridiculous hurdle - either any program will do, in which case a program so trivial that the end-user could knock one up after reading the manual for a few minutes (a few bytes of assembler to flash the screen, for instance) is sufficient, Um, I think hello world would be a bare minimum standard of usefulness. In the cases of some emulators, the most trivial programs such as that could *not* be knocked up after reading the manual for a few minutes. If it *can* be, then go ahead and put the emulator in 'main'. The trivial program would be a nice thing to put in the emulator package while you're at it. :-) or the program must be judged against some arbitrary criteria of usefulness, which is a requirement no other type of program in Debian is held to. I think every program in Debian is held to the standard of being useful. -- There are none so blind as those who will not see.
Re: Visualboy Advance question.
Evan Prodromou wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. It really does, you know. The dependee libraries and other programs are precisely as replaceable as the data. Some are easier to replace than others, of course, but that's not down to the library/program/data distinction. It also seems terribly unhackerly. I mean, heck: if I'd like to create some Free Gameboy ROMs, I'd want to do it on a Free operating system. Well, everything in 'contrib' is DFSG-free, you know. -- There are none so blind as those who will not see.
Re: Visualboy Advance question.
On Sat, Jul 10, 2004 at 10:07:35PM +1000, Matthew Palmer wrote: I don't think that the basis for a package's inclusion in main should be the packaging in main of appropriate content. The Debian Policy says something pretty close to that, in my view. 2.2.1 The main section Every package in main and non-US/main must comply with the DFSG (Debian Free Software Guidelines). In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package), * must not be so buggy that we refuse to support them, and * must meet all policy requirements presented in this manual. Similarly, the packages in non-US/main * must not require a package outside of main or non-US/main for compilation or execution, * must not be so buggy that we refuse to support them, * must meet all policy requirements presented in this manual. OTOH, as you're sure to note, an easy way around this is that a package can be completely useless in main as long as what it depends on isn't a package. Maybe that *was* your point. That would be a waste of archive resources. Er, before heading down this road, I think you should attempt an objective demonstration that we seem to give a damn about wasting archive resources in the first place. -- G. Branden Robinson|Optimists believe we live in the Debian GNU/Linux |best of all possible worlds. [EMAIL PROTECTED] |Pessimists fear that this really is http://people.debian.org/~branden/ |the best of all possible worlds. signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Sun, Jul 11, 2004 at 01:22:10PM -0400, Joey Hess wrote: Glenn Maynard wrote: On Sun, Jul 11, 2004 at 09:15:41AM +1000, Matthew Palmer wrote: The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. Lack of free data sets period, or lack of free data sets in the archive? I think if there was a presentable free data set for either, it would have been packaged, if only to get these out of contrib. There is a free[1] doom WAD, see bug #206139. Why noone has packaged it, I don't know. According to the bug logs, as of about a month ago Moritz Muehlenhoff announced his intent to package it. -- G. Branden Robinson| Why should I allow that same God Debian GNU/Linux | to tell me how to raise my kids, [EMAIL PROTECTED] | who had to drown His own? http://people.debian.org/~branden/ | -- Robert Green Ingersoll signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Sun, Jul 11, 2004 at 12:22:36AM +0900, Fedor Zuev wrote: On Fri, 9 Jul 2004, Branden Robinson wrote: Do we expect the typical user of the emulator to already have game ROMs on hand? If so, by what means? Do you really want to know and control the means, by which debian users will get the ROMs? More specifically, do you really think that [futile] attempts to control and police sources of _input_ _data_, on which debian users will run the program, is compatible with terms and principles of Free Software? I think you're jumping to conclusions. -- G. Branden Robinson| Debian GNU/Linux | Bother, said Pooh, as he was [EMAIL PROTECTED] | assimilated by the Borg. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Visualboy Advance question.
Nathanael Nerode [EMAIL PROTECTED]: Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. Yes, I suppose so. You can also make your own ROMs. In both cases it's not very easy to make a good one, for some senses of good, and most people who use the software aren't going to do it. So it's not obvious to me where to draw the line and whether those two cases really are on different sides of the line. Perhaps it would be best just to stop worrying about it. Unless there's a lot of potential main material that depends on it, does it really matter that much whether a package goes in main or contrib?
Re: Visualboy Advance question.
On Mon, Jul 12, 2004 at 02:05:16AM -0500, Branden Robinson wrote: On Sat, Jul 10, 2004 at 10:07:35PM +1000, Matthew Palmer wrote: I don't think that the basis for a package's inclusion in main should be the packaging in main of appropriate content. The Debian Policy says something pretty close to that, in my view. 2.2.1 The main section Every package in main and non-US/main must comply with the DFSG (Debian Free Software Guidelines). In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, I presume this condition is the basis for your view. I concur, but with reservations when it comes to content, because there is a far wider range of potential bitstreams which would allow the program to operate. OTOH, as you're sure to note, an easy way around this is that a package can be completely useless in main as long as what it depends on isn't a package. Maybe that *was* your point. Not exactly. I'm not a fan of useless software on the whole, so I don't believe that your work-around is a winner. I prefer to fall back on the last sentence of the first clause of the social contract: We will never make the system require the use of a non-free component.. Providing a piece of software which can only use non-free content is requiring the use of a non-free component, IMO. That would be a waste of archive resources. Er, before heading down this road, I think you should attempt an objective demonstration that we seem to give a damn about wasting archive resources in the first place. We don't give a damn? That's a pity. - Matt
Re: Visualboy Advance question.
On Mon, Jul 12, 2004 at 01:46:08AM -0400, Nathanael Nerode wrote: Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. If so, please name them; they must be removed. http://www.debian.org/devel/wnpp/unable-to-package Software that can't be packaged 8hz-mp3, bladeenc, etc -- patent problems with Fraunhofer Institute. (yes, this includes LAME, see archived discussion) (link: http://lists.debian.org/debian-devel/2000/06/msg01213.html) All MP3 encoders are non-free. -- Glenn Maynard
Re: Visualboy Advance question.
On Mon, 12 Jul 2004 01:56:45 -0400 Nathanael Nerode wrote: Why should Debian wait for one such image to *be packaged* before moving the viewer from contrib to main? Oh, it doesn't need to be packaged. If it is, however, it proves that such an image exists. I'm glad to hear this: at least it is not necessary to have DFSG-free data *packaged* in order to move a DFSG-free reader from contrib to main. The mere existence of such data seems to be sufficient... [...] 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. It seems like this belongs in main. But why hasn't anyone packaged any of the free IWADs? I really don't know. Perhaps no DD has enough time to package two files that don't even need any actual installation: you just have to download them and you are ready to feed prboom. Very similar to downloading a DFSG-free mp3 audio file and feeding mpg321: does a free-mp3-collection package exist? -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 | and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpChL5jhDqvV.pgp Description: PGP signature
Re: Visualboy Advance question.
On Mon, 12 Jul 2004 01:46:08 -0400 Nathanael Nerode wrote: Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. Out of curiosity, is that different from the status of MPEG videos? That is: are there MPEG or MPEG2 codecs in main that can generate an MPEG animation starting from its frames in separate images? I see that there are decoder libraries such as libmpeg... -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 | and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpZNXRjeiN9L.pgp Description: PGP signature
Re: Visualboy Advance question.
Nathanael Nerode wrote: J.B. Nicholson-Owens wrote: Matthew Palmer wrote: 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. Would one ROM cut it, then? Yes, in a word! Or, indeed, a compiler designed to create such ROMs. Given that many ROMs are written/modified in machine code with a hex editor, I would go as far as to say that if we have a reasonable belief that even one person will ever use the emulator for the purposes of running a hand-written ROM, then the emulator should go to main. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Visualboy Advance question.
Nathanael Nerode wrote: Edmund GRIMLEY EVANS wrote: Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. Debian main does not contain any MP3 encoders. The licensing terms of the patent on MP3 require a royalty payment on encoders (but not decoders), so Free Software MP3 encoders are non-distributable in all countries with software patents. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Visualboy Advance question.
On Sat, Jul 10, 2004 at 10:12:12PM -0400, Glenn Maynard wrote: On Sun, Jul 11, 2004 at 09:15:41AM +1000, Matthew Palmer wrote: The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. Lack of free data sets period, or lack of free data sets in the archive? I think if there was a presentable free data set for either, it would have been packaged, if only to get these out of contrib. So I take it you were presenting those data points in support of my argument, then? - Matt
Re: Visualboy Advance question.
On Sun, Jul 11, 2004 at 01:53:21PM +1000, Matthew Palmer wrote: On Sat, Jul 10, 2004 at 10:12:12PM -0400, Glenn Maynard wrote: On Sun, Jul 11, 2004 at 09:15:41AM +1000, Matthew Palmer wrote: The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. Lack of free data sets period, or lack of free data sets in the archive? I think if there was a presentable free data set for either, it would have been packaged, if only to get these out of contrib. So I take it you were presenting those data points in support of my argument, then? I'm undecided about your argument. I'm just pointing out that, at least in these cases of these games, practice has been to require that free data must exist. (FWIW, this probably isn't the right list to be discussing this.) -- Glenn Maynard
Re: Visualboy Advance question.
Glenn Maynard wrote: On Sun, Jul 11, 2004 at 09:15:41AM +1000, Matthew Palmer wrote: The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. Lack of free data sets period, or lack of free data sets in the archive? I think if there was a presentable free data set for either, it would have been packaged, if only to get these out of contrib. There is a free[1] doom WAD, see bug #206139. Why noone has packaged it, I don't know. -- see shy jo [1] It's a bit of a compilation, and I've not checked the copyright in depth. signature.asc Description: Digital signature
Re: Visualboy Advance question.
* Lewis Jardine [EMAIL PROTECTED] [040710 03:49]: The typical user of such an emulator is developing software, and using the emulator to test it (in which case visualboy advance is no different to SPIM or WINE). In my opinion, Debian contains sufficient tools to develop your own programs to run on any emulator that isn't encumbered by requiring a particular non-free file: hex editors, assemblers, compilers, and documentation. To say that a typical emulator user would not have game roms is like saying a typical user of gputils might have no PIC images (and therefore gputils should be in contrib). If there are to be used with self-made images and debian contains all tools to create them, simply make one, put it under a free licence and package it (or cause it to be included within the emulator package). Then noone will dare to tell that this is nothing for main. If noone ever made such a thing, and noone is willing to do so, then I think the argument that it used that way is somehow weak. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Visualboy Advance question.
Matthew Palmer [EMAIL PROTECTED]: The prerequisites for inclusion in main should merely be a reasonable belief that the program is useful without recourse to anything non-free, I disagree. I think an MP3 player should be allowed into main without us trying to pretend that it's only there for playing DFSG-free MP3s.
Re: Visualboy Advance question.
* Matthew Palmer [EMAIL PROTECTED] [040710 14:27]: I don't think that the basis for a package's inclusion in main should be the packaging in main of appropriate content. That would be a waste of archive resources. The prerequisites for inclusion in main should merely be a reasonable belief that the program is useful without recourse to anything non-free, and inclusion of the basic set of dependencies for correct functioning. I believe that fulfills our requirements under the social contract, while minimising archive bloat. If there is any content packaged, than such a reasonablity becomes much more apperent. If there is no content and no easy way to create such documented, it is much harder to believe. Especially as some small example is really good to test the functionality and thus worth beeing included in the distribution. (For example I never use saytime in normal operation, but install it regulary, only because it is an very easy method to test whether configuring sound worked). Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Visualboy Advance question.
Matthew Palmer [EMAIL PROTECTED]: The prerequisites for inclusion in main should merely be a reasonable belief that the program is useful without recourse to anything non-free, On Sat, Jul 10, 2004 at 02:30:45PM +0100, Edmund GRIMLEY EVANS wrote: I disagree. I think an MP3 player should be allowed into main without us trying to pretend that it's only there for playing DFSG-free MP3s. That's not a disagreement. That the software is useful without non-free content, doesn't mean that it's only useful for playing free content. -- Raul
Re: Visualboy Advance question.
On Fri, 9 Jul 2004, Branden Robinson wrote: A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting and true. But a lot is not all. I think in the case under discussion, an OS system ROM isn't necessary to run the software. You just need particular game ROMs. Do we expect the typical user of the emulator to already have game ROMs on hand? If so, by what means? Do you really want to know and control the means, by which debian users will get the ROMs? More specifically, do you really think that [futile] attempts to control and police sources of _input_ _data_, on which debian users will run the program, is compatible with terms and principles of Free Software?
Re: Visualboy Advance question.
On Sat, Jul 10, 2004 at 05:03:46PM +0200, Bernhard R. Link wrote: * Matthew Palmer [EMAIL PROTECTED] [040710 14:27]: I don't think that the basis for a package's inclusion in main should be the packaging in main of appropriate content. That would be a waste of archive resources. The prerequisites for inclusion in main should merely be a reasonable belief that the program is useful without recourse to anything non-free, and inclusion of the basic set of dependencies for correct functioning. I believe that fulfills our requirements under the social contract, while minimising archive bloat. If there is any content packaged, than such a reasonablity becomes much more apperent. If there is no content and no easy way to create such documented, it is much harder to believe. Especially as some small Certainly. But in no way should we be encouraging the fallacy that there *must* be packaged free content before we will accept a consumer of said content into the archive. - Matt
Re: Visualboy Advance question.
On Sat, Jul 10, 2004 at 02:30:45PM +0100, Edmund GRIMLEY EVANS wrote: Matthew Palmer [EMAIL PROTECTED]: The prerequisites for inclusion in main should merely be a reasonable belief that the program is useful without recourse to anything non-free, I disagree. I think an MP3 player should be allowed into main without us trying to pretend that it's only there for playing DFSG-free MP3s. I'm not pretending that the programs we distribute will only ever be used for manipulating DFSG-free data. Whether it is or it isn't is entirely not our concern, and that is one of our bases of freedom. However, as I have previously mentioned, the Social Contract states that we will never make the system require the use of anything non-free. I believe that makes any program which only works with non-free data useless in a Debian-main context. - Matt
Re: Visualboy Advance question.
On Sun, Jul 11, 2004 at 08:19:31AM +1000, Matthew Palmer wrote: Certainly. But in no way should we be encouraging the fallacy that there *must* be packaged free content before we will accept a consumer of said content into the archive. The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. -- Glenn Maynard
Re: Visualboy Advance question.
On Sat, Jul 10, 2004 at 06:49:32PM -0400, Glenn Maynard wrote: On Sun, Jul 11, 2004 at 08:19:31AM +1000, Matthew Palmer wrote: Certainly. But in no way should we be encouraging the fallacy that there *must* be packaged free content before we will accept a consumer of said content into the archive. The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. Lack of free data sets period, or lack of free data sets in the archive? - Matt
Re: Visualboy Advance question.
On Sun, Jul 11, 2004 at 09:15:41AM +1000, Matthew Palmer wrote: The quake2 and lxdoom packages are in contrib, due to lack of free data sets. This is long and strongly established, I believe. Lack of free data sets period, or lack of free data sets in the archive? I think if there was a presentable free data set for either, it would have been packaged, if only to get these out of contrib. -- Glenn Maynard
Re: Visualboy Advance question.
Branden Robinson wrote: I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting, but I think in the case under discussion, a system ROM isn't necessary to run the software. You just need particular game ROMs. ~ESP
Re: Visualboy Advance question.
On Thu, Jul 08, 2004 at 01:16:42PM -0400, Evan Prodromou wrote: Branden Robinson wrote: I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting and true. But a lot is not all. I think in the case under discussion, an OS system ROM isn't necessary to run the software. You just need particular game ROMs. Do we expect the typical user of the emulator to already have game ROMs on hand? If so, by what means? -- G. Branden Robinson| A fundamentalist is someone who Debian GNU/Linux | hates sin more than he loves [EMAIL PROTECTED] | virtue. http://people.debian.org/~branden/ | -- John H. Schaar signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Thu, Jul 08, 2004 at 12:10:59PM -0400, Evan Prodromou wrote: Francesco Poli wrote: On Wed, 7 Jul 2004 14:00:47 -0400 Glenn Maynard wrote: I think there's a fairly significant difference between an emulator that will load and display an insert ROM image (eg. NES, SNES), and one that requires a specific non-free image in order to be able to do anything at all (eg. PSX BIOS images). The first is analogous to requiring media; you see what the console displays if a cartridge isn't inserted. The second is the same as requiring a non-free library for which there is no free replacement. (I'm not aware of any free replacement PSX BIOSes.) Agreed, fully. I'd agree with that, too. Very succintly put. Sounds like a good litmus test to me. I likes me my bright-line tests. -- G. Branden Robinson|Kissing girls is a goodness. It is Debian GNU/Linux |a growing closer. It beats the [EMAIL PROTECTED] |hell out of card games. http://people.debian.org/~branden/ |-- Robert Heinlein signature.asc Description: Digital signature
Re: Visualboy Advance question.
Branden Robinson wrote: On Thu, Jul 08, 2004 at 01:16:42PM -0400, Evan Prodromou wrote: Branden Robinson wrote: I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting and true. But a lot is not all. I think in the case under discussion, an OS system ROM isn't necessary to run the software. You just need particular game ROMs. Do we expect the typical user of the emulator to already have game ROMs on hand? If so, by what means? The typical user of such an emulator is developing software, and using the emulator to test it (in which case visualboy advance is no different to SPIM or WINE). In my opinion, Debian contains sufficient tools to develop your own programs to run on any emulator that isn't encumbered by requiring a particular non-free file: hex editors, assemblers, compilers, and documentation. To say that a typical emulator user would not have game roms is like saying a typical user of gputils might have no PIC images (and therefore gputils should be in contrib). For a real-world example, many Computer Science degrees offer courses in compiler design. Target platforms are things with simple processors: MIPS embedded systems, ZX spectrums, gameboys, etc. Rather than test the output from the compiler on the real thing, it is more convenient to use an emulator. This ignores the whole 'legality of using emulators with ROM images of works which you have the license to use on the original platform' debate - if this is indeed legal (which Nintendo denies), the typical user could also be using images of their legitimately aquired games. If you don't want to continue the charade that most people use emulators, mp3 players, video players, peer-to-peer filesharing, etc. for purposes which do not infringe copyright, then I suggest they probably got them from the same place they got their 'movie trailers' from. -- Lewis Jardine IANAL IANADD
Re: Visualboy Advance question.
Francesco Poli wrote: On Wed, 7 Jul 2004 14:00:47 -0400 Glenn Maynard wrote: I think there's a fairly significant difference between an emulator that will load and display an insert ROM image (eg. NES, SNES), and one that requires a specific non-free image in order to be able to do anything at all (eg. PSX BIOS images). The first is analogous to requiring media; you see what the console displays if a cartridge isn't inserted. The second is the same as requiring a non-free library for which there is no free replacement. (I'm not aware of any free replacement PSX BIOSes.) Agreed, fully. I'd agree with that, too. Very succintly put. ~ESP
Re: Visualboy Advance question.
Branden Robinson wrote: I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting and true. But a lot is not all. I think in the case under discussion, an OS system ROM isn't necessary to run the software. You just need particular game ROMs. ~ESP
Re: Visualboy Advance question.
On Sat, Jun 19, 2004 at 06:47:53PM -0400, Evan Prodromou wrote: On Sat, 2004-06-19 at 18:17, Benjamin Cutler wrote: Perhaps my choice of words was poor, but I think that emulators fall into their own class of software because they rely on what is generally commercial, non-free (and honestly, quite probably illegal) software in order to run, which is why they fall into contrib. I guess I'm just not sure I buy that an emulator is materially different from a script interpreter, DFSG-wise. A quick 'apt-cache search emulator' turns up quite a few emulators in main. I can find a few that don't have supported programs in main -- mixal would be one. B-) I put xtrs in contrib because without the ROM (or a DFSG-free OS for the TRS-80 Model 4P, which doesn't exist or at the very least isn't packaged), the only thing it will do is display an error message that no ROM was found. My thinking is that we need to not be pulling any bait-and-switches on our users. If I were to apt-get install xtrs from main, I'd expect it to do something more than throw up an error message. In summary, the decision to put emulators that are largely or completely inoperable without supplementary materials (from non-free, or not provided by Debian at all), is not wholly compelled by the 100% Free Software portion of the Social Contract. It's also motivated by the We will be guided by the needs of our users part. -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Sun, Jun 20, 2004 at 09:50:53AM -0600, Benjamin Cutler wrote: That's all well and good, but obviously somebody (presumably somebody important) somewhere disagrees, or it wouldn't have happened in the first place. I myself don't really give a rip either way where the emulators end up, I'm just pretty sure that my explanation summarizes the supposed reasons behind it. What could be helpful is to find the first such emulator that ended up in contrib and see if there was any discussion on the debian lists prior to its inclusion in the archive. Programs don't get dumped in contrib for no reason, and I admit the reasons emulators were in contrib were not obvious to me at first (and I'm still not even sure I have it right). I'm willing to bet there was some discussion on this years ago and we just need to dig it out. I just don't really know where to start looking. When I was but an egg in the Debian Project, back in early 1998, I *asked* where xtrs should go. The consensus back then was contrib. -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Visualboy Advance question.
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. I don't think we should be putting useless software in our archive, let alone in main. -- G. Branden Robinson| Measure with micrometer, Debian GNU/Linux | mark with chalk, [EMAIL PROTECTED] | cut with axe, http://people.debian.org/~branden/ | hope like hell. signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Tue, Jun 22, 2004 at 08:03:29PM -0400, Evan Prodromou wrote: Lastly, I guess there's just something really violating about thinking that Debian is judging the data I have, or could have, on my hard drive. So I'm not working with Free data. So what? Mind your own beeswax, Debian. If you wouldn't put words in Debian's mouth, maybe you wouldn't have to feel that way. -- G. Branden Robinson| Why should I allow that same God Debian GNU/Linux | to tell me how to raise my kids, [EMAIL PROTECTED] | who had to drown His own? http://people.debian.org/~branden/ | -- Robert Green Ingersoll signature.asc Description: Digital signature
Re: Visualboy Advance question.
On Wed, Jun 30, 2004 at 11:02:39PM +0200, Francesco Poli wrote: On Tue, 29 Jun 2004 23:22:12 +0100 Andrew Suffield wrote: Nintendo are the only ones I'm aware of that try to pretend console emulators aren't legal (sheer sophistry though; they claim outright this thing is illegal because it can be used for illegal purposes). This is what I call the anti-screwdriver claim: following this line of reasoning you could argue that a screwdriver is illegal, because it can be used for illegal purposes (e.g. killing someone by thrusting the screwdriver in his/her throat). Funny how that should spring to mind in reply to a paragraph about Nintendo's lawyers. Can't imagine why. :) -- G. Branden Robinson|If you make people think they're Debian GNU/Linux |thinking, they'll love you; but if [EMAIL PROTECTED] |you really make them think, they'll http://people.debian.org/~branden/ |hate you.-- Don Marquis signature.asc Description: Digital signature
Re: Visualboy Advance question.
Branden Robinson [EMAIL PROTECTED]: I put xtrs in contrib because without the ROM (or a DFSG-free OS for the TRS-80 Model 4P, which doesn't exist or at the very least isn't packaged), the only thing it will do is display an error message that no ROM was found. My thinking is that we need to not be pulling any bait-and-switches on our users. If I were to apt-get install xtrs from main, I'd expect it to do something more than throw up an error message. In summary, the decision to put emulators that are largely or completely inoperable without supplementary materials (from non-free, or not provided by Debian at all), is not wholly compelled by the 100% Free Software portion of the Social Contract. It's also motivated by the We will be guided by the needs of our users part. Could you explain how you think the emulator and ROM situation is different from the media player and media file situation, if you think it is? Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? As for bait-and-switch, why not include a warning in the package description that you will need a ROM image to use the emulator?
Re: Visualboy Advance question.
On Wed, Jul 07, 2004 at 12:22:09PM +0100, Edmund GRIMLEY EVANS wrote: I put xtrs in contrib because without the ROM (or a DFSG-free OS for the TRS-80 Model 4P, which doesn't exist or at the very least isn't packaged), the only thing it will do is display an error message that no ROM was found. My thinking is that we need to not be pulling any bait-and-switches on our users. If I were to apt-get install xtrs from main, I'd expect it to do something more than throw up an error message. In summary, the decision to put emulators that are largely or completely inoperable without supplementary materials (from non-free, or not provided by Debian at all), is not wholly compelled by the 100% Free Software portion of the Social Contract. It's also motivated by the We will be guided by the needs of our users part. Could you explain how you think the emulator and ROM situation is different from the media player and media file situation, if you think it is? I think there's a fairly significant difference between an emulator that will load and display an insert ROM image (eg. NES, SNES), and one that requires a specific non-free image in order to be able to do anything at all (eg. PSX BIOS images). The first is analogous to requiring media; you see what the console displays if a cartridge isn't inserted. The second is the same as requiring a non-free library for which there is no free replacement. (I'm not aware of any free replacement PSX BIOSes.) I get the feeling that the TRS-80 Model 4P ROM is in the latter category. -- Glenn Maynard
Re: Visualboy Advance question.
On Wed, 7 Jul 2004 06:05:24 -0500 Branden Robinson 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. I don't think we should be putting useless software in our archive, let alone in main. Of course! What I meant was: IMHO, usefulness should not be the parameter used to decide if one package must end up in main or in contrib. Uselessness can be a reason for completely dropping the package and deciding to not distribute it. I would find it weird if uselessness were a reason for moving the package from main to contrib... That's all I meant. -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 |and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpwYDR5vZzBp.pgp Description: PGP signature
Re: Visualboy Advance question.
On Wed, 7 Jul 2004 14:00:47 -0400 Glenn Maynard wrote: I think there's a fairly significant difference between an emulator that will load and display an insert ROM image (eg. NES, SNES), and one that requires a specific non-free image in order to be able to do anything at all (eg. PSX BIOS images). The first is analogous to requiring media; you see what the console displays if a cartridge isn't inserted. The second is the same as requiring a non-free library for which there is no free replacement. (I'm not aware of any free replacement PSX BIOSes.) Agreed, fully. -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 | and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpid1DbB2t4B.pgp Description: PGP signature
Re: Visualboy Advance question.
On Wed, Jul 07, 2004 at 11:27:33PM +0200, Francesco Poli wrote: On Wed, 7 Jul 2004 06:05:24 -0500 Branden Robinson 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. I don't think we should be putting useless software in our archive, let alone in main. Of course! What I meant was: IMHO, usefulness should not be the parameter used to decide if one package must end up in main or in contrib. Uselessness can be a reason for completely dropping the package and deciding to not distribute it. I would find it weird if uselessness were a reason for moving the package from main to contrib... Useless in total = /dev/null Useless without non-free components = contrib - Matt
Re: Visualboy Advance question.
On Jun 29, 2004, at 18:22, Andrew Suffield wrote: Sony have given a stream of conflicting messages about the playstation platforms. More importantly, when they tried it against Connectix(sp?), they lost.
Re: Visualboy Advance question.
On Tue, 29 Jun 2004 23:22:12 +0100 Andrew Suffield wrote: Nintendo are the only ones I'm aware of that try to pretend console emulators aren't legal (sheer sophistry though; they claim outright this thing is illegal because it can be used for illegal purposes). This is what I call the anti-screwdriver claim: following this line of reasoning you could argue that a screwdriver is illegal, because it can be used for illegal purposes (e.g. killing someone by thrusting the screwdriver in his/her throat). :-( -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO, | 31B5 78F4 279B DD6D FCF4 | version 1.8.0 pgpEtth3FShpz.pgp Description: PGP signature
Re: Visualboy Advance question.
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...)
Re: Visualboy Advance question.
On Sun, Jun 27, 2004 at 09:12:03PM -0400, Anthony DeRobertis wrote: OK, you *are* making that argument. Why, then, should mpg321 stay in main? Honestly, how many people play DFSG-free mp3s? More than 1. -- Raul
Re: Visualboy Advance question.
@ 27/06/2004 22:12 : wrote Anthony DeRobertis : 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. Under BR computer programs act (9.609/98), one backup copies and *all* copies deemed necessary to use the program are fair game. 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. It's *not* unreasonable. The lack of widely-known Free ROMs does not prove the lack of Free but lesser known ROMs. The emulator should go to main IMHO. -- br,M
Re: Visualboy Advance question.
On Sun, Jun 27, 2004 at 09:12:03PM -0400, Anthony DeRobertis wrote: 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. I'm not aware of any relevant precedents, but at least some of the big console companies have stated in the past that (a) this is okay, and (b) it doesn't have to be a dump of *your* cartridge either - you just have to own one. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Visualboy Advance question.
Andrew Suffield wrote: On Sun, Jun 27, 2004 at 09:12:03PM -0400, Anthony DeRobertis wrote: 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. I'm not aware of any relevant precedents, but at least some of the big console companies have stated in the past that (a) this is okay, and (b) it doesn't have to be a dump of *your* cartridge either - you just have to own one. Really? I would be interested to know which console companies, since most of them try to pretend that emulation is always illegal. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Visualboy Advance question.
On Tue, Jun 29, 2004 at 08:12:52AM -0700, Josh Triplett wrote: Andrew Suffield wrote: On Sun, Jun 27, 2004 at 09:12:03PM -0400, Anthony DeRobertis wrote: 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. I'm not aware of any relevant precedents, but at least some of the big console companies have stated in the past that (a) this is okay, and (b) it doesn't have to be a dump of *your* cartridge either - you just have to own one. Really? I would be interested to know which console companies, since most of them try to pretend that emulation is always illegal. Sega at least; they have even participated in the development of emulators for various console platforms (notably including the megadrive). If you ask the subsidiary Sega of America, Inc. you'll probably get a contradictory answer though. Nintendo are the only ones I'm aware of that try to pretend console emulators aren't legal (sheer sophistry though; they claim outright this thing is illegal because it can be used for illegal purposes). Sony have given a stream of conflicting messages about the playstation platforms. Their legal efforts focus on copyright (bios image) and patent issues. They are in a rather uncomfortable position, because it was the Sony vs Universal Studios case that said VHS recorders are legal - they don't really want to disrupt that. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Visualboy Advance question.
Joe Wreschnig [EMAIL PROTECTED] wrote: On Wed, 2004-06-23 at 15:30, Walter Landry wrote: Evan Prodromou [EMAIL PROTECTED] wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. It also seems terribly unhackerly. I mean, heck: if I'd like to create some Free Gameboy ROMs, I'd want to do it on a Free operating system. Lastly, I guess there's just something really violating about thinking that Debian is judging the data I have, or could have, on my hard drive. So I'm not working with Free data. So what? Mind your own beeswax, Debian. This was all discussed to death when Quake 2 was GPL'd [1]. The main problem I see is that if you accept these arguments, contrib becomes empty. Except for all the programs that depend on proprietary libraries, or proprietary runtime environments, or installer programs (though I would be fine moving the last case to non-free). i.e. the stuff that Depends: in the Debian sense. But that seems terribly unhackerly. I mean, heck: if I'd like to create some Free version of the proprietary library, I'd want to do it on a Free operating system. ;) Whether you like it or not, there is a value judgement going on with contrib vs. main. If something is not useful enough with non-free bits, then it goes into contrib. A good comparison is, why do we ship .doc readers in Debian? I'm pretty sure we don't distribute any .docs (someone will prove me wrong on this, I bet), and I can't recall seeing one under a free license that wasn't also available in some better form. Are you going to make me attach one to this email? We've come to the conclusion that because the .doc reader itself is free and because many of our users might want to open .docs (even though they are proprietary pieces of shit), we include the reader. Debian included it because it is not that hard to find or generate free .docs. I agree that the standard should not be whether something is packaged for Debian. Rather it should be (and seems to be) whether there is any useful free content at all. Yes, useful is subjective. But I would argue that it has never been a problem in practice. Prior to the inclusion of OpenOffice, I don't even think we had anything that could generate free .docs (no, AbiWord can't); I believe GCC can generate free Gameboy binaries. The original poster claimed that there exist free and useful Gameboy binaries that this emulator can use. If that is the case, then I have no objections with regards to this particular emulator. Regards, Walter Landry [EMAIL PROTECTED]
Re: Visualboy Advance question.
Ken Arromdee wrote: On Tue, 22 Jun 2004, Josh Triplett wrote: Every package must specify the dependency information about other packages that are required for the first to work correctly. Emulators do not work correctly without software to emulate. If there is no software, then by definition the emulator works correctly on all the software that exists. The null set is still a set. There is software (or the emulator would probably never have been written), just not Free Software. - Josh Triplett
Re: Visualboy Advance question.
Evan Prodromou [EMAIL PROTECTED] wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. It also seems terribly unhackerly. I mean, heck: if I'd like to create some Free Gameboy ROMs, I'd want to do it on a Free operating system. Lastly, I guess there's just something really violating about thinking that Debian is judging the data I have, or could have, on my hard drive. So I'm not working with Free data. So what? Mind your own beeswax, Debian. This was all discussed to death when Quake 2 was GPL'd [1]. The main problem I see is that if you accept these arguments, contrib becomes empty. Whether you like it or not, there is a value judgement going on with contrib vs. main. If something is not useful enough with non-free bits, then it goes into contrib. Regards, Walter Landry [EMAIL PROTECTED] [1] http://lists.debian.org/debian-devel/2001/12/msg01723.html
Re: Visualboy Advance question.
On Tue, 22 Jun 2004, Josh Triplett wrote: Every package must specify the dependency information about other packages that are required for the first to work correctly. Emulators do not work correctly without software to emulate. If there is no software, then by definition the emulator works correctly on all the software that exists. The null set is still a set.
Re: Visualboy Advance question.
On Wed, 2004-06-23 at 15:30, Walter Landry wrote: Evan Prodromou [EMAIL PROTECTED] wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. It also seems terribly unhackerly. I mean, heck: if I'd like to create some Free Gameboy ROMs, I'd want to do it on a Free operating system. Lastly, I guess there's just something really violating about thinking that Debian is judging the data I have, or could have, on my hard drive. So I'm not working with Free data. So what? Mind your own beeswax, Debian. This was all discussed to death when Quake 2 was GPL'd [1]. The main problem I see is that if you accept these arguments, contrib becomes empty. Except for all the programs that depend on proprietary libraries, or proprietary runtime environments, or installer programs (though I would be fine moving the last case to non-free). i.e. the stuff that Depends: in the Debian sense. Whether you like it or not, there is a value judgement going on with contrib vs. main. If something is not useful enough with non-free bits, then it goes into contrib. A good comparison is, why do we ship .doc readers in Debian? I'm pretty sure we don't distribute any .docs (someone will prove me wrong on this, I bet), and I can't recall seeing one under a free license that wasn't also available in some better form. We've come to the conclusion that because the .doc reader itself is free and because many of our users might want to open .docs (even though they are proprietary pieces of shit), we include the reader. Prior to the inclusion of OpenOffice, I don't even think we had anything that could generate free .docs (no, AbiWord can't); I believe GCC can generate free Gameboy binaries. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
Walter Landry [EMAIL PROTECTED] writes: Evan Prodromou [EMAIL PROTECTED] wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. It also seems terribly unhackerly. I mean, heck: if I'd like to create some Free Gameboy ROMs, I'd want to do it on a Free operating system. Lastly, I guess there's just something really violating about thinking that Debian is judging the data I have, or could have, on my hard drive. So I'm not working with Free data. So what? Mind your own beeswax, Debian. This was all discussed to death when Quake 2 was GPL'd [1]. The main problem I see is that if you accept these arguments, contrib becomes empty. Whether you like it or not, there is a value judgement going on with contrib vs. main. If something is not useful enough with non-free bits, then it goes into contrib. Huh? Contrib would still have Java applications that require the non-free jre, stuff that build-depends on non-free software, those installer packages, etc... -- You win again, gravity!
Re: Visualboy Advance question.
On Tue, 22 Jun 2004 09:55:25 +1000 Matthew Palmer wrote: 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. I'm sorry if I misunderstood you. Just to avoid that this happen again in the future: where should a free emulator with no free data to process (and thus useless in a free-software only environment) go? I thought you said contrib... 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*. Ah. The thread started from a question by Dan Korostelev who asked why visualboyadvance is in contrib. The first answer was by Benjamin Cutler who said: | The same reason fceu was in contrib until 'efp' was packaged, because | the requires at least one piece of software that's not in Debian in | order to be useful. Find a good free rom, package it, and VBA can move | into main just like fceu did. zsnes remains in contrib for the same | reason. Note the package it part. Since you didn't stated that, in your opinion, the packaging requirement was to be dropped, I thought that you agreed with Benjamin and were just taking extreme examples when you were talking about cases with *no* free data at all. I now realize that I was wrong in this assumption: I stand corrected. 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. Well, now I think I see what you mean (also in light of the below clarification about what the Policy says about the Depends meaning...). [...] 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. So be it... -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO, | 31B5 78F4 279B DD6D FCF4 | version 1.8.0 pgpzIjzUITeov.pgp Description: PGP signature
Re: Visualboy Advance question.
On Mon, 2004-06-21 at 19:55, Matthew Palmer wrote: 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. That is nice sophistry, but I don't think it holds water. The order of dependence that you're describing is quite backwards. It's unusual (although not unheard-of) for a Debian package for an interpreter or emulator to Depends on programs that run under than interpreter, rather than the other way around. I don't think that many of us would be pleased if the 'perl' package Depends-depended on, say, 'prcs-utils' or 'mp32ogg'. 'perl' needs SOME data -- even console-entered data -- to be useful, but it doesn't need any PARTICULAR data to be useful. perl is still quite useful even if I don't have mp32ogg installed. Not only that, but we fully expect users to provide their OWN data for that software -- whether free or not. An MP3 player doesn't depend on the Free Software Song to operate. An image viewer doesn't depend the Tux image. It's OK to use non-free data with a free program in main. That's not a violation of our guidelines. Yes, we all need to be needed, in a hippy-squishy way -- Debian packages inclusive. (Have you hugged your packages today?) But saying that a Debian package Depends on packages that Depends on it is taking a mushy truism to an absurd technical conclusion. In closing: I think it's a mistake to leave out Free Software just because there's not Free Data for that software to work with. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
Evan Prodromou wrote: In closing: I think it's a mistake to leave out Free Software just because there's not Free Data for that software to work with. While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. The reason it is OK for a Free image viewer to be in main is not that it Depends on a Free image; instead, it is because Free images are known to exist, and it would be pointless to depend on any particular image or group of images. In the case of many Free emulators, no Free programs to emulate are known to exist, packaged or not. As soon that assumption is proven wrong, the software can go to main. For example, Wine is in main, even though no Windows software is packaged in Debian; this is OK, for two reasons. First, Free Software Windows programs do exist, and it would be pointless to depend on a particular Free Windows program. Second, WineLib allows linking the user's own Windows code to WineLib for the purposes of compiling and running that program under GNU/Linux. - Josh Triplett
Re: Visualboy Advance question.
On Sun, 20 Jun 2004, Dan Korostelev wrote: Please, could someone explain me why visualboyadvance package is in 'contrib' section of Debian? It's free itself, it depends on free libs, looks like it doesn't require any non-free stuff at all. There's also free (as in freedom) roms for GBA in the net. So what's the problem? Even though this is being discussed on -legal, this really has nothing whatsoever to do with the licensing of visualboyadvance or anything else remotely related to -legal. Perhaps this entire thread should be directed to -devel or the ftpmasters should be polled for their opinion, or even better, the maintainer of this package contacted and asked. The DFSG freeness of the software has (hopefully!) been weighed, and that's why it's in contrib as opposed to non-free. Why it's in contrib instead of main is a question for the maintainer and ftpmaster (and if you disagree with their assessment, the tech ctte or developers, respectively.) Don Armstrong -- This message brought to you by weapons of mass destruction related program activities, and the letter G. http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Visualboy Advance question.
Evan Prodromou wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. From Debian Policy section 3.5: Every package must specify the dependency information about other packages that are required for the first to work correctly. Emulators do not work correctly without software to emulate. It also seems terribly unhackerly. I mean, heck: if I'd like to create some Free Gameboy ROMs, I'd want to do it on a Free operating system. Agreed. I would also say that a Gameboy emulator could go into main if all the tools necessary to create a Free Gameboy ROM were packaged, even if such a ROM did not yet exist. In this case, the emulator would serve as a way to test your ROM. This situation would be much like Winelib: No software linked to libwine exists in Debian, but GCC and Winelib together provide all the tools necessary to create some. If it were only possible to create Winelib applications using a non-free compiler or toolchain, then Winelib would need to go to contrib. Lastly, I guess there's just something really violating about thinking that Debian is judging the data I have, or could have, on my hard drive. So I'm not working with Free data. So what? Mind your own beeswax, Debian. Debian is not judging the data _you_ have. Software in main is usable with both Free and non-free software/data/etc, and Debian doesn't care which you use. Software in contrib has no Free software/data/etc to work with, so it is impossible to use it on a completely Free system; you are still welcome to use it. - Josh Triplett
Re: Visualboy Advance question.
Josh Triplett wrote: Evan Prodromou wrote: On Tue, 2004-06-22 at 19:02, Josh Triplett wrote: While I agree that it is not necessarily required that a Free package Depend on some piece of Free data for it to operate on, I do believe that if there is _no_ Free data for the package to run with, and that data is required in order to operate, then the package must go in contrib until at least one free piece of data is available. I just don't think that software Depends: on the data it manipulates the way that it Depends: on, say, libraries or other programs. From Debian Policy section 3.5: Every package must specify the dependency information about other packages that are required for the first to work correctly. Emulators do not work correctly without software to emulate. Emulators work perfectly correctly without software to emulate. NO$GMB does the same thing with no image loaded that my gameboy does with no cartridge in the slot. Pacifist (I assume) does the same thing with no BIOS that a real Atari ST does if you pull out its BIOS chips*. Many emulators are for systems that are well-documented (indeed, a Free emulator is a good source of documentation in and of itself), and can be used as a basis for developing one's own software, regardless of whether Free software for the platform has yet been written, or packaged in Debian. In addition, emulator components can be used in writing ones own emulator, perhaps to prototype some embedded system. Back in the day, for many 8 and 16-bit era consoles and computers, the preferred form for modification was the ROM image itself, or rather rudimentary assembler (indeed, many spectrum games were written on paper, and assembled by hand). Debian already provides a development environment comparable to this. The policy requires packages to list as a dependency other packages which are necessary for it to operate correctly, not other packages that are necessary for it to behave in manner entertaining to an end user. In my opinion, an emulator bundled with a development environment depends on nothing else to work correctly; for most systems emulated to date, Debian provides an environment that can be used to develop software. The requirement to find/write and package an arbitrary Free program for the platform strikes me as a ridiculous hurdle - either any program will do, in which case a program so trivial that the end-user could knock one up after reading the manual for a few minutes (a few bytes of assembler to flash the screen, for instance) is sufficient, or the program must be judged against some arbitrary criteria of usefulness, which is a requirement no other type of program in Debian is held to. -- Lewis Jardine IANAL IANADD
Re: Visualboy Advance question.
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... 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? 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. 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? [1] http://freedoom.sourceforge.net/ 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? 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. 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... -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B
Re: Visualboy Advance question.
Evan Prodromou wrote: I think that it's a mistake to say that an interpreter or emulator depends on the data blobs it interprets, in the Debian sense of dependence. That's all well and good, but obviously somebody (presumably somebody important) somewhere disagrees, or it wouldn't have happened in the first place. I myself don't really give a rip either way where the emulators end up, I'm just pretty sure that my explanation summarizes the supposed reasons behind it. What could be helpful is to find the first such emulator that ended up in contrib and see if there was any discussion on the debian lists prior to its inclusion in the archive. Programs don't get dumped in contrib for no reason, and I admit the reasons emulators were in contrib were not obvious to me at first (and I'm still not even sure I have it right). I'm willing to bet there was some discussion on this years ago and we just need to dig it out. I just don't really know where to start looking.
Re: Visualboy Advance question.
On Sat, 19 Jun 2004 18:47:53 -0400 Evan Prodromou wrote:
Perhaps my choice of words was poor, but I think that emulators fall
into their own class of software because they rely on what is
generally commercial, non-free (and honestly, quite probably
illegal) software in order to run, which is why they fall into
contrib.
I guess I'm just not sure I buy that an emulator is materially
different from a script interpreter, DFSG-wise.
I agree: they are not conceptually different from interpreters or JVMs
or image viewers or audio/video players, and so on.
They don't depend on ROM images: it's quite the opposite instead!
ROM images depend on an appropriate emulator to be executed.
$ python
Python 2.1.3 (#1, Sep 7 2002, 15:29:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type copyright, credits or license for more information.
{Ctrl-D}
$
This interpreter runs perfectly fine, even without any script to
execute...
From an interpreter point of view, a script is just data to process.
Similarly Kaffe would be in main even if there were no DFSG-free Java
programs available (correct me if I'm wrong).
A Java program cannot go in main if it cannot be executed by a DFSG-free
JVM, because it depends on a JVM (or on a JIT compiler or on a
java-to-native-code-compiler such as GJC).
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.
--
| GnuPG Key ID = DD6DFCF4 | You're compiling a program
Francesco |Key fingerprint = | and, all of a sudden, boom!
Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
| 31B5 78F4 279B DD6D FCF4 | version 1.8.0
pgpuwUt7LlSYZ.pgp
Description: PGP signature
Re: Visualboy Advance question.
On Sun, 2004-06-20 at 11:50, Benjamin Cutler wrote: I think that it's a mistake to say that an interpreter or emulator depends on the data blobs it interprets, in the Debian sense of dependence. That's all well and good, but obviously somebody (presumably somebody important) somewhere disagrees, or it wouldn't have happened in the first place. Hmm. I wonder if other emulators have the same problems as the atari800 emulator. From the description: The Atari Operating System ROMs are not available with this package, due to copyright. You'll have to either make copies of them from an old Atari computer, or see README.Debian for other ways to obtain them. I'd say that this was a valid reason to put atari800 into contrib. My understanding is that this emulator *just won't work* without these ROMs. No matter what data ROM you want to run, you need the OS ROMs to do so. I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
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 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? 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. 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. 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. 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. - Matt
Re: Visualboy Advance question.
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? What if there were images in that format, but in order to get them you'd have to break copyright law? I think software usefulness is remarkably subjective and not something on which one should base inclusion in main. Perhaps usefulness is a better argument for what to include on installation media (versus what to leave in an online repository to pick up later). 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. I'd be surprised if this is entirely true all the time everywhere. It might be mostly true, but there could be demos (for example) that are DFSG-free. In some countries it might be legal to make dumps of ROMs for one's own personal use. In either case, one might want an emulator to run the ROMs one obtained legally. This might not be the most popular use for emulators, but I don't have any way to measure the most popular use of emulators and that doesn't seem to be the criterion for inclusion in main. Perhaps Debian main's criteria are being interpreted from the perspective of American law? 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. Would one ROM cut it, then? I am working to determine if one ROM is available under a DFSG-free license right now. I don't have much to report yet except thanks to those who have supplied information to help me track down the copyright holder. I should know more soon and I plan to report what I've learned on debian-legal.
Re: Visualboy Advance question.
J.B. Nicholson-Owens ([EMAIL PROTECTED]): 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. Would one ROM cut it, then? I am working to determine if one ROM is available under a DFSG-free license right now. I don't have much to report yet except thanks to those who have supplied information to help me track down the copyright holder. I should know more soon and I plan to report what I've learned on debian-legal. For GBA it shouldn't be too hard, at least a few years ago hobby GBA development was pretty popular since flash cards and flashers are widely available, and so is a gcc that can cross-compile. -Billy
Re: Visualboy Advance question.
J.B. Nicholson-Owens wrote: Would one ROM cut it, then? I am working to determine if one ROM is available under a DFSG-free license right now. I don't have much to report yet except thanks to those who have supplied information to help me track down the copyright holder. I should know more soon and I plan to report what I've learned on debian-legal. It should, if fceu getting moved to main with the inclusion of 'efp' is any indication. See this old thread I dug up from the d-legal archives: http://lists.debian.org/debian-legal/2004/01/msg00128.html
Re: Visualboy Advance question.
Dan Korostelev wrote: Hello. Please, could someone explain me why visualboyadvance package is in 'contrib' section of Debian? It's free itself, it depends on free libs, looks like it doesn't require any non-free stuff at all. There's also free (as in freedom) roms for GBA in the net. So what's the problem? PS BTW, there's new upstream version with nice GTK+ UI available, I mailed a bug, but maintainer didn't replied for month. The same reason fceu was in contrib until 'efp' was packaged, because the requires at least one piece of software that's not in Debian in order to be useful. Find a good free rom, package it, and VBA can move into main just like fceu did. zsnes remains in contrib for the same reason.
Re: Visualboy Advance question.
On Sat, 2004-06-19 at 15:09 -0600, Benjamin Cutler wrote: Please, could someone explain me why visualboyadvance package is in 'contrib' section of Debian? It's free itself, it depends on free libs, The same reason fceu was in contrib until 'efp' was packaged, because the requires at least one piece of software that's not in Debian in order to be useful. Then why gnomekiss (and fkiss?) is in 'main'? -- Dan Korostelev [EMAIL PROTECTED]
Re: Visualboy Advance question.
On Sat, 2004-06-19 at 17:09, Benjamin Cutler wrote: Please, could someone explain me why visualboyadvance package is in 'contrib' section of Debian? It's free itself, it depends on free libs, looks like it doesn't require any non-free stuff at all. There's also free (as in freedom) roms for GBA in the net. The same reason fceu was in contrib until 'efp' was packaged, because the requires at least one piece of software that's not in Debian in order to be useful. That doesn't make sense to me. An image viewer isn't useful without images, an interpreter isn't useful without scripts, nor is a library useful without some program that links to it. But we don't keep those kinds of packages out of main just because there aren't images, scripts, nor linking programs in main. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
On Sat, 2004-06-19 at 17:40 -0400, Evan Prodromou wrote: That doesn't make sense to me. An image viewer isn't useful without images, an interpreter isn't useful without scripts, nor is a library useful without some program that links to it. But we don't keep those kinds of packages out of main just because there aren't images, scripts, nor linking programs in main. I agree. Most people want a program to view images, play movies, execute scripts, etc from Debian. They have their own images, movies and scripts to work with. The same with ROMs for emulators other things like this. I don't think visualboyadvance should be in contrib instead of main just because there's no any free GBA ROM in Debian. -- Dan Korostelev [EMAIL PROTECTED]
Re: Visualboy Advance question.
On Sat, 2004-06-19 at 18:17, Benjamin Cutler wrote: Perhaps my choice of words was poor, but I think that emulators fall into their own class of software because they rely on what is generally commercial, non-free (and honestly, quite probably illegal) software in order to run, which is why they fall into contrib. I guess I'm just not sure I buy that an emulator is materially different from a script interpreter, DFSG-wise. A quick 'apt-cache search emulator' turns up quite a few emulators in main. I can find a few that don't have supported programs in main -- mixal would be one. B-) ~ESP signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
Evan Prodromou wrote: I guess I'm just not sure I buy that an emulator is materially different from a script interpreter, DFSG-wise. Ok, tack on 'console', and the fact that 99.9% of console 'programs' (ROMs) out there are extremely undistributable, as opposed to something like a Macintosh emulator for which there exists a good amount of software you can download, and I think the difference becomes more apparent. Same with something like a script interpreter or an image viewer. It's far, far easier to find free (as in beer) content for those than for a console emulator. I *think* that's the reason that console emulators end up in contrib instead of main.
