有开源媒体本周发布的一篇文章《开源界也要注意，Apache 基金会与 GitHub 都受美国法律约束》引发了开源届乃至整个 IT 行业的热烈讨论，其中有个别声音认为文章的说法有误，甚至制造了恐慌。
文中该媒体引用了两处内容，分别是 Apache 软件基金会与 GitHub 官网上关于相关产品与服务是否受美国出口法律约束的表述，其中大家似乎都明确了 GitHub Enterprise Server 会受到约束，而 Apache 部分则见解不同，并且这也是他人认为我们制造恐慌的焦点。 恰恰相反，过度渲染以制造恐慌是我们所反对的，开源中国的本意是希望借由昨天谷歌和华为的事件来提醒各位注意：在贸易战的背景下，美国出口法律对开源造成的风险。开源中国创始人红薯表示这锅咱们不背，他认为大家误解我们了，而这误解可能来自于 ASF 官网上本身描述得不够明确。 我们一直以为开源是无国界、完全不封闭的，但是却发现 Apache 软件基金会（下用 ASF）这个全球最大的开源软件基金会官网上有这样的内容：下面这段摘录自图片中 ASF 项目(ASF Products)关于出口说明的文字正是我们昨天发表那篇文章的根本原因。 美国的出口法律和法规适用于我们的分发，并且随着产品和技术再出口到不同的地方依旧保持有效。我们对这句话的理解是，除非经美国政府正式授权，否则 ASF 软件或技术不得直接或间接出口或再出口到受美国禁运或贸易制裁的任何地方。 经过与同行各位专家探讨，我们回看原文确实觉得，上边这句话表达的含义其实模棱两可，充满了不确定性。具体情况，请大家关注本次专辑…… 微软负责 .NET 的项目经理 Phillip 在博客宣布，他们已经将 F# 的 GitHub repo 从 microsoft/visualfsharp 迁移到 dotnet/fsharp，并按 corresponding RFC 中的规范来操作。 事实上，F# 的名字和品牌本身就有一段奇怪的历史。将时钟拨会 2015 年，当时 F# 有两个身份：一个是 Visual F#（或叫做 “VisualFSharp”），属于 Visual Studio 中的产品，包含可在 Windows 上使用的编译器和工具；另一个是 F#（或叫做 FSharp），这是一门独立的语言，可以独立于微软构建 F# 工具、库生态系统和软件包。
这种“双重性”的身份十分令人困惑 —— 如果你使用术语 F#，是希望表达何种含义？微软打造的工具还是其他东西？因此，F# 的创始人 Don Syme 在他的博客文章中写了一篇关于术语 “F#” 和 “Visual F#” 的公开信。 他建议的区分方法很简单：如果使用微软的 F#（即在 Windows 上通过 Visual Studio 使用），它就叫做 Visual F#；否则，就被叫做 F#。很简单是吧？但结果你可能已经猜到了，这些年来事情变得更加复杂...... 不过随着时间的推移，.NET Core 已经成为 F# 和整个 .NET 平台未来的核心。默认情况下，F# 也会安装在 Visual Studio 中，因为它是作为 .NET Core SDK 的一部分安装的。与此同时，许多 F# 社区已经接受了 .NET Core，移植了现有的库并创建了新的库以供 .NET Core 使用。更多内容，请关注本次专辑…… 据 OpenJDK 开发团队在邮件列表中的记录，有开发者反馈了一个这样的问题：可以看到，在构建这两个分别为 OpenJDK 8 和 OpenJDK 11 的版本时，均出现了问题。仔细观察内部版本号，这些 JDK 版本显示的发布时间均比实际发布时间要早。
这会导致什么问题呢？任何运行 OpenJDK 8 和 11 官方 Docker 镜像(https://hub.docker.com/_/openjdk)的人都可能以为他们正在运行 8u212 或 11.0.3，但事实上他们运行的可能只是一个临时的正在开发中的版本。 可能会有未修复的 bug 和未解决的 CVE 安全漏洞。对于导致出现这种版本号混乱情况的原因，大部分人认为这和 OpenJDK 团队没什么关系，更多是因为 Docker 团队或维护此 repo 的一方没有正确发布版本而导致的。 也有人认为这似乎与 Debian 有关，因为这些示例都附带了 Debian 版本字符串，并且它们可能是从版本控制存储库中的标记构建的。但不管如何，最终还是用户吃亏。 因为 OpenJDK 容器基于发行版容器，并为不同的发行版（debian，alpine，windows，slim debian，old debian version 等）发布多个版本。然后，用户将其容器置于 OpenJDK 容器之上，并将其包依赖项添加到其 docker 文件中。更多详细内容，请大家关注本次专辑…… |
