Re: mutt no longer in non-us?
On Mon, 15 Nov 1999, Bruce Perens wrote: From: Brian Ristuccia [EMAIL PROTECTED] What has changed that allows us to distribute mutt from the US to people outside of the US despite the fact that mutt is capable of integrating with strong encryption software and thereby capable of performing strong encryption on messages it sends? This would also restrict vi and emacs. Each is capable of piping text through a random command. It would restrict the shell. It would restrict the kernel. It would restrict any program with source code. Can't help the government on this one, sorry. If they have a problem with it, we'll have to see them in court. Just to make clear I'm understanding the situation; does mutt have anything that could be interpreted as hooks to encryption, even if it doesn't have crypto code as part of the package? Or are scripts instructions on how to add crypto to the base product provided separately from a non-us package? If the former, unless something has changed, the U.S. considers that a crypto product. If the latter, you're OK. That's why vi/emacs/shells/kernels wouldn't be called crypto products, so long as they have no direct hooks themselves to encryption routines. Of course, if the U.S. recently said that hooks to crypto is OK, then that would be cool too. But this hook business is why we can't have SSL directives routines in the base Apache distrib, even if we told people to bring over OpenSSL separately. Brian
Re: mutt no longer in non-us?
On Thu, Nov 18, 1999 at 02:00:34AM -0800, Brian Behlendorf wrote: Just to make clear I'm understanding the situation; does mutt have anything that could be interpreted as hooks to encryption, even if it doesn't have crypto code as part of the package? Or are scripts instructions on how to add crypto to the base product provided separately from a non-us package? If the former, unless something has changed, the U.S. considers that a crypto product. If the latter, you're OK. That's why vi/emacs/shells/kernels wouldn't be called crypto products, so long as they have no direct hooks themselves to encryption routines. It will run pgp if you tell it to. It has the support for it if you choose to use it. But then arguably so does bash. Of course, if the U.S. recently said that hooks to crypto is OK, then that would be cool too. But this hook business is why we can't have SSL directives routines in the base Apache distrib, even if we told people to bring over OpenSSL separately. If you think about prime numbers near the Mexican borders the US could try to say you're exporting crypto. We made the decision that a simple run this seperate program and pipe output back to me cannot reasonably be considered encryption hooks. If such is allowed to be considered encryption we must also conclude that bash contains encryption hooks (as it too will optionally run pgp and read its output) and so would any program which may run any arbitrary binary and pipe its output someplace useful. And frankly speaking for only myself as a citizen of the US and not as a developer here, the US government can shove their crypto regs someplace unpleasant---I refuse to comply with them on the grounds that they are an affront to the protections guaranteed me under the first, fourth, and fifth ammendments to the constitution and further do place myself and my personal property at great risk when conducting wire-based transactions. My personal feelings aside for a moment, I agree Debian has to be careful where it treads. I am an individual and can do whatever the hell I want to and my actions affect myself alone. Debian OTOH is not an individual and its actions affect a much larger group. That said, however, I still believe Debian's decision to include support for the use of cryptography in mutt found in Debian's main distribution is correct. The software provides configuration file options which allow you to run any arbitrary program through standard functions used for running any and every program on the system and captures the results. This does not constitute hooks for encryption, though it arguably would if mutt were somehow linked with some library which provided cryptography functions. If the US government wants to challenge that (I suspect they're smarter than to try) it would be simple to demonstrate that the PGP interface in mutt is NOT a crypto hook. And that's before you consider the rediculous nature of the restrictions, but we don't even have to go in to that to prove there are no crypto hooks in mutt that don't exist in bash or in most every program for most any operating system for that matter. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- Knghtbrd xtifr - beware of james when he's off his medication = pgpZsqxcx1YfQ.pgp Description: PGP signature
Re: mutt no longer in non-us?
On Thu, 18 Nov 1999, Joseph Carter wrote: If you think about prime numbers near the Mexican borders the US could try to say you're exporting crypto. We made the decision that a simple run this seperate program and pipe output back to me cannot reasonably be considered encryption hooks. That's great, again, so long as the program itself doesn't mention encryption in its own code or docs. Signing is OK, as the gov't has said that they're only worried about encryption, not one-way hashes. This is the same reason why the SSL-tunnelling-through-regular-HTTP-proxy HTTP directive is CONNECT rather than something like SSL-PIPE. If such is allowed to be considered encryption we must also conclude that bash contains encryption hooks (as it too will optionally run pgp and read its output) and so would any program which may run any arbitrary binary and pipe its output someplace useful. Do the bash man pages describe how to use pgp to encrypt messages? And frankly speaking for only myself as a citizen of the US and not as a developer here, the US government can shove their crypto regs someplace unpleasant---I refuse to comply with them on the grounds that they are an affront to the protections guaranteed me under the first, fourth, and fifth ammendments to the constitution and further do place myself and my personal property at great risk when conducting wire-based transactions. I'd also like to make sure the debian.org machines don't get seized one day when the gov't gets a bug up their butt. Yes, it's likely that mutt won't be the critical factor here. But if you're going to willfully violate the common interpretation of the law, at least you should make sure everyone else is on board, such as the various Debian distributors. Brian
Re: mutt no longer in non-us?
On Thu, Nov 18, 1999 at 09:22:09AM -0800, Brian Behlendorf wrote: And frankly speaking for only myself as a citizen of the US and not as a developer here, the US government can shove their crypto regs someplace unpleasant---I refuse to comply with them on the grounds that they are an affront to the protections guaranteed me under the first, fourth, and fifth ammendments to the constitution and further do place myself and my personal property at great risk when conducting wire-based transactions. I'd also like to make sure the debian.org machines don't get seized one day when the gov't gets a bug up their butt. Yes, it's likely that mutt won't be the critical factor here. But if you're going to willfully violate the common interpretation of the law, at least you should make sure everyone else is on board, such as the various Debian distributors. Wouldn't seizing said machines violate the electronic communication privacy act or something similar by interefering with email on those machines as well? I'll personally go as far as to say interferance with the free distribution of software that I've written myself represents a severe and criminal violation of my civil rights. DJB seems to agree with me, but his case is still under appeal. But mutt isn't my software. And the interferance isn't directly affecting me. So I suppose the people involved and directly responsible should try to reach a consensus on this, and perhaps take it to a vote if neccessary. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: mutt no longer in non-us?
On Thu, Nov 18, 1999 at 09:22:09AM -0800, Brian Behlendorf wrote: If you think about prime numbers near the Mexican borders the US could try to say you're exporting crypto. We made the decision that a simple run this seperate program and pipe output back to me cannot reasonably be considered encryption hooks. That's great, again, so long as the program itself doesn't mention encryption in its own code or docs. Signing is OK, as the gov't has said that they're only worried about encryption, not one-way hashes. So since procmail comes with documentation for setting it up to process things with PGP it too must go into non-us or the offending documentation removed? Sounds like government infringement on the right to free press to me. If such is allowed to be considered encryption we must also conclude that bash contains encryption hooks (as it too will optionally run pgp and read its output) and so would any program which may run any arbitrary binary and pipe its output someplace useful. Do the bash man pages describe how to use pgp to encrypt messages? No, but some of the procmail docs talks about how to use pgp with it. It also talks about how to make an email based file server, among other things. And I'm almost positive they accompany our procmail package. And frankly speaking for only myself as a citizen of the US and not as a developer here, the US government can shove their crypto regs someplace unpleasant---I refuse to comply with them on the grounds that they are an affront to the protections guaranteed me under the first, fourth, and fifth ammendments to the constitution and further do place myself and my personal property at great risk when conducting wire-based transactions. I'd also like to make sure the debian.org machines don't get seized one day when the gov't gets a bug up their butt. Yes, it's likely that mutt won't be the critical factor here. But if you're going to willfully violate the common interpretation of the law, at least you should make sure everyone else is on board, such as the various Debian distributors. The fact is there is no interpretation of the law in the court system. However the government wants us to believe it means anything they want us to. I think we should quit trying to be paranoid about them coming after us for things they simply wouldn't and couldn't and worry about things that are serious problems. I frankly don't think the DOJ cares if our mutt package has the ability to be used with pgp. I further should point out that pgp shells have traditionally been considered exportable. Through the years I have never S citizen to download a pgp shell. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- Overfiend we're calling 2.2 _POTATO_?? pgpYB1C8PRNwP.pgp Description: PGP signature
Re: mutt no longer in non-us?
Brian Ristuccia writes: Wouldn't seizing said machines violate the electronic communication privacy act or something similar by interefering with email on those machines as well? The ECPA doesn't prevent police from seizing computer hardware when they have a warrant, although it would be fun if it did. I'll personally go as far as to say interferance with the free distribution of software that I've written myself represents a severe and criminal violation of my civil rights. DJB seems to agree with me, but his case is still under appeal. Professor Bernstein has taken a different approach, in that he has refrained from distribution of Snuffle (although it's available from various places now) and filed a lawsuit in which he seeks injunctions against prosecution. (He says that the _existence_ of certain regulations is a violation of his rights -- a facial challenge. It's amazing that he is succeeding so far, because courts rarely approve of such reasoning.) Your version seems to be to publish software and, if you are prosecuted or otherwise given trouble, argue that your rights have been violated. If Professor Bernstein continues to win his case, the precedent it sets could be very helpful for programmers in general -- who could try to use it to argue that government interference with the free software development process was grounds for a first amendment lawsuit. :-) -- Seth David Schoen [EMAIL PROTECTED] | And do not say, I will study when I http://www.loyalty.org/~schoen/| have leisure; for perhaps you will http://www.loyalty.org/ (CAF)| not have leisure. -- Pirke Avot 2:5
Re: mutt no longer in non-us?
On Thu, Nov 18, 1999 at 11:31:19AM -0800, Seth David Schoen wrote: Brian Ristuccia writes: Wouldn't seizing said machines violate the electronic communication privacy act or something similar by interefering with email on those machines as well? The ECPA doesn't prevent police from seizing computer hardware when they have a warrant, although it would be fun if it did. Hmm.. Looks like you may be right. Doies the ECPA offer hardware used to run a mail server any protection from civil asset forfeiture? -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: mutt no longer in non-us?
Joseph Carter wrote: The software provides configuration file options which allow you to run any arbitrary program through standard functions used for running any and every program on the system and captures the results. This does not constitute hooks for encryption, though it arguably would if mutt were somehow linked with some library which provided cryptography functions. Quoting a small fraction of 3.3 thousand lines of mutt code that constitue the interface to gpg/pgp: snprintf(cmd, sizeof(cmd), %s%s --no-verbose -v --batch -o - --digest-algo %s --encrypt%s --textmode --armor --always-trust %s%s, NONULL(binary), sign? --passphrase-fd 0:, gpg_digalg(), sign? --sign:, PgpSignAs? -u : , PgpSignAs? PgpSignAs : ); This goes well beyond running an arbitrary program. There is a large difference of degree between three thousand lines of code like this this and bash's generic exec() of a passed command. I still think mutt belongs in non-US. Why are people so opposed to putting it there? Putting a program like this in non-US just points out that the US government's laws are so brain-dead that they consider a mail reader a munition, thus raising public awareness of the problem. It doesn't inconvenience Debian much at all. The Debian mutt package also continues to ignore the wishes of mutt's upstream authors, who do belive mutt contains crypto hooks, and who only make the version available from outside the US for that reason. I think that Debian should obey the wishes of upstream authors whenever it is at all possible, and *must* comply with all local laws, however braindead. -- see shy jo
Re: mutt no longer in non-us?
It's too much of a slippery slope. Put something with 3000 lines of crypto hooks in non-US. Then 300 lines. Then 30. Then anything that runs exec(). Bruce
GPL source vs. binary
Does a source that's licensed under the GPL automaticly produce a binary that can only be licensed under the GPL? -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgpSsCiwCBaXj.pgp Description: PGP signature
Re: GPL source vs. binary
On Thu, Nov 18, 1999, Darren O. Benham wrote: Does a source that's licensed under the GPL automaticly produce a binary that can only be licensed under the GPL? Since a compilation is a translation into machine language, then the resulting binary can be considered a derivative of the Program, according to the GPL's section 0 (if I didn't miss anything there - IANAL). Thus I think it can only be licensed under the GPL, unless of course the author decides to release it under another license as well. Sam. -- Samuel Hocevar [EMAIL PROTECTED] - http://www.via.ecp.fr/~sam/ echo what is the universe|tr a-z 0-7-0-729|sed 's/9.//g;s/-/+/'|bc
Re: GPL source vs. binary
On Thu, 18 Nov 1999, Darren O. Benham wrote: Does a source that's licensed under the GPL automaticly produce a binary that can only be licensed under the GPL? If you are the author of the program, you can distribute the binary and the source under separate, even incompatible, licenses. You could distribute the binary under a conventional license and the source under the GPL. This may of course reduce the demand for the binary. Third parties using GPL'd source must distribute any binaries produced from compiling it under the GPL (which means they must distribute the source too).
