This page provides PMC members with the information they need to ensure
U.S. export control laws are satisfied for ASF product distributions that
contain or are "specially designed" to use cryptography.

Note - the regulations covering US export control laws for encryption were
changed on June 25th 2010.
This page describes the previous process which should be continued until an updated version has
been drawn up and approved by the Apache VP Legal Affairs.

The U.S. Government places restrictions on the
export of some types
of software, such as software employing cryptographic functions.
Fortunately, the TSU
exception to these
restrictions, EAR 740.13(e), applies to cryptography of concern to the ASF.

PMCs considering including cryptographic functionality within their
products or specially designing their products to use other software with
cryptographic functionality should take the following steps before
placing such code on any ASF server, including commits to subversion :

a notification is sent to the U.S. Government's Bureau of Industry and
Security (BIS) at or before making the code publicly available
Current ASF processes satisfy the "publicly available" requirement. The
notification requirement is described below. However, the
important part of this step is to ensure the included cryptographic
functionality meets the definition of ECCN
5D002 , which can be
summarized as:

Software specially designed or modified for the development, production
or use of any of the other software of this list, or software designed to
certify other software on this list; or

Software using a "symmetric algorithm" employing a key length in excess
of 56-bits; or

Software using an "asymmetric algorithm" where the security of the
algorithm is based on: factorization of integers in excess of 512 bits
(e.g., RSA), computation of discrete logarithms in a multiplicative group
of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over
Z/pZ), or other discrete logarithms in a group in excess of 112 bits (e.g.,
Diffie-Hellman over an elliptic curve).

Software designed or modified to perform cryptanalytic functions
If the cryptographic functionality is limited to one of the above
definitions, it should be classified as ECCN 5D002, and the remaining two
steps should be taken (described below). If the release may contain
cryptographic functionality beyond what is described above, please contact
the ASF Vice President for Legal Affairs.

To satisfy the BIS requirements to make source code available for
inspection, while minimizing the number of notification emails
needed to be sent, the ASF maintains a single web page at
http://www.apache.org/licenses/exports/
with links to the applicable source code for each version of each ASF
product classified as ECCN 5D002.

To make updates to this ASF-wide Exports page as simple and consistent as
possible, the source XML
page
contains a list of XML trees under eccnmatrix that can be edited by
anyone with site-dev karma (which includes all of the PMC chairs). Note
that the exports web page is generated from the XML.

Any edits to the exports page should be tested using both the site build
process (view the index.html before committing any changes) and by running
the bisnotice.xsl transform on the product added/changed (see below). You
can probably figure out what the content of the XML fields should be by
following the example of other projects and reading the page. If you have
any further questions about the content, or if you are not sure that a BIS
notice is required, please check the FAQs first and then bring any
remaining questions to the legal-discuss mailing list. Note that the
product data should only be version-specific if the classification changes
(e.g., Apache HTTP Server version 1.3 vs 2.0) or if the link to the
controlled source code needs to change, such as if the encryption library
included in the product for different releases came from different
manufacturers. In addition, note that it is possible to include both
controlled and non-controlled (ECCN "n/a") products in the list, but a BIS
notice is only necessary for the products that have at least one version
classified as 5D002.

After ensuring the distribution's cryptography qualifies for the TSU
exception and after ensuring the applicable source code is linked from the
ASF-wide export page, but before publicly posting the distribution or
committing the controlled code , send an email using the template below.

An XSLT transformer calledbisnotice.xslhas also been provided to generate the BIS notice for a product
based on the XML data. For example, running it as:

will result in text output that looks like an email template for the PMC
chair to send to the appropriate addresses. A generic example is provided
below. Note that the product parameter selects which product(s) to print
based on matching a substring of the product name. The template output is
only correct when a single product is matched.

There are also some sample script files in the top-level directory (site/trunk):
bisnotice.cmd (Windows) and bisnotice.sh (Un*x)

MANUFACTURER(S) {list of origin of all crypto code, e.g.
"OpenSSL Project" or "Apache Software Foundation."
If product includes multiple crypto items from
different origins, list all origins.}

PRODUCT NAME/MODEL #: {Apache product name(s) that include the source
code found at the URL below, or any binaries
that were created by compiling that source code
-- do not specify version numbers if the
future versions will use source code found at
the same URL (even if the source is updated at
that URL) }

ECCN: 5D002

NOTIFICATION: http://www.apache.org/licenses/exports/

Inform Users by Including a Crypto Notice in the Distribution's README¶

Should the software qualify for the TSU exception, the notice below should
be placed into each distribution's README file. `
This distribution includes cryptographic software. The country in
which you currently reside may have restrictions on the import,
possession, use, and/or re-export to another country, of
encryption software. BEFORE using any encryption software, please
check your country's laws, regulations and policies concerning the
import, possession, or use, and re-export of encryption software, to
see if this is permitted. See <http://www.wassenaar.org/> for
more
information.

The U.S. Government Department of Commerce, Bureau of Industry and
Security (BIS), has classified this software as Export Commodity
Control Number (ECCN) 5D002.C.1, which includes information security
software using or performing cryptographic functions with asymmetric
algorithms. The form and manner of this Apache Software Foundation
distribution makes it eligible for export under the License Exception
ENC Technology Software Unrestricted (TSU) exception (see the BIS
Export Administration Regulations, Section 740.13) for both object
code and source code.

The following provides more details on the included cryptographic
software:
...
` Be sure to add some information at the bottom of the notice about the
components of the release including cryptography.

Simply the name of the ASF product (e.g. "Apache Foo"), even if the
notification is being made about another manufacturer's cryptography
included in the ASF product. The ASF product's version number should not be
listed.

A URL that directly or indirectly points to the source code for the crypto
item built by the listed manufacturer that is
distributed within the ASF product. At the ASF, we
indirectly point to the source code by having all products list
www.apache.org/licenses/exports/ as the NOTIFICATION
url, and ensuring that this page is refreshed with the set of links to the
crypto source code for the notifying product. If the product contains more
than one crypto item, the exports page simply points to the source for each
crypto item included in the product.

Prior to exporting. NOTE: this even includes distribution of code through
publicly accessible servers/repositories before there has been any official
release.

What are examples of when a crypto item is publicly accessible through ASF servers?¶

The obvious example is including something like an OpenSSL binary within a
product distribution from a /dist URL. The less obvious example , is
the point at which a subversion repository starts to include code that is
specially designed to work with any other 5D002 item, whether that item is
ever to be included within a product distribution or not. In other words, a
project should send out a notification email just after making the decision
to include code that is specially designed to work with crypto APIs but
before actually committing such code. No need to worry about surprise JIRA
attachments with such code -- only the event of committing the code to the
ASF product repository.

Are public contributions of crypto items to the mailing list, JIRA or Bugzilla databases considered exports?¶

No. We do not need to worry about surprise JIRA attachments with such code
-- only code committed to the ASF product repository. The actual poster of
these attachments would be the one 'exporting' the crypto, since it would
not be an act of the ASF project, as it addressed above.

If we distribute previously exported crypto items, must we still qualify the same item for export?¶

Yes. The ASF is responsible for complying with the EAR, regardless of
whether the item we are exporting has been previously exported under the
TSU exception by another manufacturer/company/open source project.

If the ASF distributes a particular crypto item within one product under the TSU exception, must the same item requalify for the TSU exception when distributed in a different ASF product?¶

Yes. Each product must qualify separately, which includes sending
notifications for each.

If the ASF distributes/exports a crypto item after qualifying it under the TSU exception, must the same product requalify for release of future versions?¶

No. As long as the email's notification URL for the source location still
(directly or indirectly) points to the applicable source for each version's
crypto item, no additional process is required.

If the notification URL never changes, when are additional notification emails required?¶

Each product needs to send only one notification email until information
previously submitted is no longer accurate, e.g. a change in the
manufacturer.

Is there any BIS requirement to tell users and/or redistributors of our products about the crypto within our products?¶

No, but it's a good idea to do so. See our self-imposed requirement to
inform users.

When exporting a product that is not only designed to use some third-party crypto item, but also includes the third-party crypto item, does this require two notifications or one notification with two manufacturers?¶

When multiple crypto items exist within a single product, one email should
be sent listing all manufacturers of encryption items in the product and
the standard notification URL to the ASF-wide exports
page with detailed information, including the location of the corresponding
source code.

Can the ultimate link to the crypto item's source code point to a non-ASF web page?¶

Yes, as long as the PMC is reasonably confident that the non-ASF location
is likely to remain available for BIS inspection for the foreseeable
future. If this is not the case at some point, the ASF should update the
link to a location that will remain available.

What if the object/binary code being distributed was built with a particular compiler switch?¶

It is fine to use whatever compiler switches we like. There is no need to
provide compiler switch info, as long as the pointed source code is a
superset of all the controlled source that ends up being distributed within
the object/binary file.

Do we ever need to notify the BIS of the location of object/binary files?¶

No, but whether we are distributing source or object/binary files, we must
always make sure a notification has been made pointing (directly or
indirectly) to the associated source.

If my project ships a binary that includes libssl/libcrypto, what notifications must be made?¶

Within the single notification email ( sent prior to either hosting
libssl/libcrypto or committing code that binds to it ), the ASF and the
OpenSSL project should be listed as manufacturers, since both organizations
produce encryption items included in the product. See the more generic
Q&A on this topic.

If my project ships a binary that provides bindings to OpenSSL, but does not include its source or binaries, what notifications must be made?¶

The only required notification for an Apache project that is specially
designed to use, but doesn't include, such crypto, is just the notification
for the ASF product code.

Isn't it somewhat weird that I, who am not a U.S. citizen nor resident, should be constrained as to what or how I can commit to an ASF repository by some U.S. law?¶

No. The ASF is a US-based corporation and must comply with U.S. export
controls. Incidentally, the U.S. is not the only country with controls on
cryptography. Many other nations
have very similar restrictions, primarily driven by the Wassenaar
Arrangement.