TrueOS 很快会有一些非常重大的变化。今天，我们将了解桌面 BSD 领域将会发生什么。

通告

TrueOS 背后的团队宣布，他们将改变项目的重点。到目前为止，TrueOS 使用开箱即用的图形用户界面来轻松安装 BSD。然而，它现在将成为“一个先进的操作系统，保留你所知道和喜欢的 ZFS（OpenZFS）和 FreeBSD的所有稳定性，并添加额外的功能来创造一个全新的、创新的操作系统。我们的目标是创建一个核心操作系统，该系统具有模块化、实用性，非常适合自己动手和高级用户。“

从本质上讲，TrueOs 将成为 FreeBSD 的下游分支。他们将集成更新一些的软件到系统中，例如 OpenRC 和 LibreSSL。他们希望能坚持 6 个月的发布周期。

其目标是使 TrueOS 成为可以作为其他项目构建的基础。缺少图形部分以使其更加地与发行版无关。

桌面用户如何？

如果你读过我的TrueOS 评论并且有兴趣尝试使用桌面 BSD 或已经使用 TrueOS，请不要担心（这对于生活来说也是一个很好的建议）。TrueOS 的所有桌面元素都将剥离到 Project Trident。目前，Project Trident 网站的细节不多。他们仿佛还在进行剥离的幕后工作。

如果你目前拥有 TrueOS，则无需担心迁移。TrueOS 团队表示，“对于那些希望迁移到其他基于 FreeBSD 的发行版，如 Project Trident 或 GhostBSD 的人而言将会有迁移方式。”

想法

当我第一次阅读该公告时，坦率地说有点担心。改变名字可能是一个坏主意。客户将习惯使用一个名称，但如果产品名称发生变化，他们可能很容易失去对项目的跟踪。TrueOS 经历过名称更改。该项目于 2006 年启动时，它被命名为 PC-BSD，但在 2016 年，名称更改为 TrueOS。它让我想起了ArchMerge 和 Arcolinux 传奇。

话虽这么说，我认为这对 BSD 的桌面用户来说是一件好事。我常听见对 PC-BSD 和 TrueOS 的一个批评是它不是很精致。剥离项目的两个部分将有助于提高相关开发人员的关注度。TrueOS 团队将能够为缓慢进展的 FreeBSD 添加更新的功能，Project Trident 团队将能够改善用户的桌面体验。

我希望两个团队都好。请记住，当有人为开源而努力时，即使是我们不会使用的部分，我们也都会受益。

你对 TrueOS 和 Project Trident 的未来有何看法？请在下面的评论中告诉我们。

关于作者：

我叫 John Paul Wohlscheid。我是一个有抱负的神秘作家，喜欢玩技术，尤其是 Linux。你可以在我的个人网站关注我。

via: https://itsfoss.com/trueos-plan-change/

作者：John Paul Wohlscheid 译者：geekpi 校对：wxy

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

人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。Ben Hindman 在这里解释了 Mesos 是如何对另外一种技术进行补充的。

Mesos 的起源可以追溯到 2009 年，当时，Ben Hindman 还是加州大学伯克利分校研究并行编程的博士生。他们在 128 核的芯片上做大规模的并行计算，以尝试去解决多个问题，比如怎么让软件和库在这些芯片上运行更高效。他与同学们讨论能否借鉴并行处理和多线程的思想，并将它们应用到集群管理上。

Hindman 说 “最初，我们专注于大数据” 。那时，大数据非常热门，而 Hadoop 就是其中的一个热门技术。“我们发现，人们在集群上运行像 Hadoop 这样的程序与运行多线程应用及并行应用很相似。”Hindman 说。

但是，它们的效率并不高，因此，他们开始去思考，如何通过集群管理和资源管理让它们运行的更好。“我们查看了那个时期很多的各种技术” Hindman 回忆道。

然后，Hindman 和他的同事们决定去采用一种全新的方法。“我们决定对资源管理创建一个低级的抽象，然后在此之上运行调度服务和做其它的事情。” Hindman 说，“基本上，这就是 Mesos 的本质 —— 将资源管理部分从调度部分中分离出来。”

他成功了，并且 Mesos 从那时开始强大了起来。

将项目呈献给 Apache

这个项目发起于 2009 年。在 2010 年时，团队决定将这个项目捐献给 Apache 软件基金会（ASF）。它在 Apache 孵化，并于 2013 年成为顶级项目（TLP）。

为什么 Mesos 社区选择 Apache 软件基金会有很多的原因，比如，Apache 许可证，以及基金会已经拥有了一个充满活力的其它此类项目的社区。

与影响力也有关系。许多在 Mesos 上工作的人也参与了 Apache，并且许多人也致力于像 Hadoop 这样的项目。同时，来自 Mesos 社区的许多人也致力于其它大数据项目，比如 Spark。这种交叉工作使得这三个项目 —— Hadoop、Mesos，以及 Spark —— 成为 ASF 的项目。

与商业也有关系。许多公司对 Mesos 很感兴趣，并且开发者希望它能由一个中立的机构来维护它，而不是让它成为一个私有项目。

谁在用 Mesos？

更好的问题应该是，谁不在用 Mesos？从 Apple 到 Netflix 每个都在用 Mesos。但是，Mesos 也面临任何技术在早期所面对的挑战。“最初，我要说服人们，这是一个很有趣的新技术。它叫做‘容器’，因为它不需要使用虚拟机” Hindman 说。

从那以后，这个行业发生了许多变化，现在，只要与别人聊到基础设施，必然是从”容器“开始的 —— 感谢 Docker 所做出的工作。今天再也不需要做说服工作了，而在 Mesos 出现的早期，前面提到的像 Apple、Netflix，以及 PayPal 这样的公司。他们已经知道了容器替代虚拟机给他们带来的技术优势。“这些公司在容器成为一种现象之前，已经明白了容器的价值所在”， Hindman 说。

可以在这些公司中看到，他们有大量的容器而不是虚拟机。他们所做的全部工作只是去管理和运行这些容器，并且他们欣然接受了 Mesos。在 Mesos 早期就使用它的公司有 Apple、Netflix、PayPal、Yelp、OpenTable 和 Groupon。

“大多数组织使用 Mesos 来运行各种服务” Hindman 说，“但也有些公司用它做一些非常有趣的事情，比如，数据处理、数据流、分析任务和应用程序。“

这些公司采用 Mesos 的其中一个原因是，资源管理层之间有一个明晰的界线。当公司运营容器的时候，Mesos 为他们提供了很好的灵活性。

“我们尝试使用 Mesos 去做的一件事情是去创建一个层，以让使用者享受到我们的层带来的好处，当然也可以在它之上创建任何他们想要的东西，” Hindman 说。 “我认为这对一些像 Netflix 和 Apple 这样的大公司非常有用。”

但是，并不是每个公司都是技术型的公司；不是每个公司都有或者应该有这种专长。为帮助这样的组织，Hindman 联合创建了 Mesosphere 去围绕 Mesos 提供服务和解决方案。“我们最终决定，为这样的组织去构建 DC/OS，它不需要技术专长或者不想把时间花费在像构建这样的事情上。”

Mesos vs. Kubernetes?

人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。大多数的技术在一些领域总是重叠的，并且它们可以是互补的。“我不喜欢将所有的这些东西都看做是竞争者。我认为它们中的一些与另一个在工作中是互补的，” Hindman 说。

“事实上，名字 Mesos 表示它处于 ‘中间’；它是一种中间的操作系统”， Hindman 说，“我们有一个容器调度器的概念，它能够运行在像 Mesos 这样的东西之上。当 Kubernetes 刚出现的时候，我们实际上在 Mesos 的生态系统中接受了它，并将它看做是在 Mesos 上的 DC/OS 中运行容器的另一种方式。”

Mesos 也复活了一个名为 Marathon（一个用于 Mesos 和 DC/OS 的容器编排器）的项目，它成为了 Mesos 生态系统中最重要的成员。但是，Marathon 确实无法与 Kubernetes 相比较。“Kubernetes 比 Marathon 做的更多，因此，你不能将它们简单地相互交换，” Hindman 说，“与此同时，我们在 Mesos 中做了许多 Kubernetes 中没有的东西。因此，这些技术之间是互补的。”

不要将这些技术视为相互之间是敌对的关系，它们应该被看做是对行业有益的技术。它们不是技术上的重复；它们是多样化的。据 Hindman 说，“对于开源领域的终端用户来说，这可能会让他们很困惑，因为他们很难去知道哪个技术适用于哪种任务，但这是这个被称之为开源的本质所在。“

这只是意味着有更多的选择，并且每个都是赢家。

via: https://www.linux.com/blog/2018/6/mesos-and-kubernetes-its-not-competition

作者：Swapnil Bhartiya 选题：lujun9972 译者：qhwdw 校对：wxy

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

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

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

6 将作品与依据 GNU 许可证发布的代码相结合

6.1 GPL v3 是否与 GPL v2 兼容？

不兼容。许多要求已经从 GPL v2 变为 GPL v3，这意味 GPL v2 中的精确要求并不体现在 GPL v3 中，反之亦然。例如，GPL v3 的终止条件比 GPL v2 的终止条件更为宽泛，因此与 GPL v2 的终止条件不同。

由于这些差异，两个许可证不兼容：如果您试图将依据 GPL v2 发布的代码与依据 GPL v3 发布的代码组合，则将违反 GPL v2 的第 6 部分。

但是，如果代码依据 GPL “v2 或更高版本”发布，则与 GPL v3 兼容，因为 GPL v3 是其允许的选项之一。

6.2 GPL v2 是否有提供安装信息的要求？

GPL v3 明确要求再分发中包含完整的必要的“安装信息”。GPL v2 不使用该术语，但它需要再分发中包含用于控制可编译和安装可执行文件的脚本以及完整和相应的源代码。这涵盖了 GPL v3 中称为“安装信息”的部分内容，但不包括所有内容。因此，GPL v3 对安装信息的要求较强。

6.3 各种 GNU 许可证之间如何相互兼容？

各种 GNU 许可证彼此之间具有广泛的兼容性。下面是唯一的一种您不能将遵循两种 GNU 许可证的代码结合起来的情况：将遵循旧版本许可证的代码与遵循该许可证新版本的代码进行结合。

以下是 GNU 许可证的各种结合的详细兼容性矩阵，以便为特定情况提供易于使用的参考。它假设有人依据其中一个许可证编写了一些软件，而您希望以某种方式将该软件的代码结合到您要发布的项目（您自己的原始作品或其他人的软件的修改版本）中。在表顶部的列中找到项目的许可证，并在左侧的一行中找到其他代码的许可证。它们交叉的单元格会告诉您这种结合是否被允许。

当我们说“复制代码”时，我们的意思就是：您正在从一个源代码中获取一段代码（无论是否修改），并将其插入到自己的程序中，从而基于第一部分代码形成一个作品。当您编译或运行代码时，“使用库”意味着您不直接复制任何源代码，而是通过链接、导入或其他典型机制将源代码绑定在一起。

矩阵中每个标明 GPL v3 的地方，其关于兼容性的声明也同样适用于 AGPL v3。

兼容性矩阵

角注：

1. 在这种情况下，当结合代码时，您必须遵守 GPL v2 的条款。您不能适用更高版本的条款。
2. 在这种情况下，您可以依据 GPL v2 或更高版本发布您的项目（您的原始作品和/或您收到并修改的作品），请注意，您使用的其他代码仍然只能遵循 GPL v2。只要您的项目依赖于该代码，您将无法将项目的许可证升级到 GPL v3 或更高版本，整个作品（您的项目和其他代码的任意结合）只能依据 GPL v2 的条款传递。
3. 如果您有能力依据 GPL v2 或任何更高版本发布项目，您可以选择依据 GPL v3 或更高版本发布该项目，一旦您执行此操作，您就可以结合依据 GPL v3 发布的代码。
4. 如果您有能力依据 LGPL v2.1 或任何更高版本发布项目，您可以选择依据 LGPL v3 或更高版本发布该项目，一旦您这样做，您就可以结合依据 LGPL v3 发布的代码。
5. 在这种情况下结合代码时，您必须遵守 LGPL v2.1 的条款。您不能适用更高版本 LGPL 中的条款。
6. 如果这样做，只要项目包含仅依据 LGPL v2.1 发布的代码，您将无法将项目的许可证升级到 LGPL v3 或更高版本。
7. LGPL v2.1 允许您将遵循自 GPL v2 之后任何版本 GPL 的代码进行重新许可。如果在这种情况下可以将遵循 LGPL 的代码切换为使用适当版本的 GPL（如表所示），则可以进行此种结合。
8. LGPL v3 是 GPL v3 加上在这种情况下可以忽略的额外权限。
9. 由于 GPL v2 不允许与 LGPL v3 结合，因此在这种情况下，您必须依据 GPL v3 的条款传递项目，因为它允许此种结合。

6.4 “聚合” （ aggregate ） 与其他类型的“修改版本”有什么区别？（同 2.25）

“聚合”由多个单独的程序组成，分布在同一个 CD-ROM 或其他媒介中。GPL 允许您创建和分发聚合，即使其他软件的许可证不是自由许可证或与 GPL 不兼容。唯一的条件是，发布“聚合”所使用的许可证不能禁止用户去行使“聚合”中每个程序对应的许可证所赋予用户的权利。

两个单独的程序还是一个程序有两个部分，区分的界限在哪里？这是一个法律问题，最终由法官决定。我们认为，适当的判断标准取决于通信机制（exec、管道、rpc、共享地址空间内的函数调用等）和通信的语义（哪些信息被互换）。

如果模块们被包含在相同的可执行文件中，则它们肯定是被组合在一个程序中。如果模块们被设计为在共享地址空间中链接在一起运行，那么几乎肯定意味着它们组合成为一个程序。

相比之下，管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。所以当它们用于通信时，模块们通常是单独的程序。但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以视为这两个部分合并成了一个更大的程序。

6.5 我在使用 GPL 程序的源代码时是否具有 “合理使用” （ fair use ） 权限？（同 4.17）

是的，您有。“合理使用”是在没有任何特别许可的情况下允许的使用。由于您不需要开发人员的许可来进行这种使用，无论开发人员在许可证或其他地方对此怎么说，您都可以执行此操作，无论该许可证是 GNU GPL 还是其他自由软件许可证。

但是，请注意，没有全世界范围普适的合理使用原则；什么样的用途被认为“合理”因国而异。

6.6 美国政府可否对遵循 GPL 的程序进行改进并发布？（同 3.14）

可以。如果这些改进是由美国政府雇员在雇佣期间编写的，那么这些改进属于公有领域。不过，GNU GPL 仍然涵盖了整体的改进版本。在这种情况下没有问题。

如果美国政府使用承包商来完成这项工作，那么改进本身可以被 GPL 覆盖。

6.7 GPL 对于与其所覆盖的作品进行静态或动态链接的模块有不同的要求吗？

没有。将 GPL 覆盖的作品静态或动态地链接到其他模块是基于 GPL 覆盖的作品构建结合作品。因此，GNU GPL 的条款和条件将覆盖整个结合作品。另请参阅：6.24 如果我在 GPL 软件中使用了与 GPL 不兼容的库，会出现什么法律问题？

6.8 LGPL 对于与其所覆盖的作品进行静态或动态链接的模块有不同的要求吗？

为了遵守 LGPL（任何现有版本：v2、v2.1 或 v3）：

（1）如果您静态链接到 LGPL 库，您还必须以对象（不一定是源代码）格式提供应用程序，以便用户有机会修改库并重新链接应用程序。

（2）如果您动态链接已经存在于用户计算机上的 LGPL 库，则不需要传递库的源代码。另一方面，如果您自己将可执行的 LGPL 库与您的应用程序一起传递，无论是静态还是动态链接，还必须以 LGPL 所提供的方式之一来传递库的源代码。

6.9 如果库依据 GPL（而不是 LGPL）发布，这是否意味着使用它的任何软件必须遵循 GPL 或与 GPL 兼容的许可证？

是的，因为程序实际上与库进行了链接。因此，GPL 的条款适用于整个结合作品。与库链接的软件模块可能遵循与GPL兼容的不同许可证，但整体作品必须遵循 GPL。另见：“2.23 许可证与 GPL 兼容是什么意思？”

6.10 您有一个遵循 GPL 的程序，我想将它与我的代码进行链接，来构建一个专有程序。那么事实上，我链接到您的程序意味着我必须让我的程序遵循 GPL 许可证？

不完全是。这意味着您必须依据与 GPL 兼容的许可证（更准确地说，与您链接的结合作品中所有其他代码所适用的一个或多个 GPL 版本相兼容）发布您的程序。然后，结合作品本身就可以遵循这些 GPL 版本。

6.11 如果是这样的话，有没有机会依据 LGPL 获得您的程序许可？

您可以这么要求，但绝大多数的作者都会坚定不移地说不。GPL 的想法是，如果要将我们的代码包含在程序中，您的程序也必须是自由软件。GPL 的意图是给您施加压力，让您以能够使其成为我们社区一部分的方式来发布您的程序。

您始终拥有不使用我们代码的合法选择。

6.12 我们构建专有软件的项目不能使用遵循 GPL 的某个 GNU 程序。您会为我们提供例外吗？ 这将意味着该程序拥有更多用户。

对不起，我们没有这样的例外。这样做是不对的。

最大化用户数量不是我们的目标。相反，我们正在努力为尽可能多的用户提供至关重要的自由。一般来说，专有软件项目是阻碍而不是实现软件自由的原因。

我们偶尔提供许可证例外来协助一个依据 GPL 以外的许可证生产自由软件的项目。不过，我们必须看到一个很好的理由，即这个项目为什么会推动自由软件的发展。

我们有时也会改变软件包的分发条款，这显然是为自由软件事业服务的正确方法；但是我们对此非常谨慎，所以您必须向我们展示非常有说服力的理由。

6.13 如果一个编程语言解释器是依据 GPL 发布的，这是否意味着由它解释的程序必须遵循与 GPL 兼容的许可证？

当解释器只是解释一种语言时，答案是否定的。被解释程序对于解释器来说只是数据；根据版权法，像GPL这样的自由软件许可证不能限制您使用解释器的数据。您可以使用任何数据（被解释程序），以任何您喜欢的方式运行它，并且没有任何要求规定您必须将数据授权给任何人。

然而，当解释器被扩展以向 其他程序 （ facilities ） （通常但不一定是库）提供 “绑定” （ bindings ） 时，被解释程序通过这些绑定有效地与其使用的程序相关联。因此，如果这些程序是依据 GPL 发布的，则使用它们的被解释程序必须以与 GPL 兼容的方式发布。JNI（Java Native Interface）是这种绑定机制的一个例子；以这种方式访问​​的库与调用它们的 Java 程序动态链接。这些库也与解释器联系在一起。如果解释器与这些库静态链接，或者如果它被设计为与这些特定库动态链接，那么也需要以与 GPL 兼容的方式发布。

另一个类似且非常常见的情况是为库提供解释器，它们能够自我解释。例如，Perl 带有许多 Perl 模块，Java 实现带有许多 Java 类。这些库和调用它们的程序总是动态链接在一起。

结果是，如果您选择在程序中使用遵循 GPL 的 Perl 模块或 Java 类，则必须以与 GPL 兼容的方式发布该程序，无论结合后的 Perl 或 Java 程序所依之运行的 Perl 或 Java 解释器中使用什么样的许可证。

6.14 如果编程语言解释器遵循与 GPL 不兼容的许可证，我可以在其上运行遵循 GPL 的程序吗？

当解释器解释一种语言时，答案是肯定的。被解释程序对于解释器来说只是数据；GPL 不会限制您处理程序时所使用的工具。

然而，当解释器被扩展以向 其他程序 （ facilities ） （通常但不一定是库）提供“绑定”时，被解释程序通过这些绑定有效地与其使用的程序相关联。JNI（Java Native Interface）是此种程序的一个例子；以这种方式访问​​的库与调用它们的 Java 程序动态链接。

因此，如果这些程序是依据与 GPL 不兼容的许可证发布的，则情况就像以任何其他方式跟与 GPL 不兼容的库链接。这意味着：

1. 如果您正在编写代码并将其依据 GPL 发布，您可以声明一个 明确例外 （ explicit exception ） ，允许将其链接到与 GPL 不兼容的程序。
2. 如果您依据 GPL 编写并发布程序，并且专门设计了与这些程序配合使用的功能，人们可以将其作为 隐性例外 （ implicit exception ） ，允许它们与这些程序进行链接。但是，如果这只是你的打算的话，最好明确地这么说。

您不能把别人遵循 GPL 的代码用于这种方式，或者添加这样的例外。只有该代码的版权所有者才能添加例外。

6.15 如果我将一个模块添加到遵循 GPL 的程序中，我必须使用 GPL 作为我的模块的许可证吗？

GPL 规定，整个结合后的程序必须依据 GPL 发布。所以你的模块必须可以依据 GPL 进行使用。

但是，您可以提供使用您代码的额外授权。如果您愿意，您可以依据比 GPL 更为宽松但与 GPL 兼容的许可证发布模块。许可证列表页面提供了与 GPL 兼容许可证的部分列表。

6.16 什么时候程序和插件会被认为是单一的结合程序？

这取决于主程序如何调用其插件。如果主程序使用 fork 和 exec 来调用插件，并通过共享复杂的数据结构或来回传送复杂的数据结构来建立 密切通信 （ intimate communication ） ，可以使它们成为一个单一的结合程序。如果主程序使用简单的 fork 和 exec 来调用插件并且不建立它们之间的密切通信，插件被认为是一个单独的程序。

如果主程序动态地链接插件，并且它们彼此进行函数调用并共享数据结构，我们相信它们形成了一个单一的结合程序，它必须被视为主程序和插件的扩展。如果主程序动态地链接插件，但是它们之间的通信仅限于使用某些选项调用插件的“main”功能，并等待它返回，这是一种 临界案例 （ borderline case ） 。

使用共享内存与复杂数据结构进行通信几乎等同于动态链接。

6.17 如果我写了一个用于遵循 GPL 程序的插件，那么对可用于分发我的插件的许可证有什么要求？

请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序 ？”以确定插件和主程序是否被视为单个结合程序，以及何时将其视为单独的作品。

如果主程序和插件是单个结合程序，则这意味着您必须依据 GPL 或与 GPL 兼容的自由软件许可证授权插件，并以符合 GPL 的方式将源代码进行分发。与其插件分开的主程序对插件没有要求。

6.18 在为非自由程序编写插件时，可以应用 GPL 许可证吗？

请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序？”以确定插件和主程序是否被视为单个结合程序，以及何时被视为单独的程序。

如果它们组成单一的结合程序，这意味着遵循 GPL 的插件与非自由主程序的结合将违反 GPL。但是，您可以通过向插件的许可证添加例外声明来解决该法律问题，并允许将其与非自由主程序链接。

另请参阅正在编写的使用非自由库的自由软件的问题。

6.19 我可以发布一个旨在加载遵循 GPL 的插件的非自由程序吗？

请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序？”以确定插件和主程序是否被视为单个结合程序，以及何时被视为单独的程序。

如果它们组成单一的结合程序，则主程序必须依据 GPL 或与 GPL 兼容的自由软件许可证发布，并且当主程序为了与这些插件一起使用而被分发时，必须遵循 GPL 的条款。

然而，如果它们是单独的作品，则插件的许可证对主程序没有要求。

另请参阅正在编写的使用非自由库的自由软件的问题。

6.20 我想将遵循 GPL 的软件纳入我的专有系统。我只依据 GPL 给予我的权限来使用该软件。我可以这样做吗？（同 5.6）

您不能将遵循 GPL 的软件纳入专有系统。GPL 的目标是授予每个人复制、再分发、理解和修改程序的自由。如果您可以将遵循 GPL 的软件整合到非自由系统中，则可能会使遵循 GPL 的软件不再是自由软件。

包含遵循 GPL 程序的系统是该 GPL 程序的扩展版本。GPL 规定，如果它最终发布的话，任何扩展版本的程序必须依据 GPL 发布。这有两个原因：确保获得软件的用户获得自己应该拥有的自由，并鼓励人们回馈他们所做的改进。

但是，在许多情况下，您可以将遵循 GPL 的软件与专有系统一起分发。要有效地做到这一点，您必须确保自由和非自由程序之间的通信 保持一定距离 （ arms length ） ，而不是将它们有效地结合成一个程序。

这种情况与“纳入”遵循 GPL 的软件之间的区别，是一部分实质和一部分形式的问题。实质上是这样的：如果两个程序结合起来，使它们成为一个程序的两个部分，那么您不能将它们视为两个单独的程序。所以整个作品必须遵循 GPL。

如果这两个程序保持良好的分离，就像编译器和内核，或者像编辑器和shell一样，那么您可以将它们视为两个单独的程序，但是您必须恰当执行。这个问题只是一个形式问题：您如何描述您在做什么。为什么我们关心这个？因为我们想确保用户清楚地了解软件集合中遵循 GPL 的软件的自由状态。

如果人们分发遵循 GPL 的软件，将其称为系统（用户已知其中一部分为专有软件）的“一部分”，用户可能不确定其对遵循GPL的软件所拥有的权利。但是如果他们知道他们收到的是一个自由程序加上另外一个程序，那么他们的权利就会很清楚。

6.21 我想将遵循 GPL 的软件纳入我的专有系统。我是否可以通过在 GPL 覆盖的部分和专有部分之间，放置一个遵循与 GPL 兼容的宽松许可证（如 X11 许可证）的 “封装” （ wrapper ） 模块来实现？

不可以，X11 许可证与 GPL 兼容，因此您可以向遵循 GPL 的程序添加一个模块，并让其遵循 X11 许可证。但是，如果要将它们整合到一个更大的程序中，那么这个整体将包含 GPL 覆盖的部分，所以它必须在 GNU GPL 下作为一个整体获得许可。

专有模块 A 仅通过遵循 X11 许可证的模块 B 与遵循 GPL 的模块 C 通信，该事实在法律上是无关紧要的；重要的是模块 C 包含在整体作品中。

6.22 我可以编写使用非自由库的自由软件吗？

如果您这样做，您的程序将无法在一个自由的环境中完全使用。如果您的程序依赖于一个非自由库来做某件工作，那么在自由软件世界里就不能做这个工作。如果这依赖于一个非自由库来运行，它不能是自由操作系统（例如 GNU）的一部分；这完全成为了自由软件世界里的禁区。

所以请考虑：你可以找到一种方法来完成这项工作，而不使用这个库吗？你可以为该库编写一个自由软件替代选择吗？

如果程序已经使用非自由库编写，那么改变决定也许已经太晚了。您也可以按照目前状态来发布程序，而不是不发布。但是请在 README 文件中提到，对非自由库的需求是一个缺点，并建议更改程序以便在没有非自由库的情况下执行相同的工作。请建议任何想要在程序上进行大量进一步工作的人首先将其从依赖非自由库中解脱出来。

请注意，将某些非自由库与遵循 GPL 的自由软件相结合也可能存在法律问题。有关更多信息，请参阅有关 GPL 软件与和其不兼容库的问题。

6.23 我可以将遵循 GPL 的程序与专有系统库链接吗？

每个版本的 GPL 相对于其 左版 （ copyleft ） 都有一个例外，通常称为系统库例外。如果您要使用的与 GPL 不兼容的库符合系统库的标准，则使用它们不需要做特别的工作；分发整个程序的源代码的要求不包括那些库，即使您分发包含它们的链接可执行文件。

作为 “系统库” （ system library ） 的标准在不同版本的 GPL 之间有所不同。GPL v3 在第 1 节中明确定义“系统库”，将其从 “相应源代码” （ Corresponding Source ） 的定义中排除。GPL v2 在第 3 部分的末尾进行，处理这个问题略有不同。

6.24 如果我在遵循 GPL 的软件中使用了与 GPL 不兼容的库，会出现什么法律问题？

如果您希望程序与未被系统库例外所涵盖的库链接，则需要提供许可来执行此操作。以下是您可以使用的两个许可证通知示例；一个用于 GPL v3，另一个用于 GPL v2。在这两种情况下，您应该将此文本放在您授予此权限的每个文件中。

只有该程序的版权持有人才能合法地按照这些条款发布其软件。如果您自己编写了整个程序，假设您的雇主或学校没有声明版权，您就是版权所有者，因此您可以授权该例外。但是，如果您想在代码中使用其他作者的其他遵循GPL的程序的一部分，那么您无法将例外授权给他们。您必须获得这些程序的版权所有者的批准。

当其他人修改程序时，他们不需要为他们的代码设置同样的例外——是否这样做是他们自己的选择。

如果您打算链接的库不是自由软件，请参阅使用非自由库编写自由软件部分。

如果您使用 GPL v3，您可以通过在第 7 节下授予额外权限来实现此目标。以下许可证通知将会执行此操作。您必须使用适合您程序的文本替换括号中的所有文本。如果不是每个人都可以为您打算链接的库分发源代码，则应该删除大括号中的文本；否则，只需删除大括号。

Copyright (C) [年份] [著作权人名称]

本程序为自由软件；您可以根据自由软件基金会发布的 GNU GPL 许可证的条款再分发和/或修改它；无论是依据本许可证的版本3，或（根据您的选择）任何更高版本。

本程序基于希望其有用的目标而分发，但不提供任何担保；甚至也没有适销性或适用于特定用途的默示担保。有关详细信息，请参阅 GNU GPL 许可证。

您应该已经收到本程序以及 GNU GPL 许可证的副本；如果没有，请参阅 http://www.gnu.org/licenses。

依据 GNU GPL v3 第7节的额外许可

如果您通过将[与库的名称]（或库的修改版本）链接或结合来修改本程序，或任何被覆盖的作品，其中包含被[库许可证的名称]的条款所覆盖的部分，则该程序的许可人授予您额外许可来传递所产出的作品。{这种结合的非源代码形式的相应源代码应包括所使用的[库名称]部分的源代码以及被覆盖的作品的源代码。}

如果您使用 GPL v2，您可以为许可证条款提供自己的例外。以下许可证通知将这样做。同样，您必须使用适合您程序的文本替换括号中的所有文本。如果不是每个人都可以为您打算链接的库分发源代码，则应该删除大括号中的文本；否则，只需删除大括号。

Copyright (C) [年份] [著作权人名称]

本程序为自由软件；您可以根据自由软件基金会发布的 GNU GPL 许可证的条款再分发和/或修改它；无论是依据许可证的 v2，或（根据您的选择）任何更高版本。

本程序基于希望其有用的目标而分发，但不提供任何担保；甚至也没有适销性或适用于特定用途的默示担保。有关详细信息，请参阅 GNU GPL 许可证。

您应该已经收到本程序以及 GNU GPL 许可证的副本；如果没有，请参阅 http://www.gnu.org/licenses。

将[您的程序名称]与其他模块静态或动态链接是以[您的程序名称]为基础构建结合作品。因此，GNU GPL 许可证的条款和条件将覆盖整个结合作品。

另外，作为一个特殊例外，[您的程序名称]的版权持有人可以让您将[您的程序名称]与依据 GNU LGPL 发布的自由程序或库以及依据[库的许可证名称]标准发布的[库名称]中包含的代码相结合（或具有相同许可证的此类代码的修改版本）。您可以按照[您的程序名称]所依据的 GNU GPL 的条款和其他有关代码的许可证复制和分发此系统{前提是当 GNU GPL 要求分发源代码时将其他代码的源代码包含在内}。

注意，对[您的程序名称]做出修改版本的人没有义务为其修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU GPL 许可证允许发布一个没有此例外的修改版本；该例外也使得发布一个带有该例外的修改版本成为可能。

6.25 我正在使用 Microsoft Visual C ++（或 Visual Basic）编写 Windows 应用程序，我将依据 GPL 发布它。依据GPL，是否允许将我的程序与 Visual C ++（或 Visual Basic）运行时库动态链接？

您可以将您的程序链接到这些库，并将编译后的程序分发给其他程序。执行此操作时，运行时库是 GPL v3 所定义的“系统库”。这意味着您不需要担心将库的源代码包含在程序的相应源代码中。GPL v2 在第 3 节中提供了类似的例外。

您可能不会随同您的程序以编译后的 DLL 形式分发这些库。为了防止不道德的分发者试图将系统库例外作为漏洞进行利用，GPL 表示，只有库不与程序本身一起分发，库才能被认定为系统库。如果您随同您的程序分发 DLL，则它们将不再符合此例外的资格；那么遵守 GPL 的唯一方法就是提供它们的源代码，而您无法做到。

可以编写只在 Windows 上运行的自由程序，但这不是一个好主意。这些程序将被 Windows “围困” （ trapped ） ，因此对自由软件世界的贡献为零。

6.26 我想修改遵循 GPL 的程序，并将它们与 Money Guzzler Inc. 的可移植性库链接。我无法分发这些库的源代码，因此，任何想要更改这些版本的用户都必须单独获取这些库。为什么 GPL 不允许这样做？

有两个原因。第一、一般性的原因。如果我们允许 A 公司制作一个专有文件，B 公司分发与该文件相关的遵循 GPL 的软件，其效果等同于将 GPL 撕开一个大洞。对于保持 GPL 软件各种修改和扩展的源代码来说，这如同一张署名空白纸。

让所有用户能够访问源代码是我们的主要目标之一，所以这个结果绝对是我​​们想要避免的。

更具体地说，根据我们对条款的理解，与 Money Guzzler 库链接的程序版本不会是真正的自由软件——它们不会附带完整的让用户能够更改和重新编译程序的源代码。

6.27 如果模块 Q 的许可证具有与 GPL 不兼容的要求，但是只有当 Q 自身分发时，而不是在较大程序中包含 Q 时，该要求才适用，是否可以使得该许可证与 GPL 兼容？可以将 Q 与遵循 GPL 的程序结合使用吗？

如果程序 P 依据 GPL 被发布，这意味着“任何和所有部分”都可以依据 GPL 进行使用。如果您集成了模块 Q，并依据 GPL 发布结合程序 P + Q，则表示可以依据 GPL 使用 P + Q 的任何部分。P + Q 的一部分是 Q，所以依据 GPL 发布 P + Q 意味着，Q 的任何部分可以依据 GPL 进行使用。换句话说，依据 GPL 获得 P + Q 的用户可以删除 P，所以 Q 仍然遵循 GPL。

如果模块 Q 的许可证允许您授予该许可，则其与 GPL 兼容。否则，它不与 GPL 兼容。

如果 Q 的许可证在不明确的条件下表示，您必须在自己再分发 Q 时做某些事情（与 GPL 不兼容），那么不允许您依据 GPL 分发Q。因此，您也不能依据 GPL 发布 P + Q。所以您不能将 P 与 Q 进行链接或结合。

6.28 在面向对象的语言（如 Java）中，如果我在不修改的情况下使用遵循 GPL 的类，并对其进行子类化，GPL 会以什么方式影响较大的程序？

子类化将会创建衍生作品。因此，当您创建遵循 GPL 的类的子类时，GPL 的条款会影响整个程序。

6.29 分发一个意图链接到 Linux 内核的非自由驱动程序会违反 GPL 吗？

Linux（GNU / Linux 操作系统中的内核）依据 GNU GPL v2 进行分发。分发一个意图链接 Linux 的非自由驱动程序违反 GPL 吗？

是的，这是一种违规行为，因为这样做形成了更大的结合作品。用户期望把这些片段放在一起的事实并不会改变任何事情。

在代码实体部分拥有版权的 Linux 的每个贡献者都可以执行 GPL，我们鼓励他们对那些分发非自由 Linux 驱动程序的人采取行动。

6.30 如何允许在受控接口下将专有模块与我的 GPL 库链接起来？

在声明该文件依据 GNU GPL 进行分发的文本末尾，将以下文本添加到软件包中每个文件的许可证通知中：

将 ABC 与其他模块静态或动态链接是基于 ABC 创建结合作品。因此，GNU GPL 许可证的条款和条件将覆盖整个结合作品。

作为一个特殊的例外，ABC 的版权所有者可以将 ABC 程序与自由软件程序或依据 GNU LGPL 发布的库以及通过 ABCDEF 界面与 ABC 通信的独立模块相结合。您可以根据 ABC 的 GNU GPL 条款和其他代码的许可证复制和分发此系统，前提是您在 GNU GPL 需要分发源代码时提供该代码的源代码，并且您没有修改 ABCDEF 界面。

请注意，制作 ABC 修改版本的人没有义务为其修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU GPL 许可证允许发布不含此例外的修改版本；此例外也使得发布一个带有该例外的修改版本成为可能。如果您修改了 ABCDEF 界面，此例外不适用于您修改的 ABC 版本，并且您必须在分发修改后的版本时删除此例外。

此例外是依据 GNU GPL 许可证第3版（“GPL v3”）第7节的额外权限。

此例外允许通过指定接口（“ABCDEF”）与遵循不同许可证的模块进行链接，同时确保用户仍然会按照 GPL 通常的方式接收源代码。

只有该程序的版权持有者才能合法授权此例外。如果您自己编写了整个程序，假设您的雇主或学校没有声明版权，您就是版权所有者，因此您可以授权该例外。但是，如果您想在代码中使用其他作者的其他遵循 GPL 程序的一部分，那么您无法对他们的例外进行授权。您必须获得这些程序的版权所有者的批准。

6.31 考虑这种情况：1）X 发布遵循 GPL 的项目的 V1 版本。2）基于对 V1 的修改和新代码开发，Y 对 V2 的改进做出贡献。3）X 想将 V2 转换为非 GPL 许可证。X 需要 Y 的许可吗？

需要。Y 需要依据 GNU GPL 发布其版本，因为它基于 X 的版本 V1。没有任何要求规定 Y 为其代码适用任何其他许可。因此，X 必须获得 Y 的许可才能依据另一个许可证发布该代码。

6.32 我已经编写了一个与许多不同组件链接的应用程序，它们具有不同的许可证。我对我的程序有什么许可要求感到很困惑。您能告诉我可以使用哪些许可证吗？

为了回答这个问题，我们需要看一下你的程序使用的每个组件的列表，该组件的许可证和一个简短的（几句话应该足够）说明你的库如何使用该组件的描述。两个例子是：

• 为了让我的软件工作，它必须链接到遵循 LGPL 的 FOO 库。
• 我的软件进行系统调用（使用我建立的命令行）来运行 BAR 程序，该程序遵循 GPL，“具有允许与 QUUX 链接的特殊例外”。

6.33 可以在依据与 GPL 不兼容的许可证进行许可的文档中使用遵循 GPL 的源代码片段吗？

如果片段足够小，依据“合理使用”或类似的法律，您可以将它们纳入其中，那么可以。否则，不可以。

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

在一个炎热的下午我代表 Linux 中国开源社区参加了 6 月 28 日的红帽媒体开放日。以下内容摘录自该活动，有删节。

本次参加红帽开放日的主要官方人员如题图，从左到右分别是：

• Fedora 社区工程师 Adam Samalik
• 红帽资深高级云技术官 Thomas Cameron
• ManageIQ 社区负责人 Carol Chen
• 社区活动经理 Jennifer Madriaga
• Fedora 社区负责人 Brian Exelbierd
• CoreOS 及 Prometheus 社区软件工程师 Max Leonard Inden

以下是问题摘录：

问题 1

记者：我想问各位社区成员一个问题，大家本身是社区的负责人或者工程师，同时又有红帽的背景，你们怎么把技术能量转换成价值贡献给社区，又怎么将社区开源的服务能力转化给红帽？

Thomas Cameron：这个问题非常好，其实对我们来说这并不是两边。我们想的首先是这个技术先提供给社区，然后社区进一步的开发完善，最后成为供企业可以使用的技术或者软件，开源是红帽的 DNA，对我们来说最重要的一件事是使这些软件取得成功，因此在我们的工作是就某个软件进行研究，或者推动在某个软件上增加什么新的功能的时候，或者要求红帽提供更多的资源。我们想的目的都是一样的，就是先把技术放进社区，然后在这个基础上进一步的开发创新，最终拿出来供企业使用。

问题 2

记者：比较一下十年前的开源社区跟今天的开源社区的用户差别，十年前的开源社区是极客在参与这个项目，现在再去社区里看一下，有一些用户级的，他可能遇到使用上的麻烦，可能到社区找一些答案，我们这个产品可能在场景应用当中遇到一些特殊的问题和麻烦，这个时候能不能向这些应用者，向被迫进入社区的人介绍一下咱们的沟通机制和反馈机制是怎么样的？另外一个我看到咱们这个众筹项目正在进行中，不同的项目的沟通机制是什么样的，能不能给用户一个介绍？

Brian Exelbierd：这个问题，涉及到沟通的机制，对任何一个项目来说沟通发生在多个不同的层次上，以 Fedora 社区为例，我们的这些核心贡献者、开发建造软件并且把它们提供出来的开发者，他们在 IRC 里进行沟通交流，但是大量的用户沟通的地点在自己感兴趣的场景或者内容不同发生在不同的地点，有些特别专注于游戏或者某个特定场景，他们都有论坛和交流地点，我们也会提醒我们的人要去不同的地点才能了解到更多用户的反馈意见。

下个问题也是令人兴奋的问题，因为 Fedora 的发布会涉及到很多不同的技术，从最开始社区发展起来的时候，我们就在不同的技术小组间建立了很强的反馈和交流机制，我们在进行测试的时候也会对所有的要素进行测试，比如我们会和 CentOS、OpenCI 这样的项目进行联系看看在哪些点上可以实现很好的集成，在哪些点上可能存在问题，这也是不同项目组之间进行沟通的方式。

Max Leonard Inden：我也想补充一个观点，我们每个项目的沟通方式都是不一样的，但是各个项目之间仍然存在着非常密切的沟通，而且我们大家的态度是一样的：所有的沟通都是受欢迎的，没有人会因为在不合适的地点问了问题而受到责难，我们会欢迎你充分的参与进来，提出问题，这是非常重要的一点。

红帽技术人员：再补充一点，关于您提到的现在的普通用户参与社区比十年前多多了，今天的科技更复杂，解决方案也更复杂，我们上游社区的项目同样更复杂，用户也在试图参与进来，第二，对于开发者而言，他使用的最主要的沟通方式是代码和编码，因为代码是他们的共同语言，虽然有人发布了代码，那么就有人从代码的角度看一看应该怎么对他检查，漏洞怎么进行修改，所以代码对于全世界的开发者来说都是同样的语言。

问题 3

记者：红帽愿意帮助我们设立站点下载 ISO 和文件么？当我在用一个红帽的帐户登录网站的时候，我去下载镜像，点按纽会发现有一个衔接，由于我们国家到美国的网速非常慢，整个镜像下载不下来，我们的工作没法进展，我们的解决方案是租一个美国的 VPS，从 VPS 再下载到本地还是会超时，第二个解决方案是再租一个香港 VPS，把这个从美国的拉到香港 VPS，再从香港拉到本地这个时候发现中间这一块又特别慢，想知道红帽有没有相对的解决方案？

Thomas Cameron：我非常理解您的这种沮丧的情绪，而且我们也感觉这样非常麻烦。但是特别坦率的说，这个问题的解决方案涉及到方方面面，它同时是法律问题，监管问题，涉及到条约等各种各样的问题，而我们在座的人没有一个人适合回答这样的问题，因为我们不是相关问题的专家，但是鉴于您有红帽的帐户，我建议您联系一个帐户经理，他会想办法帮您找解决方案，因为我们不想使您得到非常坏的体验，也不想麻烦您建立多个 VPS 的去解决，但是这个问题的最终解决还是需要律师法律团队和网络的工程团队，我们没办法回答，谢谢。

问题 4

记者：在 Fedora 社区有不同的区域划分，相互之间的差异化红帽是怎么解决的，在中国的本地化进程是怎样落地的，人员参与和贡献分别是多少？

Brian Exelbierd：我非得站起来回答您的第二个问题不可，因为要给您看一下我穿的体恤，这个体恤是 Fedora 本地化的主题，这是我们第 26 次发布 Fedora 版本的时候做的，主要目的是为了感谢全世界各地为 Fedora 本地化做出贡献的人们，因为确实有很多人都参与进来了，里面有一个泡泡写的是汉语。

我现在回答您问题的第一部分，您讲的非常对，我们 Fedora 是分区域的这个主要是有两个原因，首先是过去为了行政管理的便利做出的安排，因为这样分成不同的区域之后就可以更为容易的，相当于在本地做决定，而且资金的流动也更便利一些，随着全球化的发展，这个重要性降低了。还有第二个原因，您刚才提到差异化，差异性是无处不在的，我们希望在对话的时候，彼此的对话能在一个更适合的地方发生，因而在不同的国家和社区进行对话时所产生的决议有效，毕竟不同区域在文化上是有敏感性的。

回答您的第二个问题，您问到中国有多少贡献者，和他们在在这个社区中多活跃，对这样的问题，我们的回答永远是不够多，因为我们希望任何地方的贡献者都能够更多一些，希望他们更活跃的参与社区的活动。在中国我们也面临这样的挑战，因为中国的这些软件工程师或者相关可能的爱好者，他们本身的工作时间是非常长的，会加很长的班，通勤时间也非常长。这样他们就没有太多的精力投入开源社区的活动，此外中国社会不太重视让学生参与开源活动，大部分学生更专注于把考分弄的更高一点。我们在中国一直希望寻找对开源感兴趣的人，鼓励他们参与进来。不管你面临什么样的用户和场景，我们希望都是有人能够和你进行交流提供帮助的，所以我们非常鼓励大家的参与。

再补充一点，我们的开源社区是非常具有全球性的社区，因此绝不会在中国天然的有哪些情况就使得中国人为社区做贡献特别难，不会有这些情况，比如我本人经常在晚上九点和社区的成员进行交流，因为这个对大部分社区成员来说是最合适的时间。对不少中国人来讲，中国的时区和美国时区差异特别大，但是这一点不会阻止开源社区的交流。

问题 5

记者：我想问一个跟开源和闭源有关的问题，从软件开发的角度来讲，开源比闭源好，因为闭源一年更新的速度比较慢，而开源的广泛性和活跃性远远大于闭源，但是从商业角度来讲，开源还是不太成功的，以红帽为例，现在红帽每年的营收跟微软和闭源的软件厂商来讲远远不在一个级别上，从商业的角度讲，开源不那么成熟，作为开源社区的大拿来讲，吸引你们进入开源的热情是你们对技术的偏好，还是你们坚信开源技术未来在商业上有很大的潜质，什么支撑你们在开源领域里努力？

Thomas Cameron：在商业上我们已经比那些闭源的软件厂商要成功了。如果仔细的看一下红帽的财报跟他每年的增长，我们每年平均增长都在 20% 以上，所以从增速的角度来看，我们比所有的闭源软件开发公司做的都要好，所以从商业模式上已经证明了开源可以做的很好。关于为什么我个人会在开源中，这个回答非常简单，因为在这个世界上没有任何其他一个我所知道的行业能够让一个国家、或者一个村子里的人看到代码，并且利用手上的电脑开展相关的工作，没有任何一个其他的行业像开源社区一样把自己知道的一切都告诉别人，而在这个过程中我还拿到一份薪酬，当然我不能代表别人说话，我自己而言我觉得我是全世界最幸运的人，一方面我能够每天都在玩这些最酷的技术，同时还把我所知道的一切告诉任何感兴趣想学习的人，在这个过程中还能拿到工资。

给大家看一下大臂上的刺青，我觉得几乎没有那个闭源公司的员工会把自己公司的logo刻到自己的身上，但是我这样做了。大概五年前，闭源和开源软件公司之间的冲突还是非常显著的，但是今天我们可以看到所有的闭源软件公司都在采用开源的方法，他们也在发布大量的开源的代码，也就是说他们都看到了开源的模式，协作，为他人提供服务，以及做一切人人们生活变的更好的事情，这个模式是被大家认可的，这个时代是非常不可思议的，著名厂商包括IBM，微软，甲骨文等等，他们都在做开源的事情。

Jennifer Madriaga：我也补充一下，强调一下我们开源的核心是协作，在开源的社区里面，你会发现很多竞争对手同时也是合作的伙伴，我们和 IBM 是很好的伙伴，和微软是很好的伙伴，是 AWS、谷歌都是非常好的伙伴。重要的是没有他们的参与，没有我们的参与，这个行业就不可能取得这么大的成功。我经常到各个社区去，在这个过程中会和其他的组织进行交流，其中不少会被媒体描述为我们的竞争对手。我们也不仅仅和这些公司打交道，我们还和很多大学，非盈利机构进行沟通，这个社区是多样的，而且有大量的互动。开源社区伟大的一点是他特别促进创新，有这样的一个机构，CERN，欧洲原子能组织，他们的每一个软件都是开源的，他们在用 CoreOS、Fedora、Ceph 等，还有 NASA，也使用了大量的开源软件，其实他们是最早发明了 OpenStack，之后在社区得以进一步开发。行业的未来是开源，很多公司为什么用开源，因为他们知道只有用了开源才能保持自己的敏捷性，而且他们也知道自己是没有办法预测未来的，但是如果他们不与时俱进，那么这个公司可能将来就死路一条。

Adam Samalik：假如你是一个喜欢编代码的人，或者公司让程序员编写代码，如果你在社区里发布过你的代码，并且让其他人为这个代码做出贡献，你立刻会意识到开源的重要性或者价值。拿 Kubernetes 举个例子，它最早是谷歌拿出来的，一开始非常简单，但是大家都看到它的前景，现在有好多公司在为 Kubernetes 做出贡献，Kubernetes 本身也变的更为庞大，而且是非常棒的，但是在开源社区会发生这些事情，你把代码拿出来不是损失了自己的代码，有更多人会对你帮助，会有更多的贡献。

Carol Chen：谈到关系，在去年我们与阿里巴巴建立了伙伴关系，我希望并且认为肯定有更多的中国本地的伙伴关系发展起来。其实看一看 LC3 大会就知道了，有那么多大大小小的本地公司他们都在做开源，而且非常愿意分享自己用开源的经验，所以我想在这方面我们可以真实的看到这个趋势。关于个人的动机，我非常喜欢技术，我喜欢和别人分享东西，我也喜欢给别人参与这些非常酷的项目的机会，我也希望生活能够过的好，而参与开源给了我这一切。

某男：我补充一句关于创新和开源的关系，我们的 CEO 发布了一本新书《开放式创新》，现在我们看到在当今世界上人们面临的问题越来越复杂，对于这些复杂的问题一个公司单独没有办法解决，我们需要很多公司很多人合作，所以开源的平台会是非常重要的，这么多人和企业都可以一起寻找解决方案，所以开源在将来肯定会非常重要的推动创新。

Brian Exelbierd：我要讲的故事跟他们都不一样，我不知道一开始加入开源社区的动机是不是像我的同事那么纯净。 我就记得当时在大学里的朋友来找我，他当时拿着最初的 Linux 的某个版本，我们当时用软盘的复制工具复制了 64 个软盘，当时是希望能用这个东西让我非常糟糕的电脑转的更快一点。

当时我这个同学就说，欧洲有这么一个人在干这个事情，你知道我们都是美国人，住在美国也不太关心，不知道他在欧洲哪儿，但是现在我住在欧洲，知道那些地方在哪儿。当时有一个特别自私的想法，就是想让我的电脑快一点，我也做出了我的第一个贡献，因为我想让这个程序运行得有点差别，想改一下。所以最初这个动机帮助我逐步进入开源社区，当时我还是一个大学生，所以写的代码不太好，当时有代码的审阅人员，他们会看代码给你各种建议帮助你改进，这样逐步的参与动机，自私程度降低了，而更多的希望我能够也做出点贡献，也给其他人提供一些帮助。我们最早的时候有 GRP 系统，厂商根本不问我们用的怎么样，但是在开源社区情况完全不一样，我们跟企业用户沟通，他们会直接说出这个软件存在什么问题，并且他会告诉你我们应该怎么改进。

Max Leonard Inden：我为什么我参加了开源社区，我的同事们讲的非常好，从我的角度来讲是开源让我能够到这儿，让我在大会上发言，并且公开谈论我自己感兴趣的东西，而且能听别人谈。

听了大家的提问和回答，本人有如下感受：

• 开源在中国需要更多的非程序员的贡献者，来在艺术、营销、文档三个方面做出更多的贡献。
• 文化始终是大于代码的（Culture is bigger than code）。
• 开源本身是跨越了国界、地域、文化，让我们把资源更高效的利用起来让人们的生活更美好（OpenSource making people's life better）。

两个开发团队的一天

几个月以前，我与一些人讨论过关于公共云服务成本与传统专用基础设施价格比较的话题。为给你提供一些见解，我们来跟踪一下一个企业中的两个开发团队  —  并比较他们构建类似服务的方式。

第一个团队将使用传统的专用基础设施来部署他们的应用，而第二个团队将使用 AWS 提供的公共云服务。

这两个团队被要求为一家全球化企业开发一个新的服务，该企业目前为全球数百万消费者提供服务。要开发的这项新服务需要满足以下基本需求：

1. 能够随时扩展以满足弹性需求
2. 具备应对数据中心故障的弹性
3. 确保数据安全以及数据受到保护
4. 为排错提供深入的调试功能
5. 项目必须能迅速分发
6. 服务构建和维护的性价比要高

就新服务来说，这看起来是非常标准的需求 — 从本质上看传统专用基础设备上没有什么东西可以超越公共云了。

1 — 扩展以满足客户需求

当说到可扩展性时，这个新服务需要去满足客户变化无常的需求。我们构建的服务不可以拒绝任何请求，以防让公司遭受损失或者声誉受到影响。

传统团队

使用的是专用基础设施，架构体系的计算能力需要与峰值数据需求相匹配。对于负载变化无常的服务来说，大量昂贵的计算能力在低利用率时被浪费掉。

这是一种很浪费的方法  —  并且大量的资本支出会侵蚀掉你的利润。另外，这些未充分利用的庞大的服务器资源的维护也是一项很大的运营成本。这是一项你无法忽略的成本  —  我不得不再强调一下，为支持一个单一服务去维护一机柜的服务器是多么的浪费时间和金钱。

云团队

使用的是基于云的自动伸缩解决方案，应用会按需要进行自动扩展和收缩。也就是说你只需要支付你所消费的计算资源的费用。

一个架构良好的基于云的应用可以实现无缝地伸缩 —  并且还是自动进行的。开发团队只需要定义好自动伸缩的资源组即可，即当你的应用 CPU 利用率达到某个高位、或者每秒有多大请求数时启动多少实例，并且你可以根据你的意愿去定制这些规则。

2 — 应对故障的弹性

当说到弹性时，将托管服务的基础设施放在同一个房间里并不是一个好的选择。如果你的应用托管在一个单一的数据中心  —  （不是如果）发生某些失败时（LCTT 译注：指坍塌、地震、洪灾等），你的所有的东西都被埋了。

传统团队

满足这种基本需求的标准解决方案是，为实现局部弹性建立至少两个服务器  —  在地理上冗余的数据中心之间实施秒级复制。

开发团队需要一个负载均衡解决方案，以便于在发生饱和或者故障等事件时将流量转向到另一个节点  —  并且还要确保镜像节点之间，整个栈是持续完全同步的。

云团队

在 AWS 全球 50 个地区中，他们都提供多个可用区。每个区域由多个容错数据中心组成  —  通过自动故障切换功能，AWS 可以将服务无缝地转移到该地区的其它区中。

在一个 CloudFormation 模板中定义你的基础设施即代码，确保你的基础设施在自动伸缩事件中跨区保持一致 — 而对于流量的流向管理，AWS 负载均衡服务仅需要做很少的配置即可。

3 — 安全和数据保护

安全是一个组织中任何一个系统的基本要求。我想你肯定不想成为那些不幸遭遇安全问题的公司之一的。

传统团队

为保证运行他们服务的基础服务器安全，他们不得不持续投入成本。这意味着将需要投资一个团队，以监视和识别安全威胁，并用来自不同数据源的跨多个供应商解决方案打上补丁。

云团队

使用公共云并不能免除来自安全方面的责任。云团队仍然需要提高警惕，但是并不需要去担心为底层基础设施打补丁的问题。AWS 将积极地对付各种零日漏洞 — 最近的一次是 Spectre 和 Meltdown。

利用来自 AWS 的身份管理和加密安全服务，可以让云团队专注于他们的应用 —  而不是无差别的安全管理。使用 CloudTrail 对 API 到 AWS 服务的调用做全面审计，可以实现透明地监视。

4 — 监视和日志

任何基础设施和部署为服务的应用都需要严密监视实时数据。团队应该有一个可以访问的仪表板，当超过指标阈值时仪表板会显示警报，并能够在排错时提供与事件相关的日志。

传统团队

对于传统基础设施，将不得不在跨不同供应商和“雪花状”的解决方案上配置监视和报告解决方案。配置这些“见鬼的”解决方案将花费你大量的时间和精力 —  并且能够正确地实现你的目的是相当困难的。

对于大多数部署在专用基础设施上的应用来说，为了搞清楚你的应用为什么崩溃，你可以通过搜索保存在你的服务器文件系统上的日志文件来找到答案。为此你的团队需要通过 SSH 进入服务器，导航到日志文件所在的目录，然后浪费大量的时间，通过 grep 在成百上千的日志文件中寻找。如果你在一个横跨 60 台服务器上部署的应用中这么做  —  我能负责任地告诉你，这是一个极差的解决方案。

云团队

利用原生的 AWS 服务，如 CloudWatch 和 CloudTrail，来做云应用程序的监视是非常容易。不需要很多的配置，开发团队就可以监视部署的服务上的各种指标  —  问题的排除过程也不再是个恶梦了。

对于传统的基础设施，团队需要构建自己的解决方案，配置他们的 REST API 或者服务去推送日志到一个聚合器。而得到这个“开箱即用”的解决方案将对生产力有极大的提升。

5 — 加速开发进程

现在的商业环境中，快速上市的能力越来越重要。由于实施的延误所失去的机会成本，可能成为影响最终利润的一个主要因素。

传统团队

对于大多数组织，他们需要在新项目所需要的硬件采购、配置和部署上花费很长的时间 — 并且由于预测能力差，提前获得的额外的性能将造成大量的浪费。

而且还有可能的是，传统的开发团队在无数的“筒仓”中穿梭以及在移交创建的服务上花费数月的时间。项目的每一步都会在数据库、系统、安全、以及网络管理方面需要一个独立工作。

云团队

而云团队开发新特性时，拥有大量的随时可投入生产系统的服务套件供你使用。这是开发者的天堂。每个 AWS 服务一般都有非常好的文档并且可以通过你选择的语言以编程的方式去访问。

使用新的云架构，例如无服务器，开发团队可以在最小化冲突的前提下构建和部署一个可扩展的解决方案。比如，只需要几天时间就可以建立一个 Imgur 的无服务器克隆，它具有图像识别的特性，内置一个产品级的监视/日志解决方案，并且它的弹性极好。

如何建立一个 Imgur 的无服务器克隆

如果必须要我亲自去设计弹性和可伸缩性，我可以向你保证，我会陷在这个项目的开发里 — 而且最终的产品将远不如目前的这个好。

从我实践的情况来看，使用无服务器架构的交付时间远小于在大多数公司中提供硬件所花费的时间。我只是简单地将一系列 AWS 服务与 Lambda 功能 — 以及 ta-da 耦合到一起而已！我只专注于开发解决方案，而无差别的可伸缩性和弹性是由 AWS 为我处理的。

关于云计算成本的结论

就弹性而言，云计算团队的按需扩展是当之无愧的赢家 — 因为他们仅为需要的计算能力埋单。而不需要为维护和底层的物理基础设施打补丁付出相应的资源。

云计算也为开发团队提供一个可使用多个可用区的弹性架构、为每个服务构建的安全特性、持续的日志和监视工具、随用随付的服务、以及低成本的加速分发实践。

大多数情况下，云计算的成本要远低于为你的应用运行所需要的购买、支持、维护和设计的按需基础架构的成本 —  并且云计算的麻烦事更少。

通过利用云计算，我们可以更少的先期投入而使业务快速开展。整体而言，当你开发和部署业务服务时，云计算的经济性可以让你的工作更赞。

也有一些云计算比传统基础设施更昂贵的例子，一些情况是在周末忘记关闭运行的一些极其昂贵的测试机器。

Dropbox 在决定推出自己的基础设施并减少对 AWS 服务的依赖之后，在两年的时间内节省近 7500 万美元的费用，Dropbox…——www.geekwire.com

即便如此，这样的案例仍然是非常少见的。更不用说当初 Dropbox 也是从 AWS 上开始它的业务的  —  并且当它的业务达到一个临界点时，才决定离开这个平台。即便到现在，他们也已经进入到云计算的领域了，并且还在 AWS 和 GCP 上保留了 40% 的基础设施。

将云服务与基于单一“成本”指标（LCTT 译注：此处的“成本”仅指物理基础设施的购置成本）的传统基础设施比较的想法是极其幼稚的  —  公然无视云为开发团队和你的业务带来的一些主要的优势。

在极少数的情况下，云服务比传统基础设施产生更多的绝对成本  —  但它在开发团队的生产力、速度和创新方面仍然贡献着更好的价值。

客户才不在乎你的数据中心呢

我非常乐意倾听你在云中开发的真实成本相关的经验和反馈！请在下面的评论区、Twitter @Elliot\_F 上、或者直接在 LinkedIn 上联系我。

via: https://read.acloud.guru/the-true-cost-of-cloud-a-comparison-of-two-development-teams-edc77d3dc6dc

作者：Elliot Forbes 译者：qhwdw 校对：wxy

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

这是许多事情的第一步

有一个普遍的误解，那就是对开源做出贡献是一件很难的事。你可能会想，“有时我甚至不能理解我自己的代码；那我怎么可能理解别人的？”

放轻松。直到去年，我都以为是这样。阅读和理解他人的代码，然后在他们的基础上写上你自己的代码，这是一件令人气馁的任务；但如果有合适的资源，这不像你想象的那么糟。

第一步要做的是选择一个项目。这个决定是可能是一个菜鸟转变成一个老练的开源贡献者的关键一步。

许多对开源感兴趣的业余程序员都被建议从 Git 入手，但这并不是最好的开始方式。Git 是由许多有着多年软件开发经验的超级极客维护的。它是寻找可以做贡献的开源项目的好地方，但对新手并不友好。大多数对 Git 做出贡献的开发者都有足够的经验，他们不需要参考各类资源或文档。在这篇文章里，我将提供一个对新手友好的特性的列表，并且给出一些建议，希望可以使你更轻松地对开源做出贡献。

理解产品

在开始贡献之前，你需要理解项目是怎么工作的。为了理解这一点，你需要自己来尝试。如果你发现这个产品很有趣并且有用，它就值得你来做贡献。

初学者常常选择参与贡献那些他们没有使用过的软件。他们会失望，并且最终放弃贡献。如果你没有用过这个软件，你不会理解它是怎么工作的。如果你不理解它是怎么工作的，你怎么能解决 bug 或添加新特性呢？

要记住：尝试它，才能改变它。

确认产品的状况

这个项目有多活跃？

如果你向一个暂停维护的项目提交一个 拉取请求 pull request ，你的请求可能永远不会被讨论或合并。找找那些活跃的项目，这样你的代码可以得到即时的反馈，你的贡献也就不会被浪费。

这里介绍了怎么确认一个项目是否还是活跃的：

• 贡献者数量： 一个增加的贡献者数量表明开发者社区乐于接受新的贡献者。
• 提交 commit 频率： 查看最近的提交时间。如果是一周之内，甚至是一两个月内，这个项目应该是定期维护的。
• 维护者数量： 维护者的数量越多，你越可能得到指导。
• 聊天室或 IRC 活跃度： 一个繁忙的聊天室意味着你的问题可以更快得到回复。

新手资源

Coala 是一个开源项目的例子。它有自己的教程和文档，让你可以使用它（每一个类和方法）的 API。这个网站还设计了一个有吸引力的界面，让你有阅读的兴趣。

文档： 不管哪种水平的开发者都需要可靠的、被很好地维护的文档，来理解项目的细节。找找在 GitHub（或者放在其它位置）或者类似于 Read the Docs 之类的独立站点上提供了完善文档的项目，这样可以帮助你深入了解代码。

教程： 教程会给新手解释如何在项目里添加特性 （然而，你不是在每个项目中都能找到它）。例如，Coala 提供了 小熊编写指南 （进行代码分析的 代码格式化 linting 工具的 Python 包装器）。

分类的 讨论点 issue ： 对刚刚想明白如何选择第一个项目的初学者来说，选择一个讨论点是一个更加困难的任务。标签被设为“难度/低”、“难度/新手”、“利于初学者”，以及“ 触手可及 low-hanging fruit ”都表明是对新手友好的。

其他因素

• 维护者对新的贡献者的态度： 从我的经验来看，大部分开源贡献者都很乐于帮助他们项目里的新手。然而，当你问问题时，你也有可能遇到一些不太友好的人（甚至可能有点粗鲁）。不要因为这些人失去信心。他们只是因为在比他们经验更丰富的人那儿得不到发泄的机会而已。还有很多其他人愿意提供帮助。
• 审阅过程/机制： 你的拉取请求将经历几遍你的同伴和有经验的开发者的查看和更改——这就是你学习软件开发最主要的方式。一个具有严格审阅过程的项目使您在编写生产级代码的过程中成长。
• 一个稳健的 持续集成 continuous integration 管道： 开源项目会向新手们介绍持续集成和部署服务。一个稳健的 CI 管道将帮助你学习阅读和理解 CI 日志。它也将带给你处理失败的测试用例和代码覆盖率问题的经验。
• 参加编程项目（例如 Google Summer Of Code）： 参加组织证明了你乐于对一个项目的长期发展做贡献。他们也会给新手提供一个机会来获得现实世界中的开发经验，从而获得报酬。大多数参加这些项目的组织都欢迎新人加入。

7 对新手友好的组织

• coala (Python)
• oppia (Python, Django)
• DuckDuckGo (Perl, JavaScript)
• OpenGenus (JavaScript)
• Kinto (Python, JavaScript)
• FOSSASIA (Python, JavaScript)
• Kubernetes (Go)

关于作者

Palash Nigam - 我是一个印度计算机科学专业本科生，十分乐于参与开源软件的开发，我在 GitHub 上花费了大部分的时间。我现在的兴趣包括 web 后端开发，区块链，和 All things python。

via: https://opensource.com/article/18/4/get-started-open-source-project

作者：Palash Nigam 译者：lonaparte 校对：wxy

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