2017年9月

作为一名开发者,我会尝试留意那些我可能不会每天使用的技术的进步。了解这些技术至关重要,因为它们可能会间接影响到我的工作。比如由 Docker 推动的、近期正在兴起的容器化技术,可用于上规模地托管 Web 应用。从技术层面来讲,我并不是一个 DevOps,但当我每天构建 Web 应用时,多去留意这些技术如何去发展,会对我有所裨益。

这种进步的一个绝佳的例子,是近一段时间高速发展的容器编排平台。它允许你轻松地部署、管理容器化应用,并对它们的规模进行调整。目前看来,容器编排的流行工具有 Kubernetes (来自 Google)Docker SwarmApache Mesos。如果你想较好的了解上面那些技术以及它们的区别,我推荐你看一下这篇文章

在这篇文章中,我们将会从一些简单的操作开始,了解一下 Kubernetes 平台,看看如何将一个 WordPress 网站部署在本地机器上的一个单节点集群中。

安装 Kubernetes

Kubernetes 文档中有一个很好的互动教程,涵盖了很多东西。但出于本文的目的,我只会介绍在 MacOS 中 Kuberentes 的安装和使用。

我们要做的第一件事是在你的本地主机中安装 Kubernetes。我们将使用一个叫做 MiniKube 的工具,它专门用于在你的机器上方便地设置一个用于测试的 Kubernetes 集群。

根据 Minikube 文档,在我们开始之前,有一些先决条件。首先要保证你已经安装了一个 Hypervisor (我将会使用 Virtualbox)。接下来,我们需要安装 Kubernetes 命令行工具(也就是 kubectl)。如果你在用 Homebrew,这一步非常简单,只需要运行命令:

$ brew install kubectl

现在我们可以真正 安装 Minikube 了:

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.21.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

最后,我们要启动 Minicube 创建一个虚拟机,来作为我们的单节点 Kubernetes 集群。现在我要说一点:尽管我们在本文中只在本地运行它,但是在真正的服务器上运行 Kubernetes 集群时,后面提到的大多数概念都会适用。在多节点集群上,“主节点”将负责管理其它工作节点(虚拟机或物理服务器),并且 Kubernetes 将会在集群中自动进行容器的分发和调度。

$ minikube start --vm-driver=virtualbox

安装 Helm

现在,本机中应该有一个正在运行的(单节点)Kubernetes 集群了。我们现在可以用任何方式来与 Kubernetes 交互。如果你想现在可以体验一下,我觉得 kubernetesbyexample.com 可以很好地向你介绍 Kubernetes 的概念和术语。

虽然我们可以手动配置这些东西,但实际上我们将会使用另外的工具,来将我们的 WordPress 应用部署到 Kubernetes 集群中。Helm 被称为“Kubernetes 的包管理工具”,它可以让你轻松地在你的集群中部署预构建的软件包,也就是“ 图表 chart ”。你可以把图表看做一组专为特定应用(如 WordPress)而设计的容器定义和配置。首先我们在本地主机上安装 Helm:

$ brew install kubernetes-helm

然后我们需要在集群中安装 Helm。 幸运的是,只需要运行下面的命令就好:

$ helm init

安装 WordPress

现在 Helm 已经在我们的集群中运行了,我们可以安装 WordPress 图表。运行:

$ helm install --namespace wordpress --name wordpress --set serviceType=NodePort stable/wordpress  

这条命令将会在容器中安装并运行 WordPress,并在容器中运行 MariaDB 作为数据库。它在 Kubernetes 中被称为“Pod”。一个 Pod 基本上可视为一个或多个应用程序容器和这些容器的一些共享资源(例如存储卷,网络等)的组合的抽象。

我们需要给这个部署一个名字和一个命名空间,以将它们组织起来并便于查找。我们同样会将 serviceType 设置为 NodePort 。这一步非常重要,因为在默认设置中,服务类型会被设置为 LoadBalancer。由于我们的集群现在没有负载均衡器,所以我们将无法在集群外访问我们的 WordPress 站点。

在输出数据的最后一部分,你会注意到一些关于访问你的 WordPress 站点的有用的命令。运行那些命令,你可以获取到我们的 WordPress 站点的外部 IP 地址和端口:

$ export NODE_PORT=$(kubectl get --namespace wordpress -o jsonpath="{.spec.ports[0].nodePort}" services wordpress-wordpress)
$ export NODE_IP=$(kubectl get nodes --namespace wordpress -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo http://$NODE_IP:$NODE_PORT/admin

你现在访问刚刚生成的 URL(忽略 /admin 部分),就可以看到 WordPress 已经在你的 Kubernetes 集群中运行了!

扩展 WordPress

Kubernetes 等服务编排平台的一个伟大之处,在于它将应用的扩展和管理变得易如反掌。我们看一下应用的部署状态:

$ kubectl get deployments --namespace=wordpress

kubectl get deployments

可以看到,我们有两个部署,一个是 Mariadb 数据库,一个是 WordPress 本身。现在,我们假设你的 WordPress 开始承载大量的流量,所以我们想将这些负载分摊在多个实例上。我们可以通过一个简单的命令来扩展 wordpress-wordpress 部署:

$ kubectl scale --replicas 2 deployments wordpress-wordpress --namespace=wordpress

再次运行 kubectl get deployments,我们现在应该会看到下面的场景:

kubectl get deployments

你刚刚扩大了你的 WordPress 站点规模!超级简单,对不对?现在我们有了多个 WordPress 容器,可以在它们之中对流量进行负载均衡。想了解 Kubernetes 扩展的更多信息,参见这篇指南

高可用

Kubernetes 等平台的的另一大特色在于,它不单单能进行方便的扩展,还可以通过自愈组件来提供高可用性。假设我们的一个 WordPress 部署因为某些原因失效了,那 Kubernetes 会立刻自动替换掉这个部署。我们可以通过删除我们 WordPress 部署的一个 pod 来模拟这个过程。

首先运行命令,获取 pod 列表:

$ kubectl get pods --namespace=wordpress

kubectl get pods

然后删除其中一个 pod:

$ kubectl delete pod wordpress-wordpress-876183909-jqc8s --namespace=wordpress

如果你再次运行 kubectl get pods 命令,应该会看到 Kubernetes 立刻换上了新的 pod (3l167)。

kubectl get pods

更进一步

我们只是简单了解了 Kubernetes 能完成工作的表面。如果你想深入研究,我建议你查看以下功能:

你在容器平台上运行过 WordPress 吗?有没有使用过 Kubernetes(或其它容器编排平台),有没有什么好的技巧?你通常会怎么扩展你的 WordPress 站点?请在评论中告诉我们。


作者简介:

Gilbert 喜欢构建软件。从 jQuery 脚本到 WordPress 插件,再到完整的 SaaS 应用程序,Gilbert 一直在创造优雅的软件。 他粗昂做的最有名的的产品,应该是 Nivo Slider.


via: https://deliciousbrains.com/running-wordpress-kubernetes-cluster/

作者:Gilbert Pellegrom 译者:StdioA 校对:wxy

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

Tanya Reilly 的五个问题:相互依赖的服务如何使恢复更加困难,为什么有意并预先管理依赖是个好主意。

我最近请 Google 的网站可靠性工程师 Tanya Reilly 分享了她关于如何制定更好的灾难恢复计划的想法。Tanya 将在 10 月 1 日到 4 日在纽约举行的 O'Reilly Velocity Conference 上发表了一个题为《你有没有试着把它关闭之后再打开?》的演讲。

1、 在计划备份系统策略时,人们最常犯的错误是什么?

经典的一条是“你不需要备份策略,你需要一个恢复策略”。如果你有备份,但你尚未测试恢复它们,那么你没有真正的备份。测试不仅仅意味着知道你可以获得数据,还意味着知道如何把它放回数据库,如何处理增量更改,甚至如果你需要的话,如何重新安装整个系统。这意味着确保你的恢复路径不依赖于与数据同时丢失的某些系统。

但测试恢复是枯燥的。这是人们在忙碌时会偷工减料的那类事情。这值得花时间使其尽可能简单、无痛、自动化,永远不要靠任何人的意志力!同时,你必须确保有关人员知道该怎么做,所以定期进行大规模的灾难测试是很好的。恢复演练是个好方法,可以找出该过程的文档是否缺失或过期,或者你是否没有足够的资源(磁盘、网络等)来传输和重新插入数据。

2、 创建 灾难恢复 disaster recovery (DR) 计划最常见的挑战是什么?

我认为很多 DR 是一种事后的想法:“我们有这个很棒的系统,我们的业务依赖它……我猜我们应该为它做 DR?”而且到那时,系统会非常复杂,充满相互依赖关系,很难复制。

第一次安装的东西,它通常是由人手动调整才正常工作的,有时那是个具体特定的版本。当你构建第二个时,很难确定它是完全一样的。即使在具有严格的配置管理的站点中,你也可能丢了某些东西,或者过期了。

例如,如果你已经失去对解密密钥的访问权限,那么加密备份没有太多用处。而且任何只在灾难中使用的部分都可能从你上次检查它们过后就破环了。确保你已经涵盖了所有东西的唯一方法做认真地故障切换。当你准备好了的,就计划一下你的灾难(演练)吧!

如果你可以设计系统,以使灾难恢复模式成为正常运行的一部分,那么情况会更好。如果你的服务从一开始就被设计为可复制的,添加更多的副本就是一个常规的操作并可能是自动化的。没有新的方法,这只是一个容量问题。但是,系统中仍然存在一些只能在一个或两个地方运行的组件。偶然计划中的假灾难能够很好地将它们暴露出来。

顺便说一句,那些被遗忘的组件可能包括仅在一个人的大脑中的信息,所以如果你自己发现说:“我们不能在 X 休假回来前进行 DR 故障切换测试”,那么那个人是一个危险的单点失败。

仅在灾难中使用的部分系统需要最多的测试,否则在需要时会失败。这个部分越少越安全,且辛苦的测试工作也越少。

3、 为什么服务相互依赖使得灾难恢复更加困难?

如果你只有一个二进制文件,那么恢复它是比较容易的:你做个二进制备份就行。但是我们越来越多地将通用功能分解成单独的服务。微服务意味着我们有更多的灵活性和更少地重新发明轮子:如果我们需要一个后端做一些事情,并且有一个已经存在,那么很好,我们就可以使用它。但是一些需要保留很大的依赖关系,因为它很快会变得纠缠。

你可能知道你直接使用的后端,但是你可能不会注意到有新的后端添加到你使用的库中。你可能依赖于某个东西,它也间接依赖于你。在依赖中断之后,你可能会遇到一个死锁:两个系统都不能启动,直到另一个运行并提供一些功能。这是一个困难的恢复情况!

你甚至可以最终遇到间接依赖于自身的东西,例如你需要配置启动网络的设备,但在网络关闭时无法访问该设备。人们通常会提前考虑这些循环依赖,并且有某种后备计划,但是这些本质上是不太行得通的方式:它们只适用于极端情况,并且以不同的方式使用你的系统、进程或代码。这意味着,它们很可能有一个不会被发现的问题,直到你真的,真的需要它们的工作的时候才发现。

4、 你建议人们在感觉需要之前就开始有意管理其依赖关系,以防止潜在的灾难性系统故障。为什么这很重要,你有什么建议有效地做到这一点?

管理你的依赖关系对于确保你可以从灾难中恢复至关重要。它使操作系统更容易。如果你的依赖不可靠,那么你就不可靠,所以你需要知道它们是什么。

虽然在它们变得混乱后也可以开始管理依赖关系,但是如果你早点开始,它会变得更容易一些。你可以设置使用各种服务策略——例如,你必须在堆栈中的这一层依赖于这组系统。你可以通过使其成为设计文件审查的常规部分,引入考虑依赖关系的习惯。但请记住,依赖关系列表将很快变得陈旧。如果你有程序化的发现依赖关系的方式,甚至强制实施依赖,这是最好的。 我的 Velocity 谈话涵盖了我们如何做到这一点。

早期开始的另一个优点是,你可以将服务拆分为垂直“层”,每个层中的功能必须能够在下一个层启动之前完全在线。所以,例如,你可以说网络必须能够完全启动而不借助任何其他服务。然后说,你的存储系统应该仅仅依赖于网络,程序后端应该仅仅依赖于网络和存储,等等。不同的层次对于不同的架构是有意义的。

如果你提前计划,新服务更容易选择依赖关系。每个服务应该只依赖堆栈中较低的服务。你仍然可以结束循环,在相同的层次服务上批次依赖 —— 但是它们可以更加紧密地包含,并且在逐个基础上处理更容易。

5、 你对 Velocity NY 的其他部分感兴趣么?

我整个星期二和星期三的时间表都完成了!正如你可能收集的那样,我非常关心大型相互依赖的系统的可管理性,所以我期待听到 Carin Meier 关于管理系统复杂性的想法Sarah Wells 的微服务Baron 的可观察性 的谈话。我非常着迷听到 Jon Moore 关于 Comcast 如何从年度发布到每天发布的故事。作为一个前系统管理员,我很期待听到 Bryan Liles 对这个职位走向的看法


作者简介:

Nikki McDonald 是 O'Reilly Media,Inc. 的内容总监。她住在密歇根州的安娜堡市。

Tanya Reilly 自 2005 年以来一直是 Google 的系统管理员和站点可靠性工程师,致力于分布式锁、负载均衡和引导等底层基础架构。在加入 Google 之前,她是爱尔兰最大的 ISP eircom.net 的系统管理员,在这之前她担当了一个小型软件公司的整个 IT 部门。


via: https://www.oreilly.com/ideas/creating-better-disaster-recovery-plans

作者:Nikki McDonald, Tanya Reilly 译者:geekpi 校对:wxy

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

开源网络出版软件 WordPress 的联合创始人 Matt Mullenweg 日前表示,出于对 Facebook 开源许可证中专利条款的担忧,WordPress 社区将不再使用 Facebook 的 React JavaScript 库。

Mullenweg 在一篇博客文章中对其决定做出了解释。几个星期之前,即便是在 Apache 基金会表示了不再允许其项目使用 Facebook 许可证后,Facebook 还是决定保留其在 React 许可证中附加的专利条款。Mullenweg 认为,试图去删除该专利条款将“增加他们在对抗无事实根据的诉讼方面所花费的时间和费用”。

Mullenweg 表示,他不是在评论 Facebook 或者认为 Facebook 错了。Facebook 的决定对于 Facebook 来说是正确的,这是他们的工作,Facebook 可以决定以任何他们想要的方式来授权其软件。但对于 Mullenweg 来说,Facebook 的意图已经非常明确了。

几年之前,Automattic 将 React 作为基础来重写 WordPress.com 的前端 Calypso,这应该是基于 React 的最大的开源项目之一。正如 Automattic 的法律顾问所写,Automattic 做出了最好不要牵涉到专利问题的决定,在今天仍是如此。

总体来说,Mullenweg 过去一直对 React 很满意。最近,WordPress 社区开始将 React 用于 Gutenberg 项目,这是该社区多年以来最大的核心项目。人们在 React 方面的经验以及 React 社区(包括 Calypso)的规模,是 WordPress 将 React 用于 Gutenberg 项目的考虑因素之一。这使得 React 成为 WordPress 以及为 WordPress 编写的数以万计插件的事实上的标准。

Mullenweg 在博客里表示,WordPress 曾准备了一份几千字的公告,阐述了 React 是多么伟大,WordPress 如何正式采用了 React,以及鼓励插件同样采用 React。在该公告中,Mullenweg 一直希望专利问题能够以一种让用户放心使用的方式解决。

但这份公告现在不会被公布了。Mullenweg 表示,Gutenberg 项目将会退而采用另外的库来进行重写。这使得 Gutenberg 项目至少要延迟几个星期,其发布日期可能要推到明年。

Automattic 还将采用另外的同样的库来重写 Calypso,这将需要更长的时间。Automattic 目前还未牵涉到专利条款的问题当中。虽然会对业务造成短期影响,但是从内核的长期一致性来考虑,重写是值得的。WordPress 的内核升级涉及到全部网页的四分之一以上,让它们全部继承专利条款问题令人担忧。

Mullenweg 认为,Facebook 的专利条款实际上比许多公司可以采取的其他方法更清晰,Facebook 已经成为不错的开源贡献者之一。让全世界夸赞 Facebook 专利条款不是 Automattic 的工作,而是 Facebook 自己的战斗。

Mullenweg 在博客中表示,采用哪个库来重写将会在另外的帖子中公布,这主要是技术性的决定。Automattic 将会寻求具备 React 的大部分优势,同时又没有给许多人造成混淆和威胁的专利条款包袱的替代选择,并请大家就这些问题提供反馈。目前针对替换的库已经有了几个建议,包括 VueJS 、Preact 等。

另据 TechCrunch 报道,针对 Facebook 公司的专利条款,一些最激烈的批评家认为其将“特洛伊木马”引入了开源社区。对于 Mullenweg 在博客中发布的决定,一位评论家称之为“艰难但重要的决定”,其他评论家则将其称为“明智”和“有益”的决定。

而另外一些评论则发出了警告:“不要过度反应。过去五六年来,WordPress 生态系统的动荡和流失已经足够多了。Facebook 的业务规模和范围使得该条款变得非常可怕。它们最终必须放弃。”


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

WordPress 和 ReactJS 分道扬镳了,WordPress 的共同创始人 Matt Mullenweg 在其博客中宣布了这一消息。

关于 WordPress 之后将采用何种 JavaScript 框架,Matt 并未宣布,目前几个选择:

  1. VueJS
  2. Preact
  3. 其它框架(AngularEmberPolymerAurelia 等等)

其中, VueJS 和 Preact 的呼声最高。关于它们的优劣势分析如下:

VueJS

  • 优势:易于学习
  • 优势:与 Laravel 一贯协作良好
  • 优势:比 Preact 更流行,支持的社区更多
  • 优势:贡献者比 Preact 更多
  • 劣势依赖于关键人物
  • 状态:Github 上有 133 个核心贡献者,67152 个星标,做了 209 次发布
  • 资金支持:截止至本文写作, 在社区的支持下,VueJS 在 OpenCollective 得到了每年 $9,895 的捐助,作者尤雨溪在 [Patreon](https://www.patreon.com/evanyou) 得到了每月 $8,815 的捐助。

我确信 WordPress 使用 VueJS 能够更好。VueJS 有大量的拥护者,而且初学者易于上手。如果采用 VueJS,这对于 WordPress 是极好的。我自己也在几个项目中使用 VueJS,我喜欢它。

此外,这个框架也可以用在 WordPress 之外的项目(比如 Vue 与 Laravel 的集成),这可以让开发者在 WordPress 项目和非 WordPress 项目中发挥其经验。 有很多开发者都同时参与 Laravel 和 WordPress 项目,所以如果使用同一个框架,有助于同时推动 Laravel、 VueJS 和 WordPress 的发展。

PreactJS

  • 优势:易于过渡
  • 优势:与 VueJS 大致相同的资金支持,不断推进的社区
  • 优势:基于 React 的子集库仍然被 Preact 和 compat 支持
  • 劣势:过渡也许导致代码混乱和困扰(针对初学者)
  • 劣势:依赖于关键人物
  • 状态:在 GitHub 上有 100 个核心贡献者, 14319 个星标,做了 114 次发布
  • 资金支持:截止至本文写作,在社区的支持下, Preact 在 OpenCollective 得到了 $16,087 的捐助

PreactJS 有其优势,但我找不到合适的人咨询(我仅在两个项目中稍微使用过它)。不过看起来从 React 过渡到 Preact 非常容易。这也许会促使开发者选择 Preact,但是我认为这不是选择它的理由。这只会让开发者在采用这个新的 JavaScript 框架生态、node 模块、Webpack 时发生混淆,Preact 又不是 React 的别名!这会让代码味道难闻。

本文作者在几个平台上做了投票,欢迎参与你的意见:

那么你的意见呢?

(题图:maxprog.net.pl)

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分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

引子:开源软件作者发出求救

约一个月前,笔者撰写了“开源情怀遭遇专利咸猪手”。现在我们回一下锅:看看事情的进展,分析可能的结果,以期开源人再碰到类似状况时,对可能的发展能多一点预期和准备,少一点盲目性和不确定性。

事情是这样开始的:按照开源中国博客文章,一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利。

XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。

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

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

从此事开始以及开源中国与专利申请人进行交涉的进展报告发出到现在,3 个多月过去了,没有进一步的实质性进展。笔者并不认为奇怪。为什么呢?

如何发展?我们来抽丝剥茧……

没有进展,就是双方谈不拢。开源作者及开源中国一方的要求总结如下:

作者的诉求包括:

  • 专利申请人向专利局申请撤销专利。
  • 以公司名义发布正面声明,客观的描述此事。

开源中国与作者对声明内容的要求是:

  1. 详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。
  2. 在声明中表明将公开宣布主动申请撤销专利。
  3. 如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

从法律角度讲,双方对话行为属于民事行为,是基于双方自愿而进行的,任何一方都没有义务必须要进行对话协商。而如果对话不能进行,且当任何一方认为自己的正当权益受到对方损害时,可以向法院针对对方提起民事诉讼,也就是让法院做主。

专利申请人那头先按下不表,让我们看看作者一方的正当权益是否受到了损害。很遗憾,看来现在的主动权在专利申请人一边。

开源作者的要求:专利申请人向专利局申请撤销专利。

解读:如果专利申请是不正当的,上述要求是合理的。反之,则不合理。所以问题的关键是专利申请人所提出的专利申请是否正当。该问题随后再进行分析。

开源作者的要求:(专利申请人)以公司名义发布正面声明,客观的描述此事。

解读:公司就这个问题做出声明和澄清,从法律角度讲,公司可以自主做出决定,通常出于礼貌和善意的沟通,尤其不会产生负面影响时,公司会比较愿意进行。但法律方面没有强制要求,也就是说,专利申请人没有沟通或发出声明的义务,即使公司方面存在问题。而实际上,公司方面是否存在问题,即专利申请人所提出的专利申请是否正当,尚没有确定。

开源中国与作者对声明内容的要求 1:详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。

解读:“管理不善”应当是指专利申请人如果进行了不正当的专利申请,则是一个管理不善的问题。这就又转回到了那个关键问题:专利申请是否正当。

这句话是比较有意思的:“如果是在开源软件上做改进,那么应该详细描述改进的内容”。这句话字面之下似乎淡淡的有一层意思:如果专利申请针对的是在开源软件基础上做出的改进,那么专利申请可以是正当的。是否如此呢?答案基本上是肯定的。

如笔者前文中提到过的,按照专利制度的本意,任何人可以在现有的公知技术的基础上做出创新性的改进,然后就改进的内容去申请专利。这是正当的,也是受到鼓励和法律保护的。

关键问题的答案

所以,“专利申请是否正当”这个关键问题的答案就依赖于专利申请人是否做出了创新性的改进并就该改进来申请的专利,如果是,则专利申请是正当的;如果不是,就不正当。

接下来,就更加微妙了。开源方要求“细描述改进的内容”,仅就此要求而言,站在专利申请人立场上,是绝对不可以加以说明的。原因是:专利申请人就此内容的任何技术性说明都可能对申请人的专利构成不良影响。专利正在经受国家知识产权局的审查,审查的重点内容就是专利的新创性,也就是其对现有技术到底做出了什么样的改进,改进是否有新创性。专利申请人就此内容发表的任何意见,专利审查员都可以从中摘出对专利申请的新创性不利的内容,利用其来缩小专利的保护范围甚至驳回专利申请。

这种情形之下,申请人不针对“改进的内容”发表任何意见是明智、正当的。而开源方如果坚持要求申请人“细描述改进的内容”就显得强人所难,就不那么正当了。这时,开源方正确的做法是自己来完成开源软件作品与专利申请的比对,如果认为专利申请并未做出实质性的创新,可以将技术分析意见及相关支持性的技术文件按照第三方意见的形式通过正当程序提交给专利审查员。如果审查员认为开源方提出的意见是正确的,当然会加以采纳,相应会对专利申请加以合理限制或予以驳回。如果开源方对审查员的认定结果并不满意,后续还有行政和司法救济程序可以利用。

三点提示

这里提示的第一点是:不能简单因为专利申请当中涉及到的开源软件中采用的技术就直接认为专利申请中不存在新创性的技术改进。对新创性改进而得来的技术方案,在加以描述时要涉及到现有技术,这是正常的,不可避免的。

第二点:真正完成专利申请是否有实质性创新,专业性很强,成本很高;走行政和司法救济程序,成本就更高了。

第三点暂且不表。为什么事情还没有进展其实已经清楚了:专利申请人方面不表态是正当和必然的。至少要等到专利审查员做出授权或驳回的决定才有初步分晓。

开源中国与作者对声明内容的要求:

2、在声明中表明将公开宣布主动申请撤销专利。

3、如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

解读:如果专利审查员做出授权决定,表明专利针对开源软件在内的现有技术做出了新创性改进,相应专利申请也就是正当的。既然是正当的,专利申请人想来不会撤销或放弃专利申请,也不会将辛苦得来的专利“开源”或开放给公众。如果专利审查员做出驳回决定,也就不存在专利申请人撤销或放弃专利申请的问题了。当然,如果有人发起后续行政、司法救济程序,则可能带来变数。

完整地讨论好问题,就要说到第三点:如果专利最终被行政或司法认定成没有新创性从而被驳回,是否就足以证明专利申请人恶意窃取开源软件的技术成果呢?如果没有充分的相关理由和证据,还真不好这么下结论。因为很可能专利申请人出于善意想做出发明,并认为自己已经做出了具有新创性的改进,而最终做出认定的国家知识产权局或法院对新创性的理解和要求与专利申请人不同,才得出了不具有新创性的结论。如果是这种情况,专利申请人只是犯了一个诚实的错误而并不具有恶意。

收尾,旧话重提

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


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