[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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
