In my recent meandering across the web in search of other export control bloggers, I found this post by Frank Hecker in response to a question regarding the export control classification number (ECCN) for the Firefox browser. (BTW, I can’t even image how proud Frank must be in having achieved the highly-coveted number eight position in a Google search for export control blog!)

He’s also taken a creditable stab at explaining how US encryption export controls, which may well be the most confusing piece of the Export Administration Regulations, apply to Firefox. Regarding object code, Frank correctly lays out two different paths to license-free export. These are:

1. License Exception TSU, which first requires claiming that Firefox would qualify as publicly available software, if it were not controlled under 5D002 (which is excluded from eligibility for publicly available status due to encryption capabilities). Given that open-source is Mozilla’s raison d’être, this one should be a slam dunk.  The next step is to notify the Bureau of Industry and Security and the National Security Agency. You have a choice: either provide a copy of the actual source code or a link to each location where it posted. Since Firefox appears to be distributed across from multiple locations, the former might be simpler in this case.
2. No License Required (NLR), which would entail someone submitting a mass market review request to BIS. BIS would then in all likelihood grant the request (after all, they did for IE), altering the ECCN from 5D002 to 5D992 and permitting export without need for license or license exception.  Frank says that the Mozilla Foundation hasn’t done this and probably has no plans to. But anyone can request this sort of review. In fact, I wouldn’t be surprised if someone has already done so. Unfortunately there’s no way to know for sure because BIS keeps such requests confidential. Still, there’s nothing to prevent someone from requesting mass market status and posting the BIS response online at which point all exporters could avail themselves of it.

Is one of these routes preferable to the other?  Not really.  Either way you can’t export to Cuba, Iran, Libya, North Korea, Sudan or Syria.  And either way you have some sort of administrative headache, though the TSU notification is probably less burdensome.

Comments

[Frank Hecker]

Regarding fulfilling notification requirements to BIS for Mozilla code: I was not directly involved in this, but I believe that this was done by providing a URL where the source could be downloaded, not by providing a complete copy of the source code. A related issue is providing notification of ongoing changes to the Mozilla source code; everytime a new code change is checked in to the Mozilla CVS repository, a message is sent to a public newsgroup netscape.public.mozilla.crypto.checkins (gatewayed to a public mailing list mozilla-crypto-checkins@mozilla.org). If I recall correctly this mechanism was set up specifically to meet BIS requirements relating to ongoing notification; however I believe that BIS has recently loosened their requirements relating to ongoing notification, so strictly speaking providing the "new checkins" messages may no longer be necessary (although they do provide a useful service for anyone interested in ongoing changes to the Mozilla crypto code).