US citizens uploading to non-us
[I am not yet a maintainer but I expect to finish with the NM process
probably before this discussion concludes.]
The question of whether US maintainers can upload to non-US comes up
from time to time. I saw a question about SSL packages that basically
boiled down to this question in September's archive.
I can't find an answer to the question on this list's archives and so
I'm asking it again. It seems fairly clear to me that the answer is
yes, if proper procedures are followed, but since export issues are
kind of touchy I want to make sure that I'm not missing something.
I'd like to take some of your time to present my explanation of why I
believe it is reasonable for a US maintainer to upload open-source
cryptography to the non-us queue. Hopefully this issue is as clear as
I think it is and we will reach consensus. Alternatively I may be
missing something and people will explain it to me and we can go from
there.
But first, I'd like to explain why I'd want to upload to the non-us
queue. I want to maintain software (currently the Openafs package).
This software contains crypto, but is developed and released inside
the United States. I have the experience to be a good maintainer of
the package. It needs to go into the non-us queue because currently
Debian is not set up to deal with cryptography on master. Arguments I
will present later suggest that perhaps Debian could set up the US
servers to deal with crypto code. However, Debian would at least have
to deal with notification procedures which it is not currently doing.
Thus, if crypto is going into Debian it needs to go into non-us
currently. I have heard that this may change in the future and non-us
may merge into main, but this hasn't happened yet.
Things I see that could prevent me from uploading to non-us queue are
US export regulation, import regulations wherever the queue is and
Debian policy. I'd like to start by considering US export regulations.
On October 19, the Bureau of Export Administration (BXA) of the US
Department of Commerce issued a new final rule on export of
cryptographic software. This rule updated a rule released in
January. The following is a direct quotation of section 740.13(e) of
the Export Administration Regulations (EAR) found at
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:740.wais.
(e) Unrestricted encryption source code
(1) Encryption source code controlled under
ECCN 5D002, which would be considered
publicly available under §734.3(b)(3) of the EAR
and which is not subject to an express agreement
for the payment of a licensing fee or royalty for
commercial production or sale of any product
developed with the source code is released from
EI controls and may be exported or reexported
without review under License Exception TSU,
provided you have submitted written notification
to BXA of the Internet location (e.g., URL or
Internet address) or a copy of the source code by
the time of export. Send the notification to BXA
at crypt@bxa.doc.gov with a copy to ENC
Encryption Request Coordinator, or see
§740.17(e)(5) for the mailing addresses.
Intellectual property protection (e.g., copyright,
patent or trademark) will not, by itself, be
construed as an express agreement for the
payment of a licensing fee or royalty for
commercial production or sale of any product
developed using the source code.
(2) Object code resulting from the compiling of
source code which would be considered publicly
available can be exported under TSU if the
requirements of this section are otherwise met
and no fee or payment (other than reasonable and
customary fees for reproduction and distribution)
is required for the object code. See
§740.17(b)(4)(i) for the treatment of object code
where a fee or payment is required.
(3) You may not knowingly export or reexport
source code or products developed with this
source code to Cuba, Iran, Iraq, Libya, North
Korea, Sudan or Syria.
(4) Posting of the source code or corresponding
object code on the Internet (e.g., FTP or World
Wide Web site) where it may be downloaded by
anyone would not establish "knowledge" of a
prohibited export or reexport, including that
described in paragraph (e)(2) of this section. In
addition, such posting would not trigger "red
flags" necessitating the affirmative duty to
inquire under the "Know Your Customer"
guidance provided in Supplement No. 3 to part
732 of the EAR.
So, according to these regulations, provided that I tell the US
government before doing so, I can export software meeting DFSG from
the US. It's fairly clear for example that I could put software up on
a website within the US, send mail to crypt@bxa.doc.gov and then allow
non-US people to download without any special tracking or access
controls.
It turns out that I can also explicitly export such source code by
electronic mail, ssh, etc. The requirement is simply that the source
code is publicly available. Clearly something within Debian
qualifies as publicly available. I would probably also stick it on
a website I control within the US to avoid having to send the entire
source code to the BXA as I export.
According to the FAQ at
http://www.bxa.doc.gov/Encryption/Oct2KQandAs.html (question 26), I
must make sure that I have a license if I knowingly export to a
prohibited destination. However, since the incoming queue on pandora
is not in a prohibited destination it would be legal for me to upload
provided that I notified the BXA concurrently.
The next question is the importation of crypto into the jurisdiction
where pandora exists. I don't know what the laws are like, but I
suspect that since other developers around the world upload to pandora
importing crypto is fine in that jurisdiction.
The final issue is Debian policy.
I can find nothing in developer's reference section 6.2.5, the Debian
machine usage policies, or the DB entry for pandora that would prevent
me, once I am a Debian developer, from uploading to pandora.
Naturally I would notify the BXA for each upload.
Reply to: