标签 GPL 下的文章

据自由软件基金会(FSF)报道,正在进行中的 GPL 合规案件 Artifex v. Hancom 近日产生了新的裁决,一项旨在提请简易判决的动议被法院驳回。

该案涉及一款遵循 GPL v3 及之后版本许可证的名为 Ghostscript 的软件,其来源于 Artifex 公司一个用于处理 PostScript、PDF 以及打印机的项目(GNU Ghostscript 是该项目的一个单独版本,并未涉及或牵连该案)。

FSF在之前的报道中表示

在该诉讼中,基于 Hancom 公司对 Ghostscript 的使用情况,Artifex 公司提出了两项指控:(1)侵犯版权;以及(2)违反基于GPL许可证的合同。……虽然违反自由软件许可证将导致侵犯版权已经成为老生常谈,但是,违反 GPL 等许可证是否可以被视为违反合同,长期以来一直是许可专家们的讨论话题。

在之前的裁决中,本案的法官驳回了 Hancom 的撤案动议,让案件得以继续进行。现在诉讼已经到了下一步,其中包括一个主张 GPL 构成合同的 简易判决动议 Motion for summary judgment ,但是该动议日前也被法官驳回。在撤案动议中,法院假定所涉指控真实存在,并对所述指控是否真正提出了有效的合法权利主张做出了裁决。在简易判决动议中,法院会被要求去审视无可争议的事实,并确定该案件的结果是否如此明显,以至于不需要经过全面审判。类似动议虽然是例行的,但是如果通过了简易判决,意味着本案中合同理论的复苏问题依然存在(LCTT 译注:指是否被视为违法合同)。

Hancom 公司提出了一些否认 GPL 许可证构成合同的证据,其中一个特别有意思。Hancom 公司认为,如果 GPL 许可证构成合同的说法被接受,则只能考虑他们在初始违规日之前的损害赔偿。他们认为,由于违规造成了许可终止,合同也因此结束。法官指出:

GPL 许可证表明,在使用 Ghostscript 传播软件的权利被终止后,被告的义务依然存在,……因为每次传递“ 被覆盖作品 covered work ”,都需要提供源代码或承诺提供源代码,每次被告分发使用 Ghostscript 的产品,可以说随之而来的义务就是提供源代码或承诺提供源代码。

法官还发现,在这一点上没有足够的证据来对该问题做出裁决。所以,FSF 表示,目前还无法进行过多的解读。但是,法官对于违规行为之后 GPL 在什么条件下继续存在的看法,是随着本案进行,该问题如何发展的重要线索。虽然,为了保护用户自由, GPL 许可证并不需要作为合同进行维护(它作为版权许可已经成功运行了几十年)。不过,类似的程序性裁决显示了有更多的证据表明,GPL 许可证作为合同的主张在法院不容易站住脚或者容易被击败的说法并非毫无根据的造谣。

FSF 表示,随着简易判决动议被否,本案继续向前推进,并将变得更为有趣。


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

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

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

2、对于 GNU 许可证的一般了解

2.1 为什么 GPL 允许用户发布其修改版本?

自由软件的一个关键特点是用户可以自由合作。绝对有必要允许希望彼此帮助的用户与其他用户分享他们对错误的修复和改进。

有些人提出了 GPL 的替代方案,需要原作者批准修改版本。只要原作者持续进行维护,这种做法在实践中可能会不错,但是如果作者停止维护(或多或少会)去做别的事情,或并不打算去满足所有用户的需求,这种替代方案就会失败。除了实践上的问题之外,该方案也不允许用户之间互相帮助。

有时候对修改版本的控制,是为了防止用户制作的各种版本之间造成混淆。根据我们的经验,这种混乱不是一个大问题。在 GNU 项目之外出现了许多版本的 Emacs,但用户仍可以将它们区分开。GPL 要求版本创造者将他/她的名字标注其上,以区别于其他版本,并保护其他维护者的声誉。

2.2 GPL 是否要求将修改版本的源代码公开发布?

GPL 不要求您发布修改后的版本或其中的任何一部分。您可以自由地进行修改并私人使用它们,而无需进行发布。这也适用于组织(包括企业);组织可以制作修改版本,在内部使用它,并且绝不将修改版本发布到组织之外。

但是,如果您以某种方式向公众发布修改后的版本,依据 GPL 许可证,GPL 要求您保证程序的用户可以获得修改后源代码。

因此,GPL 给你以某些特定方式发布修改后的程序的授权,而不是以其他方式发布;但是,是否发布修改版本的决定取决于您。

2.3 我可以在同一台电脑上安装一个遵循 GPL 许可证的程序和一个不相关的非自由程序吗?

可以。

2.4 如果我知道某些人有一个遵循 GPL 许可证的程序的副本,我可以要求他们给我一个副本吗?

不可以,GPL 给人们制作和再分发程序副本的授权,倘若有人选择这样做的话。那个人也有权选择不去再分发该程序。

2.5 GPL v2 中的“ 书面文件 written offer 对任何第三方有效”是什么意思? 这是否意味着世界上每个人都可以获得任何遵循 GPL 许可证的程序的源代码?

如果您选择通过书面文件提供源代码,那么任何向您索求源代码的人都有权收到。

如果您对不附带源代码的二进制文件进行商业分发,GPL 要求您必须提供一份书面文件,表明将稍后分发源代码。当用户非商业性地再分发他们从您那里获取的二进制文件时,他们必须传递这份书面文件的副本。这意味着不能直接从您那里获取二进制文件的人,仍然可以收到源代码副本以及该书面文件。

我们要求书面文件对任何第三方有效的原因是,以这种方式间接收到二进制代码的人可以从您那里订购源代码。

2.6 GPL v2 中规定,发布后的修改版本必须“授予…所有第三方许可”。这些第三方是谁?

第 2 节中规定,依据 GPL,您分发的修改版本必须授权给所有第三方。 “所有第三方”当然是指所有人,但这并不要求您为他们任何事情。这仅仅意味着他们依据 GPL 从您那里获得了您的修改版本的许可。

2.7 GPL 允许我出售程序的副本以获利吗?

是的,GPL 允许每个人这样做。销售副本的权利是自由软件定义的一部分。除了一种特殊情况之外,对您可以收取什么样的价格是没有限制的。(这种例外情况是:二进制版本必须附有表明将提供源代码的书面文件。)

2.8 GPL 允许我从我的分发网站收取下载程序的费用吗?

允许。您可以对您分发程序副本收取任何您想收取的费用。如果您通过下载分发二进制文件,则必须提供“等同的访问权限”来让人们下载源代码,因此,下载源代码的费用可能不会超过下载二进制文件的费用。

2.9 GPL 允许我要求任何接收软件的人必须向我支付费用和/或通知我吗?

不允许。实际上,这样的要求会使程序变成非自由软件。如果人们在获得程序副本时必须支付费用,或者他们必须特别通知任何人,那么这个程序就不是自由软件。请参阅自由软件的定义

GPL 是自由软件许可证,因此允许人们使用甚至再分发软件,而不需要向任何人支付费用。

您可以向用户收取费用,以获取您的副本。当他们从别人那里获得副本时,您不能要求人们向您支付费用。

2.10 如果我收费分发遵循 GPL 的软件,我是否还需要向公众免费提供?

不需要。不过,如果有人向您支付费用并获得副本,GPL 给予他们免费或收费向公众发布的自由。例如,有人可以向您支付费用,然后把他的副本放在一个网站上,让公众去获取。

2.11 GPL 允许我根据保密协议分发副本吗?

不允许。GPL 规定,任何从您那里获取副本的人都有权再分发已修改或未修改的副本。您不得在任何更严格的基础上分发作品。

如果有人要求您签署保密协议(NDA),以获取来自 FSF 的遵循 GPL 的软件,请立即通知我们 mailto:[email protected]

如果违规行为涉及其他版权所有者的遵循 GPL 的代码,请通知该版权所有者,就像您对其他任何类型的 GPL 违规行为所做的工作一样。

2.12 GPL 允许我根据保密协议分发程序的修改版或测试版吗?

不可以。GPL 规定,您的修改版本必须具备 GPL 中规定的所有自由。因此,从您那里获取您的版本副本的任何人都有权再分发该版本的副本(已修改或未修改)。您不得在更严格的基础上分发该作品的任何版本。

2.13 GPL 是否允许我根据保密协议开发程序的修改版本?

可以。例如,您可以接受一份合同来开发修改版本,并同意不得发布您的修改版本,直到客户同意才可以发布。这是允许的,因为这种情况下不处于 GPL 协议之下的代码是依据 NDA 分发的。

您还可以依据 GPL 将您的修改版本发布给客户,但须同意不将其发布给其他任何人,除非客户同意。也同样在这种情况下,不处于 GPL 协议之下的代码是以保密协议或任何其他限制条款分发的。

GPL 将给予客户再分发您的版本的权利。在这种情况下,客户可能会选择不行使这项权利,但他确实拥有这项权利。

2.14 为什么 GPL 要求程序的每个副本必须包含 GPL 许可证副本?

作品包含许可证副本至关重要,因此获得程序副本的每个人都可以知道他们的权利是什么。

包括一个指向许可证的 URL,而不是将许可证本身包含在内,这是一种看起来很诱人的做法。但是您不能确定该 URL 在五年或十年后仍然有效。二十年后,我们今天所知道的 URL 们可能已不复存在。

不管网络将发生什么样的变化,确保拥有该程序副本的人员能够继续看到 GPL 许可证的唯一方法是,将许可证的副本包含在该程序中。

2.15 如果作品不是很长,那该怎么办?

如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行,那么您可以使用一个宽松的许可证,而不是像 GNU GPL这样的 Copyleft 许可证(除非代码特别重要)。我们建议这种情况使用 Apache License 2.0

2.16 我是否需要将我对遵循 GPL 的程序所做的修改声明版权?

您不需要对您的修改声明版权。不过,在大多数国家/地区,默认情况下会自动获得版权,因此,如果您不希望修改受到版权限制,您需要将修改明显地放置于公有领域。

无论您是否对您的修改声明版权,依据 GPL,您都必须将修改版本作为整体发布(参见:2.2 GPL 是否要求将修改版本的源代码公开发布?)。

2.17 GPL 对于将某些代码翻译成不同的编程语言是如何规定的?

根据著作权法,翻译工作被认为是一种修改。因此,GPL 对修改版本的规定也适用于翻译版本。

2.18 如果一个程序将公有领域代码与遵循 GPL 的代码相结合,我可以取出公有领域的部分,并作为公有领域代码来使用吗?

您可以这样做,如果您能弄清楚哪个部分是公有领域的部分,并将其与其他部分区分开。如果代码曾经由其开发人员放置在公有领域,那么它就是公有领域代码,无论它现在究竟在哪里。

2.19 我想要因我的作品获得声誉。我想让人们知道我写了什么,如果我使用 GPL,我还能获得声誉吗?

您一定能获得这份作品的声誉。遵循 GPL 发布的程序的一部分是以您自己名义撰写的版权声明(假设您是版权所有者)。GPL 要求所有副本携带恰当的版权声明。

2.20 GPL 允许我添加条款,要求在使用遵循 GPL 的软件或其输出物的研究论文中包含引用或致谢吗?

不可以,根据 GPL 的规定,这是不允许的。虽然我们认识到适当的引用是学术出版物的重要组成部分,但引用不能作为对 GPL 的附加要求。对使用 GPL 软件的研究论文要求包含引用,超出了 GPL v3 第 7(b)条中可接受的附加要求,因此将被视为对 GPL 第 7 节的额外限制。而且版权法也不允许您在软件的输出物中设置这样的要求,无论该软件是依据 GPL 还是其他许可证的条款获得许可。

2.21 为了节省空间,我是否可以省略 GPL 的引言部分,或者省略如何在自己的程序上使用GPL的 指导 instructions 部分吗?

引言和指导是 GNU GPL 的组成部分,不能省略。事实上,GPL 是受版权保护的,其许可证规定只能逐字复制整个 GPL。(您可以使用法律条款制作另一个许可证,但该许可证不再是 GNU GPL。)

引言和指导部分共约 1000 字,不到 GPL 总文字数量的 1/5。除非软件包本身很小,否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下,您可以使用一个简单的 全权 all-permissive 许可证,而不是 GNU GPL。

2.22 两个许可证“兼容”是指什么?

为了将两个程序(或它们的实质部分)组合成一个更大的作品,您需要有以组合方式使用这两个程序的权限。如果两个程序的许可证允许这种使用方式,则它们是兼容的。如果没有办法同时满足这两个许可证,则它们是不兼容的。

对于一些许可证,组合的方式可能会影响它们是否兼容,例如,它们可能允许将两个模块链接在一起,但不允许将其代码合并到一个模块中。

如果您只想在同一个系统中安装两个独立的程序,那么它们的许可证并不是必须兼容的,因为它们没有组合成更大的作品。

2.23 许可证与 GPL 兼容是什么意思?

这意味着其他许可证和 GNU GPL 兼容;在一个更大的程序中,您可以将根据其他许可证发布的代码与根据 GNU GPL 发布的代码进行组合。

所有 GNU GPL 版本都允许进行这种组合;它们还允许分发这些组合,只要该组合在相同的 GNU GPL 版本下发布。其他许可证如果允许这样做,则其与 GPL 兼容。

与 GPL v2 相比,GPL v3 与更多的许可证兼容:它允许您与具有特定类型附加要求(GPL v3 本身不包含)的代码进行组合。GPL v3 第 7 节中有关于此问题的更多信息,包括了允许的附加要求的列表。

2.24 为什么原始的 BSD 许可证与 GPL 不兼容?

因为它规定了 GPL 不包含的具体要求,即对程序广告的要求。GPL v2 第 6 节规定:

您不得对接受者行使本协议授予的权利施加进一步的限制。

GPL v3 在第 10 节中提到类似的内容。广告条款正好提供了这样一个限制,因此与 GPL 不兼容。

修订的 BSD 许可证没有广告条款,从而消除了这个问题。

2.25 “ 聚合 aggregate ”与其他类型的“修改版本”有什么区别?

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

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

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

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

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

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

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

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

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

2.27 如果我使用遵循 GNU GPL 的软件,那么允许我将原始代码修改为新程序,然后在商业上分发和销售新程序吗?

您被允许在商业上出售修改程序的副本,但仅限于在 GNU GPL 的条款之下这么做。因此,例如,您必须依照 GPL 所述,使得程序用户可获取源代码,并且,用户也依照 GPL 所述,被允许再分发和修改程序。

这些要求是将遵循 GPL 的代码包含在您自己的程序中的条件。

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

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

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

2.29 我想依据 GPL 授权我的代码,但我也想明确指出,它不能用于军事和/或商业用途。我可以这样做吗?

不可以,因为这两个目标相互矛盾。GNU GPL 被专门设计为防止添加进一步的限制。GPL v3 在第 7 节允许非常有限的一组附加限制,但是用户可以删除任何其他添加的限制。

2.30 我可以依据 GPL 来对硬件进行许可吗?

任何可以受版权保护的 材料 material 都可以依据GPL进行许可。GPL v3 也可以用于受其他类似版权法的法律保护的材料,如半导体掩模。因此,作为一个例子,您可以依据 GPL 发布物理对象的图纸或电路。

在许多情况下,版权不涵盖依照图纸制作的物理硬件。在这种情况下,无论您使用什么许可证,您对图纸的许可都不能对制造或销售物理硬件施加任何控制。当版权不涵盖利用 IC 掩膜等进行硬件制作时,GPL 能以有效的方式处理这种情况。

2.31 将遵循 GPL 的二进制文件 预链接 prelinking 到系统上的各种库,以优化其性能,将被视为修改吗?

不。 预链接 prelinking 是编译过程的一部分;与编译过程所涉及的其他各个方面相比,预链接没有引入更多的许可证要求。如果您被允许将程序链接到各种库,那么也可以预链接到各种库。如果您分发预链接后的目标码,则需要遵循第 6 节的条款。

2.32 LGPL 如何与 Java 配合使用?

详情请参阅这篇文章。LGPL 如同被设计、被预想、被期待的那样去工作。

2.33 为什么你们在 GPL v3 中发明新的术语“ 传播 propagate ”和“ 传递 convey ”?

(译者注:convey 这个词汇在一个 GPL 译本中被翻译为“转发”,此处,我们认为“转发”一词在计算机领域存在一定的歧义,因此,采用“传递”的翻译。)

GPL v2 中使用的“分发”一词来自美国版权法。多年来,我们了解到,一些司法管辖区在自己的版权法中使用了同一个词,但却给出了不同的含义。我们发明了这些新术语,无论在何处对许可证进行解释,都使我们的意图尽可能清楚。这些新术语没有使用在世界上的任何版权法中,我们直接在许可证中提供了它们的定义。

2.34 在GPL v3中的“ 传递 convey ”与GPL v2中的“ 分发 distribute ”意思一样吗?

是的,差不多是一个意思。在执行 GPL v2 的过程中,我们了解到一些司法管辖区在自己的版权法中使用了“分发”这个词,但给出了不同的含义。我们发明了一个新的术语,以使我们的意图清晰,避免这些差异可能引起的任何问题。

2.35 如果我只复制遵循 GPL 的程序并运行它们,而不分发或传递给其他人,许可证对我施加什么要求?

没有要求。GPL 不对此活动附加任何条件。

2.36 GPL v3将“向公众提供”作为 传播 propagate 的一个例子。这是什么意思? 是提供一种可获取的传递形式吗?

“向公众提供”的一个例子是将该软件放在公共网页或FTP服务器上。在您这样做之后,在任何人从您那里真正获取软件之前,可能会需要一段时间,但是由于这种情况可能会立即发生,您也需要能够立即履行 GPL 的义务。因此,我们将“ 传递 convey ”定义为包括这一活动。

2.37 鉴于分发和向公众提供作为传播形式,同样也构成了 GPL v3 中的“ 传递 conveying ”,那么有哪些传播的例子不构成传递吗?

为自己制作软件的副本是不构成“传递”的主要传播形式。您可以依此在多台计算机上安装软件,或进行备份。

2.38 GPL v3 如何让 BitTorrent 分发变得更容易?

因为 GPL v2 是在软件的点对点分发普及之前编写的,所以当您利用这种方式分享代码时,很难满足 GPL v2 的要求。在 BitTorrent 上分发 GPL v2 目标代码时,确保您合规的最佳方法是将所有相应的源代码包含在相同的 种子文件 Torrent 中,但这种方式代价高昂。

GPL v3 以两种方式解决了这个问题。首先,作为该过程的一部分,下载此种子文件并将数据发送给其他人的人不需要做任何事情。因为第 9 节规定:“受保护作品的辅助传播如果仅仅是使用点对点传输来接收副本,不需要接受[本许可证]。”

第二,通过告知接收人在公共网络服务器上哪里可获取,GPL v3 的第 6(e)节旨在给予分发者(最初制作种子文件的人)一种清晰、直观的方式来提供源代码。这样可以确保每个想要获取源代码的人都可以如此获取,而且分发者几乎不用担心。

2.39 什么是 TiVo化 tivoization ? GPL v3 对此如何防止?

一些设备使用可升级的自由软件,但被设计为用户不能修改该软件。有很多不同的方式可以做到这一点;例如,有时硬件校验所安装的软件,如果与预期签名不匹配,则关闭软件。制造商通过提供源代码来遵循GPL v2,但是您仍然无法自由修改您使用的软件。我们称这种做法为 TiVo 化 tivoization

当人们分发包含遵循 GPL v3 软件的“ 用户产品 User Products ”时,第 6 节要求他们为您提供修改该软件所需的信息。“用户产品”是该许可证特别定义的术语;“用户产品”的示例包括便携式音乐播放器、数字录像机和家庭安全系统。

2.40 GPL v3 是否禁止 DRM?

不禁止,您可以使用遵循 GPL v3 发布的代码来开发您喜欢的任何类型的 DRM 技术。不过,如果您这样做,第 3 节规定,系统不会被视为一种有效的技术“保护”措施,这意味着如果有人破坏了 DRM,他也可以自由分发他的软件,不受《美国数字千禧版权法》(DMCA)和类似法律的限制。

像往常一样,GNU GPL 并不限制人们在软件中怎么做,只是阻止他们限制他人。

2.41 GPL v3 是否要求投票人能够修改在投票机中运行的软件?

不要求。企业分发包含遵循 GPL v3 软件的设备,最多只需要为拥有目标代码副本的人提供软件的源代码和安装信息。使用投票机(如同任何其他信息亭一样)的选民不能拥有它,甚至不能暂时拥有,所以选民也不能拥有二进制软件。

不过,请注意,投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由软件,并不意味着您可以信任计算机,并进行投票。我们认为电脑不值得信任,不能被用作投票。投票应在纸上进行。

2.42 GPL v3 是否包含“专利报复条款”?

实际上,是的。第 10 节禁止传递该软件的人向其他被许可人发起专利诉讼。如果有人这样做,第 8 节解释他们将如何丧失许可证权益以及与之伴随的所有专利许可。

2.43 在 GPL v3 和 AGPL v3中,当说到“尽管有本许可证的其他规定”时,是什么意思?

这仅仅意味着以下条款胜过许可证中可能与之冲突的其他任何内容。例如,如果没有该文本,有些人可能声称,您不能将遵循 GPL v3 的代码与遵循 AGPL v3 的代码结合在一起,因为 AGPL 的附加要求将被归类为 GPL v3 第 7 节下的“进一步限制”。该文本明确表示我们的预期解释是正确的,您可以进行组合。

该文本仅解决许可证不同条款之间的冲突。当两个条件之间没有冲突的时候,您必须同时满足它们。这些段落不允许您轻率地忽略许可证的其余部分,它们只是强调了一些非常有限的例外。

2.44 在 AGPL v3 中,怎么才算是“通过计算机网络远程与[软件]进行交互”?

如果程序被明确设计为接受用户请求并通过网络发送响应,则它符合这些标准。属于此类程序的常见示例包括网络和邮件服务器、交互式网络应用程序和在线游戏的服务器。

如果程序没有被明确设计为通过网络与用户进行交互,而是恰好在这样做的环境中运行,那么它不属于此类。例如,仅仅因为用户通过 SSH 或远程 X 会话来运行的应用程序不需要提供源代码。

2.45 GPL v3 中“ you ”的概念如何与 Apache License 2.0 中“ 法律实体 Legal Entity ”的定义相比较?

它们是完全相同的。Apache License 2.0 中“法律实体”的定义在各种法律协议中是非常标准的,因此,如果法院在缺乏明确定义的情况下没有以同样的方式解释该术语,将会令人非常惊讶。我们完全期待他们在看 GPL v3 时也会如此,并考虑到谁有资格作为被许可人。

2.46 在 GPL v3 中,“ 该程序 the Program ”是指什么? 是每个依据 GPL v3 发布的程序?

术语“该程序”是指依据 GPL v3 进行许可的特定作品,由特定被许可人从上游许可人或分发者那里接收。“该程序”是您在 GPL v3 许可的指定情境下接受到的特定软件作品。

“该程序”并不意味着“依据 GPL v3 进行许可的所有作品”;由于一些原因,这种解释没有任何意义。针对那些想要了解更多的人,我们已经发表了对“该程序”一词的分析

2.47 如果某些网络客户端软件依据 AGPL v3 发布,是否必须能够向与之交互的服务器提供源代码?

AGPL v3 需要该程序向“所有通过计算机网络进行远程交互的用户”提供源代码。至于您将程序称为“客户端”还是“服务器”,那无关紧要。您需要询问的问题是,是否存在合理的期望让一个人通过网络远程与该程序交互。

2.48 对于一个运行在代理服务器上的依据 AGPL 进行许可的软件来说,如何向与该软件交互的用户提供源代码书面文件?

对于代理服务器上的软件,您可以通过向此类代理的用户传递消息的常规方法来提供源代码书面文件。例如,Web 代理可以使用登录页。当用户最初开始使用代理时,您可以将他们引导到包含源代码书面文件以及您选择提供的任何其他信息的页面。

AGPL 规定,您必须向“所有用户”提供书面文件。如果您知道某个用户已经被展示过书面文件,对于当前版本的软件,您不必再重复向该用户提供。

本文由高级咨询师薛亮据自由软件基金会(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 分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

不久之前我看到了 RedMonk 的 Stephen O'Grady 发了一个关于开源协议的有趣的推特,那个推特里面有这张图。

 title=

这张图片显示了从 2010 到 2017 年间各种开源协议之间的使用率的变化。在这张图片里,显然 GPL 2.0 —— 最纯净的 copyleft 协议之一 —— 的使用率降低了一多半。该图表表明,开源项目中 MIT 协议和 Apache 协议开始受欢迎。GPL 3.0 的使用率也有所上涨。

这些意味着什么?

为什么 GPL 2.0 的使用率跌的这么多但是 GPL 3.0 仅仅是涨了一丁点?为什么 MIT 协议和 Apache 协议的使用率涨了那么多?

当然,有很多原因可以解释这件事情,但是我想这是因为商业开源项目的增多,以及商业社会对于 GPL 协议的担心导致的,我们细细掰扯。

GPL 协议与商业社会

我知道我要说的可能会激怒一些 GPL 粉,所以在你们开始喷之前,我想说明的是:我支持 GPL,我也是 GPL 粉丝。

我写过的所有软件都使用的是 GPL 协议,我也是一直是积极出资支持 自由软件基金会 以及 软件自由保护组织 以及他们的工作的,我支持使用 GPL 协议。我在这说的无关 GPL 的合法性或者 GPL 的巨大价值 —— 毫无疑问这是一个好协议 —— 我在这要说的是业内对于这个协议的看法。

大概四年之前,我参加了一个叫做 开源智库 Open Source Think Tank 的峰会。这个峰会是一个私人小型峰会,每年都会把各大开源企业的管理人员请到加利福尼亚的酒庄。这个峰会聚焦于建立关系、构建联盟,找到并解决行业问题。

在这个峰会上,有一个分组研究,在其中,与会者被分成小组,被要求给一个真实存在的核心的开源技术推荐一个开源协议。每个小组都给出了回应。不到十分之一的小组推荐了宽容许可证,没有人推荐 GPL 许可证。

我看到了开源行业对于 Apache 协议以及 MIT 协议的逐步认可,但是他们却对花时间理解、接受和熟悉 GPL 这件事高高挂起。

在这几年里,这种趋势仍在蔓延。除了 Black Duck 的调查之外, 2015 年 GitHub 上的开源协议调查 也显示 MIT 是人们的首选。我还能看到,在我工作的 XPRIZE (我们为我们的 Global Learning XPRIZE 选择了开源协议),在我作为社区领导顾问的工作方面,我也能感觉到那种倾向,因为越来越多的客户觉得把他们的代码用 GPL 发布不舒服。

随着 大约 65% 的公司对开源事业做贡献 ,自从 2010 年以后显然开源行业已经引来了不少商业兴趣和投资。我相信,我之前说的那些趋势,已经表明这行业不认为 GPL 适合搞开源生意。

连接社区和公司

说真的,GPL 的没落不太让人吃惊,因为有如下原因。

首先,开源行业已经转型升级,它要在社区发展以及……你懂的……真正能赚钱的商业模型中做出均衡,这是它们要做的最重要的决策。在开源思想发展之初,人们有种误解说,“如果你搞出来了,他们就会用”,他们确实会来使用你的软件,但是在很多情况下,都是“如果你搞出来了,他们不是一定要给你钱。”

随着历史的进程,我们看到了许多公司,比如 Red Hat、Automattic、Docker、Canonical、Digital Ocean 等等等等,探索着在开源领域中赚钱的法子。他们探索过分发模式、服务模式,核心开源模式等等。现在可以确定的是,传统的商业软件赚钱的方式已经不再适用开源软件;因此,你得选择一个能够支持你的公司的经营方式的开源协议。在赚钱和免费提供你的技术之间找到平衡在很多情况下是很困难的一件事。

这就是我们看到那些变化的原因。尽管 GPL 是一个开源协议,但是它根本上是个自由软件协议,作为自由软件协议,它的管理以及支持是由自由软件基金会提供的。

我喜欢自由软件基金会的作品,但是他们已经把观点局限于软件必须 100% 绝对自由。对于自由软件基金会没有多少可以妥协的余地,甚至很多出名的开源项目(比如很多 Linux 发行版)仅仅是因为一丁点二进制固件就被认为是 “非自由” 软件。

对于商业来说,最复杂的是它不是非黑即白的,更多的时候是两者混合的灰色,很少有公司有自由软件基金会(或者类似的组织,比如软件自由保护组织)的那种纯粹的理念,因此我想那些公司也不喜欢选择和那些理念相关的协议。

我需要说明,我不是在这是说自由软件基金会以及类似的组织(比如软件自由保护组织)的错。他们有着打造完全自由的软件的目标,对于他们来说,走它们选择的路十分合理。自由软件基金会以及软件自由保护组织做了了不起的工作,我将继续支持这些组织以及为他们工作的人们。我只是觉得这种对纯粹性的高要求的一个后果就是让那些公司认为自己难以达到要求,因此,他们使用了非 GPL 的其他协议。

我怀疑 GPL 的使用是随着开源软件增长而变化的。在以前,启动(开源)项目的根本原因之一是对开放性和软件自由的伦理因素的严格关注。GPL 无疑是项目的自然选择,Debian、Ubuntu、Fedora 和 Linux 内核以及很多都是例子。

近年来,尽管我们已经看到了不再那么挑剔的一代开发者的出现,但是如果我说的过激一些,他们缺少对于自由的关注。对于他们来说开源软件是构建软件的务实、实用的一部分,而无关伦理。我想,这就是为什么我们发现 MIT 和 Apache 协议的流行的原因。

未来 ?

这对于 GPL 意味着什么?

我的猜想是 GPL 依然将是一个主要选项,但是开发者将将之视为纯粹的自由软件协议。我想对于软件的纯粹性有高要求的项目会优先选择 GPL 协议。但是对于商业软件,为了保持我们之前讨论过的那种平衡,他们不会那么做。我猜测, MIT 以及 Apache 依然会继续流行下去。

不管怎样,好消息是开源/自由软件行业确实在增长。无论使用的协议会发生怎样的变化,技术确实变得更加开放,可以接触,人人都能使用。


作者简介:

Jono Bacon - Jono Bacon 是一位领袖级的社区管理者、演讲者、作者和播客主。他是 Jono Bacon 咨询公司的创始人,提供社区战略和执行、开发者流程和其它的服务。他之前任职于 GitHub、Canonical 和 XPRIZE、OpenAdvantage 的社区总监,并为大量的组织提供咨询和顾问服务。


via: https://opensource.com/article/17/2/decline-gpl

作者:Jono Bacon 译者:name1e5s 校对:wxy

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

韩国一家开发了 Hancom Office 办公软件的公司在其字处理软件中集成了开源软件 Ghostscript,但是没有遵守 Ghostscript 的 GNU GPL 许可证而开源,也没有为该软件付费。近日,该韩国公司被美国联邦法院裁定其违约。

Ghostscript 是一个开源软件,由 Artifex 公司开发,其采用了两种许可证:

  • GNU GPL 许可证
  • 商业付费许可证

如果要免费使用 Ghostscript,Hancom 就需要遵循该软件的开源许可证,即 GNU GPL。该许可证要求,如果你的软件中使用了采用该许可协议的软件,并公开发布的话,就需要也采用同样的 GNU GPL 许可证开源。也就是说, Hancom 需要开源其整个办公软件套件。

否则,Hancom 就需要向 Ghostscript 的开发商 Artifex 公司支付商业许可证费用。Artifex 允许商业或其它闭源软件开发商绕开严格的开源许可证 GNU GPL,只要付费就行。

但是 Hancom 从 2013 年在其软件中使用了 Ghostscript 之后,却什么都没做:既没有开源其软件,也没有向 Artifex 公司付商业许可证的费用。

在 2016 年底,交涉无果的 Artifex 公司向美国加利福尼亚北部地区法院发起了诉讼。

“在发现 Hancom 违反了 GNU GPL 许可证,侵犯了 Artifex 的 Ghostscript 的宝贵版权之后,Artifex 要求 Hancom 停止其侵权行为,并为其多年无版权使用 Ghostscript 支付合理的版权费用,”该公司陈述到,“Hancom 拒绝了该要求,Artifex 转而寻求本法院责令 Hancom 停止进一步侵权并支付其滥用 Artifex 的开源许可证的费用。”

Artifex 还提到 Hancom 在 2015 年收入了 8630 万美元。

像 GUN GPL 这样的开源许可证的可执行性长期以来一直是一个悬而未决的法律问题。美国联邦巡回法庭在 2006 年的一个判例,雅各布森诉卡泽尔案中,对开源许可证的侵犯裁定可视作对版权申明的处理。但是在本案之前,这种侵犯开源许可证是否可以依法视作侵犯合约并未裁定。

Hancom 尝试发起动议以驳回该诉讼,其认为该公司并未签署任何东西,所以该许可证并不是真正的合约。

“并不是这样”,杰奎琳·斯科特·科里法官在 4 月 25 日的议案中说。她说 GNU GPL “规定了如果用户没有获取商业许可证,即表示同意其条款。原告称被告没有获取商业许可证,并公开表明其在 GNU GPL 下使用 Ghostscript。这些指控足以为合约的存在而辩护。”

科里法官驳回了 Hancom 的动议。按照这样的做法,就树立了像 GNU GPL 这样的开源许可证可以被视作法律合约的先例,在开发商违反了开源许可证时会被起诉。这对于开源社区来说是一个重大胜利。

当然,Artifex 是否可以最终赢得这一诉讼,还要看后继的上诉和裁定。

GNU Affero 通用公共许可证版本 3(AGPLv3)是与 GPLv3 几乎相同的 左版 copyleft 许可证。两个许可证具有相同的公共版权范围,但在一个重要方面有重大差异。 AGPLv3 的第 13 节规定了 GPLv2 或 GPLv3 中不存在的附加条件:

在本许可证的其它条款之外,如果你修改了程序,你必须把你修改的版本,给你的那些使用计算机网络远程(如果你的版本支持此类交互)与之交互的用户,明确提供一个通过一些标准或者常规的复制手段,从网络服务器上免费获得与你所修改的版本相匹配的源码的机会。

这个“通过计算机网络远程交互”的范围主要被认为是 SaaS 部署的情形,尽管其实际上读起来的意思超乎了惯例的 SaaS 部署情形。其目标是解决在用户在使用像 Web Services 这样的功能时,其代码没有公开的常规 GPL 协议所暴露出的漏洞。因此,该协议的第 13 节,在 GPLv2 第 3 节以及 GPLv3 和 AGPLv3 第 6 节中包含的目标代码分发的触发要求之外,提供了额外的源代码公开的要求。

常常被误解的是,AGPLv3 第 13 节中的源代码分发要求仅在 AGPLv3 软件已被“你”(例如,提供网络服务的实体)修改的地方才触发。我的理解是,只要“你”不修改 AGPLv3 的代码,许可证就不应该被理解为需要按照第 13 节规定的方式访问相应的源码。如我所见,尽管即使公开许可证中不要求公开的源代码也是一个好主意,但在 AGPL 下许多未修改以及标准部署的软件模块根本不会触发第 13 节。

如何解释 AGPL 的条款和条件,包括 AGPL 软件是否已被修改,可能需要根据具体情况的事实和细节进行法律层面的分析。


作者简介:

Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商 Red Hat 公司的开源 IP 律师。Jeffrey 也是托马斯·杰斐逊法学院的兼职教授。在入职 Red Hat 之前,Jeffrey 曾经担任高通公司的专利顾问,向首席科学家办公室提供开源顾问。Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。


via: https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license

作者:Jeffrey Robert Kaufman 译者:geekpi 校对:Bestony

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