让我们来看看几个任何人都能用的自由开源的 AI 工具。

在开源领域，不管你的想法是多少的新颖独到，先去看一下别人是否已经做成了这个概念，总是一个很明智的做法。对于有兴趣借助不断成长的 人工智能 Artificial Intelligence （AI）的力量的组织和个人来说，许多优秀的工具不仅是自由开源的，而且在很多的情况下，它们都已经过测试和久经考验的。

在领先的公司和非盈利组织中，AI 的优先级都非常高，并且这些公司和组织都开源了很有价值的工具。下面的举例是任何人都可以使用的自由开源的 AI 工具。

Acumos

Acumos AI 是一个平台和开源框架，使用它可以很容易地去构建、共享和分发 AI 应用。它规范了运行一个“开箱即用的”通用 AI 环境所需要的 基础设施栈 infrastructure stack 和组件。这使得数据科学家和模型训练者可以专注于它们的核心竞争力，而不用在无止境的定制、建模，以及训练一个 AI 实现上浪费时间。

Acumos 是 LF 深度学习基金会 的一部分，它是 Linux 基金会中的一个组织，它支持在人工智能、 机器学习 machine learning 、以及 深度学习 deep learning 方面的开源创新。它的目标是让这些重大的新技术可用于开发者和数据科学家，包括那些在深度学习和 AI 上经验有限的人。LF 深度学习基金会 最近批准了一个项目生命周期和贡献流程，并且它现在正接受项目贡献的建议。

Facebook 的框架

Facebook 开源了 其中心机器学习系统，它设计用于做一些大规模的人工智能任务，以及一系列其它的 AI 技术。这个工具是经过他们公司验证使用的平台的一部分。Facebook 也开源了一个叫 Caffe2 的深度学习和人工智能的框架。

CaffeOnSpark

说到 Caffe。 Yahoo 也在开源许可证下发布了它自己的关键的 AI 软件。CaffeOnSpark 工具 是基于深度学习的，它是人工智能的一个分支，在帮助机器识别人类语言，或者照片、视频的内容方面非常有用。同样地，IBM 的机器学习程序 SystemML 可以通过 Apache 软件基金会自由地共享和修改。

Google 的工具

Google 花费了几年的时间开发了它自己的 TensorFlow 软件框架，用于去支持它的 AI 软件和其它预测和分析程序。TensorFlow 是你可能都已经在使用的一些 Google 工具背后的引擎，包括 Google Photos 和在 Google app 中使用的语言识别。

Google 开源了两个 AIY 套件，它可以让个人很容易地使用人工智能，它们专注于计算机视觉和语音助理。这两个套件将用到的所有组件封装到一个盒子中。该套件目前在美国的 Target 中有售，并且它是基于开源的树莓派平台的 —— 有越来越多的证据表明，在开源和 AI 交集中将发生非常多的事情。

H2O.ai

我 以前介绍过 H2O.ai，它在机器学习和人工智能领域中占有一席之地，因为它的主要工具是自由开源的。你可以获取主要的 H2O 平台和 Sparkling Water，它与 Apache Spark 一起工作，只需要去 下载 它们即可。这些工具遵循 Apache 2.0 许可证，它是一个非常灵活的开源许可证，你甚至可以在 Amazon Web 服务（AWS）和其它的集群上运行它们，而这仅需要几百美元而已。

Microsoft 入局

“我们的目标是让 AI 大众化，让每个人和组织获得更大的成就，“ Microsoft CEO 萨提亚·纳德拉 说。因此，微软持续迭代它的 Microsoft Cognitive Toolkit（CNTK）。它是一个能够与 TensorFlow 和 Caffe 去竞争的一个开源软件框架。Cognitive Toolkit 可以工作在 64 位的 Windows 和 Linux 平台上。

Cognitive Toolkit 团队的报告称，“Cognitive Toolkit 通过允许用户去创建、训练，以及评估他们自己的神经网络，以使企业级的、生产系统级的 AI 成为可能，这些神经网络可能跨多个 GPU 以及多个机器在大量的数据集中高效伸缩。”

从来自 Linux 基金会的新电子书中学习更多的有关 AI 知识。Ibrahim Haddad 的 开源 AI：项目、洞察和趋势 调查了 16 个流行的开源 AI 项目—— 深入研究了他们的历史、代码库、以及 GitHub 的贡献。 现在可以免费下载这个电子书。

via: https://www.linux.com/blog/2018/6/6-open-source-ai-tools-know

作者：Sam Dean 选题：lujun9972 译者：qhwdw 校对：pityonline, wxy

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

Pipenv 的目标是将打包界（bundler、composer、npm、cargo、yarn 等）最好的东西带到 Python 世界来。它试图解决一些问题，并简化整个管理过程。

目前，Python 程序依赖项的管理有时似乎是一个挑战。开发人员通常为每个新项目创建一个虚拟环境，并使用 pip 将依赖项安装到其中。此外，他们必须将已安装的软件包的集合保存到 requirements.txt 文件中。我们看到过许多旨在自动化此工作流程的工具和包装程序。但是，仍然需要结合多个程序，并且 requirements.txt 格式本身并不适用于更复杂的场景。

一个统治它们的工具

Pipenv 可以正确地管理复杂的相互依赖关系，它还提供已安装包的手动记录。例如，开发、测试和生产环境通常需要一组不同的包。过去，每个项目需要维护多个 requirements.txt。Pipenv 使用 TOML 语法引入了新的 Pipfile 格式。多亏这种格式，你终于可以在单个文件中维护不同环境的多组需求。

在将第一行代码提交到项目中仅一年后，Pipenv 已成为管理 Python 程序依赖关系的官方推荐工具。现在它终于在 Fedora 仓库中提供。

在 Fedora 上安装 Pipenv

在全新安装 Fedora 28 及更高版本后，你只需在终端上运行此命令即可安装 Pipenv：

$ sudo dnf install pipenv

现在，你的系统已准备好在 Pipenv 的帮助下开始使用新的 Python 3 程序。

重要的是，虽然这个工具为程序提供了很好的解决方案，但它并不是为处理库需求而设计的。编写 Python 库时，不需要固定依赖项。你应该在 setup.py 文件中指定 install_requires。

基本依赖管理

首先为项目创建一个目录：

$ mkdir new-project && cd new-project

接下来是为此项目创建虚拟环境：

$ pipenv --three

这里的 -three 选项将虚拟环境的 Python 版本设置为 Python 3。

安装依赖项：

$ pipenv install requests
Installing requests…
Adding requests to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…

最后生成 lockfile：

$ pipenv lock
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (b14837)

你还可以检查依赖关系图：

$ pipenv graph
- certifi [required: >=2017.4.17, installed: 2018.4.16]
- chardet [required: <3.1.0,>=3.0.2, installed: 3.0.4]
- idna [required: <2.8,>=2.5, installed: 2.7]
- urllib3 [required: >=1.21.1,<1.24, installed: 1.23]

有关 Pipenv 及其命令的更多详细信息，请参见文档。

via: https://fedoramagazine.org/install-pipenv-fedora/

作者：Michal Cyprian 选题：lujun9972 译者：geekpi 校对：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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

这段时间以来，以太坊通证很流行。这些通证可以用来代表现实世界的各种价值单位：黄金、 谎言、 猫咪 甚至是类似 公司股票 一样的东西。迄今为止，人们已经募集了 20 亿美元的通证。那些通证是以 ERC20 为标准的，人们可以轻松地在钱包之间进行交易。在这篇教程中，我准备指导你部署你自己的 ERC20 通证到真实的以太坊网络上去。

事先准备：

• 一个文本编辑器（Atom 不错，不过我喜欢 Vim）
• 对命令行和终端（模拟器）有起码的了解。Mac 内置的应用“终端”就很好，不过我喜欢 iTerm2
• Chrome 浏览器
• Node.js 8（或更高版本）
• 你的通证的名字。我的准备叫做 HamburgerCoin（汉堡币）

你需要做的第一件事是安装 MetaMask。访问 Metamask 网站 并点击“Get Chrome Extention”。

Metamask 可以让你通过 Chrome 在以太坊上进行交易。它依靠运行着公开以太坊节点的 Infura ，所以你不用自己运行以太坊全节点。如果你颇具探索精神，你也可以下载和安装 Mist 以替代它。运行 Mist 就可以让你运行你自己的以太坊节点。运行自己的节点你就需要将你的计算机与该网络进行同步，这需要不短的时间。从技术上讲这更安全，因为这样你不必信任 Infura 来处理你的交易。Infura 可以忽略你的交易而干预你，但是它并不能偷走你的钱。因为安装 Metamask 比 Mist 更快也更简单，所以我假设你在下面的教程中使用 Metamask。

接着你需要安装 truffle：

 $ npm install -g truffle

现在为你自己的新通证创建一个新目录，cd 到其中并初始化你的 truffle 项目。

$ mkdir hamburger-coin
$ cd hamburger-coin
$ truffle init

很好，你的 truffle 项目已经设置好了！

现在来创建我们的通证。首先我们需要安装 OpenZepplin 框架。OpenZepplin 框架包括了大量预先构建好的合约，包括我们要部署的 ERC20 通证合约。

（只需要按下回车接受默认值即可）

$ npm init
package name: (hamburger-coin)
version: (1.0.0)
description:
entry point: (truffle.js)
test command:
git repository:
keywords:
author:
license: (ISC)
About to write to /Users/masonf/src/hamburger-coin/package.json:

{
  "name": "hamburger-coin",
  "version": "1.0.0",
  "description": "",
  "main": "truffle.js",
  "directories": {
    "test": "test"
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}


Is this ok? (yes) yes
$ npm install zeppelin-solidity

现在我们可以创建我们的通证合约了。创建一个 contracts/HamburgerCoin.sol 文件并加入如下内容：

pragma solidity ^0.4.18;
import "zeppelin-solidity/contracts/token/StandardToken.sol";

contract HamburgerCoin is StandardToken {
  string public name = "HamburgerCoin"; 
  string public symbol = "HBC";
  uint public decimals = 2;
  uint public INITIAL_SUPPLY = 10000 * (10 ** decimals);

  function HamburgerCoin() public {
    totalSupply_ = INITIAL_SUPPLY;
    balances[msg.sender] = INITIAL_SUPPLY;
  }
}

（LCTT 译注：上述合约内容中指定了合约的名称、符号和供应量。在 ERC20 当中，通证的供应量其实是整数，上述合约中通证的实际供应量是 10000 * 100 个，出于显示 2 位小数的需求，你在合约浏览器、钱包软件中看到和操作的 1 个通证，实际上在交易中是以 100 个进行的。）

OpenZepplin 的 StandardToken 是一个标准的 ERC20 通证。如果你感兴趣，你可以看看它的 源代码 以了解是如何工作的。

实际上并不太复杂。该合约有一个 地址到余额 的映射（LCTT 译注：你可以理解为哈希、关联数组），它也有一个 允许转账 的列表。你可以看做是支票。你可以写张支票，但是直到它被兑付前，钱并不会被转账。

如果有人要转走一些资金，你可以在合约上调用 approve 方法，设置你要发送的通证数量。这就像是写支票一样。

然后调用 transferFrom 会实际进行转账。

我们可以从头写这些合约，但是最好采用经过完备的社区测试的合约。从头写一个 ERC20 通证那就是另外一篇文章了。

试着运行 compile 来编译我们的合约：

$ truffle compile
Compiling ./contracts/HamburgerCoin.sol...
Compiling zeppelin-solidity/contracts/math/SafeMath.sol...
Compiling zeppelin-solidity/contracts/ownership/Ownable.sol...
Compiling zeppelin-solidity/contracts/token/BasicToken.sol...
Compiling zeppelin-solidity/contracts/token/ERC20.sol...
Compiling zeppelin-solidity/contracts/token/ERC20Basic.sol...
Compiling zeppelin-solidity/contracts/token/MintableToken.sol...
Compiling zeppelin-solidity/contracts/token/StandardToken.sol...
Writing artifacts to ./build/contracts Next you'll need to add a migration file which will tell truffle how to deploy your contract.

接下来我们需要增加一个 truffle 迁移。

创建 migrations/2_deploy_hamburgercoin.js 文件并添加如下内容：

var HamburgerCoin = artifacts.require("./HamburgerCoin.sol");

module.exports = function(deployer) {
  deployer.deploy(HamburgerCoin);
};

现在让我们配置 truffle 以能够使用 Infura 公共节点。如果我们要部署到公共节点，那就需要钱包的私钥。我们可以将该私钥包含在我们的源代码当中，但是如果任何人可以访问你的源代码（和版本库），他就能够偷走我们所有的汉堡币！要避免这种情况，我们会使用 dotenv node.js 模块。（LCTT 译注：dotenv 用于存储机密信息的文件 .env 是以 “.” 开头的，默认不会进入版本库，当然，如果有人能查看你全部的项目文件，你的私钥还是会被泄露。）

让我们安装部署到 Infura 所需的所有模块。

npm install --save-dev dotenv truffle-wallet-provider ethereumjs-wallet

（LCTT 译注：可能安装过程中会有很多警告，大多应该是属于定义了未使用的变量和方法的编译警告，可以忽略。）

现在编辑 truffle.js 并（原样）加入如下内容：

require('dotenv').config();
const Web3 = require("web3");
const web3 = new Web3();
const WalletProvider = require("truffle-wallet-provider");
const Wallet = require('ethereumjs-wallet');

var mainNetPrivateKey = Buffer.from(process.env["MAINNET_PRIVATE_KEY"], "hex")
var mainNetWallet = Wallet.fromPrivateKey(mainNetPrivateKey);
var mainNetProvider = new WalletProvider(mainNetWallet, "https://mainnet.infura.io/");

var ropstenPrivateKey = Buffer.from(process.env["ROPSTEN_PRIVATE_KEY"], "hex")
var ropstenWallet = Wallet.fromPrivateKey(ropstenPrivateKey);
var ropstenProvider = new WalletProvider(ropstenWallet, "https://ropsten.infura.io/");


module.exports = {
  networks: {
    development: {
      host: "localhost",
      port: 8545,
      network_id: "*" // Match any network id
    },
    ropsten: {
      provider: ropstenProvider,
      // You can get the current gasLimit by running
      // truffle deploy --network rinkeby
      // truffle(rinkeby)> web3.eth.getBlock("pending", (error, result) =>
      //   console.log(result.gasLimit))
      gas: 4600000,
      gasPrice: web3.toWei("20", "gwei"),
      network_id: "3",
    },
    mainnet: {
      provider: mainNetProvider,
      gas: 4600000,
      gasPrice: web3.toWei("20", "gwei"),
      network_id: "1",
    }
  }
};

（LCTT 译注：原文采用 new Buffer 来获取私钥设置，但 node.js 升级后，废弃了 new Buffer 这种用法，运行时会发出警告，所以上面我修改为使用 Buffer.from 。）

接下来我们从 Metamask 中得到我们的私钥：

1. 点击你的 Chrome 窗口右上角的狐狸图标。
2. 点击 “Account 1” 右侧的省略号。
3. 点击 “Export Private Key”。
4. 输入你的密码。
5. 点击该文字以复制私钥到剪贴板。

然后打开 .env文件，并像下面这样贴入你的私钥（对于 Ropsten 测试网和 Mainnet 主网，你的私钥是一样的）：

ROPSTEN_PRIVATE_KEY="123YourPrivateKeyHere"
MAINNET_PRIVATE_KEY="123YourPrivateKeyHere"

接下来，让我们部署到 Ropsten 以太坊测试网。

以太坊测试网是一个你可以测试合约的地方。此外还有 Kovan 和 Rinkeby 测试网。我在这个教程中选择 Ropsten 是因为现在很容易得到 Ropsten 的测试 ETH。这些测试网都类似，你可以使用任何一个你喜欢的，但是在此教程当中我假设你在使用 Ropsten。访问 https://faucet.metamask.io/ 以得到一些测试 ETH。从 faucet 得到一些 ETH 后，你就可以部署了。

$ truffle deploy --network ropsten
Compiling ./contracts/HamburgerCoin.sol...
Compiling ./contracts/Migrations.sol...
Compiling zeppelin-solidity/contracts/math/SafeMath.sol...
Compiling zeppelin-solidity/contracts/token/BasicToken.sol...
Compiling zeppelin-solidity/contracts/token/ERC20.sol...
Compiling zeppelin-solidity/contracts/token/ERC20Basic.sol...
Compiling zeppelin-solidity/contracts/token/StandardToken.sol...
Writing artifacts to ./build/contracts

Using network 'ropsten'.

Running migration: 1_initial_migration.js
  Deploying Migrations...
  ... 0xc2bbe6bf5a7c7c7312c43d65de4c18c51c4d620d5bf51481ea530411dcebc499
  Migrations: 0xd827b6f93fcb50631edc4cf8e293159f0c056538
Saving successful migration to network...
  ... 0xe6f92402e6ca0b1d615a310751568219f66b9d78b80a37c6d92ca59af26cf475
Saving artifacts...
Running migration: 2_deploy_contracts.js
  Deploying HamburgerCoin...
  ... 0x02c4d47526772dc524851fc2180b338a6b037500ab298fa2f405f01abdee21c4
  HamburgerCoin: 0x973b1a5c753a2d5d3924dfb66028b975e7ccca51
Saving artifacts...

在 “Saving aritfacts” 上面的这行即是你的合约的新地址。

复制并黏贴该地址到 Ropsten Etherscan 搜索框，你就能看到你新部署的合约。

现在你可以在任何 ERC20 兼容的钱包，如 Mist 、MyEtherWallet（LCTT 译注：或 ImToken 这样的手机应用）里面使用你的通证了。

为了这篇教程，我构建了一个名为 Etherface 的钱包来做演示。

首先你需要添加你的通证到 Etherface：

1. 访问 http://etherface.io/ 。
2. 确认你在 Metamask 中选择了 “Ropsten” 网络。
3. 点击 “Tokens”。
4. 点击右上角的加号按钮。
5. 输入上面的合约地址。

如果你有朋友想要一些汉堡币，你现在就可以发送给他们了。如果没有，你也可以在你的两个账号间测试转账：

1. 在 Metamask 中点击 “切换账号”按钮（在右上角），并改变你的账号为 “Account 2”。
2. 点击 “Account 2” 右边的省略号，然后选择 “Copy Address to clipboard”。
3. 切换回 “Account 1”，这很重要！否则交易会失败。
4. 在 Etherface 中你的余额下点击 “Send”。
5. 黏贴 “Account 2” 的地址。
6. 输入你要发送的数量。
7. Metamask 会弹出确认窗口，点击 “Submit”。
8. 等大约 15-30 秒。
9. 你的 “Account 1” 的余额应该会减少，“Account 2” 现在会有了一些汉堡币！

最后，让我们来部署到主网（LCTT 译注：这会花费你真实的 ETH，你可以通过查看前面部署到 Ropsten 的合约信息中了解花费了多少 gas，以相应估计实际要花费多少 ETH）：

$ truffle deploy --network mainnet

你可以如前面一样加你的通证到 Etherface ，并发送你新打造的通证给你的朋友们了！

你是狂热的自由软件支持者吗？你目前在使用任何基于 Arch 的 Linux 发行版吗？我有一个小小的提示送给你！现在，你可以轻松地在 Arch Linux 及其变体（如 Antergos、Manjaro Linux 等）中找到已安装的专有软件包。你无需在已安装软件包的网站中参考其许可细节，也无需使用任何其它外部工具来查明软件包是自由的还是专有的。（LCTT 译注：其实下面还是借助了一个外部程序）

在 Arch Linux 中查找已安装的专有软件包

一位开发人员开发了一个名为 “Absolutely Proprietary” 的实用程序，它是一种用于基于 Arch 发行版的专有软件包检测器。它将基于 Arch 系统中的所有安装包与 Parabola 的软件包 blacklist 和 aur-blacklist 进行比较，然后显示出你的 斯托曼自由指数 Stallman Freedom Index （“自由/总计”比分）。此外，你可以将该列表保存到文件中，并与其他系统/用户共享或比较。

在安装之前，确保你安装了 Python 和 Git。

然后，git clone 仓库：

git clone https://github.com/vmavromatis/absolutely-proprietary.git

这条命令将会下载所有内容到你当前工作目录中的 absolutely-proprietary 目录。

进入此目录：

cd absolutely-proprietary

接着，使用以下命令查找已安装的专有软件：

python main.py

这条命令将会下载 blacklist.txt、aur-blacklist.txt，并将本地已安装的软件包与远程软件包进行比较并显示其指数。

以下是在我的 Arch Linux 桌面的示例输出：

Retrieving local packages (including AUR)...
Downloading https://git.parabola.nu/blacklist.git/plain/blacklist.txt
Downloading https://git.parabola.nu/blacklist.git/plain/aur-blacklist.txt
Comparing local packages to remote...
=============================================
47 ABSOLUTELY PROPRIETARY PACKAGES INSTALLED
=============================================

Your GNU/Linux is infected with 47 proprietary packages out of 1370 total installed.
Your Stallman Freedom Index is 96.57

+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| Name | Status | Libre Alternatives | Description |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| chromium-pepper-flash | nonfree | | proprietary Google Chrome EULA, missing sources |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| faac | nonfree | | [FIXME:description] is a GPL'ed package, but has non free code that can't be distributed und|
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| libunrar | nonfree | | part of nonfree unrar, Issue442 |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| opera | nonfree | | nonfree, nondistributable, built from binary installers, etc |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| shutter | nonfree | | need registered user to download (and access website) the source code and depends perl-net-d|
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| ttf-ms-fonts | nonfree | | |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| ttf-ubuntu-font-family | nonfree | | Ubuntu font license considered non-free by DFSG and Fedora |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| unace | nonfree | | license forbids making competing ACE archivers from unace |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| unrar | nonfree | unar | |
| | | fsf | |
| | | unrar | |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| virtualbox | nonfree | | contains BIOS which needs a nonfree compiler to build from source (OpenWatcom compiler), doe|
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+
| wordnet | nonfree | | |
+------------------------|---------|--------------------|---------------------------------------------------------------------------------------------+


Save list to file? (Y/n)

如你所见，我的系统中有 47 个专有软件包。就像我说的那样，我们可以将它保存到文件中稍后查看。为此，当提示你将列表保存在文件时，请按 y。然后按 y 接受默认值，或按 n 以你喜欢的格式和位置来保存它。

Save list to file? (Y/n) y
Save as markdown table? (Y/n) y
Save it to (/tmp/tmpkuky_082.md): y
The list is saved at /home/sk/absolutely-proprietary/y.md

You can review it from the command line
using the "less -S /home/sk/absolutely-proprietary/y.md"
or, if installed, the "most /home/sk/absolutely-proprietary/y.md" commands

你可能已经注意到，我只有 nonfree 包。它还会显示另外两种类型的软件包，例如 semifree、 uses-nonfree。

• nonfree：这个软件包是公然的非自由软件。
• semifree：这个软件包大部分是自由的，但包含一些非自由软件。
• uses-nonfree：这个软件包依赖、推荐或不恰当地与其他自由软件或服务集成。

该使用程序的另一个显著特点是它不仅显示了专有软件包，而且还显示这些包的替代品。

希望这有些帮助。我很快就会在这里提供另一份有用的指南。敬请关注！

干杯!

资源：

• Absolutely Proprietary

via: https://www.ostechnix.com/find-installed-proprietary-packages-arch-linux/

作者：SK 译者：MjSeven 校对：wxy

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

所有的 Linux 打包系统和工具都会让人迷惑，但是这篇面向初学者的教程可以帮助你搞明白。

如你所见，众所瞩目的 Linux 已经用在互联网，以及 Arduino、Beagle 和树莓派主板等设备上，或许你正在考虑是时候尝试一下 Linux 了。本系列将帮助你成功过渡到 Linux。如果你错过了本系列的早期文章，可以在这里找到它们：

• 第1部分 - 入门介绍
• 第2部分 - 磁盘、文件和文件系统
• 第3部分 - 图形操作环境
• 第4部分 - 命令行
• 第5部分 - 使用 sudo

安装软件

要在你的计算机上获得新软件，通常的方法是从供应商处获得软件产品，然后运行一个安装程序。过去，软件产品会出现在像 CD-ROM 或 DVD 一样的物理媒介上，而现在我们经常从互联网上下载软件产品。

使用 Linux，安装软件就像在你的智能手机上安装一样。如同你的手机应用商店一样，在 Linux 上有个提供开源软件工具和程序的 中央仓库 central repository ，几乎任何你想要的程序都会出现在可用软件包列表中以供你安装。

每个程序并不需要运行单独的安装程序，而是你可以使用 Linux 发行版附带的软件包管理工具。（这里说的 Linux 发行版就是你安装的 Linux，例如 Ubuntu、Fedora、Debian 等）每个发行版在互联网上都有它自己的集中存储库（称为仓库），它们存储了数千个预先构建好的应用程序。

你可能会注意到，在 Linux 上安装软件有几种例外情况。有时候，你仍然需要去供应商那里获取他们的软件，因为该程序不存在于你的发行版的中央仓库中。当软件不是开源和/或自由软件的时候，通常就是这种情况。

另外请记住，如果你想要安装一个不在发行版仓库中的程序时，事情就不是那么简单了，即使你正在安装自由及开源程序。这篇文章没有涉及到这些更复杂的情况，请遵循在线的指引。

有了所有的 Linux 包管理系统和工具，接下来干什么可能仍然令人困惑。本文应该有助于澄清一些事情。

包管理

目前在 Linux 发行版中有几个相互竞争的用于管理、安装和删除软件的包管理系统。每个发行版都选择使用了一个 包管理工具 package management tools 。Red Hat、Fedora、CentOS、Scientific Linux、SUSE 等使用 Red Hat 包管理（RPM）。Debian、Ubuntu、Linux Mint 等等都使用 Debian 包管理系统，简称 DPKG。还有一些其它包管理系统，但 RPM 和 DPKG 是最常见的。

图 1: Package installers

无论你使用的软件包管理是什么，它们通常都是一组构建于另外一种工具之上的工具（图 1）。最底层是一个命令行工具，它可以让你做任何与安装软件相关的一切工作。你可以列出已安装的程序、删除程序、安装软件包文件等等。

这个底层工具并不总是最方便使用的，所以通常会有一个命令行工具，它可以使用单个命令在发行版的中央仓库中找到软件包，并下载和安装它以及任何依赖项。最后，通常会有一个 图形应用程序 graphical application ，可以让你使用鼠标选择任何想要的内容，然后单击 “install” 按钮即可。

图 2: PackageKit

对于基于 Red Hat 的发行版，包括 Fedora、CentOS、Scientific Linux 等，它们的底层工具是 rpm，高级工具叫做 dnf（在旧系统上是 yum）。图形安装程序称为 PackageKit（图 2），它可能在系统管理菜单下显示名字为 “Add/Remove Software（添加/删除软件）”。

图 3: Ubuntu Software

对于基于 Debian 的发行版，包括 Debian、Ubuntu、Linux Mint、Elementary OS 等，它们的底层命令行工具是 dpkg，高级工具称为 apt。在 Ubuntu 上管理已安装软件的图形工具是 Ubuntu Software（图 3）。对于 Debian 和 Linux Mint，图形工具称为 新立得 Synaptic ，它也可以安装在 Ubuntu 上。

你也可以在 Debian 相关发行版上安装一个基于文本的图形化工具 aptitude。它比 新立得 synaptic 更强大，并且即使你只能访问命令行也能工作。如果你想通过各种选项进行各种“骚”操作，你可以试试这个，但它使用起来比新立得更复杂。其它发行版也可能有自己独特的工具。

命令行工具

在 Linux 上安装软件的在线说明通常描述了在命令行中键入的命令。这些说明通常更容易理解，并且将命令复制粘贴到命令行窗口中，可以在不出错的情况下一步步进行。这与下面的说明相反：“打开这个菜单，选择这个程序，输入这个搜索模式，点击这个标签，选择这个程序，然后点击这个按钮”，这经常让你在各种操作中迷失。

有时你正在使用的 Linux 没有图形环境，因此熟悉从命令行安装软件包是件好事。表 1 和表 2 列出了基于 RPM 和 DPKG 系统的一下常见操作及其相关命令。

请注意 SUSE，它像 RedHat 和 Fedora 一样使用 RPM，却没有 dnf 或 yum。相反，它使用一个名为 zypper 的程序作为高级命令行工具。其他发行版也可能有不同的工具，例如 Arch Linux 上的 pacman 或 Gentoo 上的 emerge。有很多包管理工具，所以你可能需要查找哪个适用于你的发行版。

这些技巧应该能让你更好地了解如何在新的 Linux 中安装程序，以及更好地了解 Linux 中各种软件包管理方式如何相互关联。

通过 Linux 基金会和 edX 的免费 “Linux 入门”课程了解有关 Linux 的更多信息。

via: https://www.linux.com/blog/learn/2018/3/migrating-linux-installing-software

作者：JOHN BONESIO 译者：MjSeven 校对：pityonline, wxy

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