分类 观点 下的文章

投身开源软件的人,多是有情怀的理想主义者,期望通过无私的努力,让世界更美好。这是原本专注于专利问题的笔者,偶然被牵入到开源研究项目后,对他们所产生的第一印像。

然而,即使专利人也有专利情怀,现实世界中开源与专利的碰撞依然难免丑陋。这要求投身开源的理想主义者必须比一般人更加坚强和执着,才可能推进他们的美好理想。以下,笔者从伸向开源情怀的专利咸猪手这一角度,来提示一下开源人所要面对的现实、承受的考验。

引子

相信社区里的人对此事并不陌生:一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利

按照开源中国博客文章XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。依照开源中国的另一篇博客文章,XXL-JOB 作者委托开源中国与专利申请人进行交涉,作者的基本诉求包括:申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望,如,申请人从事实和技术角度加以澄清,并提出如果专利授权,应声明其与有关开源项目的关系,并“无偿开源”等。

开源软件遭遇专利咸猪手

我们暂且将之称为开源软件遭遇专利咸猪手吧!应当说,此事件很典型,无论在国内还是国外都不是孤立性事件。事情的根本在于:开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留,将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利:包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

开源软件开发者的情怀在于:多少相信,免费获取和利用知识是人的权利。投身开源的人,对售卖知识的知识产权制度多少有些敌意。不得不承认,我们当今的知识产权制度并不完美,最典型的就是专利海盗现象,它给技术进步和产业发展,尤其是软件产业发展带来了巨大的负面冲击。从某种意义上讲,开源软件的产生,就是一种打破目前知识产权制度对软件行业过度禁锢的积极尝试,而且发展势头良好。

而现实世界比较复杂。从开放的眼光看,存在即为合理,开源软件所遭遇的海盗式专利咸猪手,并非一无是处。因为目前不完美的知识产权制度仍是当下最为现实的解决方案。对于智力成果给予专有保护的必要性和积极意义是毋庸质疑的。知识产权专有保护的着力点主要在限制商业应用;而对于利用知识、技术进行学习和研发,则采取支持、鼓励的态度。

专利咸猪手的法理依据是这样的:

  • 在前人智力成果的基础上再进行创造性改进是每个人的权利,是利于社会进步的,即使前人智力成果也受知识产权保护。
  • 创造性改进的成果也是智慧成果,可以申请成专利,它的知识产权属于做出创造性改进的人,也就是专利发明人。

应再强调,这里的发明人不应将前人的成果纳入自己的权利保护范围,仅可以就自己做出的改进部分主张权利。相信有情怀的开源人和专利人都不会反对以上两条。

而以下这两个问题,大家可以充分探讨和质疑:仅就 XXL-JOB 专利事件,专利是将 XXL-JOB 的已有技术也纳入了保护范围?还是仅对 XXL-JOB 的改进部分要求进行保护?

如果情况属于前者,该专利将不符合法定授权条件,不应获得授权。如果情况属于后者,第三方发明人获得专利保护则是完全正当的。

现实的狗血在于,想回答清楚这个问题:专利是否将 XXL-JOB 的已有技术纳入了保护范围,是技术上很复杂,成本非常高的问题。负责任地回答这个问题,需要进行非常专业的技术和法律分析,而得出的结论还不能是定论。没错,这个专业分析的成本几千元起,花几万元可能也不奇怪,即专业性强,还成本高,而且没有定论,这一点是肯定的。

为什么没有定论?简单讲,经过司法程序认定,例如,在产生了生效判决的情况下,才有司法定论。请注意,是生效判决,指不被后续司法救济程序推翻的判决。通常,有了司法定论可能还平息不了学术争议,但司法定论是现实中管事的。而要得到司法定论,成本就更高了。

这是开源作者必然会面对的局面,并且常常让人感觉悲哀无助,因为专业性问题可以先放其次,高成本是谁都难以轻易承担的。

还就 XXL-JOB 专利事件而言,即使专利说明书中包括了 XXL-JOB 的技术内容,也不能简单得出专利要求将 XXL-JOB 的已有技术内容纳入了保护范围的结论。技术改进中涉及原有技术的内容是正当的、不可避免的。专利申请人是否不恰当地将 XXL-JOB 的已有技术内容纳入了保护范围,各方各有观点,但尚无定论,第一个要正式面对和回答这一问题的就是专利局的专利审查员。

专利审查员的工作受技术条件、现实条件的制约,也并不能解决全部问题。很多问题只能留待以后产生争议时,由后续准司法和司法程序解决。这又回到了前面所提及的:问题分析专业性强,成本高。

开源作者未完结的悲哀无助

开源作者所受的悲哀无助还没有完。使问题更为加剧的是恶意利用制度和程序而产生的问题。简单而言,就是专利海盗式的操作。既然问题难有定论,就拦不住有人在商业利益的驱动之下,百折不挠地努力尝试打各种擦边球,而且总会有所收获。他们中的急先锋便是各类专利海盗。专利海盗充分利用了复杂的程序、高专业性、高成本形成的高门槛。专利,经过专业性的包装等手法,会给专利审查增加很高的技术难度,有可能将开源软件中的已有技术改头换面包装成改进过的新技术,变相纳入私有保护范围,从而混水摸鱼得偿所愿:例如通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

实际上,以这种方式做事的,不仅止是专利海盗,背后和之后还有大批正当公司,因为有商业利益驱动。有可能有些激进,但这属于合理利用法律制度和程序。这个问题,至少目前还看不到根本性的解决办法。

开源软件遭遇专利咸猪手,说开了,就是被摘了桃子。实际上,专利高手,充分利用制度和程序,合理合法地何止是摘开源软件的桃子,谁的桃子都摘。这已经属于商业经营活动中的正常专利风险,任谁都避不干净。

白话总结

如果以简单直白的方式总结一下的话:任何人都有权利对开源软件中的技术方案加以改进然后去申请专利,如果做得专业老道,有可能用这些专利卡住开源软件的脖子。这种做法合理合法,其中手段高超的,还会被圈里人称赞为:专利布局水平很高!

笔者忍不住要插一句:当年我们都不懂知识产权时,外国人没少这么搞我们。现在,我们也已经有一些高手可以这么去搞外国人了。这是有钱才玩得起的昂贵的游戏。一旦搞起来,谈不上对内对外,外国人和我们对内自然也免不了一样搞法。没办法,这就是西方人设计的知识产权制度骨子里的东西。

这是开源作者必然面对的局面,很多时候除了想开些,除了以很高的成本对簿公堂,没有现实的解决办法。笔者有把世界描写得太过黑暗吗?

我看到,投身开源软件的有情怀的理想主义者,有一些在这些黑暗和不公的打击之下,愤而退出了开源事业。笔者非常理解他们。我还看到,更多的人无视这些打击,以不变的情怀和理想,在这条道路上继续栉风沐雨,砥砺前行。笔者非常敬佩他们。人间正道是沧桑。

开源软件开发者这边的故事讲完了,而开源用户应当如何面对这些问题呢?希望以后有机会与大家讨论。

(题图:legalraasta.com)


作者:李可,江湖人称“可哥”,老牌专利代理人,集慧智佳知识产权咨询公司的知识产权高级咨询师。70 后文艺理工男,属牛,性子慢但踏实稳妥。

关于 React.js 的开源许可证从去年 7 月份争议到现在,Apache 基金会终于确认了立场,反对使用 React.js 和 Facebook 其他使用此许可证(BSD+Patents licensed)的流行软件。

最近,随着开源运动不断壮大,这边 LC3 大会刚过去不久,人们的热情还是未曾消去,那边 Apache 和 Facebook 又搅动着整个社区。

作为本次事件焦点的 Facebook Patents license 已经不是第一次出风头了,时不时成为人们讨论的主题。

上一次挑动大众神经是在 2016 年 7 月,Facebook 给 React 应用的开源许可协议是,在 BSD3-clause 协议基础上加上旨在保护 Facebook 自身的扩展协议。而这一次依然是围绕 Facebook Patents license 展开,简单梳理此次事件:

  • 2017 年 4 月,Apache Cassandra 项目正考虑增加 RocksDB 作为存储引擎,但考虑到专利授权的问题,Jeff Jirsa 向 Apache 法律社区寻求意见。
  • 2017 年 6 月,Apache 法律社区开始讨论 Facebook Patents license 协议专利授权的不对称性问题,且该协议与Apache Software License(即 Apache 2.0 等)不兼容。
  • 2017 年 7 月 15 日,Apache Software Foundation(以下简称 ASF)主管兼法律事务副主席 Chris Mattmann 正式发表声明称:Facebook BSD+Patents license(以下简称 FB+PL)已经正式被列入 “CategoryX” 列表,因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码;而已经发布的代码,涉及 FB+PL 许可证的,需要在 8 月 31 号前完成替换。

这一结论一出场便自带光环,引起了整个社区的关注,包括国内著名社交论坛知乎。当然,其对 Apache 项目自身的影响不比外界的关注度低。

如,虽然 Facebook 已于本月 17 号将 RocksDB 许可证更新为 Apache 2.0 和 GPLv2 双许可,但更大的问题是 React 也是基于 FB+PL 开源,Apache 的 CouchDB 项目、Apache Superset 项目等都依赖于 React,但是要让其开发人员在一个月内摆脱对 React 的依赖似乎也不是一件简单的事情。

到底是什么原因让 ASF 对 Facebook 的 FB+PL 许可协议下禁止令?要回答这个问题,需要先分析一下 FB+PL 许可协议。

众所周知,Facebook 也算是开源社区的中坚力量,截至目前已经发布了很多开源软件技术,包括使用广泛的 React.JS 框架和键值数据库 RocksDB。

不过,Facebook 没有像其他社区一样,自定义自己的开源许可证,也没有仅采用现存的开源许可证,而是采用 “BSD+Patents license” 许可证组合授权其大部分项目,该协议组合也被称为 FB+PL 组合。

其中,BSD 是指 BSD3-clause license,是被 OSI 和 FSF 都认可的开源软件许可证,也是被业界称为“宽松型”的开源许可证。

正是这个“宽松型”的 BSD 许可证附加了专利条款的开源许可协议,已经被 ASF 列为 “Category X”,杜绝了任何以 FB+PL 授权的软件进入 Apache 项目中的可能性,等于 FB+PL 已被 Apache 明确打入冷宫。

FB+PL 协议中,BSD3-clause license 本身没有问题,问题自然就出在 Facebook Patents license,即 Facebook 开源软件组合协议 FB+PL 中的附加专利许可条款。

以下是 Facebook Patents license 条款内容

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software. Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent
infringement against you in the first instance, and you respond by filing a
patent infringement counterclaim in that lawsuit against that party that is
unrelated to the Software, the license granted hereunder will not terminate
under section (i) of this paragraph due to such counterclaim.

A "Necessary Claim" is a claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone.

A "Patent Assertion" is any lawsuit or other action alleging direct, indirect,
or contributory infringement or inducement to infringe any patent, including a
cross-claim or counterclaim.

就是以上这段不算长的附加专利授权条款,让不少开发者甚至开源社区组织顾虑重重。

对开源运动有了解的人可能都知道,开源社区对专利非常敏感,甚至有开源大佬和前辈毫不掩饰对软件专利的厌恶和痛恨。更甚者,国外有专门的反软件专利组织,但毕竟专利制度是很多国家的法律制度,不可能受某个人或某一个群体的人的意见而转移。

因此,开源社区能做的就是改变自己以及影响自己可以影响的人,所以不少开源软件许可证都有针对专利的规范条款。

不过,对于 Facebook 附加专利许可协议,开源圈内人士从一开始都不是特别待见。甚至一些反对软件专利的人认为 FB+PL 协议关于专利的授权,拥有这样的专利授权比没有这样的授权更糟糕。

究其原因,从以上 Facebook Additional Grant of Patent Rights(附加专利授权条款)可以看出,该协议是一个单边优惠协议,授予人和被授予人的权利不平衡。

简单说就是基于 FB+PL 授权的软件使用者以及基于 FB+PL 开发衍生代码的开发者,与 Facebook 的权利不平衡。一旦被许可人对 Facebook 及其子公司甚至关联公司提出直接的或间接专利诉讼,无论该诉讼是与所涉及项目有关还是无关,亦或是硬件专利诉讼,甚至是 Facebook 主动提出的专利诉讼而被告者进行的专利反诉,该协议授予用户的专利权利即刻自动终止。

另外,2015 年 4 月 10 以前,Facebook Additional Grant of Patent Rights 第一版中,针对 Facebook 任何形式的诉讼,包括反诉、以及与专利无关的诉讼,都会导致基于该协议的专利授权自动终止。后来由于社区人员对该条款争议较大, Facebook 进行了修改,也即是目前的第二版

值得一提的是,在众多的开源许可证中,有专利权利终止以及许可证权利终止条款的许可证并不少见,例如,Apache2.0 以及GPLv2/v3 都有关于权利终止的条款约束。之所以 FB+PL 会有如此强烈的反应关键有两点:

  1. FB+PL 专利终止条款过于宽泛;
  2. FB+PL 专利条款使得被授予者与 Facebook 之间的权利不平衡。

从另一个层面上讲,Facebook 附加专利授权条款的存在也不是全无道理,毕竟开源软件无时无刻不在承受着来自软件专利的威胁。尽管这些年软件专利没有成功将开源运动送入坟墓,反而使其不断壮大,而开源社区对专利的排斥和恐惧却已深入骨髓。

Facebook 作为开源领域一员猛将,并且已经开源了大量的代码和技术,将所有可能导致侵权的专利技术授权给用户。另一方面,为了自身防护的原因,想办法建立一种自保的机制也在情理之中,毕竟谁都不想成为被鱼肉被屠宰的一方。

整体来讲,Facebook 附加专利授权条款是一个带有严格的惩罚性措施的协议,其严厉性特别表现在其第一版,虽然在第二版中,将诉讼范围限定于专利诉讼,但在许多人看来其范围依然是过大。

Facebook 附加专利授权条款有一种过激的表现,但是如果你能想象一个刚刚崭露头角的少年,还未有可观的积蓄(专利),在群狼环嗣,个个武装到牙齿的对手面前,那种本能的警惕,也许会对 Facebook 多少有点理解。

毕竟,即便 Facebook 附加专利授权条款在严格,对于个人开发者,以及不喜欢搞专利诉讼的组织来说,大家彼此相安无事,也不失为一件好事。

就我个人来讲,我对 Facebook 之于开源的真诚性是认可的。

目前,虽然“ 开源软件 Open Source Software ”和“ 自由软件 Free Software ”两种哲学理念还存在分歧,但很多社区以及组织包括像 Facebook 这样自我保护略显偏激的组织,都是开源/自由软件理念真诚的践行者。还有一部分像微软一样“从良”的,也为开源做了不少贡献,像这种老牌的商业公司背负了太多的包袱,一下子转身可能性不大。

当然,浑水摸鱼以及投机的分子也肯定不少。不过,开源是软件开发的未来趋势和必然走向,开源理念不仅避免了重复开发中时间、人力和资金了浪费,更是智力共享、集体智慧的完美实践。

因此,虽然目前开源运动还存在着种种的冲突和矛盾,但就像所有的新生事物一样,从萌芽到成长再到成熟都会有一个过程,而在这个过程中磕磕绊绊在所难免。

整体上说,这次 Apache 对 Facebook 附加专利授权条款下禁止令,只是开源运动在一件小事,而开源的生命力正是在这种碰撞、冲突和磨合中逐渐显现,慢慢成熟。

(题图:react-etc.net)


作者简介:付钦伟,专利代理人、专利咨询师,任职于集慧智佳知识产权咨询公司。研究生选专业“误入歧途”,进入高大上的知识产权领域,目前从事专利咨询分析工作,励志为中国知识产权事业抛头颅、洒热血。

开放容器计划 Open Container Initiative (OCI)宣布本周完成了容器运行时和镜像的第一版规范。OCI 在是 Linux 基金会 Linux Foundation 支持下的容器解决方案标准化的成果。两年来,为了建立这些规范已经付出了大量的努力。 由此,让我们一起来回顾过去两年中出现的一些误区。

OCI

误区:OCI 是 Docker 的替代品

诚然标准非常重要,但它们远非一个完整的生产平台。 以万维网为例,它 25 年来一路演进,建立在诸如 TCP/IP 、HTTP 和 HTML 等可靠的核心标准之上。再以 TCP/IP 为例,当企业将 TCP/IP 合并为一种通用协议时,它推动了路由器行业,尤其是思科的发展。 然而,思科通过专注于在其路由平台上提供差异化的功能,而成为市场的领导者。我们认为 OCI 规范和 Docker 也是类似这样并行存在的。

Docker 是一个完整的生产平台,提供了基于容器的开发、分发、安全、编排的一体化解决方案。Docker 使用了 OCI 规范,但它大约只占总代码的 5%,而且 Docker 平台只有一小部分涉及容器的运行时行为和容器镜像的布局。

误区:产品和项目已经通过了 OCI 规范认证

运行时和镜像规范本周刚发布 1.0 的版本。 而且 OCI 认证计划仍在开发阶段,所以企业在该认证正式推出之前(今年晚些时候),没法要求容器产品的合规性、一致性或兼容性。

OCI 认证工作组目前正在制定标准,使容器产品和开源项目能够符合规范的要求。标准和规范对于实施解决方案的工程师很重要,但正式认证是向客户保证其正在使用的技术真正符合标准的唯一方式。

误区:Docker 不支持 OCI 规范的工作

Docker 很早就开始为 OCI 做贡献。 我们向 OCI 贡献了大部分的代码,作为 OCI 项目的维护者,为 OCI 运行时和镜像规范定义提供了积极有益的帮助。Docker 运行时和镜像格式在 2013 年开源发布之后,便迅速成为事实上的标准,我们认为将代码捐赠给中立的管理机构,对于避免容器行业的碎片化和鼓励行业创新将是有益的。我们的目标是提供一个可靠和标准化的规范,因此 Docker 提供了一个简单的容器运行时 runc 作为运行时规范工作的基础,后来又贡献了 Docker V2 镜像规范作为 OCI 镜像规范工作的基础。

Docker 的开发人员如 Michael Crosby 和 Stephen Day 从一开始就是这项工作的关键贡献者,确保能将 Docker 的托管和运行数十亿个容器镜像的经验带给 OCI。等认证工作组完成(制定认证规范的)工作后,Docker 将通过 OCI 认证将其产品展示出来,以证明 OCI 的一致性。

误区:OCI 仅用于 Linux 容器技术

因为 OCI 是由 Linux 基金会 Linux Foundation 负责制定的,所以很容易让人误解为 OCI 仅适用于 Linux 容器技术。 而实际上并非如此,尽管 Docker 技术源于 Linux 世界,但 Docker 也一直在与微软合作,将我们的容器技术、平台和工具带到 Windows Server 的世界。 此外,Docker 向 OCI 贡献的基础技术广泛适用于包括 Linux 、Windows 和 Solaris 在内的多种操作系统环境,涵盖了 x86、ARM 和 IBM zSeries 等多种架构环境。

误区:Docker 仅仅是 OCI 的众多贡献者之一

OCI 作为一个支持成员众多的开放组织,代表了容器行业的广度。 也就是说,它是一个小而专业的个人技术专家组,为制作初始规范的工作贡献了大量的时间和技术。 Docker 是 OCI 的创始成员,贡献了初始代码库,构成了运行时规范的基础和后来的参考实现。 同样地,Docker 也将 Docker V2 镜像规范贡献给 OCI 作为镜像规范的基础。

误区:CRI-O 是 OCI 项目

CRI-O 是 云计算基金会 Cloud Native Computing Foundation (CNCF)的 Kubernetes 孵化器的开源项目 -- 它不是 OCI 项目。 它基于早期版本的 Docker 体系结构,而 containerd 是一个直接的 CNCF 项目,它是一个包括 runc 参考实现的更大的容器运行时。 containerd 负责镜像传输和存储、容器运行和监控,以及支持存储和网络附件等底层功能。 Docker 在五个最大的云提供商(阿里云、AWS、Google Cloud Platform(GCP)、IBM Softlayer 和 Microsoft Azure)的支持下,将 containerd 捐赠给了云计算基金会(CNCF),作为多个容器平台和编排系统的核心容器运行时。

误区:OCI 规范现在已经完成了

虽然首版容器运行时和镜像格式规范的发布是一个重要的里程碑,但还有许多工作有待完成。 OCI 一开始着眼于定义一个狭窄的规范:开发人员可以依赖于容器的运行时行为,防止容器行业碎片化,并且仍然允许在不断变化的容器域中进行创新。之后才将含容器镜像规范囊括其中。

随着工作组完成运行时行为和镜像格式的第一个稳定规范,新的工作考量也已经同步展开。未来的新特性将包括分发和签名等。 然而,OCI 的下一个最重要的工作是提供一个由测试套件支持的认证过程,因为第一个规范已经稳定了。

在 Docker 了解更多关于 OCI 和开源的信息:


作者简介:

Stephen 是 Docker 开源项目总监。 他曾在 Hewlett-Packard Enterprise (惠普企业)担任董事和杰出技术专家。他的关于开源软件和商业的博客发布在 “再次违约”(http://stephesblog.blogs.com) 和网站 opensource.com 上。


via: https://blog.docker.com/2017/07/demystifying-open-container-initiative-oci-specifications/

作者:Stephen 译者:rieonke 校对:wxy

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

或许是出于疲倦,也有可能是出于对 GNOME 应用开发体系的不满,GNOME 桌面环境默认的文本编辑器、核心应用之一的 gedit 的开发者前几天宣布不再维护它了。它的最新稳定版本是 3.22。

gedit 开发者 Sébastien Wilmet 在邮件列表中说

“gedit 不再维护,我已将其添加到此维基页面: https://wiki.gnome.org/Apps/Unmaintained

有没有感兴趣接手 gedit 维护的开发者?”

庆幸的是,gedit 在“无维护”页面呆了几天后,就有两位新的维护者加入了维护行列,我们可以不用担心 gedit 就此消亡——虽然“当前的 GTK+ 3 已经稳定,就是不维护,不出意外的话 gedit 也可以持续工作很长时间”。

gedit 是 GNOME 的默认编辑器,但其实它在 Linux 上的编辑器家族里面并不是很出彩,只能说是中规中矩、简单而轻量级罢了。但是可能也正是因为这个原因,才让大家忽视了这些默不出声的应用也是需要人来关爱的。

gedit 初次发布于 1999 年,而今已经有 18 岁了,但是它的开发者却一直不多,功能和特性的增加也不大,而且,几年前曾经历一次 UI 的较大变更,变更后的 UI 变成非常难用,所以使用者对此也颇有腹诽。但是可能是由于下面的原因,参与维护的人很少:

“另外, gedit 的核心是用 C 写的(为了支持 Mac OS X ,还有一点 Objective-C),一些插件是用 Vala 或 Python 写的。如果你要接手 gedit 的维护,你需要和这四种语言打交道(还不算构建系统)。 Python 代码是没编译的,所以如果重构 gedit 核心的话,可能需要移植所有的插件(python 代码也不如 C 代码那么便于 grep),不过至少 Vala 有个编译器,虽然我不推荐它。”

所以,这可能真的会让维护者头大。

此外,Sébastien Wilmet 对 GNOME 生态的开发也颇有抱怨:

“如果 gedit 死了,我认为这对于所有的 GTK+ 应用都是一个教训:要写更多的库,并在几个类似应用之间共享且一同维护它们。GtkSourceView 仍在维护,但是 gedit 所用的代码要超过了 GtkSourceView。在我给 GtkSourceView 贡献代码前, gedit 里面就有 8000 行以上的代码来保存和载入文件(只是后端,不算前端)。你显然不会认为只有 gedit 需要在用 GtkSourceView 时使用载入和保存文件吧?其它的文本编辑器呢?比如 Anjuta (也有很大一个不再维护的代码库),而且现在 gnome-builder 还在犯同样的错误(在它的角落里面开发了许多文本编辑器功能;你真的认为 Vim 模式只在 gnome-builder 中有用?!)

这事不只是文本编辑器的事,我们造了多少个音乐播放器的轮子?照片管理器呢?IRC/聊天客户端呢?天气预报呢?等等~”

好吧,或许是该正视这个问题的时刻了,毕竟只有良好的开发环境,才有丰富的应用生态,只有丰富的应用生态,才能大量的使用者。

本文由高级咨询师薛亮据自由软件基金会(FSF)的英文原文翻译而成,这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题,对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据 GNU 许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

1、关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题

1.1 “GPL” 代表什么意思?

“GPL” 代表“ 通用公共许可证 General Public License ”。 最常见的此类许可证是 GNU 通用公共许可证,简称 GNU GPL。 如果人们能够自然而然地将其理解为 GNU GPL,可以进一步缩短为“GPL”。

1.2 自由软件是否意味着必须使用 GPL?

根本不是的,还有许多其他自由软件许可证。我们有一个不完整的列表。任何为用户提供特定自由的许可证都是自由软件许可证。

1.3 为什么我要使用 GNU GPL,而不是其他自由软件许可证?

使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过,在某些特殊情况下,最好使用一个更宽松的许可证。

1.4 所有 GNU 软件都使用 GNU GPL 作为其许可证吗?

大多数 GNU 软件包都使用 GNU GPL,但是有一些 GNU 程序(以及程序的一部分)使用更宽松的许可证,例如 LGPL( 较宽松公共许可证 Lesser GPL )。我们这样做是基于战略考虑。

1.5 如果一个程序使用 GPL 许可证,是否会使其成为 GNU 软件?

任何人都可以依据 GNU GPL 发布一个程序,但并不能使其成为 GNU 软件包。

让程序成为 GNU 软件包意味着将其明确地贡献给 GNU 项目。当程序的开发人员和 GNU 项目都同意这样做时,才会发生这种情况。如果您有兴趣向 GNU 项目贡献程序,请写信至 mailto:[email protected]

1.6 我可以将 GPL 应用于软件以外的其他作品吗?

您可以将 GPL 应用于任何类型的作品,只需明确该作品的“源代码”构成即可。 GPL 将“源代码”定义为作品的首选形式,以便在其中进行修改。

不过,对于手册和教科书,或更一般地,任何旨在教授某个主题的作品,我们建议使用 GFDL,而非 GPL。

1.7 手册为什么不使用 GPL 许可证?

手册也可以使用 GPL 许可证,但对于手册来说,最好使用 GFDL( 自由文本授权 GNU Free Documentation License )许可证。

GPL 是为软件程序设计的,它包含许多复杂的条款,对于程序来说至关重要;但对于图书或手册来说,这将是麻烦和不必要的。例如,任何人如果(以 GPL )出版纸质图书,就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”,或提供书面文件,表明将稍后发送“源代码”。

同时,GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款,例如,出售封面文字。 背书 Endorsements 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的,但该修改版本不能被标记为“该标准”。

使用 GFDL,我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要,因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由,它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” invariant ,使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。

1.8 GPL 被翻译成其他语言了吗?

将 GPL 翻译成英文以外的语言将是有用的。人们甚至进行了翻译,并将文本发送给我们。但我们不敢将翻译文本批准为正式有效。其中的风险如此之大,以至于我们不敢接受。

法律文件在某种程度上就像一个程序。翻译它就像将程序从一种语言和操作系统转换到另一种语言。只有同时熟练使用这两种语言的律师才能做到这一点——即便如此,也有引入错误的风险。

如果我们正式批准 GPL 的翻译文本,我们将不得不给予所有人许可,让他们可以去做翻译文本规定可以做的任何事情。如果这是一个完全准确的翻译,那没关系。但如果翻译错误,后果可能是我们无法解决的灾难。

如果一个程序有 bug,我们可以发布一个新的版本,最终旧版本将会逐渐消失。但是,一旦我们给予每个人去根据特定翻译文本行事的许可,如果我们稍后发现它有一个错误,我们无法收回该权限。

乐意提供帮助的人有时会为我们做翻译工作。如果问题是要找人做这个工作的话,那问题就解决了。但实际的问题是错误的风险,做翻译工作不能避免风险。我们无法授权非律师撰写的翻译文本。

因此,目前我们并不认可GPL的翻译文本是全球有效和具有约束力的。相反,我们正在做两件事情:

  • 将非正式的翻译指引给人们。这意味着我们允许人们进行GPL的翻译,但是我们不认可翻译文本具有法律效力和约束力。
    未经批准的翻译文本没有法律效力,应该如此明确地表述。翻译文本应标明如下:
This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English).
本 GPL 翻译文本是非正式的,没有被自由软件基金会(FSF)正式批准为有效。若要完全确定何种行为被允许,请参阅原始 GPL(英文)。

但未经批准的翻译文本可以作为如何理解英文 GPL 的参考。对于许多用户来说,这就足够了。不过,在商业活动中使用 GNU 软件的企业,以及进行公共 ftp 发行的人员,需要去核查实际的英文 GPL,以明确其允许的行为。

  • 发布仅在单个国家/地区有效的翻译文本。
    我们正在考虑发布仅在单个国家正式生效的翻译文本。这样一来,如果发现有错误,那么错误将局限于这个国家,破坏力不会太大。
    即便是一个富有同情心和能力的律师来做翻译,仍然需要相当多的专门知识和努力,所以我们不能很快答应任何这样的翻译。

1.9 为什么有一些 GNU 库依据普通 GPL 而不是 LGPL 来发布?

对于任何特定库使用 LGPL 构成了自由软件的倒退。这意味着我们部分放弃了捍卫用户自由权利的努力,对基于 GPL 软件所构建产品的分享要求也降低了。在它们自身而言,这是更糟糕的变化。

有时一个小范围的倒退是很好的策略。某种情况下,使用 LGPL 的库可能会带来该库的广泛使用,从而进一步改善该库,为自由软件带来更广泛的支持,诸如此类。如果在相当大的程度上出现这种情况,这可能对自由软件很有好处。但它发生的几率有多少呢?我们只能推测。

在每个库上用一段时间的 LGPL,看看它是否有帮助,如果 LGPL 没有帮助,再将其更改为 GPL。这种做法听起来很好,但却是不可行的。一旦我们对特定库使用了 LGPL,那就很难进行改变。因此,我们根据具体情况决定每个库使用哪个许可证。对于我们如何判断该问题,有一段很长的解释

1.10 谁有权力执行 GPL 许可证?

由于 GPL 是版权许可,软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为,您应该向遵循GPL的该软件的开发人员通报。他们是版权所有者,或与版权所有者有关。若要详细了解如何报告 GPL 违规,请参阅“如果发现了可能违反 GPL 许可证的行为,我该怎么办?

1.11 为什么 FSF 要求为 FSF 拥有版权的程序做出贡献的贡献者将版权 分配 assign 给 FSF?如果我持有 GPL 程序的版权,我也应该这样做吗?如果是,怎么做?

我们的律师告诉我们,为了最大限度地向法院要求违规者强制执行 GPL,我们应该让程序的版权状况尽可能简单。为了做到这一点,我们要求每个贡献者将贡献部分的版权分配给 FSF,或者放弃对贡献部分的版权要求。

我们也要求个人贡献者从雇主那里获得版权放弃声明(如果有的话),以确保雇主不会声称拥有这部分贡献的版权。

当然,如果所有的贡献者把他们的代码放在公共领域,也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权,只把小规模的修改放在公共领域。

如果您想要在您的程序中执行 GPL,遵循类似的策略可能是一个好主意。如果您需要更多信息,请联系 mailto:[email protected]

1.12 我可以修改 GPL 并创建一个修改后的许可证吗?

您可以制作GPL的修改版本,但这往往会产生实践上的后果。

您可以在其他许可证中合法使用GPL条款(可能是修改过的),只要您以其他名称来称呼您的许可证,并且不包括 GPL 的 引言 preamble ,只要您对最后的使用说明进行了足够多的修改,使其措辞明显不同,没有提到 GNU(尽管您描述的实际过程可能与其类似)。

如果您想在修改后的许可证中使用我们的引言,请写信至 mailto:[email protected],以获得许可。我们需要查看实际的许可证要求,才能决定我们是否能够批准它们。

虽然我们不会以这种方式对您修改许可证提出法律上的反对意见,但我们希望您三思而行,别去修改许可证。类似这些修改后的许可证几乎肯定与 GNU GPL 不兼容,并且这种不兼容性阻碍了模块之间的有用组合。

不同自由软件许可证的扩散本身就是一个负担。请使用 GPL v3 提供的 例外 exception 机制,而不是去修改 GPL。

1.13 为什么你们决定将 GNU Affero GPL v3 作为一个单独的许可证?

GPLv3 的早期草案在第 7 节中允许许可人在发布源代码时添加一个类似 Affero 的要求。但是,一些开发和依赖自由软件的公司认为这个要求太过繁重。他们希望避免使用遵循这个要求的代码,并且对检查代码是否符合这个附加要求所带来的管理成本表示担忧。通过将 GNU Affero GPL v3 作为单独的许可证发布,在该许可证以及 GPL v3 中允许遵循该许可证的代码链接到彼此,我们完成了所有最初的目标,同时更容易确定哪些源代码需要遵循发布要求。

(题图:pycom.io)


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

coreos-oci-open-container-industry-standard

CoreOS开放容器联盟(OCI) 周三(2017 年 7 月 19 日)发布的镜像和运行时标准主要参照了 Docker 的镜像格式技术。

然而,OCI 决定在 Docker 的事实标准平台上建立模型引发了一些问题。一些批评者提出其他方案。

CoreOS 的 CTO 及 OCI 技术管理委员会主席 Brandon Philips 说, 1.0版本为应用容器提供了一个稳定标准。他说,拥有产业领导者所创造的标准,应能激发 OCI 合作伙伴进一步地发展标准和创新。Philips 补充道,OCI 完成 1.0 版本意味着 OCI 运行时规范和 OCI 镜像格式标准现在已经可以广泛使用。此外,这一成就将推动 OCI 社区稳固日益增长的可互操作的可插拔工具集市场。

产业支持的标准将提供一种信心:容器已被广泛接受,并且 Kubernetes 用户将获得更进一步的支持。

Philips 告诉 LinuxInsider,结果是相当不错的,认证流程已经开始。

合作挑战

Philips 说,开放标准是容器生态系统取得成功的关键,构建标准的最好方式是与社区密切协作。然而,在 1.0 版本上达成共识所花费的时间超出了预期。

“早期,最大的挑战在于如今解决项目的发布模式及如何实施该项目”,他追述道,”每个人都低估了项目所要花费的时间。“

他说,OCI 联盟成员对他们想做的事情抱有不相匹配的预期,但是在过去的一年中,该组织了解了期望程度,并且经历了更多的测试。

追逐标准

CoreOS 官方在几年前就开始讨论行业支持的容器镜像和运行时规范的开放标准的想法,Phillips 说,早期的探索使我们认识到:在标准镜像格式上达成一致是至关重要的。

CoreOS 和容器技术创造者 Docker 在 2015 年 6 月宣布 OCI 成立。合作起始于 21 个行业领导者制定开放容器计划(OCP)。它作为一个非营利组织,旨在建立云存储软件容器的最低通用标准。

联盟包括容器业界的领导者:Docker、微软、红帽、IBM、谷歌和 Linux 基金会。

OCI 的目的是让应用开发者相信:当新的规范出来并开发出新的工具时,部署在容器上的软件仍然能够持续运行。这种信心必须同时满足所有私有和开源软件。

工具和应用是私有还是开源的并没有什么关系。当规范开始应用,产品可以被设计成与任何容器配置相适应,Philips 说。

“你需要有意识地超越编写代码的人能力之外创建标准。它是一个额外的付出。”他补充道。

作为联盟的一部分,Docker 向 OCP(开放容器计划)捐献出它的镜像格式的事实标准技术。它包括该公司的容器格式、运行时代码和规范。建立 OCI 镜像标准的工作起始于去年。

标准的里程碑给予容器使用者开发、打包、签名应用容器的能力。他们也能够在各种容器引擎上运行容器,Philips 强调。

唯一选择?

Pund-IT 的首席分析师 Charles King 表示:联盟面临着两种实现标准的方式。第一种选择是汇集相同意向的人员来避免分歧从零开始建立标准。

但是联盟成员似乎满足于第二种方案:采用一种强大的市场领先的平台作为一个有效的标准。

“Docker 对 Linux 基金会的贡献使 OCI 坚定的选择了第二种方案。但是那些关注于 Docker 的做法和它的市场地位的人也许感觉应该有更好的选择。”King 对 LinuxInsider 说。

事实上,有个 OCI 成员 CoreOS 在开始的时候对该组织的总体方向进行了一些强烈的批评。他说,“所以看看 V1.0 版本是否处理或不处理那些关注点将是很有趣的事情。”

更快之路

Docker 已经被广泛部署的运行时实现是建立开放标准的合适基础。据 Cloud Technology Partners 的高级副总裁 David Linthicum 所说,Docker 已经是一个事实标准。

“我们能很快就让它们工作起来也是很重要的。但是一次次的标准会议、处理政治因素以及诸如此类的事情只是浪费时间” 。他告诉 LinuxInsider。

但是现在没有更好的选择,他补充道。

据 RedHat 公司的 Linux 容器技术高级布道者 Joe Brockmeier 所说,Docker 的运行时是 runC 。它是 OCI 运行时标准的一种实现。

“因此,runC 是一个合适的运行时标准的基础。它被广泛的接受并成为了大多数容器技术实现的基础。他说。

OCI 是比 Docker 更进一步的标准。尽管 Docker 确实提交了遵循 OCI 规范的底层代码,然而这一系列代码就此停止,并且没真正的可行替代方案存在。

对接问题

Pund-IT 的 King 建议:采用一种广泛使用的产业标准将简化和加速许多公司对容器技术的采纳和管理。也有可能一些关键的供应商将继续关注他们自己的专有容器技术。

“他们辩称他们的做法是一个更好的方式,但这将有效的阻止 OCI 取得市场的主导地位。”他说,“从一个大体上实现的标准开始,就像 OCI 所做的那样,也许并不能完美的使所有人满意,但是这也许能比其他方案更加快速有效的实现目标。”

容器已经标准化的部署到了云上,Docker 显然是领先的。Semaphore 联合创始人 Marko Anastasov 说。

他说,Docker 事实标准的容器代表了开发开放标准的的最佳基础。Docker 的商业利益将如何影响其参与 OCI 的规模还有待观察。

反对观点

开放标准并不是在云部署中采用更多的容器的最终目标。ThoughtWorks 的首席顾问 Nic Cheneweth 表示。更好的的方法是查看 IT 行业的服务器虚拟化部分的影响。

Cheneweth 对 LinuxInsider 说:“持续增长和广泛采用的主要动力不是在行业标准的声明中,而是通过使用任何竞争技术所获得的潜在的和实现的效率,比如 VMware、Xen 等。”

容器技术的某些方面,例如容器本身,可以根据标准来定义。他说,在此之前,深入开源软件参与引导的健康竞争将有助于成为一个更好的标准。

据 Cheneweth 说,容器编排标准对该领域的持续增长并不特别重要。

不过,他表示,如果行业坚持锁定容器事实标准,那么 OCI 所选择的模型是一个很好的起点。“我不知道是否有更好的选择,但肯定这不是最糟糕的选择。”

作者简介:

自 2003 年以来,Jack M.Germain一直是一个新闻网络记者。他主要关注的领域是企业 IT、Linux 和开源技术。他已经写了很多关于 Linux 发行版和其他开源软件的评论。


via: http://www.linuxinsider.com/story/84689.html

作者:Jack M. Germain 译者:LHRchina 校对:wxy

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