RE: draft regulations?
> -Original Message-
> From: John Gilmore [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 25, 1999 3:55 PM
> To: Rodger, William
> Cc: William Allen Simpson; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: draft regulations?
>
I wrote:
> > Open Source code, believe it or not, would be essentially
> > decontrolled by this proposal.
John GIlmore replied:
> Look closer. The large print granteth and the small print
> taketh away.
John's entirely right, provided one wants to guard against all future
possible reversals on this issue. My view is this process has been headed in
one direction only and at worst will stagnate there. Given that,
"essentially" decontrolled seems about right.
In the meantime, useful source code on disk remains non-exportable without a
license.
My own view: the entire regime will be dead within three years.
Will
> It would be simple to exempt published encryption software from the
> regulations; the Commerce Dept regs did this for years, before the
> State Dept rules were folded into it. The Commerce regs today state
> state that all other forms of published software -- except crypto --
> are "not subject to the EAR". It's in Part 734.3(b)(3). Published
> word processors and other software don't need to prevent web accesses
> from certain countries, or impose any conditions on recipients. True
> deregulation would involve *removing* the special case for crypto.
> This is not what the draft offers.
>
> Open source is not a single piece of code, it's a development process.
> The proposal offers open source developers poisoned bait. If you jump
> through some hoops, you can export single patches, or pieces of
> software, from the US. That's the bait. The poison is that the
> software and everything derived from it becomes permanently tainted
> with US export controls ("subject to the EAR"). This appears to
> include all future releases of the open source project, and all object
> code derived from them, no matter where in the world they are
> produced or used.
>
> (Every licensed export currently requires the exporter to get the
> recipient to agree that the recipient will not re-forward the exported
> stuff to places or recipients that the US disapproves of. The draft
> rules would drop the requirement to get prior permission for the
> export, but retain the requirement to impose US controls on every
> future recipient. And the US can change those controls at any time,
> either by sending you a private letter about an individual product --
> as they did by revoking their permission a year after giving Hugh
> Daniel written permission to export DNS Security authentication source
> code -- or by unilaterally altering their published regulations.)
>
> Suppose standard Linux releases included US-based crypto code under
> these rules. Every subsequent copy of Linux running everywhere in the
> world would become subject to US export controls, which are subject to
> the whim of the NSA and the current US administration. It would be a
> poor design decision to subject *every* Linux user to whatever new
> crazy ideas the NSA dreams up to help them wiretap the world next
> year.
>
> The draft rules also appear to require web sites to take active
> measures to discourage people from six or seven little countries from
> being able to access the site. This is just like the current BXA
> rules about publishing crypto on US web sites, except the list of
> countries "allowed" to access your web publications is bigger.
> (Anonymous accesses appear to be disallowed since they might be from a
> disallowed country.) The draft rules offer a bigger cage to censor
> yourself within, not a change to true freedom of expression for
> cryptographers.
>
> The censor-access-by-country rules would apply to any international
> web site (or mirror site) that published any code that includes US
> crypto source code contributions. Who would be idiotic enough to do
> this to their web sites? Much easier and safer to continue current
> policy of refusing to accept US contributions to int'l crypto code.
>
> At the moment nobody is crazy enough to start an open source crypto
> project in the US; they are all based in free countries. Naive
> readings of the draft proposal encourage US developers to start such
> projects (which end up producing products that are restricted by US
> export controls on object code). They also encourage internationally
> based projects to pollute their code by accepting contributions from
> US contributors, thereby rendering their entire source base subject to
> US export controls. Both of these outcomes would be poor decisions
> for open sour
Re: draft regulations?
Of course not, "click here if you aren't a terrorist" is incorrect. "click here if you are not a citizen or national of, and this data is not being downloaded to, Cuba, Iran, Iraq, Libya, ..." quite probably is adequate. When I designed the initial CyberCash wallet downloading page, it checked the inverse DNS and dumped you if that said you were from a trading-prohibited country, and then asked you the citizenship/nationality question and the download loation question as yes/no radio buttons. If you answered the questions that you were from a trading-prohibited country or the wallet was to be downloaded to a trading-prohibited country, you got a page saying it was not allowed. This page had a "retry" button on it that took you back to the questions. This was consider adequate security. Donald From: Martin Minow <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Date: Wed, 24 Nov 1999 16:10:56 -0800 Reply-To: [EMAIL PROTECTED] To: Russell Nelson <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> <14396.26852.364756.5962 [EMAIL PROTECTED]> >Russell Nelson wrote: >> ... You also have to (somehow) prevent users from >> Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria form downloading >> the code. > >Ok. how am I going to do that (rhetorical question)? My Web Server is the >module distributed with every recent MacOS system (i.e., all those millions >of iMac's and iBooks). It's a Control Panel (TSR in DOS-speak) called >"Web Sharing". As far as I know, it has no mechanism for preventing >certain domains from accessing a local web page. Of course, I could >put up a link that says "click here if you aren't a terrorist", but >I rather doubt that this will satisfy the regulations. > >Martin Minow >[EMAIL PROTECTED] >
Re: draft regulations?
Will Rodger said:
> Open Source code, believe it or not, would be essentially
> decontrolled by this proposal.
Look closer. The large print granteth and the small print taketh away.
It would be simple to exempt published encryption software from the
regulations; the Commerce Dept regs did this for years, before the
State Dept rules were folded into it. The Commerce regs today state
state that all other forms of published software -- except crypto --
are "not subject to the EAR". It's in Part 734.3(b)(3). Published
word processors and other software don't need to prevent web accesses
from certain countries, or impose any conditions on recipients. True
deregulation would involve *removing* the special case for crypto.
This is not what the draft offers.
Open source is not a single piece of code, it's a development process.
The proposal offers open source developers poisoned bait. If you jump
through some hoops, you can export single patches, or pieces of
software, from the US. That's the bait. The poison is that the
software and everything derived from it becomes permanently tainted
with US export controls ("subject to the EAR"). This appears to
include all future releases of the open source project, and all object
code derived from them, no matter where in the world they are
produced or used.
(Every licensed export currently requires the exporter to get the
recipient to agree that the recipient will not re-forward the exported
stuff to places or recipients that the US disapproves of. The draft
rules would drop the requirement to get prior permission for the
export, but retain the requirement to impose US controls on every
future recipient. And the US can change those controls at any time,
either by sending you a private letter about an individual product --
as they did by revoking their permission a year after giving Hugh
Daniel written permission to export DNS Security authentication source
code -- or by unilaterally altering their published regulations.)
Suppose standard Linux releases included US-based crypto code under
these rules. Every subsequent copy of Linux running everywhere in the
world would become subject to US export controls, which are subject to
the whim of the NSA and the current US administration. It would be a
poor design decision to subject *every* Linux user to whatever new
crazy ideas the NSA dreams up to help them wiretap the world next
year.
The draft rules also appear to require web sites to take active
measures to discourage people from six or seven little countries from
being able to access the site. This is just like the current BXA
rules about publishing crypto on US web sites, except the list of
countries "allowed" to access your web publications is bigger.
(Anonymous accesses appear to be disallowed since they might be from a
disallowed country.) The draft rules offer a bigger cage to censor
yourself within, not a change to true freedom of expression for
cryptographers.
The censor-access-by-country rules would apply to any international
web site (or mirror site) that published any code that includes US
crypto source code contributions. Who would be idiotic enough to do
this to their web sites? Much easier and safer to continue current
policy of refusing to accept US contributions to int'l crypto code.
At the moment nobody is crazy enough to start an open source crypto
project in the US; they are all based in free countries. Naive
readings of the draft proposal encourage US developers to start such
projects (which end up producing products that are restricted by US
export controls on object code). They also encourage internationally
based projects to pollute their code by accepting contributions from
US contributors, thereby rendering their entire source base subject to
US export controls. Both of these outcomes would be poor decisions
for open source projects to make.
Someday the US will truly deregulate published crypto source code, so
that the nationality of a crypto researcher or developer is not a
factor in whether to accept their contributions to an open source
project. With some luck, this will be backed up by a Supreme Court
ruling in the Bernstein case, which can't be later rescinded by
administrative whim. (BTW, none of the bills in Congress demands true
free expression in crypto code.) The Administration seeks to avoid
being required by the courts or Congress to stick to free expression
even when it hurts, so it may temporarily truly deregulate on December
15, 1999. But even that much won't happen unless they make real
changes to the draft rules they released this week.
John Gilmore
open source software developer
& part of Bernstein litigation team for free expression in crypto code
Re: draft regulations?
Martin Minow writes: > > Russell Nelson wrote: > > ... You also have to (somehow) prevent users from > > Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria form downloading > > the code. > > Ok. how am I going to do that (rhetorical question)? My Web Server is the > module distributed with every recent MacOS system (i.e., all those millions > of iMac's and iBooks). It's a Control Panel (TSR in DOS-speak) called > "Web Sharing". As far as I know, it has no mechanism for preventing > certain domains from accessing a local web page. Of course, I could > put up a link that says "click here if you aren't a terrorist", but > I rather doubt that this will satisfy the regulations. Make the code accessible only through a CGI script which does a reverse lookup on the IP address, and if it's a bad guy, send them a picture of Bill Clinton eating a steak, bacon and cheese sandwich (which in theory ought to offend *every* religious person, with Bill Clinton there to mop up the irreligious). Of course, that doesn't do a *darned* thing to prevent an embassy official from hand-carrying it out of the country, or someone downloading it through anonymizer.com, or someone ftp'ing it down to an ISP with a shell account, etc etc etc. It's just a damn stupid waste of people's time. I'm going to suggest that it be removed. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: draft regulations?
Russell Nelson wrote: > ... You also have to (somehow) prevent users from > Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria form downloading > the code. Ok. how am I going to do that (rhetorical question)? My Web Server is the module distributed with every recent MacOS system (i.e., all those millions of iMac's and iBooks). It's a Control Panel (TSR in DOS-speak) called "Web Sharing". As far as I know, it has no mechanism for preventing certain domains from accessing a local web page. Of course, I could put up a link that says "click here if you aren't a terrorist", but I rather doubt that this will satisfy the regulations. Martin Minow [EMAIL PROTECTED]
RE: draft regulations?
Rodger, William writes:
> Based on a conversation I had with Commerce Undersecretary William Reinsch
> last night, as well as other crypto-savvy attorneys, I think it's probably
> more useful to look at the first page of the draft. Open Source code,
> believe it or not, would be essentially decontrolled by this proposal.
Essentially. You have to tell them you're publishing it, but that's
not a prior restraint, and there's no provision for denying you your
freedom to publish. You also have to (somehow) prevent users from
Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria form downloading
the code. Personally, I'd just check the domain name on the reverse
DNS, and if it's one of the above, shunt them aside. If anyone thinks
that's not sufficient, then the onus is on them to define what is.
I wonder if they've thought about the fact that in Perl, the source
code *is* the product ("any encryption product developed with source
code released under this provision is subject to the EAR (see Section
740.17).") And if one can export the source code, one is exporting an
encryption product without reference to the EAR.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
RE: draft regulations?
Based on a conversation I had with Commerce Undersecretary William Reinsch last night, as well as other crypto-savvy attorneys, I think it's probably more useful to look at the first page of the draft. Open Source code, believe it or not, would be essentially decontrolled by this proposal. The draft starts thus: "740.13 TECHNOLOGY AND SOFTWARE UNRESTRICTED (TSU) "This License Exception authorizes exports and re-exports of operation technology and software; sales technology and software; software updates (bug fixes); and "mass market" software subject to the General Software Note; and non-commercial encryption source-code. Note that encryption software is no longer subject to the General Software Note (see paragraph (d)(2) of this section). " (verbiage regarding the definition of mass-market software snipped) It then includes the following as eligible for export: "(1) Encryption source code controlled under 5D002 which would be considered publicly available under Section 734.3(b)(3) and which is not subject to any proprietary commercial agreement or restriction is released from EI controls and may be exported or re-exported without review under License Exception TSU, provided you have submitted to BXA notification of the export, accompanied by the Internet address (e.g. URL) or copy of the source code by the time of export. Submit the notification to BXA and send a copy to ENC Encryption Request Coordinator (see Section 740.17(g)(5) for mailing addresses). " Now, telling the govt. what you're up to at the time you do it isn't exactly free speech. But these regs were included _specifically_ to allow the export of Open Source software. If you're looking for someone to thank or blame, you should talk to Netscape, who wanted this badly for its Open Source Mozilla effort. My sources tell me they were particularly concerned that MS could ship its browser almost anywhere while they sat on the sidelines. So why wasn't this mentioned back in September when they unveiled the plan? Simple: they hadn't thought of it. http://www.usatoday.com/life/cyber/tech/ctg734.htm Will > -Original Message- > From: William Allen Simpson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 24, 1999 11:56 AM > To: [EMAIL PROTECTED] > Subject: Re: draft regulations? > > > > > "Steven M. Bellovin" wrote: > > > I was about to make a snide comment that they're just > endorsing open source > > software -- but is there any definition of "other > restriction"? Does the GPL > > count? Are they trying to ban any publication of anything > that isn't flat-out > > public domain? And if something is flat-out public domain, > how can the > > "exporter" impose the viral restrictions? For that matter, > what is "export"? > > Posting something to Usenet? Putting it up on a Web page > or FTP server? The > > act of downloading it? > > > These are excellent questions. > > I think the GPL counts. I think that BSD counts. I have no idea how > the exporter imposes the viral restrictions, but I suspect that it > could result in prosecution -- "a compare shows this line of code is > identical to that line of US origin code, guilty as charged." > > > "Salz, Rich" wrote: > > I think they want to make sure that if some non-US package > > (openssl being the example most obvious to me) picks it up > > that it doesn't suddenly become "free." So it's not the GPL, > > really, but more like the old BSD license. > > /r$ > What I meant is, I'd like to contribute code to FreeSWAN, or OpenSSL, > or whatever, but the inclusion of a single line of my code will make > the entire thing subject to EAR regulation. Worse, a single line of > code that "looks" like a line I published will subject the > whole thing > to regulation. Means we cannot publish _anything_ for fear > of damaging > the efforts of our freinds. Not good. > > [EMAIL PROTECTED] > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B > 6A 15 2C 32 > application/ms-tnef
solutions?, was Re: draft regulations?
William Allen Simpson wrote: > What I meant is, I'd like to contribute code to FreeSWAN, or OpenSSL, > or whatever, but the inclusion of a single line of my code will make > the entire thing subject to EAR regulation. Worse, a single line of > code that "looks" like a line I published will subject the whole thing > to regulation. Means we cannot publish _anything_ for fear of damaging > the efforts of our freinds. Not good. I guess much will still be said (and, changed) on this now and in the foreseeable future. There is more context at www.bxa.doc.gov in its encryption page, with information on current policy and practice, as well as a separate page for viewing the Export Administration Regulations (EAR). But, besides William's comments, I believe that the main market value being reduced by the regulation is interoperation (a non-exportable product reduces interoperation and thus increases production costs, reduces market, increases the number of versions and thereby the occurrence of bugs, increases time to market, etc.). So, how could we boost interoperation in the face of (possible) regulation? I am working on a technical approach to this. Of course, the political track may be pursued in different countries, administrations and over time, but is essentially local and will have different results for different countries. A technical track could be globally effective and even help defuse the political questions by denying the cause. Can we devise such solutions? Cheers, Ed Gerck
Re: draft regulations?
According to William Allen Simpson: > ... > What I meant is, I'd like to contribute code to FreeSWAN, or OpenSSL, > or whatever, but the inclusion of a single line of my code will make > the entire thing subject to EAR regulation. I wonder how broad is or will be "code" concept. An interesting example is SET ASN.1 definitions that looks like code. --vf
Re: draft regulations?
"Steven M. Bellovin" wrote: > > I was about to make a snide comment that they're just endorsing open source > software -- but is there any definition of "other restriction"? Does the GPL > count? Are they trying to ban any publication of anything that isn't flat-out > public domain? And if something is flat-out public domain, how can the > "exporter" impose the viral restrictions? For that matter, what is "export"? > Posting something to Usenet? Putting it up on a Web page or FTP server? The > act of downloading it? > These are excellent questions. I think the GPL counts. I think that BSD counts. I have no idea how the exporter imposes the viral restrictions, but I suspect that it could result in prosecution -- "a compare shows this line of code is identical to that line of US origin code, guilty as charged." "Salz, Rich" wrote: > I think they want to make sure that if some non-US package > (openssl being the example most obvious to me) picks it up > that it doesn't suddenly become "free." So it's not the GPL, > really, but more like the old BSD license. > /r$ What I meant is, I'd like to contribute code to FreeSWAN, or OpenSSL, or whatever, but the inclusion of a single line of my code will make the entire thing subject to EAR regulation. Worse, a single line of code that "looks" like a line I published will subject the whole thing to regulation. Means we cannot publish _anything_ for fear of damaging the efforts of our freinds. Not good. [EMAIL PROTECTED] Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
RE: draft regulations?
>Looks like they are reinventing the GPL, except to infect >other sources. I think they want to make sure that if some non-US package (openssl being the example most obvious to me) picks it up that it doesn't suddenly become "free." So it's not the GPL, really, but more like the old BSD license. /r$
Re: draft regulations?
In article <[EMAIL PROTECTED]>, Steven M. Bellovin <[EMAIL PROTECTED]> wrote: >For that matter, what is "export"? Posting something to Usenet? >Putting it up on a Web page or FTP server? The act of downloading it? As far as I know, they haven't changed the definition of "export". Which means this is still the one: EAR 734.2 (b)(9) reads: // (9) Export of encryption source code and object code software. (i) For purposes of the EAR, the export of encryption source code and object code software means: (A) An actual shipment, transfer, or transmission out of the United States (see also paragraph (b)(9)(ii) of this section); or (B) A transfer of such software in the United States to an embassy or affiliate of a foreign country. (ii) The export of encryption source code and object code software controlled for EI reasons under ECCN 5D002 on the Commerce Control List (see Supplement No. 1 to part 774 of the EAR) includes downloading, or causing the downloading of, such software to locations (including electronic bulletin boards, Internet file transfer protocol, and World Wide Web sites) outside the U.S., or making such software available for transfer outside the United States, over wire, cable, radio, electromagnetic, photooptical, photoelectric or other comparable communications facilities accessible to persons outside the United States, including transfers from electronic bulletin boards, Internet file transfer protocol and World Wide Web sites, unless the person making the software available takes precautions adequate to prevent unauthorized transfer of such code outside the United States. Such precautions shall include: (A) Ensuring that the facility from which the software is available controls the access to and transfers of such software through such measures as: (1) The access control system, either through automated means or human intervention, checks the address of every system requesting or receiving a transfer and verifies that such systems are located within the United States; (2) The access control system, provides every requesting or receiving party with notice that the transfer includes or would include cryptographic software subject to export controls under the Export Administration Act, and that anyone receiving such a transfer cannot export the software without a license; and (3) Every party requesting or receiving a transfer of such software must acknowledge affirmatively that he or she understands that the cryptographic software is subject to export controls under the Export Administration Act and that anyone receiving the transfer cannot export the software without a license; or (B) Taking other precautions, approved in writing by the Bureau of Export Administration, to prevent transfer of such software outside the U.S. without a license.// So that would mean putting source on a web or ftp site in the US, available to anyone on the Internet, would be "export". And note, too, that the new rules which say you're allowed to "export" certain kinds of crypto source, *except to the evil countries*, means that you _still_ can't just put source on the web without making an attempt to keep the evil Cubans, etc. from getting it. - Ian "who doesn't trust the "new regs" any further than he could throw Fidel Castro"
Re: draft regulations?
... For that matter, what is "export"? Posting something to Usenet? Putting it up on a Web page or FTP server? The act of downloading it? Egad, Steve, a highest and best use for spam. I'll buy those 300,000 e-mail addresses and send them all a copy of the GPG source, each with another of those 300,000 addresses as apparent sender, of course. Or maybe chain letters; yeah, chain letters are good. Melissa, come here. I need you. --dan
Re: draft regulations?
In message <[EMAIL PROTECTED]>, William Allen Simpson writes: > Looks like they are reinventing the GPL, except to infect other sources. > > (4)(i) for encryption source code (including published source code > which is subject to proprietary commercial agreements or other > restriction), any new product developed with this source code must be > classified by BXA (see paragraph (e) of this section) prior to > re-export. > > A little slap in the face to PGP -- and may make GPG code classifiable. I was about to make a snide comment that they're just endorsing open source software -- but is there any definition of "other restriction"? Does the GPL count? Are they trying to ban any publication of anything that isn't flat-out public domain? And if something is flat-out public domain, how can the "exporter" impose the viral restrictions? For that matter, what is "export"? Posting something to Usenet? Putting it up on a Web page or FTP server? The act of downloading it? --Steve Bellovin
