某些编程语言(例如Java和C)在其标准库中包含加密软件包。其他诸如Python和Ruby的功能使我们可以下载第三方模块以进行强加密。我认为这是出于法律原因；也许Sun Microsystems有足够的律师，他们不怕被起诉，而Guido van Rossum则更容易受到起诉。

但是法律实际上对此有何规定？在这一点上，如果开放源代码作者在其编程语言的标准库中包括强加密功能，会不会有什么担心的呢？如果是这样，那为什么不呢？如果没有，那么Sun和Microsoft如何摆脱它。

解决方案

IANAL，但是...

Java和Care是封闭源代码，因此在EULA中有或者多或者少说"如果我们不应该在某个地方使用它，这不是我们的错"。他们也有律师团队来保护自己并执行该条款。

正如OP所说，大多数开源许可证都没有类似的语言，即使有许可证，他们也没有律师团队。

同样，从从美国出口加密软件被视为非法的年代起，Python和PERL比Java和C＃要古老。自从法律改变以来，不添加加密技术可能只是一个"一致性就是好"的决定。

在美国，重要的法律是ITAR。

快速谷歌出现了维基百科的文章。

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

但是到目前为止，"无需重新发明轮子"似乎是正确的。

存在两个问题：加密软件的导入和加密软件的导出。

一些国家(中国，俄罗斯，伊朗，伊拉克，缅甸等)限制其公民使用加密技术。将加密软件导入这些国家是非法的。

要在JDK中启用无限的加密强度，我们必须下载一个新的策略文件。如果我们所在的国家/地区不允许导入加密，则该软件许可证不允许我们使用该软件。这被称为"无限强度管辖权政策"，在下面，我包括其README.txt的一部分。

美国等其他国家也不想将加密软件出口到邪恶之轴。因此，将加密软件出口到那些国家可能是非法的。

美国的出口限制已大大放松，这可能是因为认识到将加密技术置于敌人手中是徒劳的，或者可能是鼓励使用NSA破坏的加密技术。但是，它们并没有完全消失。我不认为该软件可以被恐怖分子许可。

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.