La légalité du chiffrement dans les bibliothèques standard [fermé]

Question

Certains langages de programmation tels que Java et C # incluent des packages de chiffrement dans leurs bibliothèques standard. D'autres, comme Python et Ruby, vous obligent à télécharger des modules tiers pour effectuer un cryptage renforcé. Je suppose que c'est pour des raisons légales; Sun Microsystems a peut-être suffisamment d'avocats pour ne pas craindre d'être poursuivis en justice, alors que Guido van Rossum se sent plus vulnérable.

Mais que dit la loi à ce sujet? À ce stade, les auteurs open source auraient-ils quelque chose à craindre s'ils incluaient un cryptage fort dans les bibliothèques standard de leurs langages de programmation? Si oui, alors pourquoi pas eux? Si ce n’est pas le cas, comment Sun et Microsoft s’en tireront-ils?

Answer 1

Il existe deux problèmes: l'importation d'un logiciel de cryptage et l'exportation d'un logiciel de cryptage.

Certains pays (Chine, Russie, Iran, Irak, Myanmar, etc.) restreignent l'utilisation de la cryptographie par leurs citoyens. Il est illégal d'importer un logiciel de chiffrement dans ces pays.

Pour activer un cryptage illimité dans le JDK, vous devez télécharger un nouveau fichier de stratégie. La licence du logiciel ne vous autorise pas à utiliser le logiciel si vous vous trouvez dans un pays où l'importation du cryptage n'est pas autorisée. C’est ce que l’on appelle la "Politique de juridiction à force illimitée". et ci-dessous, j'inclus une partie de son fichier README.txt.

D'autres pays, comme les États-Unis, ne souhaitent pas exporter de logiciel de chiffrement vers Axis of Evil. Il peut donc être illégal d'exporter un logiciel de chiffrement vers ces pays.

Les restrictions à l’exportation des États-Unis se sont considérablement assouplies, probablement en raison de l’inutilité de garder le cryptage hors de portée des ennemis, ou éventuellement d’encourager le recours à un cryptage compromis par la NSA. Mais, ils ne sont pas partis tout à fait. Je ne pense pas que le logiciel puisse être licencié par des terroristes.

  

JCE pour JDK 5.0 a suivi le processus de révision des exportations américain.   Le framework JCE, ainsi que le fournisseur SunJCE fourni   standard avec elle, est exportable.

     

L’architecture JCE permet une puissance cryptographique flexible   à configurer via les fichiers de règles de juridiction. En raison de   restrictions d'importation de certains pays, la politique de la juridiction   Les fichiers distribués avec le logiciel JDK 5.0 ont des fonctions intégrées.   restrictions sur la force cryptographique disponible. La juridiction   fichiers de règles de ce paquet de téléchargement (le paquet comprenant ce   Fichier README) ne contient aucune restriction sur les forces cryptographiques.   Ceci est approprié pour la plupart des pays. Les vendeurs de framework peuvent   créer des offres de téléchargement comprenant des fichiers de règles de juridiction   qui spécifient les restrictions cryptographiques appropriées aux pays   dont les gouvernements imposent des restrictions. Utilisateurs dans ces pays   pouvez télécharger un paquet approprié, et le framework JCE   appliquer les restrictions spécifiées.

     

Il vous est conseillé de consulter votre conseil en contrôle des exportations / importations ou   avocat pour déterminer les exigences exactes.

Answer 2

Aux États-Unis, la loi importante est la ITAR .

Answer 3

Google a créé un article sur Wikipedia.

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

Mais à partir de maintenant, cela semble être le "Pas besoin de réinventer la roue". est correct.

Answer 4

IANAL, mais ...

Java et C # sont des sources fermées, et le CLUF contient donc des termes qui disent plus ou moins "Ce n'est pas notre faute si vous utilisez ce logiciel quelque part, ce que vous n'êtes pas censé". Ils ont également des équipes d'avocats pour se protéger et appliquer cette clause.

La plupart des licences open source n’ont pas le même langage, et même celles qui en ont, elles n’ont pas d’équipes d’avocats, comme l’a dit le PO.

De plus, Python et PERL sont plus anciens que Java et C #, à l’époque où il était illégal d’exporter des logiciels de chiffrement à partir des États-Unis. Ne pas ajouter de cryptographie depuis que la loi a été modifiée est peut-être simplement une "cohérence est bonne" décision.