> This stuff makes my head hurt, I have to admit. The concern is that
> incorporating exported code makes the whole of OpenSSL subject to EAR
> (which it currently isn't). Currently this means nothing interesting,
> but it isn't clear what it may mean in the future.
I'm sorry, but OpenSSL is subject to EAR regardless of whether or not
it has a single line of code from a U.S. author. The EAR does not
care about where products were developed. All it cares about is where
it was exported from.
Now if you really want to take the paranoid stance of ensuring that
OpenSSL cannot be affected by EAR, then you have to ensure that
U.S. citizens and companies never use the product. This is because if
the U.S. citizen has control of the product and then distributes it to
someone who is not from the U.S. or Canada that person/company is
performing an export operation as defined in the EAR.
The EAR governs all "exports" therefore it governs OpenSSL whenever it
is passed from a U.S. citizen/company to anyone else. It doesn't
matter if it is OpenSSL (open source), RSA-C (commercial non-U.S.), or
BSAFE (commercial U.S.). If the developed code ever travels into the
U.S. it may not travel out once again. That is why you can't buy
RSA-C within the U.S. It would be cheaper to simply do away with
BSAFE and only sell RSA-C, but then it would not be provable that the
copies being used outside the U.S. were not originally purchased
inside the U.S. and then exported.
The fact that OpenSSL is not developed with U.S. assistance is of no
matter since it is currently legal for U.S. citizens/companies to
provide technical assistance and export source code as long as the
rules are followed:
. A web site must be used for distributing the source code (patches)
. BXA must be notified when the initial source code associated with
a specific product is released
The key portion of the current BXA regulations is summarized on the
chart
http://www.bxa.doc.gov/Encryption/licchart.htm
Source Code (publicly available, unrestricted use) does not require a
review (including when it is a foreign product) as long as the BXA is
notified at the time the export occurs (the code is posted to the web
site.)
> You may be right that it means nothing from the POV of the US, because
> of constitutional protection against such things, but that's not what my
> advice says. Also, not everyone has constitutional protection against
> these things. For example, imagine that the UK government agreed with
> the US government to ban the export of EAR controlled s/w - where would
> we be then? Screwed, is where.
If the UK decides to enforce the US EAR laws, you still have no
problem because the EAR cannot make something that was legally
exported suddenly illegal.
> > >Please support that claim (saying that the consitution prevents past
> > >acts from being made illegal does not support it).
> >
> > Mr. Altman quoted the section. Or were you looking for something more?
> If you snip the claim, I can't answer the question. I've forgotten what
> that was a response to. Anyway, IANAL, I'm am merely trying to follow
> advice from someone who is. Don't expect me to defend that advice in
> detail.
The restriction on the creation of laws that make past actions illegal
was written into the Constitution at the beginning of this country.
The founders did not like the fact that European rulers had often
passed laws that made past actions suddenly illegal or would apply
taxes to past sales. Therefore, in they added:
U.S. Constitution Article I Section 9:
"No bill of attainder or ex post facto Law shall be passed. "
Its a very straight forward statement that has been upheld by the
United States Supreme Court on numerous occasions. Its meaning is
very clear. The US government (unlike the governments of the EU) may
not change the laws that change the rules as they apply to the past.
That means that the US government cannot make the exporting today of
US source code or technical assistance to the OpenSSL team illegal
tomorrow. All the US government can do is make future exports of
source code and technical assistance illegal. But once the source
code has been legally exported without restriction, it cannot be
restricted in the future. That would be a violation of one of the
clearest sections of the US Constitution.
I understand that you are looking to follow the advice of people that
know more than you do, but in this case the advice you are following
makes no sense. I'm not a lawyer but Constitutional law is one of my
hobbies. I find it fascinating. And this opinion makes no sense in
this context.
> > >We _have_ listened to Cindy Cohn. She supports my views. I am in the
> > >process of getting even more comprehensive advice from her for the ASF.
> > >Regrettably, it still looks like we have a problem.
> >
> > I find it hard to believe that Ms. Cohn really concurs with what you
> > wrote above. I must not be understanding it at all. Could you
> > please explain a bit more? Thanks.
>
> Here is the relevant section of the letter Cindy wrote us:
>
> "The main question you have asked me is whether OpenSSL would be
> �tainted� --that is subject to regulation by the United States � if you
> allow submissions from U.S. contributors. Although nothing is
> certain--the
> United States Government could change their regulations or their
> interpretations of them in almost any way, and although the situation is
> more complicated than this, the short answer to that question is:
> a. The absolute safest path would be to continue refuse to
> include US code, but
>
> b. It is quite unlikely that OpenSSL would be "tainted"
> for
> purposes of future regulation if the code from U.S. programmers that is
> included is exported under the TSU exception. That is, if the US
> programmers make their contributions publicly available at the time of
> export and send a copy of the URL where the code resides to the
> government
> at the time of "export" (i.e. at the time of publication of the web page
> and shipping of it to the OpenSSL project). Again, this requires that
> the
> developer (and OpenSSL) will not reserve the right to be paid licensing
> fees or royalties if the code is compiled and sold by others and
> compliance with the other provisions of the TSU license. Also, the
> developer could not "knowingly" send the program to anyone in the
> restricted T-7 countries and the denied persons list."
>
> As you can see, she thinks it is "quite unlikely" that there would be a
> problem, but "the absolute safest path would be to continue refuse to
> include US code". Call me paranoid, but when dealing with spooks, "quite
> unlikely" isn't good enough for me.
You are the paranoid one. :-) Cindy Cohn is doing exactly what she
should be doing. "Covering her own butt." Ms. Cohn has said exactly
the right thing. OpenSSL cannot be tainted if the TSU exception is
used. That is exactly what I have been saying. Any lawyer worth
their fees is not going to tell you an absolute since they are not the
judge ruling on any potential litigation and these laws have not been
tested in court.
The way things work is that the Executive and Legislative branches of
government write laws. Sometimes these laws violate the
Constitution. When they do the courts throw them out. But it
requires that someone take the US Government to court.
I think part of the problem is you are making the assumption that
OpenSSL is not covered by the EAR simply because it contains no US
source code (or technical assistance). Ms Cohn answered (as most
lawyers and consultants do) the question that you asked them. They
can't answer questions you should have asked. And the question that
should have been asked first is
"under what circumstances can OpenSSL be covered by the EAR?"
Ms Cohn's statement "The absolute safest path would be to continue
refuse to include US code ..." is the equivalent way of saying that to
ensure that you do not get AIDS do not have any physical contact with
any other human beings. Refusing all contact will definitely prevent
the infection, but at what cost? Clearly now that we know more about
AIDS (but not all) we are willing to put ourselves at much higher
risk because the risks of infection by living our lives is very very
small.
Ms Cohn then follows with "It is quite unlikely that OpenSSL would be
"tainted" ..." Not just "unlikely" but "quite unlikely". The risk of
being tainted is really small.
Ms Cohn then goes on the describe a process which (if enforced) will
allow you to ensure (to the best of our knowledge) that OpenSSL will
not be "tainted" by the inclusion of US source code.
. All US contributors must follow the rules of the TSU exception
. All source code must be posted to a Web site
. When source code is posted a letter must be sent to BXA stating
that it is there.
If these procedures are followed, the risk of being tainted is
minimized to the absolute minimum. Why is this procedure acceptable?
Because the US government cannot pass a law that would make future use
of the source code that has been exported under the TSU exception
illegal. Ms Cohn does not state this in her opinion, but it is the
Constitutional guarrantees of Article I Section 9 that is the basis
for her opinion. As Rich said several weeks ago, no one even thinks
to mention it in legal opinions because it is one of the foundations
upon which all US law is based. People just assume that you realize
that.
I know you hate talking about this, but it is only by discussing this
is public that we can get to the heart of the matter.
Have a good rest of the weekend.
- Jeff
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
