Simon Phipps 发布的文章

谨以此文纪念 “ 开源软件 open source software ” 这个名词的二十周年纪念日,开源软件是怎么占有软件的主导地位的?以后会如何发展?

 title=

二十年以前,在 1998 年 2 月,“ 开源 open source ” 这个词汇第一次出现在“软件”这一名词之前。不久之后, 开源的定义 Open Source Definition (OSD) 这一文档被创建,并成为了撒播 开放源代码促进会 Open Source Initiative (OSI)的种子。正如 OSD 的作者 Bruce Perens 所说:

“开源”是这场宣传自由软件的既有概念到商业软件,并将许可证化为一系列规则的运动的正式名称。

二十年后,我们能看到这一运动是非常成功的,甚至超出了当时参与这一活动的任何人的想象。 如今,开源软件无处不在。它是互联网和网络的基础。它为我们所有使用的电脑和移动设备,以及它们所连接的网络提供动力。没有它,云计算和新兴的物联网将不可能发展,甚至不可能出现。它使新的业务方式可以被测试和验证,还可以让像谷歌和 Facebook 这样的大公司在已有的基础之上继续攀登。

如任何人类的造物一样,它也有黑暗的一面。它也让反乌托邦的监视和必然导致的专制控制的出现成为了可能。它为犯罪分子提供了欺骗受害者的新的途径,还让匿名且大规模的欺凌得以存在。它让有破环性的狂热分子可以暗中组织而不会感到有何不便。这些都是开源的能力之下的黑暗投影。所有的人类工具都是如此,既可以养育人类,亦可以有害于人类。我们需要帮助下一代,让他们能争取无可取代的创新。就如 费曼所说:

每个人都掌握着一把开启天堂之门的钥匙,但这把钥匙亦能打开地狱之门。

开源运动已经渐渐成熟。我们讨论和理解它的方式也渐渐的成熟。如果说第一个十年是拥护与非议对立的十年,那么第二个十年就是接纳和适应并存的十年。

  1. 在第一个十年里面,关键问题就是商业模型 —— “我怎样才能自由的贡献代码,且从中受益?” —— 之后,还有更多的人提出了有关管理的难题—— “我怎么才能参与进来,且不受控制 ?”
  2. 第一个十年的开源项目主要是替代现有的产品;而在第二个十年中,它们更多地是作为更大的解决方案的组成部分。
  3. 第一个十年的项目往往由非正式的个人组织进行;而在第二个十年中,它们经常由创建于各个项目上的机构经营。
  4. 第一个十年的开源开发者经常是投入于单一的项目,并经常在业余时间工作。 在第二个十年里,他们越来越多地受雇从事于一个专门的技术 —— 他们成了专业人员。
  5. 尽管开源一直被认为是提升软件自由度的一种方式,但在第一个十年中,这个运动与那些更喜欢使用“ 自由软件 free software ”的人产生了冲突。在第二个十年里,随着开源运动的加速发展,这个冲突基本上被忽略了。

第三个十年会带来什么?

  1. 更复杂的商业模式 —— 主要的商业模式涉及到将很多开源组件整合而产生的复杂性的解决方案,特别是部署和扩展方面。 开源治理的需求将反映这一点。
  2. 开源拼图 —— 开源项目将主要是一系列组件,彼此衔接构成组件堆栈。由此产生的解决方案将是开源组件的拼图。
  3. 项目族 —— 越来越多的项目将由诸如 Linux Foundation 和 OpenStack 等联盟/行业协会以及 Apache 和 Software Freedom Conservancy 等机构主办。
  4. 专业通才 —— 开源开发人员将越来越多地被雇来将诸多技术集成到复杂的解决方案里,这将有助于一系列的项目的开发。
  5. 软件自由度降低 —— 随着新问题的出现,软件自由(将四项自由应用于用户和开发人员之间的灵活性)将越来越多地应用于识别解决方案是否适用于协作社区和独立部署人员。

2018 年,我将在全球各地的主题演讲中阐述这些内容。欢迎观看 OSI 20 周年纪念全球巡演!

本文最初发表于 Meshed Insights Ltd. , 已获转载授权,本文,以及我在 OSI 的工作,由 Patreon patrons 支持

关于作者

Simon Phipps - 计算机工业和开源软件专家 Simon Phipps 创办了公共软件公司,这是一个欧洲开源项目的托管公司,以志愿者身份成为 OSI 的总裁,还是 The Document Foundation 的一名总监。 他的作品是由 Patreon patrons 赞助 —— 如果你想看更多的话,来做赞助人吧! 在超过 30 年的职业生涯中,他一直在参与世界领先的战略层面的开发 ... 关于 Simon Phipps


via: https://opensource.com/article/18/2/open-source-20-years-and-counting

作者:Simon Phipps 译者:name1e5s 校对:wxy

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

Facebook 公司的 BSD+专利许可证失败的原因不是因为许可证本身,而是因为它忽略了开源软件更深层次的本质。

2017 年 7 月,Facebook 公司应用于 react 等项目的许可证组合被 Apache 软件基金会禁止使用。该许可证组合曾被 Facebook 应用于其所有作为开源软件发布的项目,它使用了被 OSI 批准的广泛使用的非互惠许可证 BSD 3-Clause,并且加入了宽泛的、非互惠的专利授权条款,但为了应对挑衅者,该许可证组合的终止规则同样宽泛。这种组合代表了一种新的开源许可证,我称之为“Facebook BSD+专利许可证”(FB + PL),在我看来,该许可证试图与 GPL v2 和 Apache v2 许可证保持兼容,以规避这些许可证所指称的不兼容性。

使用 FB + PL 许可证的 Apache 项目仍在发挥作用,但是我认为 Facebook 所犯错误的原因可能不会立即被一贯秉持实用主义态度的软件开发人员们所注意到。例如,由律师转行做程序员的 Dennis Walsh 针对这个问题表示:“它没有什么实质意义”。他的观点是,FB + PL 许可证仅对你所使用的适用该许可证的特定软件项目产生影响,专利授权撤回的后果对另一个专利持有者来说并不严重。他得出结论说:

“Facebook 想要推广开源软件同时不被起诉——这是一个崇高的目标。为此,它可以使用一些苛刻的条款。但在这种情况下,由于上述实践和法律方面的原因,很难在被攻击之后发现是谁干的。”

Dennis 也许是对的,但这并不重要。Facebook 自出机杼地发明自己的开源许可证是一个坏主意。有一系列非直接风险或具体情境的重要因素需要考虑,Facebook 的许可证几乎将它们完全忽略了。

  1. 许可证审批很重要
    使用非 OSI 批准的许可证意味着,就像任何专有许可证一样,将其应用于企业用途时总是需要法律审查。OSI 许可证审批之所以重要,是因为它为开发人员提供了一种指示,即社区评估已经认可了该许可证,并认为它以不会产生不可接受风险的方式提供了软件自由。如果 Facebook 采取了寻求 OSI 批准的路线,那么很有可能一开始就会发现并且回避了他造成的问题。实际上有一种 OSI 批准的许可证能够实现 Facebook 的明确目标(BSD + 专利许可证)。该许可证最近刚被提交和批准,这看起来是 Facebook 可以考虑采用的合理替代方案。
  2. 较少的提前许可
    不仅仅是许可证批准很重要。任何有关创新自由的不确定性都会阻碍开发人员使用代码。与使用相关的含糊条款在使用前需要消除歧义——该步骤相当于为了继续推进而寻求许可。出于同样的原因,公共领域对于软件开发者来说是不利的,因为使用条款规定了在采用之前需要寻求许可。由于需要向项目添加一个与 Facebook 相关的法律文件,每个企业开发人员现在都需要与法律顾问联系,才能继续推进。即使答案是“是的,可以”,他们仍然不得不停下来寻求许可。正如 Aaron Williamson 指出的那样,这可能不是他们的反应。
  3. 不公平的比赛场
    Facebook 使用的专利授权条款为其提供了特殊权利和保护,而项目中的其他人并不享有。这使得开源开发人员感到紧张,原因与 贡献者协议 ( contributor agreements ) 一样。开源项目的软件自由的全部价值在于它创造了一个安全的空间,在其中每个人都是平等的,它保护每个人免受他人动机的影响。刻意为自己设置额外权利是反社会的行为,可悲的是,开源社区有很多不平等权利最终被滥用的例子。
  4. 隐含的授权无效
    许多开源法律机构认为,通过对用于任何目的的软件使用授予许可,即使没有提及专利的许可证也隐含授予专利许可。通过添加任意形式的外部专利授权,Facebook 表示它不认为隐含授权足够(最好的情形)或存在(最差的情形)。专注于开源软件的律师们认为,这是 Facebook 毫无根据的扩大化解释。这也是为什么 OSI 放弃了对 CC0 许可协议批准的原因。
  5. Apache 基金会的规则
    虽然我没有找到清晰和完整的理由,但 Apache 基金会似乎已经对 Facebook 的许可证组合做出了裁定,因为 Apache 基金会认为,Facebook 的专利授权比 Apache v2 许可证中的专利条款限制性更强。Apache 基金会希望自身是一个中立的软件来源——一个“万能供血者”,而对此产生妨害的条款很有可能违背其规则。对于旨在成为 Apache 生态系统一部分的组件,与 Apache 的许可证产生混乱的做法看起来不太明智。

所以争论这个问题没有什么意义,因为风险很小,问题微不足道。以一种忽视我上面列出的五个社区规范的方式行动无益于任何人,甚至也帮不了 Facebook。虽然 Facebook 目前正在坚持己见,但我希望它能够改正,我愿意提供帮助。


作者简介:Simon Phipps 是 “公开软件” ( Public Software ) 开源项目的发起人,以志愿者身份担任 OSI 和 文档基金会 ( The Document Foundation ) 的理事。

译者简介:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

随着 Solaris 团队的彻底完蛋,看起来 Sun 微系统公司最终连块骨头都没剩下。

来自前 Sun 社区的消息表明,一月份的传闻(Oracle 裁员 450 人)成为了现实,上周五,Oracle 裁掉了 Solaris 和 SPARC 团队的核心员工,选择这个时候( 美国劳动节 ( Labor Day ) 前的周末)或许是希望这个消息被大众所忽略。

可以肯定,这意味着对于这些产品只会剩下骨架级的维护,特别是, Solaris 12 也取消了。这是一个典型的 Oracle 式的“ 无声结局 ( silent EOL ) ”,无论他们怎么声称保证履行对富士通和其它客户的合同条款。

随着该硬件的淘汰,我估计这是最后一个被 Oracle 收购处置的 Sun 资产了。在收购 Sun 微系统公司之后,Oracle 的埃里森对 Sun 的管理毫不留情,而且最大化地利用其手中的机会。那么,Sun 的资产都在 Oracle 手里都有什么遭遇呢?我并不是很关注 Oracle 的业务,但是可以从下列报告中一窥:

  • Java 被称之为“皇冠上的宝石”,但是其买下 Java SE 的真实原因其实是——试图起诉 Google 赔偿 80 亿美金,而且还两次败诉。
  • 埃里森说 Java 是中间件成功的关键,但是现在 Java EE 正准备交给一个开源基金会。
  • Oracle 批评 Sun 没能从 Java 上挣到钱(忽略了 1996 - 2000 年 Java 使硬件市场获利的事实)并提出了一个根本不会产生收入的免费模型。
  • 他们 拥抱了 NetBeans,而现在它被捐献给了 Apache 基金会。
  • 对 MySQL 安全修复的官僚主义导致一部分社区成员转而和 MySQL 创始人 Monty 创建了 MariaDB 分支,而新分支已经足以支撑起一家公司。
  • 埃里森说要重建 Sun 的硬件业务,但是其负责人已经在一个月前离职了,而剩下的员工也属于裁员的一部分。
  • 尽管 Sun 的前老板 McNealy 明白 Solaris 只有开源才能赢得市场,Oracle 表示“你说的没错”,然后把 Solaris 弄死了。其结果就是,上周末的裁员——而这在今年一月份就已经有了传闻。
  • Hudson 处理失当,意味着其 CI 业务只能跟在 CloudBees 从 Hubson 分支而来的 Jenkins 后面。
  • Oracle 放弃了 Sun 的身份管理项目,而现在 Forgerock 用它撑起了一个价值五亿美金的业务,为那些 Oracle 所不在意的客户服务。
  • Oracle 决定 取消 Sun Cloud ,并拆除了 Solaris 中的云服务功能,然后现在是云服务的天下了。
  • Oracle 重命名了 StarOffice,然后宣布了一个云端版本,但是没卵用。感觉该项目将走向末日,遭受到了严厉对待的社区决定另起锅灶去做 LibreOffice。
  • 只有 VirtualBox 看起来还好。

也许这并不是 Sun 失败的真正原因——在开源 Solaris 上花了太长时间,并在 2000 - 2002 年间试图用以市场为主导的方式来替代 Sun 一贯的工程为主导的方式——埃里森指责那些承担力挽狂澜责任的、硕果仅存的领袖们 McNealy、Zander、Tolliver 和他们的团队。埃里森从来没有理解过 Schwartz 所采取的开创性做法,而是在博客中嘲讽和取消所有正在进行中的“科学项目”,拆除合作伙伴渠道,溯源开源社区。

与本周 HPE 将放弃的旧产品卖给 Micro Focus ,让其照料这些产品的做法相反,Oracle 的做法更残酷。Oracle 说过它将“重振 Sun 品牌”,但是事实上他们杀死的产品比 Sun 管理层曾经管理过的都要多——毫无疑问,这是“交易的艺术”。今天,和许多前 Sun 同事一样,这件事使我非常悲伤。

(本文由 Patreon 赞助支持, 欢迎你也成为支持者之一!)

你的组织的律师准备好与开源社区打交道了么?不要让他们犯这些错。

 title=

我注意到有相当多的人尝试与开源推进联盟的许可证评估社区以及 Apache 软件基金会的法律事务委员会建立沟通,当轮到你与开放社区进行法律讨论时,我想提供一些成功的提示和技巧。

不要代理人

首先,也是最重要的是,要确保进行谈话的人员既是有资格的,也是有授权的。不要用代理人,这只会让社区沮丧,他们很快会发现你的代表总是扮演二手车推销员的角色并且要求到后面的房间交易。显然,法律讨论将涉及公司的一个团队,可能涉及产品管理、工程和内部咨询。 但代表们需要能够自己控制谈话内容,不要总是引用幕后某个匿名人物的话。

多边主义

开源社区就安全合作所需的确定性达成了难得一致的共识。这种共识体现在其治理中,尤其是在他们使用的开源许可证中。所以当你提出一个新的提案时,就不像是一个普通的商业交易。这些是双边谈判,以双方的自由为代价来创造一个最佳妥协的和平条约。在这个讨论中,你只是许多方面之一,你需要解释为什么你的提案对所有人都有益。写上多边之间的调整本质上是缓慢的,所以不要设置最后期限。无论你做什么,不要建议对开源许可证进行更改!

首先学习

现有的共识和过程其存在是有原因的。你应该了解每个元素的原因,最好连同其发生的历史一起了解,然后再提出修改。这样,你可以在进一步发展的背景下表达你的提案,这样你可以避免在社区历史中受教育(浪费社区资源,降低你机会的有效性)。回看邮件列表,并向开发人员询问历史和来龙去脉。

透明

开源开发人员使用一个迭代、增量修改的过程。即使需要大的变化,它几乎总是用一系列更小、更好的解释或不言而喻的正确变化来实现的,这样每个人都可以跟进并支持。你提出的更改也是如此。不要弄出新的贡献者协议或者修改过的许可证,并期望每个人都相信你是专家、一切都是对的。你需要提供一根“红线”(相当于法律文件的差异),记录每个变化,并提供一个承认任何社区影响并为其辩护的理由。如果你只是为了你自己的利益需要一个东西,那就承认它,而不是希望没有人会注意到。

谦逊

你是一个炙手可热的律师,而你认为只有程序员才使用邮件列表。很明显,对你而言他们缺乏讨论的经验,所以你安排了一个你认为是同等的代理人,简化这一切,或者提出与社区选择的律师进行一对一的讨论。 我很抱歉地说你做的全都是错的。由于社区的政策是多边协商一致的,所以他们很有可能知道他们为什么定下现在的这些决定。名单上的一些人将具有优秀的领域知识,可能会比你的更好。而且一对一这件事是终极的羞辱,就像询问是否有一个成年人可以与你说话。

不要秘密渠道

有可能在某种领导机构,也许你认识在公司法务工作的 VP,也许你认识社区的总法律顾问。虽然在某些情况下,询问如何操控流程的提示可能是可以接受的,但尝试通过秘密渠道讨论或协商来试图影响甚至决定结果,那么结果会很糟糕。你最终可能会被邀请进行一对一的讨论, 但你不应该要求或期待它。

成为一个成员

如果你一切都做得正确,那么社区就有可能尊重你。坚持这些。作为一名冷静、机智的贡献者建立你的声誉。当人们犯你犯过的错误(或者已避免的)时,帮助他们。作为邮件列表社区的值得信赖的参与者,你是项目和雇主的真正资产。继续贡献,一些项目最终会在它们的治理中为你提供一个角色。

这个文章的早期版本最初发表在 Meshed Insights 中。

(题图: opensource.com)


作者简介:

Simon Phipps - 计算机行业和开源老手 Simon Phipps 上线了 Public Software,一个欧洲的开源项目托管,Document Foundation 的志愿者总监。他的帖子由 Patreon 赞助者赞助 - 如果你想要看更多,成为其中一个!


via: https://opensource.com/open-organization/17/3/legal-matters-community

作者:Simon Phipps 译者:geekpi 校对:wxy

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