Legalidade da criptografia em Bibliotecas padrão [fechado]

Question

Algumas linguagens de programação como Java e C # incluem pacotes de criptografia em suas bibliotecas padrão. Outros, como Python e Ruby fazer você baixar módulos de terceiros para fazer criptografia forte. Presumo que este é por razões legais; talvez Sun Microsystems tem advogados suficientes de que eles não têm medo de ser processado, enquanto Guido van Rossum se sente mais vulnerável.

Mas o que a lei realmente dizer sobre isso? Neste ponto, seria open source autores têm nada a temer, se eles incluíram forte criptografia em bibliotecas padrão suas linguagens de programação? Se assim for, então por que não? Se não, então como é que Sun e Microsoft fugir com ele.

Answer 1

Há duas questões: importação de software de criptografia, e exportação de software de criptografia

.

Alguns países (China, Rússia, Irã, Iraque, Mianmar, etc.) restringir o uso de criptografia por seus cidadãos. É ilegal para import software de criptografia para esses países.

Para ativar a força de encriptação ilimitada no JDK, você tem que baixar um novo arquivo de política. A licença de software lá não permite que você use o software se você estiver em um país que não permite a importação de criptografia. Isso é chamado de "Política ilimitado Força Jurisdição", e abaixo eu incluir parte da sua README.txt.

Outros países, como os EUA, não querem software de criptografia de exportação para o Eixo do Mal. Assim, ele pode ser ilegal exportação software de criptografia para esses países.

As restrições de exportação dos EUA ter diminuído consideravelmente, provavelmente em reconhecimento da futilidade de manter a criptografia das mãos de inimigos, ou, eventualmente, para incentivar o uso de criptografia que foi comprometida pela NSA. Mas, eles não sumiram completamente. Eu não acho que o software pode ser licenciado por terroristas.

JCE para JDK 5.0 tem sido através do processo de revisão de exportação EUA. O quadro JCE, juntamente com o provedor SunJCE que vem padrão com ele, é exportável.

A arquitetura JCE permite que a força de criptografia flexível para ser configurado via arquivos de política de jurisdição. Devido à restrições à importação de alguns países, a política de jurisdição arquivos distribuídos com o software JDK 5.0 têm built-in restrições sobre a força de criptografia disponível. a jurisdição arquivos de política neste pacote de download (o pacote inclui este arquivo README), de restrições sobre os pontos fortes de criptografia. Isto é apropriado para a maioria dos países. fornecedores estrutura pode criar pacotes de download que incluem arquivos de política de jurisdição que especificam criptográfico restrições apropriadas para os países cujos governos restrições mandato. Os usuários nesses países pode baixar um pacote adequado, ea vontade quadro JCE fazer cumprir as restrições especificadas.

Você são aconselhados a consultar o seu exportação / conselho de controle de importação ou advogado para determinar as necessidades exatas.

Answer 2

Nos EUA a lei importante é ITAR .

Answer 3

rápida Google transformou-se um artigo da Wikipedia.

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

Mas a partir de agora parece que o "Não há necessidade de reinventar a roda" está correto.

Answer 4

IANAL, mas ...

Java e C # são de código fechado, e assim ter os termos do EULA que dizem mais ou menos "Não é nossa culpa se você usar isso em algum lugar que você não deveria". Eles também têm equipes de advogados para se proteger e fazer cumprir essa cláusula.

A maioria das licenças de código aberto não têm langauge semelhante, e até mesmo os que fazem, eles não têm equipes de advogados do seu lado, como o OP disse.

Além disso, Python e Perl são mais velhos do que Java e C #, desde os dias em que era ilegal exportar software de criptografia dos EUA. Não acrescentar criptografia desde que a lei foi mudada talvez seja simplesmente uma "consistência é-bom" de decisão.