> -----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 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
>
application/ms-tnef
