Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, 18 Dec 2003 13:42:23 -0500 Branden Robinson [EMAIL PROTECTED] wrote: Actually, I think daemons first showed up in the _Fiend Folio_, which means we have the British to thank for this confusion. ;-) What about Maxwell's daemon? This is usually thought to be the computer origin of the term. 19th Century. http://ei.cs.vt.edu/~history/Daemon.html Jim Penny
Re: rice doc status
On Fri, 7 Nov 2003 15:55:25 -0500 [EMAIL PROTECTED] wrote: I don't know if you are virused, or if your sender has been spoofed, or what. Anyway, you might want to look into this. You appear to be spewing odd word documents people you don't know. Jim Penny -Original Message- From: Melody,Thomas,GREENWICH,Information Services Sent: Wednesday, November 05, 2003 3:09 PM To: Winters,John,GREENWICH,Information Services Cc: Fine,Paul,GREENWICH,Information Systems Subject:FW: rice doc status John, Was this completed ? Tom -Original Message- From: Fine,Paul,GREENWICH,Information Systems Sent: Wednesday, November 05, 2003 2:48 PM To: Melody,Thomas,GREENWICH,Information Services Subject:rice doc status Tom, I am unsure if you have this rice doc or not If not here it is...it is to copy the ship-to to the shipment doc in dv3 240 Thanks Paul Fine Nest Data Transfer for shipto.doc e Waters North America SAP Analyst Phone-203-629-7234 Pager-1-888-22-WATER
Re: Removing python-pygresql and libpqpp packages
On Fri, 10 Oct 2003 14:46:15 +0100 Oliver Elphick olly@lfix.co.uk wrote: Barring objection, and there may be some legitimate objection, as I am well behind and feeling mighty damned guilty about it, I will pick it up. This is somewhat natural because I am already PoPy packager, and PoPy is being merged into pygresql. Jim Penny This is not strictly orphaning, more infanticide. I'm not sure conventional orphaning fits, since the source package is not being orphaned. The PostgreSQL python interface (python-pygresql) has been separated upstream into its own source tree. Since it no longer needs to be built with postgresql itself, and since I do not use python, the python binaries will no longer be built when postgresql 7.4 is released (in a few weeks).
Re: 2.5/2.6 IPsec stack should live in a kernel-patch!
On Thu, 2 Oct 2003 01:38:45 +0200 [EMAIL PROTECTED] (Domenico Andreoli) wrote: On Wed, Oct 01, 2003 at 05:38:51PM -0500, Steve Langasek wrote: [ObPrivate: this doesn't belong on private. Quote me freely.] On Wed, Oct 01, 2003 at 11:56:14PM +0200, martin f krafft wrote: Thus I propose that Herbert should remove the IPsec patch and make it a separate kernel-patch. If anyone has other objections than I won't do it because it's my choice, I don't feel like it, and there is nothing you can do about it, then please speak up. On the other hand, if you agree with me, let your voice be heard! i'm interested only in the debian kernel without 2.5/2.6 IPsec. in my mind this should be vanilla kernel + debian fixes. But 2.5/2.6 include IPSEC in the vanilla kernel! Jim Penny
Re: music sheet
On Tue, 9 Sep 2003 08:14:59 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. - Matt The problem, amazingly enough, is that he did google for dueling banjos sheet music, and Debian is the number one and number two hit! This has become a self-perpetuating google-flop. People google, google points them to Debian to get this sheet music, and the act of asking reinforces google's notion that debian is a good place to get the music! Jim Penny
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Hmm, that is not the only reason, and maybe not the real reason. What about bones piles? Doesn't nethack do this partially so that levels from dead games could be reused in future games? On a multi-user system, you get a better set of bones piles, because you have no idea of what killed the adventurer, and probably no idea of whether anything is worth picking up and risking the possibility of a curse. Jim Penny who has in past lives spent far too many hours playing nethack
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, 30 Jul 2003 11:38:12 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2003 at 05:56:32PM +0200, Emile van Bergen wrote: I object to this ITP. Not very strongly, but I still object. I think it's a wonderful idea to have a decss package in Debian. If Debian cannot distribute the decss that allows Debian users to view DVD movies (yet), then distributing this one is a good alternative, I'd say. You're clearly quite mad. Regardless of whether this script is trivial to implement, it's not something anyone should be encouraged to actually*use*. CSS is the *best* feature of the HTML4 standard. Why would anyone in their right mind wish to strip nearly all the logical structure markup out of a document? Uhh, it is to tweak the international copyright cartel, and the RIAA in particular. They have written cease and desist letters to anyone who has a file names deCSS on their system. This is an attempt to make such a filename so common that these letters are pointless, and possibly evidence of illegal activity. Jim Penny
Re: Debconf or not debconf
On Wed, 02 Jul 2003 22:25:26 +0200 Thomas Viehmann [EMAIL PROTECTED] wrote: Jim Penny wrote: Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. What is difficult to test in ssl connections fail? I routinely test mine with telnet-ssl or python scripts (though I remember something about python and IMAP SSL not too long ago)... Well, you have to have a place to launch the scripts from. It the tunnel is at the edge, and listening only to the outward-facing interface, or it is listening only to localhost, and you don't want to have the testing tools on your firewall, or ... Also, the silentness would IMHO be better fixed by adding a big fat NOT to the init script (although anything more than a NOT will be controversial as well...). Reminds me of something I should fix for my packages... This is a completely different complaint, more of an aside that should never have been raised here. It has nothing to do with the change in format of configuration information, debconf-ing or not debconf-ing. It has to do with the experience of making repeated changes to the configuration file, while feeling under some time pressure, running/etc/init.d/stunnel restart, seeing no output, and thinking silence is golden. You know, the usual Unix tradition. Jim Penny
Re: Debconf or not debconf
On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. Jim Penny -- Steve Langasek postmodern programmer
Re: Debconf or not debconf
On Wed, 2 Jul 2003 15:57:01 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Jul 02, 2003 at 10:50:29AM -0400, Jim Penny wrote: On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. While it is indeed preferable to not break things, there are times when avoiding breakage is quite difficult. This appears, to me, to be one of those times. I was aware of the issue, because I had looked at the upgrade for Windows users. I still got mildly bitten by this upgrade. I would prefer to have a hard stop message. Jim Penny
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? No, actually, that is ambiguous. Read literally, it means that only software source similar to GNU Autoconf can be configured with this tool. You really mean: A tool, similar to GNU Autoconf, for configuring software Admittedly this is ugly. It may also be really inaccurate. I have no idea of how similar to GNU Autoconf the tool is. I hope that it is not very similar at all. Perhaps: A tool to configure software (GNU Autoconf also has this purpose) Jim Penny
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 15, 2003 at 10:43:50PM +0200, Bj?rn Stenberg wrote: Matthias Urlichs wrote: Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Note that the version shown is simply the current libgcc.so version. Current as of when? When the upload was done? Current at package build time, that is when dpkg-shlibdeps is run. dpkg-shlibdeps has no idea whether an older version would be sufficient, so it plays safe. Isn't this a problem? Especially for packages depending on libraries with long release cycles, such as libgcc1 and libc6. Not often. Most slow release libraries are strongly backwards compatible. When it does become a problem, it can be terrible for a few weeks. Lots of packages need to be rebuilt. Unstable becomes, well, unstable. Then things get back to the normal level of chaos. Jim Penny Note: I don't have a suggestion for a better method right now, I'm just trying to understand the implications of the current system. -- Bj?rn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Tue, Dec 10, 2002 at 05:18:38PM -0500, Branden Robinson wrote: On Thu, Dec 05, 2002 at 08:33:08PM -0600, John Hasler wrote: However, if that data can only be usefully expressed in precisely that way (that is, reverse-engineering those algorithms would regenerate the file) then the copyright on the file is probably unenforceable. Exactly. If there is no possibility for original expression within the technical constraints imposed, one has no ability to generate the sort of work which copyright is designed to protect. about 48 or more scripts are encoded. ASCII was frozen. That leaves 47! ways to order the scripts (and they did not choose alphabetic by english name). Latin alone has 840 code points (characters). Even given that there is a traditional ordering in the portions of this, there are other big spans that have no natural order. Bunch more choices made here. Then, each character has a potential of 22 binary properties, (not derived from UnicodeData.txt, but in a separate file PropList.txt), and 14 fields, most of which have 20 to 256 or more options. I would venture to guess that even with a perfect oracle, it would be essentially imposible to reverse engineer the Unicode data files, much less the ancillary algorithms. That is, a 32 bit search space with at least 36 properties to be discovered per data point is whopping big. Jim Penny
Re: location of UnicodeData.txt
On Fri, Dec 06, 2002 at 08:12:57AM -0600, John Hasler wrote: Thomas Bushnell writes: The copyright is on the *file* and not on the data,... Did I say it was? ...and certainly not on the *information* which the file contains. An instantiation of that information could be considered a derivative of the copyrighted work. My second paragraph explains one reason why it might not be. A couple of URLs of interest: http://lxr.mozilla.org/seamonkey/source/intl/unicharutil/tools/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/unicode/makeunicodedata.py?rev=1.17content-type=text/vnd.viewcvs-markup Both show that these projects (at least) are mechanically deriving their internal unicode tables from UnicodeData.txt. Jim Penny
Re: location of UnicodeData.txt
But they clearly do not want you to modify anything, including character name! Character name is a searchable field, which some applications may need. It's an English field, for which there is a canonical translation for French, and there should be translation for other languages. But, on the unicode stability policy page http://www.unicode.org/unicode/standard/stability_policy.html it says: The character names are used to distinguish between characters, and do not always express the full meaning of each character. They are designed to be used programmatically, and thus must be stable. In some cases the original name chosen to represent the character is inaccurate in one way or another. Any such inaccuracies are dealt with by adding annotations to the character name list (which is printed in the Unicode Standard and provided in a machine-readable format), or by adding descriptive text to the standard. Note: It is possible to produce translated names for the characters, to make the information conveyed by the name accessible to non-English speakers. Hmmm. What does that mean? Are translated names to be annotations, descriptions, character names, or are they maintained in a separate table? How do you use the name programmatically if you don't know the language they are in? I did some googling, but could not find the French trasnlation files. Is there an URL? Jim Penny
Re: location of UnicodeData.txt
If a system simply declared a section of data to be UniCode data, and made no attempt to comprehend the contents, it probably would not need to have access to the contents of Unicode.txt. Just like if a system simply declared a section of data to be code complaint to Fortran-2026, and if it made no attempt to comprehend it, it wouldn't need access to the contents of that standard. A text-processing program that needs to display data is going to need the contents of UnicodeData for BiDi. A proper cut program should use UnicodeData, so it doesn't seperate a character from a subsequent combining character. A spell program is going to need the data to know which characters end words. Anything that handles text in a way more complex then cat will access to this data. OK, now, supposing that the unicode license is found to be non-DSFG free, and hence that UnicodeData.txt is non-free. Suppose a program implements either unicode collation, regular expressions, or any of the other things mentioned above. (collation is at: http://www.unicode.org/unicode/reports/tr10/, regular expressions are at http://www.unicode.org/unicode/reports/tr18/) Can the program be in debian main? In other words, does the program require ... non-free packages or packages which are not in our archive at all for ... execution? Jim Penny
Re: location of UnicodeData.txt
On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote: On Sat, Nov 30, 2002 at 12:35:25PM -0500, Jim Penny wrote: I think you are missing the points here. First of all, DFSG applied to the standard does not want to change the standard, but wants all to be able to change the text of the standard. Huh? If I change the text of the standard, I have changed the standard! No you haven't, only the standards body in question can do that. The above is in the context of people wanting to be able to change the unicode.txt file(s). This file cannot be changed without producing something that differs from the standard. Correcting it produces an artifact that is distinct from the standard. Is that unclear? There are all sorts of reasons why you might wish to create derivative works based on the standard -- a new standard for a different purpose, for example. Derivative works are covered by copyright. Period. I would advise that you not base a defense of infringment of copyright on the fact that you have only used it to create a derivative work. Or helpful documentation of the standard for people who are intimidated by the 'dry' nature of the original... This, on the other hand, would probably be regarded as fair use, especially as you would need only illustrative snippets to create such documentation. In normal circumstances, embedding the entire table in your documentation would likely not be regarded as fair use, but that is a fact based pattern that would have to be decided on a case by case basis. In this case, it is arguable that the Unicode Consortium's license specifically permits inclusion of the entire table, as it does permit unlimited extraction. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Engage brain. Do you think that if I want to create a competitor to, say, GNU Emacs, that I should expect to have to start from scratch? Or fetchmail? Or any one of the thousands of DFSG-free packages that are in main? Brain engaged. OK, according to you, anyone can make a competitor to GNU Emacs and may use the GNU emacs code. Great. So, now consider microsoft visual gnu emacs, which is released under the MS-EULA. If that seems to fail to capture your meaning, then well, suppose I think that the GPL sucks, and that BSD is the one true license. Can I the create FreeOpenBSDGNU emacs with a BSD license (as a derivative work)? What's that? Oh, you mean that anyone may produce a derivative work that is licensed in a manner compatible with the original work's license, provided the original license specifically grants that right? Oh. Yes, I agree with that. Stated in those terms, it is not much of a surprise. Now, where in the Unicode license does it give you permission to create derivative works? The license does say Information can be extracted from these files Oh, and you have to provide an accompanying notice indicating the source. The license does not say that any of the information in files provided by the Unicode Consortium can be modified (except by extraction). This makes it fail DSFG guideline 3. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Tomorrow will be cancelled due to lack of interest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Sun, Dec 01, 2002 at 11:10:09AM +0100, Bernhard R. Link wrote: * Jim Penny [EMAIL PROTECTED] [021130 18:43]: Huh? If I change the text of the standard, I have changed the standard! For example, if I have : 0332;COMBINING LOW LINE;Mn;220;NSM;N;NON-SPACING UNDERSCORE and change this to 0332;NON-COMBINING LOW LINE;Mn;220;NSM;N;SPACING UNDERSCORE Then the standard has been changed! That is, this file is line after line of character number assignment, followed by character name, (and other information). There is no possible change that does not change the standard! Hint: (from standard writer's viewpoint) - A standard that can be changed by anyone, at anytime, without notice and consultation is not a standard, especially if it is a contentious standard that has some people seriously upset (i.e, Russian and XJK users). You seem to understand less and less. If the text is changed, it is no longer the standard. (A standard can not be changed changing the text, as the standard is not a local file, but the unmodified text). So, can a standard be DSFG free? What the licence of a standard file may resonable demand is that no changed text pretends to be the unmodified standard. They can demand more than that, a lot more. All of copyright law comes to bear (if the standard is deemed copyrightable and has been copyrighted.) In particular, the owner of a copyright has, unless waived, control over the right to distribute derivative works. The text of every standard that I know of is modifiable. However, it normally takes the consent of the standards body and is issued under its aegis. Again, Jim Penny's unicode standard has no value, and even debian unicode has very limited appeal. You are again talkin of the standard. Not the text of the standard. A standard body can issue a new standard. And trademark laws and other things can force any new XYZ standard for UVW to be issued by some special entity. Look at the file! UniCode.txt is the core of the standard, it happens to be an ASCII text file. So what, every standard is embodied in text at some point! You seem to regard standards as some Platonic ideal, completely divorced from the text which defines them. This may be a valid viewpoint in some cases; e.g. the original algol-60 report. It is not in other cases, e.g. the algol-68 report. UniCode.txt is a text file which has no redundacy and no explanatory text. There is simply no portion of this file that can be modified without making an artifact that differs from the standard in some substantive way. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Now, IANAL, but I suspect that any unicode editor that reproduced enough information from the unicode standard to be useful would be considered a derived work. More importantly, I think that is is arguable that this table is, in the terms of the Debian Social Contract, necessary for the execution of a full unicode editor. (The language of the debian Social Contract is even more general and vague than copyright law! It talkes about and to freely use the information supplied in the creation of products supporting the UnicodeTM Standard. If this does not include making modifications, then jurisdiction is more broken then I ever thought. (In my eyes the information should even not be copyrightable at all, but this point may be discussed). The license permits extraction of information for documentation or programs. This may be completely different from modification or correction of information. In either case, the social contract would place the unicode table into non-free; and any editor that depended on the table, or information derived from the table (in a copyright sense) in either non-free or contrib. The table itself may be non-free. I doubt any editor will use the file itself but use modification suitable for the program. I have no problem with this result. But saying that the unicode character table cannot be distributed by debian, in spite of specific language permitting us to do so, seems a bit extreme. If it does not suit for main, then it can not be distributed as part of debian. (by definition) But is can be distributed by debian, not as a part of debian. That is, it may be put in non-free, and it may be distributed using the debian mirrors. Note: I did not use the phrase part of, that is yours. And the consequences of this decision will probably seem extreme to many people. This example just happens to be particularly cogent; there is no doubt it is non-free, there is no doubt it is copyrightable, there is little doubt that it is necessary for the execution of a substantial corpus of programs
Re: location of UnicodeData.txt
On Mon, Dec 02, 2002 at 07:30:57PM +0200, Richard Braakman wrote: On Mon, Dec 02, 2002 at 11:16:07AM -0500, Jim Penny wrote: On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote: There are all sorts of reasons why you might wish to create derivative works based on the standard -- a new standard for a different purpose, for example. Derivative works are covered by copyright. Period. I would advise that you not base a defense of infringment of copyright on the fact that you have only used it to create a derivative work. Umm, yes. That's exactly why the text of a standard should be free. You seem to be confusing the should be and is discussions. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Engage brain. Do you think that if I want to create a competitor to, say, GNU Emacs, that I should expect to have to start from scratch? Or fetchmail? Or any one of the thousands of DFSG-free packages that are in main? Brain engaged. OK, according to you, anyone can make a competitor to GNU Emacs and may use the GNU emacs code. Great. So, now consider microsoft visual gnu emacs, which is released under the MS-EULA. You seem to have hit the wrong button when you tried to engage your brain. Why would create a competitor have to mean create a competitor under a conflicting license? The GNU Emacs license allows you to create a competitor without starting from scratch. That is what makes it free! The question above did not specify that the competitor was to be GPL licensed. In the universe of GPL licensed programs, you are indeed free to create a competitor using code incorported from GNU emacs; in fact, the universe of DFSG licenses was specified. In the universe of DFSG licensed programs, you are not free to create a competitor using incorporated code, in particular, you cannot create a BSD licensed version of GNU emacs using derived code. (And if BSD licenses were allowed, then so would the MS-EULA license, by washing the GPL through the BSD license.) What's that? Oh, you mean that anyone may produce a derivative work that is licensed in a manner compatible with the original work's license, provided the original license specifically grants that right? Oh. Yes, I agree with that. Stated in those terms, it is not much of a surprise. I don't think he meant that at all. You're confusing may with should expect to be able to. The whole provided... clause misses the point. Laws do not define morality. This is straying terribly far from field, but are you saying that it is morally correct that the debian project modify standards without permission of the standards body? Or that it is morally correct to incorporate (portions of) other programs in your work unconditiontally and without permission of the original creators? Are you saying that if the FSF brings a suit alleging GPL violation, that this suit is immoral? If your answer to any of these is yes, then your morality is very different from mine. Now, why do you think that it would not be a good thing for the text of the text of the Unicode license to be free? Your only answer so far seems to be because it currently isn't. 1) that is a good enough answer to make a determination on whether it is part of non-free, contrib, or main. 2) It is an embodiment of years of work by many people who did not agree that it should be free (in DSFG terms). 3) I can think of no value in a standard that is DFSG free. The purpose of a standard is to ensure interoperability. If there first has to be a discovery phase to determine how my standard deviates from your standard, interoperability is reduced if not destroyed. This is not to say that standards should not permit extension. Most do. However, even this has been controversial in the past (Microsoft Kereboros, for example). Jim Penny Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Mon, Dec 02, 2002 at 10:43:42AM -0800, Thomas Bushnell, BSG wrote: Jim Penny [EMAIL PROTECTED] writes: Now, where in the Unicode license does it give you permission to create derivative works? The license does say Information can be extracted from these files Oh, and you have to provide an accompanying notice indicating the source. The license does not say that any of the information in files provided by the Unicode Consortium can be modified (except by extraction). This makes it fail DSFG guideline 3. What about the null extraction, done by using the extraction tool named cat? As far as I can tell, this is permitted. It would not be permitted under normal copyright law, but the license does permit arbitrary extraction. Extraction of the entirety still appears to be extraction. What the Unicode Consortium does not say is what the distribution rights are relative to the subsetted tables. This is a license weakness, but I suspect that any sane judge would hold that giving permission to do the extracting implies giving permission to distribute the result. But, I suspect that any sane judge would also say that extraction for the purpose of license laundering is not implied. That is, you could not take the Unicode Consortium's file, apply cat to it, and relicense the result under BSD (for example). Now, what is Unicode Consortium really saying here? They are saying that you are allowed to use subsets of Unicode. For example, you may be interested in only a few languages. You may select the relevant portions of the table out. Or, if you know that you don't care about bidirectionality, ligation, extenders, grapheme link, or any of the other various and sundry attibutes, you may drop them. In other words, you can do either row or column projection if that is advantageous to you. But they clearly do not want you to modify anything, including character name! Character name is a searchable field, which some applications may need. Jim Penny -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of UnicodeData.txt
On Fri, Nov 29, 2002 at 11:37:41AM +0100, Bernhard R. Link wrote: * Jim Penny [EMAIL PROTECTED] [021128 03:35]: So, according to Branden, international standards are supposed to allow debian the right to modify them and to distribute the modified versions. Absent said permission, which is hardly ever going to be given, they must be considered non-free. (This is, of course, logically forthright.) Moreover, according to the non-free removal proponents, we should not even distribute the un-modified copies of these files. Yet, unicode is supposed to be the canonical character encoding scheme for debian. Does this mean every unicode text editor belongs in contrib (depends on something non-free)? I think you are missing the points here. First of all, DFSG applied to the standard does not want to change the standard, but wants all to be able to change the text of the standard. Huh? If I change the text of the standard, I have changed the standard! For example, if I have : 0332;COMBINING LOW LINE;Mn;220;NSM;N;NON-SPACING UNDERSCORE and change this to 0332;NON-COMBINING LOW LINE;Mn;220;NSM;N;SPACING UNDERSCORE Then the standard has been changed! That is, this file is line after line of character number assignment, followed by character name, (and other information). There is no possible change that does not change the standard! Hint: (from standard writer's viewpoint) - A standard that can be changed by anyone, at anytime, without notice and consultation is not a standard, especially if it is a contentious standard that has some people seriously upset (i.e, Russian and XJK users). This is a good thing, the text of standards should be modifiable. How else shall someone write the following standard without having written the first or having to write all from scratch? The text of every standard that I know of is modifiable. However, it normally takes the consent of the standards body and is issued under its aegis. Again, Jim Penny's unicode standard has no value, and even debian unicode has very limited appeal. On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Secondly: What has a unicode editor have to do with the unicode standard? It should only implement it. If it would contain parts of the standard-text (tables or whatever) that were protected by copyright law and the standard would allow no modifications, then noone would be allowed to copy the editor. (No special problem with debian) A unicode editor must know certain properties of the character set (note, I am not talking about font properties here, unicode does not deal with fonts.) Examples might be langauge, combining marks, bidirectionality, input methods, surrogates, Hangul syllables. These are things that an editor must know, and that pretty much, must be looked up in the unicode table. Now, the unicode license happens to be fairly clear, and fairly permissive. See: http://www.unicode.org/Public/UNIDATA/UnicodeCharacterDatabase.html It specifically gives permission for redistibution, without fee, providing a statement of copyright, and a disclaimer are preserved. It also specifically allows incorporation into programs under the same terms. But those terms happen to be non-DSFG free. They fail 3 and 8. Now, IANAL, but I suspect that any unicode editor that reproduced enough information from the unicode standard to be useful would be considered a derived work. More importantly, I think that is is arguable that this table is, in the terms of the Debian Social Contract, necessary for the execution of a full unicode editor. (The language of the debian Social Contract is even more general and vague than copyright law! In either case, the social contract would place the unicode table into non-free; and any editor that depended on the table, or information derived from the table (in a copyright sense) in either non-free or contrib. I have no problem with this result. But saying that the unicode character table cannot be distributed by debian, in spite of specific language permitting us to do so, seems a bit extreme. And the consequences of this decision will probably seem extreme to many people. This example just happens to be particularly cogent; there is no doubt it is non-free, there is no doubt it is copyrightable, there is little doubt that it is necessary for the execution of a substantial corpus of programs which are otherwise DFSG free. These program would certainly include unicode editors, and would probably include python, perl and ruby. Jim Penny Hochachtungsvoll, Bernhard R. Link -- gEistiO sagen wir mal...ich hab alle sourcen in /lost+found/waimea me gEistiO: [...] Warum lost+found? gEistiO wo haette ich es denn sonst hingeben solln
Re: location of UnicodeData.txt
On Wed, Nov 27, 2002 at 03:54:35PM -0500, Branden Robinson wrote: On Wed, Nov 27, 2002 at 07:59:00PM +0200, Richard Braakman wrote: On Wed, Nov 27, 2002 at 08:50:10AM -0800, Thomas Bushnell, BSG wrote: Heh. There's another: miscfiles: /usr/share/misc/unicode.gz The current version is Unicode 3.1.1. According to http://www.unicode.org/Public/UNIDATA/UnicodeData.html there's a version 3.2. Hmm, is this file Free? There's a license on that same page: This is a question for -legal, FYI. Limitations on Rights to Redistribute This Data Recipient is granted the right to make copies in any form for internal distribution and to freely use the information supplied in the creation of products supporting the Unicode^TM Standard. The files in the Unicode Character Database can be redistributed to third parties or other organizations (whether for profit or not) as long as this notice and the disclaimer notice are retained. Information can be extracted from these files and used in documentation or programs, as long as there is an accompanying notice indicating the source. I see no problem with this license as far as it goes, but it doesn't go far enough. There is no permission granted to make modifications (and distribute modified versions). (DFSG 3) So, according to Branden, international standards are supposed to allow debian the right to modify them and to distribute the modified versions. Absent said permission, which is hardly ever going to be given, they must be considered non-free. (This is, of course, logically forthright.) Moreover, according to the non-free removal proponents, we should not even distribute the un-modified copies of these files. Yet, unicode is supposed to be the canonical character encoding scheme for debian. Does this mean every unicode text editor belongs in contrib (depends on something non-free)? What an interesting anecdote! Jim Penny
Re: location of UnicodeData.txt
On Wed, Nov 27, 2002 at 04:53:00PM -0500, Branden Robinson wrote: On Wed, Nov 27, 2002 at 04:23:51PM -0500, Jim Penny wrote: I see no problem with this license as far as it goes, but it doesn't go far enough. There is no permission granted to make modifications (and distribute modified versions). (DFSG 3) So, according to Branden, international standards are supposed to allow debian the right to modify them and to distribute the modified versions. Moreover, according to the non-free removal proponents, we should not even distribute the un-modified copies of these files. I cannot speak for all proponents of the proposed GR, but yes, that's my understanding. Yet, unicode is supposed to be the canonical character encoding scheme for debian. I don't see that in the current version of the Policy manual, but it wouldn't surprise me if we were to standardize on Unicode, since it seems to be the best-of-breed in the character set department. Does this mean every unicode text editor belongs in contrib (depends on something non-free)? Many (perhaps all) RFCs are non-free as well; does that mean that compliant implementations must go into contrib or non-free? I notice that you did not answer. As far as I can tell, given the current definition, the logically coherent answer is yes. There is some wiggle room in this. See below. What an interesting anecdote! I do not grasp what place emotionalism has in a simple, coolheaded discussion of licensing. If you are upset with the ramifications of the DFSG, you can always propose a General Resolution to amend its terms, or repeal it entirely, perhaps in favor of something more pragmatic. Anecdote. A particular fact of an interesting nature. Incidentally, is there a reason you did not respect the Mail-Followup-To header? Yup, the anecdote had nothing to do with legal. Had a lot to do with the ramifications of the more radical interpretations of the DFSG and the consequences of these interpretations. It was interesting to see you argue that a license was non-free. To be consistent with the GR, you should have been observing that it could not be a part of debian. If there is a point in this, it is that the status quo ante allows some wiggle room. In particular, section 5 of the social contract grants this. If you remove section 5, and reduce debian to only things that have a DSFG license, the resulting axiomatic system can be used in interesting ways. In particular, recursive application of the axioms is very intersting. Can an artifact that claims to be compliant with a non-DSFG free standard itself be considered to be free? That is, does it depend on the standard for its execution? Compare and contrast this with an installer of a non-free package. Note: the typical installer can, in fact, install an infinite number of items -- after all, most installers are not strongly version dependent! Jim Penny Note: there is an intentional ambiguity of the word debian above, which will drive some fundamentalists crazy. My definition of debian: the totality of software, documents, and other artifacts produced by debian developers and contributed to the debian archives.
Re: Pick a name, any name...
On Wed, Nov 27, 2002 at 05:34:20PM -0800, Sean 'Shaleh' Perry wrote: On Wednesday 27 November 2002 02:03, Roland Mas wrote: Current candidates include: hey how about something much less cryptic like forge. Nothing worse than having to guess what woman's name some silly coder named the program I am looking for. On the other hand, if you want truly obscure, here are some suggestions: Norse: Magni As Magni and Modi grew older, they learned many things from the dwarves, whom they would often visit. When Modi came of age, he took it upon himself to teach man how to forge and fashion bronze. Magni continued to learn things from the dwarves; and after learning many things, took it upon himself to teach man how to forge and fashion iron. Note: learned from dwarfs; positive association with magnificent. Norse: Draupnir Draupnir was a golden ring (or belt, there seems to be some confusion), that had the property that every ninth day 8 gold rings of equal weight dropped from it. Note: No special special affiliation with forges, just a promise of riches. Gaulish: Belisama The Gaulish/Celtic goddess of light and fire, the forge and of crafts. Note: sounds kind of like bellissimo. Hawaiian: Pele The Hawaiian (Polynesian) goddess of the fire in the volcano, the mother of eruptions. She is a ravishing, whimsical goddess who resides in the volcano Kilauea on Hawaii. Note: no special affinity with forges, but mother of eruptions (and flame-wars?) seems appropriate. Aztec: Veveteotl God of fire and creativity. Darkover: Sharra The most dangerous matrix on all Darkover was the legendary Sharra. Embodied in the image of a chained woman, wreathed in flames, it was the last remaining weapon of the Ages of Chaos that had almost destroyed civilization on the planet of the Bloody Sun. Then again, forge seems much safer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 03:25:01PM +0200, Laura Creighton wrote: On Aug 06, Torsten Landschoff wrote: As the new upstream of python-gnome (for GNOME 2) needs python 2.2 for building I am wondering when python 2.2 will get the default version for Debian. Any insights? I believe a consensus was reached on debian-python that we would move to Python 2.3 as the next default Python, skipping 2.2 entirely. My recommendation would be to separately maintain a python 2.2-compatible python-gnome and a 2.1 compatible version, at least until the 2.3 release. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 The new Python Business Forum (www.python-in-business.com) is collaborating with the Python developers to produce Python-in-a-Tie, a business-targetted release of Python. This is a 'Sumo-Release', which will include other useful Python libraries and programs which are not part of the standard Python releases. What we want is a release we tell our cyustomers to run which will give them 18 months or so during which there is no need for them, as users, not developers, to upgrade a to a newer version of Python. Then we will target a next release, and to be the next Python-in-a-Tie. I am the Chairman of the Python-in-a-Tie SIG, and the Python-in-a-Tie release is going to be based on 2.2, not 2.1 or 2.3. Thus 2.2 is the release which we are telling Python developers is the release which they should write for. Therefore I think that skipping the 2.2 release in favour of the 2.3 would be a mistake. Please cc any discussion and replies to me since I do not read debian-devel. Thanks very much, But, this does not say that python2.2 will not be available. It is, and, as far as I know, will continue to be. I think that the general consensus was that debian would maintain whatever versions we had to, if Python-in-a-Tie were packaged in debian, it would mark python2.2 as a requirement, and until said package was either rewritten to use python2.3+, or removed from the archive, it would be impossible to remove python2.2. Nor is it much of a pain for a developer: scripts being /usr/bin/python2.2, rather than just /usr/bin/python. Your group does not even need to be aware of this; this is something the debian developer should be taking care of. There has been dicussion of removing python1.5. But this is because there are very few packages left that depend on it. Debian does not historically remove packages easily or without thought. Jim Penny Laura Creighton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 11:02:18AM -0400, Guido van Rossum wrote: Thanks for the post, Laura. I agree -- Python 2.3 won't be ready for a long time, and I recommend to the Debian folks that they standardize on Python 2.2. For now, that will be Python 2.2.1; a maintenance release, 2.2.2 will be issued some time later this year. But Zope 2.5, one the more popular applications, requires 2.1.3. Can we be more aggressive in changing default versions than Zope? Jim Penny I don't expect 2.3 to reach maturity until mid 2003. --Guido van Rossum (home page: http://www.python.org/~guido/) [Context:] snipped.
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 02:54:31PM -0500, Chris Lawrence wrote: On Aug 14, Laura Creighton wrote: The new Python Business Forum (www.python-in-business.com) is collaborating with the Python developers to produce Python-in-a-Tie, a business-targetted release of Python. This is a 'Sumo-Release', which will include other useful Python libraries and programs which are not part of the standard Python releases. What we want is a release we tell our cyustomers to run which will give them 18 months or so during which there is no need for them, as users, not developers, to upgrade a to a newer version of Python. Then we will target a next release, and to be the next Python-in-a-Tie. I am the Chairman of the Python-in-a-Tie SIG, and the Python-in-a-Tie release is going to be based on 2.2, not 2.1 or 2.3. Thus 2.2 is the release which we are telling Python developers is the release which they should write for. Therefore I think that skipping the 2.2 release in favour of the 2.3 would be a mistake. Please cc any discussion and replies to me since I do not read debian-devel. Thanks very much, Laura: (and Guido et al.) Debian plans to support at least Python 2.2 and 2.3 in the next release (sarge); unlike other distributors, we do not have a problem with making multiple Python versions available so long as they are useful. If you need to target a specific release of Python (i.e. 2.2), you should use #!/usr/bin/env python2.2. However, the *default* Python shipped by Debian (i.e. /usr/bin/python) affects things within our distribution, and there may be wins for us basing on 2.3 rather than 2.2 (the enumerate builtin being an obvious, immediate example; universal newline support may also be important). Now, if 2.3 won't be stable until well into next year (as opposed to the schedule in PEP 283), then we may want to target 2.2.x as our default version. This is something that largely depends on our anticipated release schedule - which is not very calendar driven, but Q2 2003 is less likely to make sarge than Q4 2002. (Note that debian-python is probably the most appropriate list for followups.) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ One final point. We will almost definitely not switch the default python in sid (current unstable), until there is talk that Sarge is nearing a freeze. There is simply no point in undergoing the pain of a major python release twice in a single unstable cycle. We will instead make the decision of what python will be default in Sarge when it nears release, not now. Current stable, woody, is shipping with 2.1 as default. That cannot be undone, it is released, and at the time the decision was made, 2.2 was way too close to the cutting edge for comfort. Moreover, we would not recommend that the target audience of Python-in-a-Tie run sid. Sid breaks things occasionally, sometimes badly. Sid tortures small defenseless things for a hobby! 2.2 is available in woody already. Invoke it using /usr/bin/python2.2. BTW: is the PIAT consortium going to offer any DSFG free software? Jim Penny
Postgres and non-us
PostgreSQL now has a dependency on openssl/ssl.h in a fundamental header file, postgresql/libpq-fe.h. Does this mean that every piece of software which requires this header file to compile will also have to be migrated to nonus? Jim Penny
Re: kernel-{image,headers} package bloat
I also do NOT like the kernels compiled for a huge number of systems. I do not think it helps either hotrodders or little old ladies from pasadena. Hotrodders can and should build their own, and lolfp's cannot tell which kernel they need (they do not know, or care if they have a 586 or a Pentium Classic, and probably think they have a Pentium, even if it is from AMD)! I am not even sure that initrd is all that great. I have looked in the man pages, in /usr/share/doc/kernel-doc-2.4.2, /usr/share/doc/kernel-image-2.4.2-pentiumiii-smp, on google, and in other places and have yet to see the answer to my questions. These are: 1) how do I boot from a non-IDE root disk? 2) How do I control what goes into initrd in a more reasonable way than nothing/most/all. (and what does most do, anyway?). Jim Penny
