Hey John (et al)...
Interim final is up for review on the CDT web site.
Basically the same thing as the second draft, but with some
clarifications addressing a couple of your issues below...
On Wed, Jan 12, 2000 at 01:30:19AM -0800, John Gilmore wrote:
> > This basically says that crypto source code which is unencumbered
> > may be exported merely by notifying them of the URL (mailto URL's????)
> > where it is available from. No review, no approval, no license, no key
> > length silliness, and no inherited encumberances. :-)
> Under these draft regs, things are a lot better, though they still
> restrict Internet distribution in ways that they couldn't get away
> with for books (e.g. requiring you to notify the gov't when you
> publish one?!). The court cases will proceed until they really do
> make it compatible with the First Amendment.
Agreed. We're not done yet. We were hoping to get the nose
of the camel in the tent and we got the nose, face, front quarters
and fanny. It ain't in bed yet and we still have this notification
"tail" wagging outside the tent yet, but it's real close.
It's interesting that this latest round is now taking explicit
notice of the unique nature of "the 'open source' approach to software
development". IMHO, this is a good thing on the balance. What's left
in these regs, vis-a-vis open source and publicly available source,
shouldn't stand too much longer. There just isn't much left there for
them to regulate.
Conversely, and indirectly, they've actually made it much harder
to use lawsuits in the open source arena to attack their key-length
limits and other regulations for commodity software and other regulated
items. Even if the remaining lawsuits aren't thrown out on their ear
as moot, the regs look pretty well compartmentalized that they could
throw out the remaining few gotchas for open source (maybe they were
left there as throwdowns?) and still retain all of their existing regs
for the commercial arena. That angle does not leave me with a warm
> In particular it's unclear whether mirror sites also have to mail in
> their URLs or face prosecution. And if you KNOW that a recipient is
A clarification there was that the notification was only for
"initial" export and that end-users (would a mirror site be a user)
would be explicitly exempt from the notification requirement. Mirror
sites are still a little bit hazy but looking better.
> in one of the seven verboten countries, e.g. Syria or Cuba, then you
> are still in trouble. ...
Actually, no. Not if it's an ftp or web site. If you SHIP
something to them on a CD or in explicit private E-Mail, it may be a
different issue. It's pretty well spelled out that posting on an ftp
or http site does not establish "knowledge" or a necessity to even ask
(don't ask don't tell). You might argue that prior knowledge of individuals
on the proscribed list may trigger a requirement to proactively block that
access, but since you are not required to screen access to the site (as
you are for commercial software downloads), I don't see how that can be
made applicable to this particular safe haven clause.
They don't even include the "not to government or military users"
that still plague the commodity regs for that. The commodity regs still
have the screening requirements that include things like ".gov" and ".mil"
screening. Gag... None of that applies to open source ftp sites.
> ... And if you provide technical assistance to
> someone outside the US, like answering questions on a mailing list,
> that's still a crime under separate sections of the same regulations.
Now here they made a very clear, very explicit clarification.
] Moreover, under §744.9, exporters of unrestricted encryption source
] code are not restrained from providing technical assistance to foreign
] persons working with such source code.
That language is pretty clear. One MIGHT argue that one
interpretation would be that I could only provide technical assistance
for software which I exported, but I don't think that interpretation
will hold water. It says "exporters of unrestricted encryption source
code" and then refers to "persons working with such source code". I take
that to mean "unrestricted encryption source" when they say "such source
code" and not to mean "the source code I exported". I think it COULD
be argued that this clause doesn't kick in unless I have exported source
code, thus triggering a notification clause somewhere else. It would
appear on it's face that someone who as never exported unrestricted
encryption source code would not be so protected under this clause, but
that's a stretch (but a plausable stretch, I'll concede).
> I still plan to run the Linux IPSEC project using the same old rules
> (avoiding US contributions), at least for a few months, while we see
> how things shake out. However, the Linux kernel people are free
> to pick up the code and do what they want with it, including putting
> it into the main distribution.
Makes perfect sense to me. I still look forward to the day when
I can stop bitching "IT'S BROKE!" and send it fixes. :-)
> We were at least hoping we could get the include file and misc
> "patches" changes into the 2.4 distribution, so we could stop patching a
> bunch of existing kernel files (making it possible to distribute IPSEC
> as a module that can be separately compiled, and added to any kernel).
This would be a VERY GOOD THING. :-)
I'm working on lobying for at least that very thing. I think
HPA has already posted something (prior to the second draft) along the
lines that he and Linus have been thinking about it.
> Also note that the current IPSEC code only does VPNs and requires
> manual configuration and debugging. We're shooting for a version that
> does automatic configuration, and automatically encrypts with
> anybody else who's also running IPSEC, within the next few months.
> (We call that a Real Private Network, not a Virtual Private Network.)
> I'd rather not have a monster user base running the old manual stuff,
> making it hard to move over to the right stuff. This is a case where
> the good may be an enemy of the best; the current stuff doesn't
> scale, but the best stuff will scale to worldwide use.
Hmmm... Interesting point. But if we worried too much about
the old user base stuff, we would have a hard time with any release cycle
and would loose out on an expanded bug-fix feedback effect. Most of this
is pluto and user-land stuff for keying, though, isn't it? The real
biggie for the kernel would be the crypto algorithms and such. I've
got and installed base of IPSec out there now (TimeStep, CheckPoint VPN-1 and
some OpenBSD). I'm more worried about interoperability and limits on my
ability to deploy Linux systems into this existing infrastructure.
> > I won't post the whole $#@$#@ thing (since you can read it at the
> > CDT site anyways) but for things like "Idea" and "RSA", which ARE encumbered
> > by patents, similar clauses exist at 740.17(a)(5) which say basically the
> > same thing.
> Actually that other section is for published source code that you can't
> commercialize, like Sun's "Community Source License". Copylefted
> code, even if it includes patented algorithms, isn't covered. We
> think. But this part of the regs is particularly unclear.
Yeah... I read that several times and I wasn't clear how to
interpret it. My original point was to make it clear we were safe no
matter which way you interpret it. They added explicit language to
clarify that by adding that "Intellectual property protection (e.g.,
copyright, patent, or trademark) would not, by itself, be construted
as an express agreement...."
> This brings up a separate issue, which kernel folks may not care about
> since it isn't in kernel code. The Pluto daemon that negotiates keys
> for the kernel currently implements RSA as one of its options, since
> it's the best technology, and is available for use everywhere other
> than the US, as well as in all US Federal sites, and in any big
> company that has a patent license. That patent expires in October
> 2000; in the meantime, US folks will run a risk if they don't do
> something special (like replace the RSA implementation with a
> paid-for-or-otherwise-licensed one). I think they're OK as long as
> they don't use the optional RSA feature, but it will become required
> for automatic configuration, once we have that working.
John... This one really should be a dead issue. It's been addressed
several times over in the SSL libraries, Apache-ssl, mod-ssl, SSH, PGP,
and a host of others.
People outside the US use the international libraries
People inside the US use RSAREF2 (with appropriate overflow patches
now) for non-commercial use.
People inside the US wanting to use this commercially pay a nominal
fee to an appropriate vendor for the flavor that they want. I bought the
RedHat E-Commerce package to have a fully licensed, legal for commercial use,
Apache-SSL server. If you are using it for commercial use, it won't break
your back (especially compared with the REAL commercial stuff).
We're already use to working like this. We may not like it, but it
beats the hell out of not having it!
We've already solved this problem with other apps, pluto is just
another app in that regard. Come October, the need for RSAREF2 evaporates
as does the commercial licensing issues. I can live with that.
Michael H. Warfield | (770) 985-6132 | mhw@xxxxxxxxxxxx
(The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!