The validity of encryption in standard libraries

Question

Some programming languages, such as Java and C #, include encryption packages in their standard libraries. Others, such as Python and Ruby, allow third-party modules to be loaded to provide strong encryption. I guess this is for legal reasons; Sun Microsystems may have enough lawyers that they are not afraid to receive a lawsuit, while Guido van Rossum feels more vulnerable.

But what does the law really say about this? At the moment, open source authors should be wary if they include strong encryption in the standard libraries of their programming languages? If so, why not? If not, how will Sun and Microsoft handle this.

Answer 1

There are two questions: importing encryption software and exporting encryption software.

Some countries (China, Russia, Iran, Iraq, Myanmar, etc.) restrict the use of cryptography to their citizens. It is forbidden to import encryption software into these countries.

To enable unlimited encryption in the JDK, you need to upload a new policy file. The software license does not allow you to use the software if you are in a country that does not allow the import of encryption. This is called the “Unrestricted Jurisdiction Restriction Policy”, and below I will include part of my README.txt.

Other countries, such as the United States, do not want to export encryption software to Axis of Evil. Therefore, it may be prohibited to export encryption software to these countries.

U.S. export restrictions have loosened significantly, probably in recognition of the futility of keeping encryption from the hands of enemies, or perhaps encouraging the use of encryption that has been compromised by the NSA. But they did not leave at all. I do not think that software can be licensed by terrorists.

JCE for JDK 5.0 went through the US export review process. The JCE structure, along with the SunJCE provider, which comes standard with it, can be exported.

The JCE architecture provides flexible cryptographic strength for customization through jurisdiction policy files. Due to import restrictions in some countries, jurisdiction policies files distributed using JDK 5.0 software have built-in restrictions on the available cryptographic strength. The jurisdiction policy files in this download kit (README is included in the package) do not contain restrictions on cryptographic benefits. This is suitable for most countries. Framework providers can create download packages that include jurisdiction policy files that define cryptographic restrictions that apply to countries whose governments require restrictions. Users in these countries can download the appropriate kit, and the JCE framework will apply the specified restrictions.

Consult your export / import control consultant or lawyer to determine the exact requirements.

Answer 2

In the USA, ITAR is an important law.

Answer 3

A quick google appeared in a Wikipedia article.

http://en.wikipedia.org/wiki/Export_of_cryptography

But at the moment it seems that “No need to reinvent the wheel” is correct.

Answer 4

Ianal but ...

Java and C # are proprietary and therefore have terms in EULA that say more or less: "This is not our mistake if you use it somewhere that you shouldn't." They also have legal teams to protect themselves and to enforce this provision.

Most open source licenses do not have a similar langauge, and even those that do, they do not have legal groups on their side, as OP said.

In addition, Python and PERL are older than Java and C # since the day it was illegal to export cryptographic software from the United States. Without adding cryptography, as the law has been amended, perhaps this is simply a “consistency is good” solution.