开发人员可以通过将开源软件集成到其代码库中，节省时间并避免重复发明轮子。然而，这也带来了严重的许可侵权风险。你必须遵守适用于重新使用的开源代码的众多开源许可证之一。如果你不这样做，你（或你所在公司）有可能因违反开源许可证条款而被起诉。即使这种诉讼并不普遍发生，它们确实存在。实际上，考虑到现在许多开源项目由希望保护其在开源社区中的投资的企业运营，这种情况在未来可能更加频繁发生。

1、熟悉开源许可证

了解开源许可证是防止开源许可侵权问题中最重要的一步。很容易认为所有开源许可证都施加相同的条件，或者它们都基本要求源代码的持续可用性。实际上，有数十种不同的开源许可证，它们都有着非常不同的条款。简单地认为只要你从一个开源项目获取代码，你可以随意使用它并保持源代码可访问，这是一个严重的错误。几个开源许可证的一个典型但经常被忽视的条件可能是需要向原始作者提供致谢。

2、记录你使用的开源内容

建立一个标准化的方法来记录你使用开源代码的情况是一个优秀的做法。导入模块或从 GitHub 粘贴代码并不难。但如果你不追踪代码来自何处以及使用了何种许可证，你可能会忘记在代码库中如何以及在哪里集成开源内容。此外，如果你在借用代码时无法证明自己遵守了有效的许可条件，那么在开源许可证发生变化时可能会产生问题。考虑在文档维基（如果有的话）中添加一个页面，列出你使用的开源代码，以避免出现这个问题。每当你包含开源组件或依赖时，至少在你自己的源代码中添加注释。

3、避免使用未经授权的开源组件

有时，你可能会偶然发现一个隐藏的 GitHub 存储库或其他源代码托管位置，其中包含你希望使用的代码，但没有提到任何许可指南。你可能会认为代码的创建者希望让其成为开源代码，并且你可以根据自己的意愿使用它。但这是一个危险的假设。开发人员可能会后续对代码设置特定的许可条件，并要求你遵守这些条件，这可能导致未来产生许可侵权的指控。除非你有非常充分的理由，否则避免使用缺乏明确许可限制的模糊代码。

4、创建自己的开源代码

将你自己的软件完全开源是减少与开源许可相关风险的一种方法。这意味着你将自动遵守任何要求保留派生源代码的开源许可条件。然而，请记住，仅仅开放你自己的代码并不能确保完全遵守许可证。你仍然需要努力确保你遵守每个许可证的规定，因为适用于你借用的代码的许可证可能与你选择的开源许可证不同。然而，你无需担心与源代码共享相关的任何条款。

5、自动检测开源组件

虽然在代码库内手动跟踪你如何使用开源是很好的做法，但通过使用能够自动识别开源组件和依赖项的软件，你可以降低出错的可能性。在这里，我们应该考虑两种不同类型的工具。一种是源代码组成分析（SCA）软件，它会自动扫描源代码并识别从值得信任的外部来源获取的元素。另一种是软件供应链管理解决方案，除其他功能外，还支持查找和监控应用程序堆栈中的任何开源依赖项。

（题图：MJ/2168d466-cfc3-47de-a8a5-fc7ebaaa445f）

via: https://www.opensourceforu.com/2022/08/5-ways-to-prevent-open-source-licensing-violations/

作者：Laveesh Kocher 选题：lkxed 译者：ChatGPT 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

软件自由保护协会 Software Freedom Conservancy （SFC）是一家由开源倡导者组成的非营利性社区。今天（本文原文发表于 2022 年 7 月 5 日），它发布了一篇抨击性的博文，宣布退出 GitHub，并请求其成员及支持者公开谴责该平台。SFC 与 GitHub 的如此纷争，源于这一颇受指责的举动：微软和 OpenAI 训练了一个名为 Copilot 的 AI 系统，而其训练数据的来源，是那些使用了开源许可证公开的代码。开源代码不是捐款箱，不是想拿多少就拿多少，想怎么用就怎么用的。

它更像是摄影作品。即便摄影师没有向你收取照片的使用费，你仍需要在该署名的地方进行署上来源。据 SFC 的一篇 博文 所述，Copilot 在使用他人的代码片段时，并没有保留来源信息：

“这反映了 GitHub 长期以来的问题，也是我们必须一齐放弃 GitHub 的关键原因。从 Copilot 中，从 GitHub 的代码托管服务中，从我们所见的基本每个领域，我们都发现 GitHub 的行为比其同行要差得多。我们也不相信 Amazon、Atlassian、GitLab 等其他盈利性的代码托管平台，能有杰出的表现。然而，将 GitHub 的行为与其同行相对比较一下，就能发现 GitHub 的行为要差得多了。”

GitHub 是全世界事实上的开源代码仓库。它是 YouTube、Twitter 和 Reddit 的混合体，但专为程序员及其代码服务。自然，替代品是有的。但是，从一个代码仓库生态切换到另一个，并不等同于用 Instagram 来替代 TikTok。微软在 2018 年花了 70 多亿美元来收购 GitHub。从那时起，微软就利用其 OpenAI 的主要受益者的地位，来共同开发 Copilot。并且，要访问 Copilot 服务，只能通过微软的特别邀请，或者支付订阅费。该举激怒了 SFC 及其他开源倡导者，因为微软和 OpenAI 实际上在将他人的代码货币化，同时让使用这些代码的人们不能正确地表明归属信息。

Copilot 必须毁灭。或者，微软和 OpenAI 可以造一台时光机，然后穿越到过去，将 Copilot 数据库中的每一点数据做标记，从而能够为所有输出提供正确的署名。但是，与其去关心你产品或者服务中的伦理问题，不如去鼓动人们，去开拓那荒野西部似的监管环境，后者总是更加简单的。

（题图：MJ/1a101872-c0d6-475e-b3e2-3646c9a2d66b）

via: https://www.opensourceforu.com/2022/07/github-copilot-is-only-effective-because-it-steals-open-source-code/

作者：Laveesh Kocher 选题：lkxed 译者：Peaksol 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

安卓的一个重要进展是将 安卓开源项目 Android Open Source Project （AOSP）移植到 RISC-V 处理器架构。

AOSP 已经开始在上游启用 RISC-V，这将促进 RISC-V CPU 在可穿戴设备、物联网，以及最终在智能手机和笔记本电脑中的使用。

为了开放生态系统，中国科学院 PLCT 实验室的工程师和软件开发人员在 2020 年开始将 Android 10 移植到 RISC-V 架构上。阿里巴巴的云计算部门和平头哥芯片子公司一起努力保持开发与最新的安卓版本同步。

“我们很高兴看到谷歌对构建针对 RISC-V 的 AOSP 的更多支持！阿里云一直致力于通过一系列的创新来支持 RISC-V 社区的发展，比如将安卓的基本功能移植到 RISC-V 上，这证明了在从多媒体到信号处理、设备互联和人工智能等场景中使用基于 RISC-V 的设备的可行性。”阿里云生态系统总监、RISC-V 国际组织的应用与工具水平委员会副主席 David Chen 博士说：“我们期待着与安卓团队合作，为繁荣的 RISC-V 社区做出贡献。”

通过增强 RISC-V 上的安卓系统的基本功能，在 2021 年，阿里云的专家们付出了巨大的努力，积极推动了软件生态系统的发展。 RISC-V on Android 的工作集中在 RISC-V Android 工作组和软件库中进行。

via: https://www.opensourceforu.com/2022/11/the-android-open-source-project-is-now-risc-v-compatible/

作者：Laveesh Kocher 选题：lkxed 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

自 Copilot 首次亮相以来，Butterick 就对该计划提出了批评。

微软在 2018 年支付 75 亿美元收购了 GitHub，此后将这个代码仓库整合到其开发者工具中，同时在很大程度上采取了放手的态度。Matthew Butterick 是一名作家、律师，也是一名程序员，他认为微软基于机器学习的代码助手 GitHub Copilot 存在一些问题，它似乎不正确地对待开源代码许可证。

GitHub Copilot 是 Visual Studio 和其他 IDE 的一个插件，通过在你输入时提供代码完成的 “建议” 来运作。Codex 是该系统的动力源。然而，Butterick 等开发者认为 AI 在如何学习方面存在问题，或者更具体地说，AI 是从哪里训练的。

这里的问题是，GitHub 所训练的公开代码仓库是有许可证的，当他们的工作被利用时，需要按照许可证进行。虽然微软对其使用代码的问题一直避而不谈，称其为合理使用，但 Copilot 除了提供建议外，还能生成逐字逐句的代码部分。

根据 Codex（由微软授权）的开发者 OpenAI的说法，“Codex 是在数以千万计的公开代码仓库中训练出来的，包括 GitHub 上的代码。”微软自己也含糊地将训练材料描述为数十亿行的公共代码。

via: https://www.opensourceforu.com/2022/10/github-copilot-appears-to-be-in-violation-of-the-open-source-licence/

作者：Laveesh Kocher 选题：lkxed 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

谷歌 AI 引入了一个用于数组存储的高性能开源库 TensorStore。

谷歌开发的开源 C++ 和 Python 框架 TensorStore 旨在加速大型多维数组的读写设计。覆盖单一大型坐标系的多维数据集通常用于当代计算机科学和机器学习应用程序中。使用这些数据集具有挑战性，因为客户经常希望进行涉及多个工作站并行操作的调查，并且可能会以不可预测的间隔和不同的规模接收和输出数据。

谷歌研究院开发了 TensorStore，该库为用户提供了一个可以管理巨大数据集的 API，而无需复杂的硬件，以解决数据存储和操作问题。该库支持许多存储系统，包括本地和网络文件系统、谷歌云存储等。

为了加载和处理大量数据，TensorStore 提供了一个简单的 Python API。任何任意大小的基础数据集都可以加载和更新，而无需将数据集完整存储在内存中，因为在需要精确切片之前不需要在内存中读取或保存实际数据。

这是通过索引和操作语法实现的，它与 NumPy 操作的语法非常相似。除了虚拟视图、广播、对齐和其他复杂的索引功能，TensorStore 还支持如数据类型转换、降低取样和随意创建的数组这些功能。

此外，TensorStore 包含一个异步 API，可以并发进行读取或写入操作。在执行其他工作时，软件可以进行内存缓存处理（可配置），从而减少在访问常用数据时处理较慢存储系统的需要。

大型数值数据集需要大量的处理能力来检查和分析。实现这一点的常用方法是在分散在许多设备上的大量 CPU 或加速器内核之间并行化任务。在保持出色速度的同时并行分析单个数据集的能力一直是 TensorStore 的关键目标。 PaLM、脑图和其他复杂的大规模机器学习模型是 TensorStore 应用案例的一些例子。

via: https://www.opensourceforu.com/2022/10/google-ai-unveils-a-new-open-source-library-for-array-storage/

作者：Laveesh Kocher 选题：lkxed 译者：KevinZonda 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

开源代码可能是当今大多数公司最可行的选择，但它也伴随着自己的问题。

许多人支持使用 开源软件 open source software （OSS）。毕竟，我们为什么要不断地尝试构建代码来解决别人已经解决过的问题？为什么不分享信息并逐步和迭代地增强当前的开源解决方案呢？这些 平等主义价值观 egalitarian values ，可能是整个文明的根本，更不用说软件了，但还是包含了几千年来一直存在的冲突。

开源软件安全的问题在于，尽管任何人都可以查看源代码，但这并不意味着他们会这么做。有一些广泛使用的开源项目仅由数量有限的工程师维护。这些工程师无法完全自愿地提供时间和精力，因为他们也需要支付他们的账单。

即使对于更复杂的开源项目，这也是一个问题。举个例子，Linux 内核项目由 3000 多万行代码组成，包含数百个需要解决的缺陷，并有近 2000 名活跃的开发者。每个活跃的开发者都写了超过 15000 行的代码。

根据 Linux 基金会最近的一项研究，一个应用程序平均有 5.1 个重大漏洞仍未解决，41% 的企业对其开源软件的安全性缺乏信心。而更糟糕的是，只有 49% 的企业拥有开源安全策略。

即使开源软件有安全漏洞，这也不能保证它能被修复。调查显示，目前修复一个漏洞平均需要 97.8 天，使使用该软件的企业在几个月内容易受到攻击。这就是开源软件安全有时被忽视的地方：就像好人可以寻找代码中的错误和漏洞来修复它们一样，坏人也可以寻找同样的漏洞来利用它们。

仅仅依靠志愿者社区来发现漏洞、报告漏洞和修复漏洞是一个漫长的过程。在你继续受益于开源的广泛优势的同时，花钱请人检查你的开源解决方案的安全性可以帮助弥补这个问题。

由于必须部署开源软件的更新和补丁以保证系统的安全，这一要求会带来独特的困难。如果你的解决方案依赖于某个软件版本，更新你的关键任务软件可能会导致功能损失和/或计划外的停机。当情况对业务至关重要时，聘请专家来回传补丁并维护一个时间更长的版本可能比让大型社区愿意去做更加优雅。

开源社区经常使用的一句话是：“这是开源的，去改变它吧！”它强调了一个关键点：当别人在项目中投入时间、精力或金钱的时候，期望白白得到良好的安全水平是不合理的，也是不可持续的。

要么按原定计划为开源做出贡献，改进代码并为他人发布，要么聘请专业人士管理开源代码并在必要时进行调试，这些都是选择。然而，这个行业无法承担完全不做贡献。

via: https://www.opensourceforu.com/2022/10/security-issues-with-open-source-in-todays-world/

作者：Laveesh Kocher 选题：lkxed 译者：KevinZonda 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出