Binaries and MIT/expat license interpretative tradition
(My question is not Debian-related, but I figured the people who know the answer read this list.) The usual interpretation (seen in the list archives) of the MIT/expat license seems to be the that the copyright notice needs to be retained in the source but does not have to be displayed by binaries. The license does not say that the binaries do not constitute a copy of the Software. What's the basis of the interpretation and that the copyright notices do not need to be grepped from the source and stuffed in an about box or similarly placed on binaries? I have written MIT/expat-licensed code thinking that I am not placing an obnoxious notice burden on binaries. Now I have to explain that I am not, and I can't just waive the notice requirement in cases where I am not the sole copyright holder. Should I switch to the zlib license for code that I can relicense? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Arnoud Engelfriet wrote: Interesting point. But the statement would apply certainly to Linus' own contributions. And that would preclude distribution of anything containing those contributions under anything but GPLv2 I think. But if you can take out his code (and any other that's GPLv2 only), you'd be free to apply GPLv3 if and when it comes out. Arnoud Sorry, but no, no, no. Everything that is not completely independent and extractable and beyond any doubt non-historically-derived of Linus code is a derivative work and, as such, can only be distributed under the terms of the GPLv2. To prove something not derivative, you would have to show that historically, it was made for other kernel, and that there is no tranformation of the linux kernel that resulted in that something. There *is* at least one example in the tree: the ppp code is derivative from one of the BSDs. So, you could take ppp and distribute under the BSD but not a lot else. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Glenn Maynard [EMAIL PROTECTED] writes: Such language is fine as long as the copyright holder and the license author are the same entity. New versions of the license are likely to reflect changes in the opinions of the authors, and they have every right to make provisions for a modified license to automatically apply to already released works. The danger arises when people start out-sourcing the writing of licenses to third parties. The FSF has its own agenda, and has little reason to consider the opinions of others, who just happen to use their license texts, when writing the next version. A couple years ago, this would all have been patently false. The FSF has a very strong interest in their notion of freedom being considered reliable, and having the community trust them to remain consistent There is no single the community, sharing a single opinion on freedom. There are many different views out there, and some recent moves from FSF have been in a direction away from a large enough number of people, with loud enough voices, to make it noticeable. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Sun, Mar 13, 2005 at 03:30:28PM +0100, Måns Rullgård wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: And probably it will also deal with running the code on a publicly accessible server. The question is if a license based on copyright can legally place such restrictions on use of the program. Some idea of how the FSF may attempt this can be seen from the Affero General Public License. Apparantly the Affero GPL is a modified version of the GNU GPL, it adds Section 2(d): * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. It also adds an interesting twist on the or later thing often used with the GPLv2: Affero Inc. may publish revised and/or new versions of the Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by Affero, Inc. If the Program does not specify a version number of this License, you may choose any version ever published by Affero, Inc. You may also choose to redistribute modified versions of this program under any version of the Free Software Foundation's GNU General Public License version 3 or higher, so long as that version of the GNU GPL includes terms and conditions substantially equivalent to those of this license. So, if you wish to use the AGPL, you as copyright holder can choose between AGPLv1 and AGPLv1 or later. But whichever you choose, you cannot remove the option to 'upgrade' to GNU GPLv3. -- Kuno. (ps. this is probably my first post to this list, so.. hi! everyone :). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Humberto Massa [EMAIL PROTECTED] writes: Arnoud Engelfriet wrote: Interesting point. But the statement would apply certainly to Linus' own contributions. And that would preclude distribution of anything containing those contributions under anything but GPLv2 I think. But if you can take out his code (and any other that's GPLv2 only), you'd be free to apply GPLv3 if and when it comes out. Arnoud Sorry, but no, no, no. Everything that is not completely independent and extractable and beyond any doubt non-historically-derived of Linus code is a derivative work and, as such, can only be distributed under the terms of the GPLv2. To prove something not derivative, you would have to show that historically, it was made for other kernel, and that there is no tranformation of the linux kernel that resulted in that something. There *is* at least one example in the tree: the ppp code is derivative from one of the BSDs. Some of the filesystems (XFS and JFS, at least) have external origins, although they must have been somewhat adapted to the Linux VFS layer. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Kuno Woudt [EMAIL PROTECTED] writes: On Sun, Mar 13, 2005 at 03:30:28PM +0100, Måns Rullgård wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: And probably it will also deal with running the code on a publicly accessible server. The question is if a license based on copyright can legally place such restrictions on use of the program. Some idea of how the FSF may attempt this can be seen from the Affero General Public License. Apparantly the Affero GPL is a modified version of the GNU GPL, it adds Section 2(d): * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. This appears to only apply to self-distributing programs. If the program does not have a send-the-source function, I don't see any requirement that source be provided to users of a service based on the program. It also adds an interesting twist on the or later thing often used with the GPLv2: Affero Inc. may publish revised and/or new versions of the Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. I've always wondered what similar in spirit is supposed to mean. AFAIK, that phrase has no established legal interpretation. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by Affero, Inc. If the Program does not specify a version number of this License, you may choose any version ever published by Affero, Inc. This looks similar to the language used in the GNU GPL. You may also choose to redistribute modified versions of this program under any version of the Free Software Foundation's GNU General Public License version 3 or higher, so long as that version of the GNU GPL includes terms and conditions substantially equivalent to those of this license. It would be interesting to see the reaction of these people, if the GNU GPLv3 does not include a source-for-service clause, after all. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Humberto Massa wrote: Everything that is not completely independent and extractable and beyond any doubt non-historically-derived of Linus code is a derivative work and, as such, can only be distributed under the terms of the GPLv2. You're correct in that anything that's a derivative work of any GPLv2 code also cannot be distributed under GPLv3 or later. But it's going to be very interesting to figure out what code is a derivative work of what. Anyway, this seems rather theoretical. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Arnoud Engelfriet wrote: You're correct in that anything that's a derivative work of any GPLv2 code also cannot be distributed under GPLv3 or later. But it's going to be very interesting to figure out what code is a derivative work of what. Anyway, this seems rather theoretical. Arnoud Yeah, but in a back-of-envelop calculation, to completely determine what code is derivative of what in Linux, one would take approximately 19 man-years. Maybe some automated way to study cvs.kernel.org changesets would shorten it up a bit, but ... ;-) Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the xbox scene is a sensible area?
On Mon, Mar 14, 2005 at 02:47:16AM -0500, Pascal Giard wrote: There's no way you can use xbgm# if you haven't modchipped or softmodded your xbox. So... what do you think? Well, there's no problem with copyright or freeness here. But we probably shouldn't distribute this in the US (at least without consulting a lawyer) given their absurdist DMCA behaviour. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Binaries and MIT/expat license interpretative tradition
On Mon, Mar 14, 2005 at 11:24:24AM +0200, Henri Sivonen wrote: (My question is not Debian-related, but I figured the people who know the answer read this list.) The usual interpretation (seen in the list archives) of the MIT/expat license seems to be the that the copyright notice needs to be retained in the source but does not have to be displayed by binaries. The license does not say that the binaries do not constitute a copy of the Software. What's the basis of the interpretation and that the copyright notices do not need to be grepped from the source and stuffed in an about box or similarly placed on binaries? The copyright notice does need to be included with the binaries. On Debian systems it is placed in /usr/share/doc/$package/copyright. This isn't a particularly strange or restrictive thing to require... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Linux and GPLv2
Kuno Woudt wrote: * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. Incidentally, this is pretty badly drafted, IMO. For example: - The requirement to not remove certain particular code is probably non-free; - The general requirement to make code available for download could be asserted without the don't remove code X clause; - Specifying HTTP is not future-proof, and may not be appropriate for some programs or environments; - What happens if the program interacts with other programs over a network? How do you define interacting with a user? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binaries and MIT/expat license interpretative tradition
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Mar 14, 2005 at 11:24:24AM +0200, Henri Sivonen wrote: (My question is not Debian-related, but I figured the people who know the answer read this list.) The usual interpretation (seen in the list archives) of the MIT/expat license seems to be the that the copyright notice needs to be retained in the source but does not have to be displayed by binaries. The license does not say that the binaries do not constitute a copy of the Software. What's the basis of the interpretation and that the copyright notices do not need to be grepped from the source and stuffed in an about box or similarly placed on binaries? The copyright notice does need to be included with the binaries. On Debian systems it is placed in /usr/share/doc/$package/copyright. This isn't a particularly strange or restrictive thing to require... This is different from the requirement of some licenses that a notice be displayed on the console, or in a dialog box, when the program is run. I think this is what the OP was afraid of. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL for documentation ?
Henning Makholm wrote: The word linking (or any of its forms) appears exactly once in the GPL, and that is in a non-legal, non-technical aside comment: | If your program is a subroutine library, you may consider it more | useful to permit linking proprietary applications | with the library. If this is what you want to do, use the GNU | Library General Public License instead of this License. Fair enough. Having read more widely on the subject, the problems of using the GPL specifically aren't nearly as great as I first thought. Thanks for taking the time to apply the cluestick :-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Sun, 13 Mar 2005 18:29:36 -0500 Glenn Maynard wrote: There's a more significant problem: if you say or later, and you don't like GPLv3--either because it allows things you don't like, or (as recent events suggest may be more likely) includes restrictions you don't like, people can take your work, modify it, and place their modifications under GPLv3-only. If you want to keep your code available under GPLv2, you can't incorporate those changes, since they're not available under v2. Considering that a primary motivator of the GPL is to prevent the case where you can't incorporate other people's enhancements to your work due to licensing, this seems like a potentially major failure. Indeed. [...] The or later gives the FSF more flexibility to change the license terms for a vast amount of software they really have no connection at all with, with or without the approval of the copyright holders of said software. The or later is intended, as I understand--from rational logic, as I don't believe I've seen any statement from the FSF--to allow the FSF to fix problems in the GPL. You've seen it, believe me! It's in the GPLv2 text itself! ;-) | 9. The Free Software Foundation may publish revised and/or new | versions of the General Public License from time to time. Such new | versions will be similar in spirit to the present version, but may | differ in detail to address new problems or concerns. ^^^ Without or later, it's impossible: the only way a bugfixed GPL could be used is after getting explicit permission from every copyright holder of a GPL work. Further, and just as importantly, the bugfixed GPLv3 would be incompatible with the original GPLv2! That would fragment the GPL at a fundamental level. Yes, at level that only dual licensing (which is what GPLv2 or later actually is) can cure... That would be fine, if the FSF had maintained its traditional consistency. Frankly, they broke that trust with the GFDL, and so I'd sympathise with people no longer willing to use the or later language. The above problem doesn't go away, though. Agreed entirely. The or later trick works as long as the FSF is trusted to actually fix problems and release better and better GPL versions. But I'm not sure that this trust is deserved any longer... :-( and :-(( and then :-((( -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJdE7XjSW0A.pgp Description: PGP signature
Re: Linux and GPLv2
On Mon, 14 Mar 2005 17:53:35 + Gervase Markham wrote: [about the don't remove get_source feature] - The requirement to not remove certain particular code is probably non-free; I don't think it's forbidding to remove the code: it's merely forbidding to drop a feature. You could reimplement it in a better (or even worse) way, but you must support it. Anyway I agree it's non-free. Suppose for example that my derivative work is intended for use on an embedded system with very limited hardware resources. I could fail to comply with my constraints, due to this prohibition to drop a functionality (in the meanwhile, perhaps, I'm distributing my derivative work separately, through my website, in both source and binary forms and even through Debian archives, since I'm a DD myself and have packaged my derivative work for Debian! Thus I'm a very good guy!). Obviously, this is a thoroughly hypothetical example (I don't write programs for embedded systems, IANADD, and, above all things, I wouldn't create derivative works of AGPL'd programs!) - The general requirement to make code available for download could be asserted without the don't remove code X clause; Yes, though I don't think such clauses could be made DFSG-free... :( - Specifying HTTP is not future-proof, and may not be appropriate for some programs or environments; Definitely agreed. - What happens if the program interacts with other programs over a network? How do you define interacting with a user? Who knows? I agree that this is very gray and unclear. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgproudW5yfWV.pgp Description: PGP signature
Re: Linux and GPLv2
Francesco Poli [EMAIL PROTECTED] writes: On Sun, 13 Mar 2005 19:14:09 -0500 Glenn Maynard wrote: [...] There havn't been any such bugs, though, fortunately. Some people don't like the PHP loophole or whatever you want to call it, but I don't believe that's fixable in a free license, Could you please elaborate on the PHP loophole? I've never heard of it: what do you mean by that? (feel free to change the subject or even to reply to me in private, if you think it's better) I'm also curious about this one. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Francesco Poli [EMAIL PROTECTED] writes: Could you please elaborate on the PHP loophole? I've never heard of it: what do you mean by that? It's the whole web-as-platform idea. Let's say I take a copy of latex (assuming for the moment that it were GPL, which it isn't IIRC), and I enhance it (maybe I integrate it with word somehow, under NDA) so that it is no longer remotely compatible with the standard latex, and then set up a web site offering a document processing service for a fee. I never distribute the program in binary form, so I never have to distribute code either. I'm therefore able to take advantage of all the work the latex tex folks have done without contributing my own changes back to the community -- or to the users of the software. A valid concern, arguably, even if it does hinge on certain ideas about how the computing field will evolve that I doubt will turn out to be accurate. But the only licenses we've seen so far that deal with this problem (if it is a problem) give up too much freedom in exchange. At least, IMHO. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Mon, Mar 14, 2005 at 05:53:35PM +, Gervase Markham wrote: Kuno Woudt wrote: * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. Incidentally, this is pretty badly drafted, IMO. For example: Add another one -- must offer an [...] opportunity for all users [...] to request immediate transmission by HTTP -- doesn't mean that the request must be successfully honoured... grin - Matt signature.asc Description: Digital signature
Re: Linux and GPLv2
On Mon, 14 Mar 2005, Jeremy Hankins wrote: Francesco Poli [EMAIL PROTECTED] writes: Could you please elaborate on the PHP loophole? I've never heard of it: what do you mean by that? It's the whole web-as-platform idea. This is commonly refered to as the ASP[1] loophole not the PHP loophole for the obvious reasons that the former describes the actual problem, whereas the latter is just a language that isn't restricted to usage by ASPs. Search for affero and asp loophole from somewhere around 2003 on -legal if you want more information on why closing this loophole is probably not possible to do in a free manner. Don Armstrong 1: Where ASP is application service provider. -- The solution to a problem changes the problem. -- Peer's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Mon, Mar 14, 2005 at 02:44:02PM +0100, Måns Rullgård wrote: There is no single the community, sharing a single opinion on freedom. There are many different views out there, and some recent moves from FSF have been in a direction away from a large enough number of people, with loud enough voices, to make it noticeable. Historically, the FSF had been very consistent, enough so that many people have been willing to trust the FSF to act in good faith with the will be similar in spirit to the present version of GPL#9. Given the relatively recent developments, we're in agreement, though. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Kuno Woudt [EMAIL PROTECTED] writes: On Mon, Mar 14, 2005 at 08:00:24PM -0500, Jeremy Hankins wrote: A valid concern, arguably, even if it does hinge on certain ideas about how the computing field will evolve that I doubt will turn out to be accurate. But the only licenses we've seen so far that deal with this problem (if it is a problem) give up too much freedom in exchange. At least, IMHO. Can you be specific on which licenses you think attempt to deal with this problem? So far I only know of the Affero GPL, which I already mentioned elsewhere in this thread, and I am curious how other license authors have attempted to fix this problem. The Affero GPL is the main one. Back when it came up on this list I think there was some discussion about possibly clauses that might serve the same purpose, but I don't think we came up with anything satisfactory. The APSL tries to do this, I think, through the use of the term externally deploy. I think it does a somewhat better job than the Affero license does, but is still subject to a lot of confusion about what sorts of things count as providing a service (which is part of the externally deploy definition). It's also not clear where it gets the legal authority to place restrictions on providing services that it does. Possibly by claiming that it would be a public performance. You can see the discussion in the archives, if you're interested. It was in August of '03 came up again in June of '04. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Kuno Woudt wrote: Can you be specific on which licenses you think attempt to deal with this problem? So far I only know of the Affero GPL, which I already mentioned elsewhere in this thread, and I am curious how other license authors have attempted to fix this problem. Larry Rosen's Open Software License also tries to cover this. In article 5 it defines External Deployment as follows: 5. External Deployment. The term External Deployment means the use or distribution of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be accessed or used by anyone other than You, whether the Original Work or Derivative Works are distributed to those persons or made available as an application intended for use over a computer network. This quite clearly is intended to cover usage on a website by an ASP. And then article 5 goes on to say: As an express condition for the grants of license hereunder, You agree that any External Deployment by You shall be deemed a distribution and shall be licensed to all under the terms of this License, as prescribed in section 1(c) herein. Article 1(c) is the you may distribute, but derivatives must be OSL as well article. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Mar 15, 2005, at 03:24, Kuno Woudt wrote: On Mon, Mar 14, 2005 at 08:00:24PM -0500, Jeremy Hankins wrote: A valid concern, arguably, even if it does hinge on certain ideas about how the computing field will evolve that I doubt will turn out to be accurate. But the only licenses we've seen so far that deal with this problem (if it is a problem) give up too much freedom in exchange. At least, IMHO. Can you be specific on which licenses you think attempt to deal with this problem? The license of POV-Ray 3.0 and 3.1 (free as in beer, source available; not free in the DFSG sense) addressed this issue in the section called ONLINE OR REMOTE EXECUTION OF POV-Ray. Charging for CPU time was allowed provided that the charge for POV-Ray CPU time was the same as for other CPU time. Obscuring the fact the POV-Ray was being run was prohibited. The users had to be provided with access to the files of the POV-Ray package. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
