Legality 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 make you download third-party modules to do strong encryption. I assume that this is for legal reasons; perhaps Sun Microsystems has enough lawyers that they aren't afraid of getting sued, while Guido van Rossum feels more vulnerable.

But what does the law actually say about this? At this point, would open source authors have anything to fear if they included strong encryption in their programming languages' standard libraries? If so, then why don't they? If not, then how do Sun and Microsoft get away with it.

Answer 1

IANAL, But...

Java and C# are closed-source, and thus have terms in the EULA that say more-or-less "It's not our fault if you use this somewhere you're not supposed to". They also have teams of lawyers to protect themselves and enforce that clause.

Most open-source licenses do not have similar langauge, and even the ones that do, they don't have teams of lawyers on their side, as the OP said.

Also, Python and PERL are older than Java and C#, from the days when it was illegal to export cryptographic software from the US. Not adding cryptography since the law was changed is perhaps simply a "consistency-is-good" decision.

Answer 2

In the US the important law is ITAR.

Answer 3

Quick google turned up a Wikipedia article.

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

But as of now it seems like the "No need to reinvent the wheel" is correct.

Answer 4

There are two issues: importation of encryption software, and exportation of encryption software.

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

To enable unlimited encryption strength in the JDK, you have to download a new policy file. The software license there doesn't allow you to use the software if you're in a country that doesn't allow importation of encryption. This is called the "Unlimited Strength Jurisdiction Policy," and below I include part of its README.txt.

Other countries, like the US, don't want to export encryption software to the Axis of Evil. So, it can be illegal to export encryption software to those countries.

The US export restrictions have eased up considerably, probably in recognition of the futility of keeping encryption out of the hands of enemies, or possibly to encourage use of encryption that has been compromised by the NSA. But, they aren't gone altogether. I don't think the software can be licensed by terrorists.

JCE for JDK 5.0 has been through the U.S. export review process. The JCE framework, along with the SunJCE provider that comes standard with it, is exportable.

The JCE architecture allows flexible cryptographic strength to be configured via jurisdiction policy files. Due to the import restrictions of some countries, the jurisdiction policy files distributed with the JDK 5.0 software have built-in restrictions on available cryptographic strength. The jurisdiction policy files in this download bundle (the bundle including this README file) contain no restrictions on cryptographic strengths. This is appropriate for most countries. Framework vendors can create download bundles that include jurisdiction policy files that specify cryptographic restrictions appropriate for countries whose governments mandate restrictions. Users in those countries can download an appropriate bundle, and the JCE framework will enforce the specified restrictions.

You are advised to consult your export/import control counsel or attorney to determine the exact requirements.