标签 许可证 下的文章

“我们现在的许可证已无法满足需求,” 自由软件的先驱 Bruce Perens 如是说。

Bruce Perens,作为开源运动的创始人之一,已准备好迎接接下来的新阶段:后开源运动。

“我已经写过关于这个话题的论文,试图构建一个许可证原型,” Perens 在与 The Register 网站的独家采访中解释道,“很显然,我需要律师的协助。接下来,我将寻求一些研究资金。”

Perens 提到,开源社区需要解决几个紧迫的问题。

“最首要的一点,我们现在的许可证已无法满足需求,”他表示,“我们已经给了企业太多时间去找到所有的漏洞,因此,我们需要做出些新的改变。当三分之一的付费 Linux 系统在销售时都规避了 GPL 许可证时,很显然 GPL 并没有起到应有的作用。我说的就是 RHEL。”

RHEL 是 红帽企业 Linux Red Hat Enterprise Linux 的缩写,6 月份,这个属于 IBM 的公司 停止 了对 GPL 源代码开放。

Perens 近期刚从中国回来,他在 Bench 2023 大会上做了主题发言。在准备与我们的对话时,他写下了一些关于他的访问以及关于开源软件社区现状的看法。

他脑海中涌现的一件事是关于红帽的问题。

“红帽已经不是那个红帽,而是 IBM,”Perens 在给 The Register 分享的备忘录中写道,“显而易见,他们已经停止了对 CentOS 的分发,而且很长的一段时间里,他们一直在做我认为违反 GPL 的事情,我曾因为另一家企业做同样的事情提起过 诽谤案:他们告诉你,如果你是 RHEL 的客户,你不能公开 RHEL 制作的安全补丁的 GPL 源代码,否则他们将不再允许你成为他们的客户。这些 IBM 的员工坚称,他们仍然在为上游开源项目贡献补丁 —— 而他们实际上并没有这个义务。

“这种状况已经持续了很长时间,只因为红帽公开发行 CentOS(本质上是 RHEL 的无品牌版本),我们才容忍了这一情况。但现在 IBM 不再这么做了。因此,我感觉 IBM 已经从开源社区得到了他们想要的一切,而我们却收到了他们的中指。

“显然,CentOS 对许多企业同样重要,他们正在努力采用 Rocky Linux。我倒是希望他们能切换到一个 Debian 衍生版本,不过这也没什么。而开源这只骆驼背上已经有很多稻草了,会不会有一根压垮它呢?”

另外一根压在开源骆驼背上的沉重稻草,Perens 写道,“是开源完全未能服务于普通人。在大多数情况下,如果他们使用的是开源软件,也是通过如苹果公司的 iOS 或谷歌的安卓这样的专有软件公司的系统,这两者都用开源作为基础设施,但大部分应用程序还是专有的。普通人对于开源一无所知,他们也不知道我们所倡导的自由是他们应该日益关心的问题。其实,现如今,开源已经被用来监视甚至剥削他们。”

正如 Perens 所阐述的,自由软件走过了半个世纪的历程,而开源的首度亮相也已有 30 年的光阴。“难道现在不该是我们审视过去所做所为,并寻求是否能做的更好的时候了吗?当然,同时我们也需要对开源进行保护。开源将一直存在,并提供相同的规则和范式,但接续开源的新模式应当有一个全新的称谓,并且永远不应该假冒为开源。此刻,我暂且称其为‘ 后开源 Post-Open ’。”

他所描述的“后开源”,比开源稍微复杂一些。它将明确企业与开发者的关系,以确保企业为所获得的利益支付合理的费用。对于个人和非营利机构,仍可免费使用,而且只需一个许可证即可。

他设想了一个简单的年度合规程序,让企业可以获得使用“后开源”软件所需的所有权利。企业将会资助开发者,鼓励他们编写非技术专家也能使用的软件。

Perens 指出,看看苹果公司、谷歌和微软等的流行应用,“因为许多软件倾向于以用户为目标,所以他们当然会受到大量的监控,甚至在某些情况下被滥用。所以,开源开始真正为普通人服务的时机已经到来。”

Perens 表示,目前这种情况不常见的原因在于,开源开发者多是为自己和同样精于技术的人群编写代码。他坚信,为了避免这一情况,应支付给开发者报酬,让他们有时间和支持去编写用户友好的应用。

他建议,这笔费用由公司承担,可以采用一种类似度量 GitHub 的软件,据此分配付款给贡献者,这个软件能精确显示出谁为哪个产品做出了多少贡献。他说,Merico 就是提供这样一种软件的公司。

Perens 承认,这需要解决很多阻碍。例如,需要找到一个可以接受的机构来负责度量和分发资金。而且,这种金融结构必须有足够的吸引力,让大量的开发者愿意参与。

他深思道:“而且,所有的这一切必须既足够透明,又具备足够的灵活性,以防止出现许多不同的分叉。因此,我其实也觉得担心,这种设想真的可以实现吗?”

不论这种设想能否成功,Perens 相信,仅仅依靠 GPL 是远远不够的。“GPL 的设计不是作为合同,而是作为一个许可证。 理查德·斯托曼 Richard Stallman 的初衷并不愿意剥夺任何人的权利,他只是想给予大家权利。因此,它不是合同,而是许可证。然而,我们不能再这样了,我们需要具有执行力的合同条款。”

当被问到像 HashiCorpElasticNeo4jMongoDB 这样的公司采用非开源许可证是否代表了一种可行的服务模式,Perens 认为这需要新的思维。

他对像 “ 公共资源条款 Commons Clause ” 这样的许可证非常反感,因为这正是 Neo4j 陷入 法律纠纷 的中心原因之一。

他写道:“为什么公共资源条款会引发问题?首先,涉及到品牌问题。开源许可证有一个‘品牌’,这是对他们所赋予的权利的理解。当然,开源本身也有品牌,即对开源定义中的权利的理解。然而,公共资源条款看似使用的是开源许可证,但实际上并没有提供同样的权利,这样就滥用了该许可证的品牌,以获取利润。

“另一个问题是,公共资源条款被添加到不允许进行添加条款的许可证中,如 Neo4J 上的 AGPL v3。AGPL 和 GPL 的条款都明确禁止增加新条款。因此,当许可人添加公共资源条款时,他们创造了一个自我矛盾的许可证。”

Perens 告诉 The Register:“我们已经在(软件即服务)问题上投入了大量的研究。我记得参加过一个(自由软件基金会)会议,问题就是,‘我们该如何应对谷歌?’ 结果是,那次会议后诞生了 AGPL。”

在云服务公司的环境下,Perens 认为 AGPL 或其他各种非开源许可证没有找准关注的重点。

Perens 说,“像 AGPL 这样的许可证,要求软件以某种方式公开自己的源代码。但我们实际上讨论的是软件的公开演示,而这在版权法下是一种独立的权利,因为它对于戏剧和电影来说是必需的。由此,我们有权利使用这项在版权法下的权利。我认为那些许可证都在尝试着去实现一个目标,由于它们只试图在开源的基础上稍做改动,所以它们只达成了部分目标。要知道,我们已有 30 年的开源历史了,是时候做一些彻底的变革了。”

当被问到现在大家对 AI 的热情时,Perens 表示了他的不满。

他说,“我认为 AI 总是在剽窃。当你训练模型时,你其实是在用其他人的受版权保护的东西来训练。AI 所做的就是混合、匹配,然后输出所输入内容的组合。我们必须考虑这一点,我们该如何补偿那些数据用于训练模型的人们呢?我们应该使用开源软件训练它吗?我不这么认为,AI 还有更多的功能,比如读取人们的网站、读取整个维基百科。但对于这些输入的贡献者,他们并未得到合理的补偿。所以这确实是一个我们需要解决的大问题。”

至于美国试图阻断中国技术的努力是否有效,Perens 表示这些基本上没有效果。

他说,“中国人能做到我们所做的所有事情,只有一两个例外,但也马上就会赶上。”他指出,尽管他们在先进的芯片方面落后,但他们会迎头赶上。(此处有删节)

他也提出,由于美国的出口法律,特别是美国国务院施行的国际武器交易限制(ITAR)和美国商务部监管的出口管理法规(EAR),与中国保持一定程度的友好关系对开源社区也有影响。

Perens 解释道:“目前,空间卫星、数字语音编码器、某些 Kraken RF 项目的应用,还有可能数百个其他的开源项目,都还在受限技术名单之上。然而,由于好几起诉讼的影响,ITAR 和 EAR 都为‘公开的信息’开了一道口子,这并不意味着是‘公域软件’,那是版权的问题。它的含义是‘非商业秘密’,所以它包括开源与公开的研究。

“现在,根据 ITAR 和 EAR,完全公开的项目可以不受限制地运行。不久前, 开源研究院 Open Research Institute 做了一项工作,使这样的项目得到了美国的国务院和商务部的明确批准。因此,目前有可能运行一个开源项目,开发原本可能属于 ‘军用’ 的技术,包括与原本受 ITAR 和 EAR 限制的国家合作。这对于我们保护开源技术和公共研究都很重要。随着美国政客对 3D 打印枪支等事务越来越关心,以及许多人希望更严格地限制与中国等国的技术分享,这项权益总是受到威胁。”

Perens 表示:“我认为,我们有可能与这个国家发生纷争,这是非常可怕的。但如果你看看这些人,他们和今天的我们非常相似。我们真的应该和平共处。”

(题图:DA/b125f972-5005-44c0-8fd2-88526c27b307)


via: https://www.theregister.com/2023/12/27/bruce_perens_post_open/

作者:Thomas Claburn 译者:ChatGPT 校对:wxy

并不是,不过 “功能源代码许可证” 却更进一步混淆了开源许可证的界限。

回溯到我们还用打孔卡和磁带载入软件的那时,所有的程序都是 “自由软件” 和 “开源” 的。然而随后专有软件的出现,一切都变了。针对此状况,程序员们反抗并发展出了第一个正式的自由和开源软件的定义。

现如今,不开源的代码甚至成为了罕见的例外。然而,这并未阻止某些误将开源视为一种商业模式,而非开发模式的公司,试图将专有方法和 “开源” 代码相结合。最新的案例就是 Sentry 推出的 “ 功能源代码许可证 Functional Source License ”(FSL)。

沿袭 服务端公共许可证 Server-Side Public License (SSPL)、 公共条款 Common Clause 商业源代码许可证 Business Source License 的传统,FSL 表面上似乎重视开源的重要性,却对开源的核心理念进行嘲讽,形容其方式为“享有自由却无需付出努力”。

呵呵。

其实,Sentry 是一个面向开发者的应用代码监控服务,它源于对 Django(一款开源的,高级的 Python 网络框架)的少量代码开发。如今,它仍然主要用开源代码进行开发。不难看出,没有开源,Sentry 啥都不是。

这也同样适用于其他所有使用 “ 源代码可用 source-available ” 或其他半开源许可证的公司。它们都源自于开源公司,然后为了最大化利润,它们将免费获取的代码进行了重新许可,以锁定代码。

正如 开源倡议 Open Source Initiative (OSI)董事会副主席 Thierry Carrez 对我说的,“有些公司通过利用开源代码库作为主体建立了他们的软件,不需要在使用数百个开源软件包作为他们的依赖关系之前就请求许可。他们通过公开承诺遵守开源原则建立了口碑。但在试图追求更大价值的过程中,他们短视地放弃了最初带给他们成功的模式。”说的真对。

例如 Sentry、MariaDBRedisHashiCorp 这样一些前开源公司,之所以他们能做出这样的举动,可以归功于他们采用了侵犯了权利的 贡献者许可协议 Contributor License Agreements (CLA)。这些协议是一种法律文件,它定义了贡献者为他们的代码在开源项目中被使用所设定的条款。尽管有些 CLA,像 Apache 软件基金会的 CLA 或 Linux 的 开发者原创证书 Developer Certificate of Origin ,只是用来保护他们项目的法律权利。但其他一些,比如 MongoDB 的贡献者协议,却被用来占有你的代码及其版权。通过这样的 CLA,在任何他们喜欢的方式中使用和重新许可你的代码,对于他们来说易如反掌。

SourceHut 的创始人兼首席执行官 Drew Devault 在谈论 Elasticsearch 从开源向“源码可用”转变时表达了他的观点:“Elasticsearch 归其 1,573 名贡献者所有,他们自己保留着版权,并向 Elastic 授予了一个无条件分发他们作品的许可。当 Elastic 决定 Elasticsearch 不再开源时,他们就利用了这个漏洞,这个漏洞实际上一开始就被他们故意安插进去…… Elastic 对 1,573 的贡献者们、以及所有信任、忠诚于他们,给予他们支持的人们翻了脸。”

如今,我们看到企业 Sentry 和之前的案例如出一辙,换汤不换药。公正地讲,Sentry 很长一段时间以来都一直在使用源码可用许可证。在该公司创建并采用 FSL 前,自 2018 年以来就用了 BSL。如果还有人继续向 Sentry 捐献代码,那他们肯定知道自己在做什么。

那么为何还要做一个新许可证呢?Sentry 的开源负责人 Chad Whitacre 这样解释道:“BSL 存在两个显著的弊端。首先,预设的非竞争期为四年,对于软件行业来说,这简直就是个漫长的周期。这可能会让人产生一种感觉,即最后的开源转变只是一种象征性的举措。这几乎可以说是 100 年那么长。对于 Sentry,我们选择将这个期限缩短到三年,但我们也承认,可能连三年都过长了。”

该许可证期满后,这些代码将会使用 Apache 2.0 或者 MIT 许可证。但实际上,这并不像初听起来那么慷慨。根据 FSL,你可以将它的代码用在任何用途 —— “除了竞争性使用的情况下。所谓竞争性使用,指的是利用该软件开发或提供能够与我们的产品或服务竞争的商业产品或服务,不论是该软件本身,还是我们基于该软件提供的任何其他产品或服务,只要我们是在该软件发布之日或之前就已经提供了这类竞争产品或服务。”

换种说法,你可以查看代码,但不能用这些代码运营业务。如需更深入了解,你可以查看该公司的 FSL 版本的 Apache 和 MIT 许可证。就我个人而言,我认为这两个都不算是开源许可证。

Whitacre 进一步说明了,“更严重的缺陷是 BSL 有过多的参数:变更日期、变更许可证,以及额外使用授予。最大的问题在于额外使用授予,它是一项巨大的填空题,意味着每一个 BSL 实质上都是不同的许可证。”

我无法反驳这一观点。每个公司的 BSL 都不一样。同时,这也意味着当客户与使用 BSL 的公司签约时,他们很难确切知道法律上为他们保留了哪些权益。Sentry 希望通过 FSL 让其产品和服务对其客户更具吸引力。

也许这方法行得通。但我赞同 Carrez 所说的:“发布另一种能剥夺开发者在技术选择中的自主权的许可证变体并非新鲜事:他们其实就是要从整个软件生态系统中摧毁开发者的基本自由,从而明确自己对其专有软件及其许可使用权的所有权。这并不是开源:这只是包装在开源幌子下的专有门户。”

(题图:MJ/beb19f23-c230-4a3f-9bb3-210066ad749b)


via: https://www.theregister.com/2023/11/24/opinion_column/

作者:Steven J. Vaughan-Nichols 译者:ChatGPT 校对:wxy

你认为开源许可证应当进行演变吗?

2023 年,我们以人工智能(AI)崭露头角开始了新的一年,同时也见证了众多公司全力以赴投身于 AI。

比如说 Mozilla,它在 2023 年初制定了 开源 AI 计划,以开发各种 AI 驱动的解决方案。而 HuggingChat 也成为了第一个推出 ChatGPT 开源替代品 的组织。

即便是 Meta,他们也不例外。他们自家的 大型语言模型 Large Language Model (LLM)Llama 2 项目在这一年都颇受关注,几个月前他们甚至推出了一款新的 ChatGPT 竞争对手

然而,也有很多人开始 提出质疑,主张 Meta 的 Llama 2 模型并不像人们期望的那样开放,查看它的开源许可证似乎更是印证了这个观点。

该许可证 不允许拥有超过 7 亿日活跃用户的服务使用 Llama 2,同样的,它也不能被用于训练其他的语言模型

这也就意味着 Meta 对于 Llama 2 的许可证 未能满足 开源倡议组织 Open Source Initiative (OSI)的 开源定义 Open Source Definition (OSD)所列出的 全部要求

人们可以争辩,像 EleutherAIFalcon 40B 这样的机构就做出了很好的示范,展示了如何适当地处理 AI 的开源许可。

然而,Meta 对此的看法却截然不同。

开源许可需要进化

在与 The Verge 的交谈中,Meta 人工智能研究副总裁 Joëlle Pineau 为他们的立场进行了辩解。

她说,我们 需要在信息共享的益处和可能对 Meta 商业造成的潜在成本之间寻找平衡

这种对开源的态度让他们的研究人员能够更加专注地处理 AI 项目。她还补充说:

开放的方式从内部改变了我们的科研方法,它促使我们不发布任何不安全的东西,并在一开始就负起责任。

Joëlle 希望他们的生成型 AI 模型能够和他们过去的 PyTorch 项目一样受到热捧。

但是,问题在于现有的许可证机制。她又补充说,这些许可证并不是设计来处理那些需要利用大量多源数据的软件。

这反过来为开发者和用户提供了有限责任,以及,对版权侵犯的有限赔偿(解释为:保护)。

此外,她还指出:

AI 模型与软件不同,涉及的风险更大,因此我认为我们应该对当前用户许可证进行改变,以更好地适应 AI 模型。

但我并不是一名律师,所以我在此问题上听从他们的意见。

我赞同她的观点,我们需要更新现有的许可方案,使之更好地适应 AI 模型,以及其他相关事务。

显而易见,OSI 正在努力进行此事。OSI 的执行董事 Stefano Maffulli 向 The Verge 透露,他们了解到 当前的 OSI 批准的许可证无法满足人工智能模型的需求

他们正在商讨如何与 AI 开发者合作,以提供一个 “透明、无许可但安全” 的模型访问。

他还补充说:

我们肯定需要重新思考许可证的方式,以解决 AI 模型中版权和授权的真正限制,同时仍遵循开源社区的一些原则。

无论未来如何,显然,开源标准必须推动其演化,以适应新的以及即将出现的技术 ,而此类问题不仅仅局限于 AI。

对于未来几年开源许可的变革,我充满期待。

? 对于你来说呢?你认为对于陈旧的开源标准,我们需要进行什么样的改变?

(题图:MJ/e8bae5f6-606b-47db-aaea-c992c0bd143e)


via: https://news.itsfoss.com/open-source-definition-ai/

作者:Sourav Rudra 选题:lujun9972 译者:ChatGPT 校对:wxy

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

HashiCorp 放弃开源原则这件事并无新意。

在加利福尼亚蒙特利召开的 Linux 基金会成员峰会 Linux Foundation Members Summit 上,最受关注的议题是人工智能和开源。而第二重要的话题涉及到 HashiCorp 放弃 Terraform 的 Mozilla 公共许可证 Mozilla Public License (MPL),转而采用 商业源代码许可证 Business Source License (BSL)1.1,以及由此引发的 OpenTofu 项目复刻。因 Linux 基金会对 OpenTofu 项目的支持,HashiCorp 的 CEO David McJannet 表现出极度的不满。

关于许可证切换、源代码复刻以及由此产生的争议,火热的讨论并未减少。但在我看来,有一点被人们忽视:人们一直误认为这是新鲜事物,实则不然。

之前已经有过不止一次,甚至不止十次,公司将开源代码转变为专有程序,或者隐藏在一个专有的包装中。

首先,人们经常拿走开源代码,但却抹去其许可证信息,然后就此继续下去。虽然这并不一定构成窃取行为,实际上,有些许可证,比如 MIT 许可证和两句版 BSD 许可证,完全允许公司和开发者在他们的专有程序中使用这些代码。例如,我们都熟知以下基于 MIT 许可证的程序,比如 Angular、.NET、Node.js、Ruby on Rails 和 React。

其次,有一些程序最初以开源的形式开始,但随着时间的推移,原始所有者和许可证规则发生了变化,以至于许多人甚至都不知道它们曾经是开源的。举例来说,苹果公司的 macOS 就是其中的一个典型。

你是否知道 macOS 曾经是开源的?确实,它曾经是。

macOS 的核心基于 Darwin,这是一种 Unix 操作系统。 史蒂夫·乔布斯 Steve Jobs 回归苹果公司时,引入了他的基于 Unix 的 NeXTStep 操作系统。到了 2000 年,苹果公司逐步放弃了他们的经典 Mac 操作系统,转而支持 macOS Darwin。除了来自 NeXTStep 的部分,Darwin 还大量借鉴了开源的 FreeBSD 和 Mach 操作系统的设计。

如今,如果你深入研究,仍然可以在 macOS 中找到 Darwin,它在 苹果公共源代码许可证 Apple Public Source License 2.0 下开源。虽然还有一项名为 PureDarwin 的工作正在努力制作一个独立的 Darwin 操作系统,但进展甚微。在这个过程中,苹果公司巧妙地减弱了一个重要的开源操作系统的影响力。更为常见的方式是开源软件以 “ 开放核心 open core ” 的方式融入商业程序中。简而言之,开放核心,与开源不同的是,这是一种商业模式。在这种模式中,公司基于一个免费的、开源的核心程序,然后通过加入商业版本或者专有的附加组件来发展。

此术语由 Andrew Lampitt 在 2008 年提出,虽然代表的并不是一个新的概念。他提出这个术语是为了替代混乱的术语 “ 双重许可 dual licensing ”。这个命名更改是为了 “消除误解,推广一个对于开源社区、付费客户和供应商都有利的商业模式”。同时,其目标也是为了消解我们现在在 HashiCorp 看到的 “ 诱捕并切换 bait and switch ” 类似的争议。

尽管我们可以辩论这是否是一个 “出色的商业模式”,但无可争议的是它已经成为一个非常流行的模式。然而,近年来,我们看到的趋势是,许多企业从开放核心模式退回到 源码可得 source-available 模式。在源码可得模式下,你可以查看所有的代码,但在某些情况下你不能修改或使用它。

例如,MongoDB 创建 了一种非开源许可证,即 服务端公共许可证 Server Side Public License (SSPL),以应对那些通过提供自托管版本和服务从其代码中获利的超级云计算公司。

并非只有 MongoDB 做出了这样的决定。Elastic 在开源核心模型运作的很好,但当亚马逊 AWS 等公司通过提供 ElasticSearch 服务赚取巨额利润时,Elastic 在 2021 年做出了 策略调整。它放弃了开源的 Apache 2.0 许可,转而采用非开源的 SSPL 和 Elastic 许可证。

Elastic 和其他几家公司(如 Redis 等)的此类做法,主要目的是阻止云服务公司将他们的开源程序作为一种服务而提供。然而,这个做法反过来对 Elastic 产生了负面影响,因为 AWS 对这个项目进行了 复刻。这一切是否让你想起了 HashiCorp?是吧。

尽管这些向非开源许可的转变惹怒了一些用户和很多开发者,但这些公司的业绩仍表现相对稳定。你可能对此感到不满,但事实是,对于这些公司来说,这种转变在一定程度上取得了成功。

接着,我们来看红帽公司的情况。红帽公司对其红帽企业 Linux(RHEL)代码的使用 施加了限制,只允许其客户使用。几十年来,红帽公司一直在权衡作为开源领导者与处理 RHEL 克隆产品(例如 CentOS,以及最新的 AlmaLinux 和 Rocky Linux)的关系。

随着时间的推移,红帽公司对与他人共享其代码表现出越来越大的犹豫。现在,你可以(且很多人确实正在这么做)辩论红帽公司不再是一个真正的开源公司。批评者认为,红帽公司虽然仍然严格遵守 GNU 通用公共许可证(GPL)的条款,但已经失去了开源精神。

虽然 RHEL 和与其相关的一系列程序仍在产生可观的利润,但红帽公司希望能够从中获取更多的收益,因此,它也开始逐步偏离开源原则。

实际上,所有这些案例的共同之处在于:对更大财富的欲望。如圣经所言,“贪财是万恶之根”。我不确定这一句话的真假,但我确实知道,对金钱的热爱和开源原则很难两全。

对于从开源软件中赚钱并没有错误之处。 理查德·斯托曼 Richard M Stallman (RMS)曾言:“工作寻求报酬,或者寻求尽可能增加收入,这并没有错,只要不采用破坏性的方式即可。” 然而,在 RMS 看来,“通过限制它们的使用来从程序的用户中挤取金钱,是一种破坏行为。”

尽管在现今开源软件与商业实践交汇的情况下,RMS 的观点可能并不如过去那样深受欢迎,但他仍然拥有众多的支持者。

(题图:MJ/b06e9a62-5c0d-49c5-a7b3-fd5af60ac0b1)


via: https://www.theregister.com/2023/10/27/open_source_vs_sort_of_open_source/

作者:Steven J. Vaughan-Nichols 译者:ChatGPT 校对:wxy

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

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

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中国 荣誉推出

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

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中国 荣誉推出