反对开放源代码滥用的十字军东征-王其杉博客|程序员|科技新闻
萨里尔·德希潘德
撰稿人
Salil Deshpande担任贝恩资本风险投资公司的董事总经理。他专注于基础设施软件和开源软件。
更多撰稿人
共享条款阻止开源滥用
让我们定义“容器本土化”
地平线上有一片乌云。云基础设施提供商(如Amazon)的行为威胁到开源的可行性。我第一次在TechCrunch的前一篇文章中谈到了这个问题。值得庆幸的是,在2018年,几位领导人已经动员起来(在争议之中)提出解决这个问题的多种方案。这就是上个月发生的事情。
问题
转到Amazon Web服务(AWS),并在顶部的产品菜单上悬停。您将看到许多不是Amazon创建的,而是作为服务运行的开源项目。这为亚马逊每年提供了数十亿美元的收入。显然,这不是非法的。但这不利于开源社区的可持续发展,尤其是商业开源创新。
两个解决方案
2018年初,我召集了24家大型开放源码公司的创建者、CEO或总顾问,以及受人尊敬的开放源码律师希瑟·米克尔,讨论该做什么。
我们希望定义一个许可证,防止云基础设施提供商将某些软件作为商业服务运行,同时使该软件有效地为其他人开放源代码,即不将软件作为商业服务运行的每个人。
对于第一个提议,Commons子句,我们采取了最直接的方法:我们构造了一个子句,它可以添加到任何自由开源许可中,防止被许可方“销售”软件,其中“销售”包括将其作为商业服务运行。(当然,允许销售用Commons Class软件制作的其他软件。)应用Commons Class将项目从开放源码转换为可用源。
我们还喜欢另一个参与者MongoDB(称为服务器端公共许可证(SSPL))率先提出的建议。SSPL并不禁止软件作为服务运行,而是要求您开放源码用于使软件作为服务可用的所有程序,包括但不限于管理软件、用户界面、应用程序接口、自动化软件、监视器ng软件、备份软件、存储软件和托管软件,所有这些都使得用户可以运行服务的实例。这就是所谓的“版权所有”。
这两个许可证是完全相同的问题的两个不同的解决方案。Heather Meeker写了两个解决方案,支持由福萨组织反馈。
这些努力试图“欺骗”社区的最初喧嚣和指责幸运地让位于开源社区的理解和确认,这里有一个真正的问题需要解决,是时候让开源社区变得真实,以及现在网络巨头们应该为它们所依赖的开放源码付出公平的代价。
在十月,Apache软件基金会(ASF)的董事会成员之一向我伸出援手,建议共同创造一个现代开源许可证来解决行业的需求。
对蒙哥大的赞誉
MondoDB明确声明他们将使用SSPL,并将SSPL与名为开放源码倡议(OSI)的组织并行提交,以作为开放源码许可证进行认可,但并不等待OSI的认可开始发布SSPL下的软件,这更值得称赞。
OSI在某种程度上自诩为“决定”许可证是否是开源的机构,它习惯于短视地辩论什么是开源,什么不是。随着SSPL向OSI提交,MongoDB已经把球放在OSI的场地上,要么加快步伐,帮助解决一个行业问题,要么把他们的头埋在沙子里。
事实上,MangGDB对OSI有很大的帮助。MongoDB已经解决了这个问题,并将一个完全可用的开源许可证交给了OSI。
开源香肠
OSI关于SSPL的辩论的公开档案有时信息丰富,有时很有趣,近乎滑稽。在MongoDB最初的提交之后,成员们为寻找理由认为SSPL不是开放源码许可而欢呼,随后是一些+1的。成员John Cowan提醒小组,仅仅因为OSI不认可许可证为开放源码,并不意味着它是不开放源代码:
据我所知(这相当远),OSI不这样做。他们从未公开说过“许可证X不是开源的。”各种邮件列表上的人都这样做了,但是OSI本身并没有这样做。而且他们当然不会说“任何不在我们的OSI认证™列表中的许可证都不是开源的”,因为这将是错误的。编写一个明显是开源的许可证很容易,OSI出于各种原因永远不会进行认证。
Eliot Horowitz(CTO和MongoDB的联合创始人)对问题、评论和反对作出了令人信服的回答,总结如下:
简言之,我们相信,在当今世界,链接已经被提供节目作为服务和通过网络连接节目作为节目组合的主要形式所取代。目前尚不清楚现有的版权许可是否明确地适用于这种形式的程序组合,我们打算让SSPL成为开发人员解决这种不确定性的一种选择。
随后讨论了OSI的目的、作用和相关性。Van Lindberg、McCoy Smith和Bruce Perens提出了或解决了各种各样的法律问题。
希瑟·米克尔(起草了共同条款和SSPL的律师)介入并完全解决了迄今为止提出的法律问题。艾略特·霍洛维茨还做了其他各种澄清,他还表示愿意改变许可证的措辞,如果有帮助的话。
成员们继续讨论OSI的作用、相关性和目的,其中一位成员敏锐地指出,这个小组中有许多“自由软件”专家,试图将开源混为一谈,以鼓吹他们自己的议程:
相反,如果OSI已经决定他们现在是自由软件组织,并且自由软件是“我们”所做的,并且“我们”的重点是“自由软件”,那么让我们将名称改为“自由软件倡议”,并为其他一些实体打开大门,这些实体都是关于O的。笔源,担当那份工作,自豪地去做。-)
关于SSPL是否歧视用户类型存在争论,这将使SSPL失去开源的资格。艾略特·霍洛维茨给出了一个令人信服的解释,说明它并没有,这似乎让观众安静下来。
希瑟·米克尔对这个团体失去了一些更多的法律知识,这似乎足以解决悬而未决的问题。所谓的开源定义第6项的作者Bruce Perens承认SSPL不违反定义第6项或第9项,随后建议修改第9项,以便SSPL违反它:
我们不会因为这件事而掉以轻心。而且只要董事会能够开会,我们就可以通过添加“或执行”两个单词来修复OSD#9。但这很烦人。
凯尔·米切尔,他自己也是一位杰出的开源律师,反对这种策略。拉里·罗森指出,一些成员的断言(即“开源对于每个人都可以出于任何目的使用程序是至关重要的”)是不真实的。关于OSI的用途和开放源码的含义,接下来还有更多有趣的讨论。
Carlos Piana简洁地说明了为什么SSPL确实是开源的。Kyle Mitchell补充说,如果以该组判断SSPL的方式来判断许可证,那么GPL v2也不是开源的。
涌浪
同时,数据库公司ScyllaDB的创始人Dor Lior对SSPL和AGPL进行了比较,并认为“MongoDB使用Commons子句会更好,或者只是吞下一颗硬丸,然后留在APGL中。”Player.FM基于Commons子句许可的RediSe发布了他们的服务Arch,在内存数据库公司Redis Labs将RediSearch和其他四个特定附加模块(但不是Redis本身)置于Commons子句之下,以及图形数据库公司Neo4J将其整个代码库置于Commons子句之下,并筹集了8000万美元的系列E之后。
然后,红帽Ansible的创始人Michael DeHaan为他的新项目选择了Commons子句。当被问及他为什么没有选择OSI已经“认可”的任何现有许可证作为开源时,他说:
2018年的膨胀应该充分表明,存在一个需要解决的行业问题。
艾略特·霍洛维茨总结并解决了所有的问题,放下麦克风,离开了一会儿。当看起来SSPL确实遵循了开源许可的所有规则,并且获得了成员的支持时,Brad Kuhn提出了一个笨拙的论点,为什么OSI应该根据需要改变规则,以防止SSPL被视为开源,并得出结论:
很可能我们使用的整个“许可证评估过程”都有固有的缺陷。
米切尔的论点是,SSPL是开源的,具有决定性的点。Horowitz感谢成员们的评论,并表示愿意在修订中解决任何问题,并在几天后带着修订的SSPL返回。
OSI自蒙哥大的新提交做出选择后有60天:
醒醒过来,意识到SSPL(可能带有一些编辑)确实是一个开源许可证,或者
有效地向世界表明,OSI并不希望帮助解决该行业的问题,他们宁愿成为政策专家,进行理论辩论。
这里的“旺克”指的是尽可能好的方式。
重要的是,无论MunGDB是否继续使用SSPL。如果MongoDB要等到OSI的决定,或者如果OSI更相关,我们可能会屏息以待,以了解OSI是否会认可SSPL作为开源许可证。
因此,OSI的决策对OSI本身来说更为重要。