Re: dpANSI
Greetings, and thanks for this! Adam Warner [EMAIL PROTECTED] writes: On Tue, 2004-06-22 at 07:50, Camm Maguire wrote: Greetings! Can anyone comment on the DFSG status of the material at: ftp://parcftp.xerox.com/pub/cl ? Please cc: me directly. Hi Camm. This is an earlier answer from the X3J13 Project Editor, Kent M Pitman. It is as definitive as you can get without further evidence being made public: http://groups.google.com/groups?selm=sfwr84z4dnq.fsf%40shell01.TheWorld.com I am personally prepared to rely upon the Common Lisp community understanding that they are public domain documents. Whether the Debian project is similarly prepared to accept the uncertainty is their decision. I suggest the Debian project is relatively safe continuing to distribute gcl-doc and gclcvs-doc which include these unofficial sources. It would be nice for those in the know/responsible for Debian's legal understanding to put forth a consensus on this. Others have suggested the possible usefulness of contacting others on the committee. I have a call into one such person. But given this statement, this course might be a waste of time. Thoughts? Just remember than you should never use the HyperSpec nor the official ANSI Common Lisp standard as source as these are both clearly copyright and distribution is encumbered. Indeed -- we don't and never will. Regards, Adam -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah
Re: dpANSI
On 2004-06-22 16:56:33 +0100 Camm Maguire [EMAIL PROTECTED] wrote: http://groups.google.com/groups?selm=sfwr84z4dnq.fsf%40shell01.TheWorld.com I am personally prepared to rely upon the Common Lisp community understanding that they are public domain documents. [...] It would be nice for those in the know/responsible for Debian's legal understanding to put forth a consensus on this. I would like to rely upon it, but I am scared by the possibility that some of the authors may object. Roughly how many others are distributing this and since when? If it is a large number, then it seems fairly likely that they are usually regarded as public domain and any copyright assertion will be widely opposed. You should include an excerpt from the lead author's message above in the debian copyright file. I can't quite bring myself to say yes, this is fine, because it still feels potentially thorny. Maybe that is why I was mistaken for a lawyer at a conference ;-) -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing
Re: dpANSI
On 22 Jun 2004 11:56:33 -0400 Camm Maguire [EMAIL PROTECTED] wrote: Adam Warner [EMAIL PROTECTED] writes: I am personally prepared to rely upon the Common Lisp community understanding that they are public domain documents. Whether the Debian project is similarly prepared to accept the uncertainty is their decision. It would be nice for those in the know/responsible for Debian's legal understanding to put forth a consensus on this. Reading Kent Pitman's statement didn't exactly instil me with confidence: Kent M Pitman ([EMAIL PROTECTED]) wrote: Documents do exist (but are not on display publicly) This raises the question: why not? that would show that the legal intent was to have placed them into the public domain, even though we botched the final execution of that. So, this stuff definitely *isn't* in the public domain, then. A good intellectual property lawyer would tell you that this means the legal status is messy Whoo, a lawyerbomb. those who paid for its creation could (hypothetically) have grounds to make a claim that it was encumbered in some way, that is, to assert that they have some right of ownership. But since all of those parties at one time or another signed into this system of contracts identifying that the intent was to make a public domain document, I don't personally think they would succeed. It would be nice to know who all the parties in question are. Also: 1) The papers that detail the contract aren't on public display. 2) They might not even be in the possession of the prosecuting party, making obtaining access to them via some disclosure process difficult. 3) I'm not sure how much intent would be worth, and indeed 4) Surely a contract is only binding between the signatories? I fail to see how it could realistically be used as proof of any obligation to third parties. IANAL, but this sounds highly dodgy to me. -- Andrew Saunders
Re: How long is it acceptable to leave *undistributable* files in
On Mon, 21 Jun 2004 20:09:52 -0400 Raul Miller wrote: I will agree that you are not creating creative elements. I see no reason to agree that you are not adding creative elements. You might very well be adding someone else's creative elements (depending on how your system is configured). Ah, OK. I meant that you are not adding creative elements *that are your own*. But, you're right in saying that I didn't stated explicitly... -- | 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 pgptrSRurEX7X.pgp Description: PGP signature
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: dpANSI
On Wed, 2004-06-23 at 03:56, Camm Maguire wrote: It would be nice for those in the know/responsible for Debian's legal understanding to put forth a consensus on this. Others have suggested the possible usefulness of contacting others on the committee. I have a call into one such person. But given this statement, this course might be a waste of time. Thoughts? Contacting the committee will be worthwhile. The parties involved aren't getting any younger and subsequent owners or estates could be intransigent or litigious. It would be great if this could be an agenda item for the next Committee meeting (assuming one will be constituted to discuss this). Please let me know the outcome of the contact you have made. It's unlikely your contact will be a waste of time. Further statements on the legal status of the dpANS draft documents from Committee members will be valuable. They should also appreciate the benefits to Common Lisp adoption of being able to annotate the standard with clarifications, community interpretations and implementation specific details. It is also important to have a solid foundation to build a future standard upon. It is highly unlikely a future Common Lisp will be the product of such a rigorous and formal process. But being able to build upon the drafts to the world's best language specification will be a good start. Regards, Adam
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
