众所周知，开源密码工具在美国的开发存在很大问题：由于美国出口限制，所有基于 ssh 的开源软件都是专门在 A 的美国以外开发的。
http://www.employees.org/~satch/ssh/faq/ssh-faq-1.html#ss1.10.2
虽然位于美国，但如果我想重用一些 MIT 许可的 ssh 代码，比如来自 OpenSSH、Dropbear 或 PuTTY 的代码，并在其上编写一些功能，并在类似的许可下将结果作为开源发布，该怎么办？作为我获得原始代码的依据？
我不是数学爱好者，所以我的 ssh 贡献很可能只包含深度集成部分：例如，创建各种基于 ssh 的文件传输客户端。
我是否打开了可能因美国出口违规而在刑事案件中被起诉的大门？
想要利用加密功能的美国团体经常使用的一个技巧是通常单独加载此功能的一种方式。以不使用加密源代码分发的方式构建您的应用程序，并提供有关如何从创建者处获取首选源代码并将其构建/链接到您提供的代码的附加说明。
只要您不修改库，而仅在它们之上构建，它就可以工作。
里程因开发语言和用户的技术知识而异。
这也很好，因为它强制了某种程度的抽象 - 如果您不想导出的 API 的表面区域有限，这也意味着您对它们的依赖有限，并且可以更轻松地升级或如果您以后发现其他您更喜欢的东西，请切换它们。
我认为只要没有实际的密码学代码与新的基于 ssh 的工具一起重新发布，那么这种基于 ssh 的工具就可以在美国编写。
我假设它可能会限制在现有 ssh 产品和正在寻求 ssh 集成的产品之间实际实现更深层次集成的能力：例如，做一个 sftp 客户端可能最终会有些棘手，这取决于抽象是在导入以进行黑客攻击的原始代码中完成的。
但是，基本上，发布一组单独的补丁，在现有的基于 ssh 的代码和文件系统客户端之间进行集成，恕我直言，应该是一个安全的选择。只要确保没有原始 ssh 实现或任何加密函数与此类补丁一起发布。