Laveesh Kocher 发布的文章

根据 Aiven 的一份新报告,谷歌已经提高了其对开源软件的投入,并在活跃贡献者方面超过了微软。

根据 Aiven 的报告(LCTT 译注:我没有找到这份报告),谷歌目前的活跃贡献者多于微软,这要归功于对开源代码库 GitHub 的每月提交量同比增长 20%。根据开源贡献者指数(OCSI)的数据,谷歌 7 月份有 5421 名活跃贡献者,而微软的活跃贡献者为 5268 名。

Aiven 联合创始人兼首席技术官 Heikki Nousiainen 说,谷歌超过微软“特别令人惊讶”。

“这其中的一个因素是微软对开源项目的提交逐年下降,”Nousiainen 说,“然而,微软对开发者自由和创新的投入是一致的,该公司是开源的主要参与者,甚至在 2018 年收购了 GitHub。”

Aiven 指出,亚马逊已经开始更加重视开源计划,其对 OpenSearch(ElasticSearch 的复刻)的支持以及 GitHub 上项目数量的增加就是证明。Nousiainen 认为,亚马逊对 OpenSearch 和 ElasticSearch 的支持代表了“该公司方向的重大改变”,以及对重大开源项目掌舵的愿望。据 Aiven 介绍,这些科技巨头正在迅速扩大对开源软件的使用。根据数据,现在来自亚马逊、微软和谷歌的活跃 GitHub 贡献者比六年前多了 300%。

“这项研究的总体信息是积极的,”Nousiainen 说,“在开源社区有大量的创新在继续发生,其结果使我们所有人受益。数不清的人正在为其他人树立一个榜样。”


via: https://www.opensourceforu.com/2022/08/google-surpasses-microsoft-in-terms-of-open-source-contributors-says-a-study/

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

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

在 2020 年 SolarWinds 网络间谍活动之后,一系列进一步的软件供应链漏洞凸显了确保软件监管链安全的必要性。在这场间谍活动中,俄罗斯黑客渗透到一个广泛使用的 IT 管理平台,并将受污染的升级程序悄悄带入其中。由于开源项目从根本上来说是分散的,而且经常是临时的活动,因此在这种背景下,这个问题尤其紧迫。GitHub 著名的 npm 注册中心广泛使用的 JavaScript 软件包遭到一系列令人不安的黑客攻击后,该公司前不久公布了一项战略,以提供更好的开源安全保护。

代码签名平台 Sigstore 将由微软旗下的 GitHub 支持,以用于 npm 软件包。代码签名类似于数字蜡封。为了让开源维护者更加容易地确认他们编写的代码是否与全球范围内人们实际下载的软件包中最终包含的代码相同,跨行业协作促成了该工具的创建。

GitHub 并不是开源生态系统的唯一组成部分,但 Sigstore 的联合开发者、Chainguard 的首席执行官 Dan Lorenc 指出,它是社区的一个重要枢纽,因为绝大多数项目都在这里存储和共享源代码。然而,当开发人员真正想下载开源软件或工具时,他们通常会通过软件包管理进行。

通过让包管理器可以使用 Sigstore,开发人员可以在 Sigstore 工具的帮助下,在软件通过供应链时处理加密检查和要求。这增加了产品流通过程中每个阶段的透明度。Lorenc 说,许多人在得知这些完整性检查尚未实施时感到震惊,开源生态系统中相当大的一部分长期以来一直依赖于盲目的信心。拜登政府于 2021 年 5 月发布了一项行政命令,主要涉及软件供应链安全问题。

Linux 基金会、谷歌、红帽、Purdue Universit 和 Chainguard 都对 Sigstore 的开发做出了贡献。现在有了使用 Sigstore 为 Python 包发行版签名的官方软件,而且开发软件的开源环境 Kubernetes 现在也支持它。

Sigstore 依靠免费和简单易用来鼓励采用,就像主要行业推动 HTTPS 网络加密一样,这在很大程度上是由非营利组织 互联网安全研究组 Internet Security Research Group 的 Let's Encrypt 等工具实现的。据 GitHub 称,该项目会首先提出 Sigstore 将如何在 npm 中实现的建议,并在开放评论期征求社区人员对该工具的精确部署策略的意见。然而,最终的目标是让这样的代码签名能够被尽可能多的开源项目使用,从而让对供应链的攻击更加困难。

GitHub 的 Hutchings 说:“我们希望看到这样一个世界,最终所有的软件工件都被签名并链接回源代码,这就是为什么构建像 Sigstore 这样的开放技术栈是如此重要,其他打包存储库也可以采用这种技术。”


via: https://www.opensourceforu.com/2022/08/github-takes-action-to-prevent-supply-chain-attacks-on-open-source/

作者:Laveesh Kocher 选题:lkxed 译者:lzx916 校对:wxy

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

开源是一个具有挑战性的概念。许多人认为,开源意味着可以任意的使用软件,并且可以免费下载。这实际上取决于你如何被许可 —— 开发者分享代码时使用的许可证决定了它。开源软件可以是收费的,也可以限制你如何去使用它,在极少数情况下,甚至让你陷入法律纠纷。

Fedora 项目最近决定拒绝所有使用 知识共享 Creative Commons “公共领域专用” CC0 许可证的代码,以避免这种情况的出现。CC0 将从新提交代码中准许使用的许可证列表中剔除,但是,像艺术品一类的贡献仍被允许所以它,甚至可能在个案的情况下对当前的软件包进行逐一的处理。

如果 Fedora 反对一个软件许可证,通常不会成为新闻。事实上,在那么多的许可证当中,该项目拒绝了许多许可证。这种情况的意外之处在于,CC0 最初被认为是一个有效的许可证,现在只是由于更大的自由及开源(FOSS)社区内的观点转变而被重新分类。

CC0 是因为什么让 Fedora 决定停止支持它,这又是否意味着你不能在你自己的项目中使用它呢?

这一段描述让最熟悉知识共享及其许可系列的人惊讶的是,Fedora 最初批准了 CC0 的软件。毕竟,知识共享从一开始的目标是为艺术作品提供一系列明确的许可证。该组织的使命和许可证的要求在其名称“知识共享”中就有所体现。

为了“克服分享信息和创造力的法律障碍”,提供一个自由的框架来为人们组织分享如音乐、医学或教育材料的资源,知识共享组织的前身—— 开放内容项目 Open Content Project ,于 2001 年成立。然而,软件从来不是它的组成要素。为什么呢?因为那时,如 MIT、GPL 一类的重要的软件许可证已经出现了十几年。

很明显,如果一家公司不遗余力地警告你他们制造的东西不适合某种特定用途,你也许应该相信他们。知识共享的 FAQ 列出了一些反对在软件上使用他们的许可证的令人信服的论据,但对于像 Fedora 项目这样的用户来说,其中一个问题特别突出:专利权。

鉴于 CC0 许可证是为公共领域的作品准备的,而且通过使用它,创作者明确地“放弃了他或她在版权法下对作品的所有权利”,这似乎矛盾的。但是,问题在于,版权法并不适用于专利。事实上,仔细审视许可证的完整措辞后可以发现,它在一个令人担忧的部分解决了这个问题,该部分内容如下:“宣告者拥有的任何商标或专利权都没有被本文本放弃、抛弃、交出、租赁或以其他方式修改。”

换言之,即使被 CC0 许可的东西的作者可能愿意放弃对它的权力,但他们仍然可以自由的为它申请专利。更糟糕的是,他们仍然保留着以他们认为合适的方式使用该专利的能力。

理论上来说,这意味着最初在 CC0 下提供的源代码的人在发布了代码之后,他们可能会在之后断言任何使用该代码的人侵犯了他们的专利,并要求支付专利费。

这显然会让像 Fedora 这样的项目担忧。考虑一下这样的情形:CC0 许可的代码进入到一个系统的核心,然后被提供给数以百万计的用户。突然间,不知道从哪里冒出来的原创作者,声称侵犯了专利权,并要求付款。红帽或 Fedora 的律师可以驳倒这种说法么?也许吧。那么,为了查明真相而使用 CC0 代码值得么?不值得。

要着重提到的是,这完全不是一个新问题。实际上,早在 2012 年,专利条款就阻止了开源倡议(OSI)许可证的审查委员会,他们无法最终确定 CC0 是否真正符合他们对开源许可证的定义。委员会未能达成一致意见,因为其成员认为将此类条款纳入软件许可将创造一个危险的先例。考虑到 Fedora 动荡的历史,它最初接受 CC0 的决定着实让人费解。


via: https://www.opensourceforu.com/2022/08/what-made-fedora-choose-to-use-cc0-licensed-code-as-the-boot/

作者:Laveesh Kocher 选题:lkxed 译者:yjacks 校对:wxy

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

7-Zip 是用于 Windows、Mac 和 Linux 的知名开源文件归档器。它的最新版本 22.00 现已推出。它是 2022 年的第一个稳定版本。上一个版本是 21.07,于 2021 年 12 月发布。7-Zip 的用户可以从官方网站获取该应用的最新版本,下载适用于 Windows 64 位、32 位和 ARM 版本。该应用仍然与过时的 Windows 版本兼容,例如 XP 和 Vista。它还支持所有官方支持的 Windows 版本,包括服务器版本。适用于 Linux 的 7-Zip 22.00 已经可以下载,但 Mac OS 版本还不可用。

7-Zip 22.00 包含一些增强了应用功能的新特性。这个归档器现在支持提取 苹果文件系统 Apple File System (APFS)镜像。几年前,苹果公司在 Mac OS 10.13 和 iOS 中引入了苹果文件系统。该文件系统在设计时就考虑到了闪存(Flash)和固态硬盘(SSD)存储。

7-Zip 22.00 包括了对其 TAR 存档支持的多项增强。使用选项 -ttar -mm=pax-ttar -mm=posix,7-Zip 现在可以创建符合 POSIX 标准的 tar 格式的 TAR 档案。此外,使用选项 ttar -mm=pax -mtp=3 -mtc -mta,7-Zip 可以在 tar/pax 存档中存储高精度的文件时间戳。

最后,Linux 用户可以在 TAR 归档文件中使用以下两个新选项:

  • snoi:将所有者/组 ID 保存在存档中,或将所有者/组 ID 从存档复制到提取的文件中。
  • snon:在存档中保留所有者/组的名称。

适用于 Windows 的 7-Zip 22.00 添加了对 -snz 选项的支持,该选项用于传播区识别符(LCTT 译注:区标识符是微软在 2013 年为 IE 设计的安全功能,它会标记那些用户自网络上所下载的文件,并在用户准备打开时跳出警告)。

要提取文件,请使用标识符流。出于安全目的,Windows 使用了该流,它可用于确定文件是在本地创建的还是从互联网下载的。

在“ 添加到存档 add to archive ”配置对话框中,7-Zip 22.00 包含一个新的选项窗口。它包括用于更改时间戳精度、更改其他与时间相关的配置选项,以及防止更改源文件的最后访问时间等选项。


via: https://www.opensourceforu.com/2022/06/the-final-version-of-7-zip-22-00-is-now-available/

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

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

2022 年 6 月 16 日,微软更新了其应用商店的策略。其中一项禁止了发布者对开源或免费的软件收取费用,另一项则针对的是商店使用的不合理高价。如果你在过去几年中访问过微软应用商店,你可能已经注意到,它正在成为越来越多的开源和免费产品的所在地。如果原始开发者将应用程序和游戏上传到商店,这将是有益的,但情况并非如此,因为它们是由第三方上传的。

更糟糕的是,其中许多程序仅作为付费应用提供,而不是免费下载。换句话说,微软的客户必须付费才能购买应用商店的版本,而它们在其他地方是免费的!在应用商店中,免费版和付费版有时并存。为免费应用付费已经够糟糕的了,但这并不是用户在购买时可能遇到的唯一问题。更新也可能是一个问题,因为山寨应用可能不会像源头应用程序那样频繁或快速地更新。

在更新的微软商店政策中,微软在 10.8.7 节下指出:

在您决定产品或应用内购买的定价时,您的数字产品或服务的所有定价(包括销售或折扣)必须:

遵守所有适用的法律、法规和监管要求,包括联邦贸易委员会的《反欺骗性定价指南》。您不得试图从开源软件或其他可免费获得的软件中获利,您的产品也不应提供一个(与它提供的特性和功能相比)过高的不合理定价。

这个新策略在更新部分中得到了确认。如果开源和免费产品普遍免费提供,则它们不得在微软应用商店上出售,发布者也不得对其产品收取不合理的高价。开源和免费应用的开发者可以在微软应用商店上为其产品收费。例如,Paint.net 的开发者就是这样做的。如果微软强制执行这些策略,许多应用将从应用商店中删除。以前,开发者可以向微软报告应用程序,但在新策略下,微软可以直接控制应用的列出和提交。


via: https://www.opensourceforu.com/2022/06/microsoft-to-charge-for-available-open-source-software-in-microsoft-store/

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

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

自 2016 年开源以来,Mattermost 一直在开发一个具有不断增加的用例的消息传递平台。6 月 16 日,Mattermost 7.0 平台发布,其中包括了新的语音呼叫、工作流模板和用于开源技术的应用框架。新版本扩展了 2021 年 10 月发布的 6.0 版本引入的功能。一直以来,Mattermost 都在与包括 Slack、Atlassian 和 Asana 在内的几家大公司,竞争不断增长的协作工具市场。另一方面,Mattermost 侧重于对开发者的支持,尽管该平台也可用于安全和 IT 运营。

Mattermost 的软件同时提供有商业版和开源版,目前它们都升级到了 7.0 版。Tien 解释说,Mattermost 的商业平台是建立在开源基础上的。在开放核心模型中,开源版作为软件的基础或核心,专有的企业功能则内置于商业版中。合规性、规模性和高级配置是 Mattermost 的关键企业功能。Tien 声称,开源版本对于中小型团队来说已经足够了。他认为,拥有 500 名或更多用户的团队才需要考虑使用商业版。

Tien 认为开源也关乎社区贡献。Mattermost 开源项目有超过 4000 名个人贡献者,他们贡献了超过 30000 行代码。

以前,Mattermost 依赖集成第三方呼叫服务(例如 Zoom)来启用语音呼叫功能。在 7.0 版本中,它通过开源 WebRTC 协议引入了呼叫功能的直接集成,所有现代 Web 浏览器都支持该协议。直接集成呼叫功能的目标是为协作提供单一平台,这符合 Tien 对该平台的总体愿景。现在,除了提供集成工具以实现协作之外,该平台还会增加“工作流模板”功能,以帮助(用户)组织构建可重复的流程。

工作流概念采用了 剧本 playbook ,其中包含了为“特定类型的操作”所执行的动作和操作的清单。例如,在发生服务故障或网络安全事件时,公司可以为事件响应创建工作流模板。

这个清单可以链接到 Mattermost 操作 operation ,例如让特定用户发起呼叫,并协助生成报告。Tien 表示,Mattermost 还与常见的开发者工具集成,并且工作流模板的功能将随着时间的推移而扩展,以便使用第三方工具来实现更多自动化。


via: https://www.opensourceforu.com/2022/06/mattermost-extends-workflow-platform-with-7-0-release/

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

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