开源用户无需担心许可证合规性

目前尚无读者喜欢这个。
FOSS?

Opensource.com

许可证合规性是专有软件的一个主要且代价高昂的问题,但在这种情况下涉及的许可证是最终用户许可协议 (EULA),而不是提供广泛自由的源代码许可证。当我们进行同类比较时,我们发现开源软件没有此类问题。最终用户不需要许可证管理服务器,不需要进行审计,不需要害怕 BSA 的突击检查。开源软件要容易得多!

但这很容易被遗忘。 《纽约时报》最近报道了 GPL 执行社区的活动。虽然我个人很高兴有人在做这件事,但我担心他们善意的行为——以及其他地方的行为,例如 Linux 基金会的合规计划——是公众对开源软件理解的焦点。在许多可以成为首要考虑因素的软件自由属性中,在我看来,开源软件的最低许可证合规负担实际上是一个相对优势,并且将它们作为一项功能呈现,只会为软件自由的诋毁者应用“框架”。

关于框架

我欠美国进步学者 George Lakoff 关于框架的见解。正如他在《我们赖以生存的隐喻》中详细解释的那样,以及在《别想大象》(如果带有政治倾向)中更容易理解的术语中解释的那样,我们用来描述事物的词语和概念是塑造我们对事物理解的强大工具。用于谈论一个主题的术语的选择可以比我们想象的更强大地传达对该主题的看法和评价。因此,不断重复“税收和支出”来描述一个政党的政治,即使不带指责地使用(“他们不像你想象的那样容易提高税收,而且他们的支出在很大程度上受到控制”),也定义了评判该政党的标准,即他们提高税收的倾向,而真正应该进行比较的领域实际上可能在其他地方。

通过仔细选择用于谈论对手的一组术语和概念——围绕他们放置的“框架”——有可能完全分散观众对真正问题和实际好处的注意力,因为框架的受害者将花费所有时间反驳框架(从而加强它作为他们的定义问题),而不是谈论他们的优势。

开源合规性不是用户问题

我们需要担心许可证合规性吗?显然,尊重作者和遵守法律很重要,但对于我们大多数人来说,答案可能都是“否”,还有更重要的事情要担心。开源软件附带一组通常称为“四个自由”的自由。我对它们的总结是,任何在开源许可证下的软件都可以用于任何目的进行使用、研究、修改和分发,只要遵守许可证即可。我相信开源的所有好处都是这些自由的一阶和二阶导数。

  • 作为软件的用户,对您的使用没有任何类型的条件限制;您可以自由地将其用于任何目的。没有合规性要求。 请暂停并思考片刻。开源不对最终用户施加合规负担,不强制接受最终用户许可协议,也不让您受到 BSA 的准警察行动的影响。这是一个显着的优势,难怪专有供应商想要对您隐瞒它,并让您认为开源许可在某种程度上是复杂、繁重或有风险的。如果您只想使用该软件——这正是您被允许使用专有软件所做的一切,因为其他三个自由完全不存在——那么开源软件带来的风险要小得多。

  • 如果您超越了软件的使用并研究源代码,也没有合规负担。使用您获得的知识用于其他目的不存在任何风险。您不会以某种方式“受到污染”,并且在您使用这些知识构建相关软件时,无需创建“净化室”环境。

  • 如果您超越了研究代码并实际修改它,则没有合规负担。您可以自由地以任何您希望的方式使用修改后的版本,无论是在个人方面还是在您的业务范围内。无需说明您的使用情况,无需将您的改进发送到其他地方,也无需您参与社区。当然,如果您不这样做,您将无法获得与加入社区相关的所有好处,但无论如何,选择权仍然在您手中。

  • 如果您超越了修改代码并决定分发您修改后的版本(或原始版本),那么此时可能会出现与开源许可证的合规性问题。您只需要检查您是否将与您收到原始代码时相同的权利传递给他人。

    即使那样,并非所有开源许可证都对您施加任何重大责任。像 Apache、BSD、MIT 和 X11 许可证这样的许可证非常容易遵守,而像 CDDL 和 Mozilla 许可证这样的许可证,如果您参与开源社区,则几乎不需要任何管理工作——只需将代码提交回社区存储库就足够了。只有像 GPL 系列这样的强 copyleft 许可证才需要审计流程,即使如此,对于我们大多数人来说,它也并不比我们在版本控制系统中通常会做的跟踪工作更繁重。

确实存在一些公司在产品中交付开源代码时需要注意的问题,但在我看来,这些问题并不比交付专有软件引起的问题更复杂和繁重。重要的是要确保您知道您对您交付的所有内容都拥有必要的权利,并且当您交付由专有元素制成的代码时,您自然会这样做。只有马虎的开发人员才会不这样做,而 Linux 基金会的计划正是针对这种马虎的良药。

软件自由与许可证无关

使情况看起来并非如此的结果是,开源的更微妙的反对者能够提出关于合规性的F恐惧,附加只能通过额外成本才能解决的U不确定性,而这些成本实际上并不适用于大多数用途,从而播下D疑虑,即这种麻烦真的值得吗。这一切都具有 FUD 的经典特征,它扭曲了专有软件及其 BSA 调解的强制执行机构的弱点,并暗示开源软件也存在同样的问题。我们应该拒绝这个框架

最终,软件自由与许可证无关;它们只是机制的一部分。它关乎使用、研究、修改和分发软件的自由,我们可以自由地使用这种自由,无论多少,都不会受到干扰。让自己从自由中分心是一个错误,自由是个人和企业从开源中获得的所有好处的根源。不要让专有软件的力量对您这样做。拒绝这个框架,尽情享受您的自由吧!

[首次发表于 ComputerWorld UK]

标签
Simon Phipps (smiling)
计算机行业和开源资深人士 Simon Phipps 创立了 Public Software,这是一个欧洲开源项目托管平台,并以志愿者的身份担任 OSI 主席和 The Document Foundation 的董事。他的帖子由 Patreon 赞助人赞助 - 如果您想看到更多,请成为其中一员!

3 条评论

<p>
在专有案例中,您或许可以说服版权持有人给您一个特殊许可,让您在您的作品中(重新)使用他们作品的一部分(至少如果您付足够的钱),但在开源许可中,这通常甚至不是一种选择。因此,Linux 无法采用 OpenSolaris 的一部分,反之亦然,将 OpenSSL 与其他东西混合使用是不可靠的,……
<p>
请查看 David A. Wheeler 关于此事的 <a href="http://www.dwheeler.com/essays/gpl-compatible.html">文章</a>,以进行深入讨论。

就我个人而言,我很乐意在我们构建的一些软件产品中使用开源库等。不幸的是,GPL/LGPL 许可使希望使用这些模块/库的公司面临相当大的版权侵权诉讼风险,“贡献”一词的定义不明确,而且我认为我们都不想成为第一个在法庭上检验法律和许可协议的人。我认为,虽然开源的论点在代码的一致性和交叉传播方面很充分,但如果解决其中一些问题,仍然可以改进开源的采用。

最初错过了您的评论,抱歉。

我不认为您面临的风险与使用专有库的风险有任何不同;两者都有需要在交付产品中管理的合同条款。在 Sun 公司,我们对所有进入公司的受版权保护的材料都使用工作流程系统,以便我们可以跟踪和履行我们在交付的任何产品中的责任。将 GPL 软件视为某种有毒物质是对不熟悉事物的一种自然的初步反应,但允许它持续存在只是一个错误;管理风险,不要让风险管理您。

当然,这甚至是在假设存在风险的情况下。目前尚不清楚您是否为一家销售软件的公司工作;如果您是,那么肯定存在需要管理的风险,但如果您创建的软件产品供您自己的公司使用或部署为 Web 服务,则不会触发 GPL 的分发,并且基本上没有风险需要管理。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 3.0 Unported License 获得许可。
© . All rights reserved.