Harmony，Canonical 牵头的旨在为开源项目提供一套全面的贡献者协议的努力，在 Canonical 总法律顾问 Amanda Brock 在 opensource.com 上 宣布 该倡议一年后，悄然发布了其 1.0 版本。在那一年的大部分时间里，Harmony 的构建都在公众视野之外进行，审议过程被 查塔姆研究所规则 所掩盖。
尽管我对 Harmony 的推动者们充满钦佩、尊敬和喜爱，但我无法认可他们的工作成果。我认为 Harmony 是不必要的、令人困惑的，并且可能对开源和自由软件开发有害。
贡献政策和自由软件传统
四分之一个世纪以来，大多数自由软件项目的特点是交易的非正式性和许可方平等这两个规范。大多数项目从未使用过正式的贡献者协议。相反，它们通常在一种我称之为“入站=出站”的规则下运作：本质上，贡献被理解为根据适用的出站项目许可证（或明确的入站许可证由项目下游传递）获得许可。这使得有价值的贡献者可以轻松参与项目，而不会受到恐吓和繁文缛节的困扰，并使所有项目贡献者（无论是补丁提交者还是提交者）在法律上处于平等的地位。这是一种如此普遍的法律治理形式，以至于我必须得出结论，开源开发模型的巨大成功很大程度上归功于此。
自由软件基金会为早期的 GNU 项目强制执行的版权转让政策多年来一直是这一普遍社会规则的主要例外。正式贡献者协议的使用在最近一段时间有所增加，但它仍然是一种少数派方法。在使用此类协议的情况下，基本上有两种方法，我将其称为最大化主义和最小化主义。最大化主义方法以版权转让协议和贡献者许可协议 (CLA) 为代表，这些协议要求最大限度地广泛授予入站版权许可。最小化主义方法可能不太为人所知；它们通常涉及对使用特定的知名自由软件许可证进行贡献的简单明确承诺。这通常是项目的适用出站许可证（入站=出站习俗的正式化），或某些标准的宽松许可证。
最大化主义贡献者协议在 FLOSS 开发社区中一直备受争议，尤其是在由单一企业利益控制的项目要求的版权转让政策的情况下。对该主题的最佳考察仍然是 Michael Meeks 的文章 “关于版权转让的一些想法”。值得注意的是，Canonical 在因其自身的版权转让协议而受到广泛的社区批评几个月后宣布了 Harmony 项目。
约束的幻觉
Harmony 选择遵循并因此使最大化主义方法合法化，但以一种我担心可能会引起混乱的新方式。使用 Harmony 的项目必须首先决定是要求贡献者转让版权还是最大限度地广泛授予入站版权许可；没有其他选择。然后，项目应从一组五个互斥的条件中选择贡献中分配或许可的内容如何由项目向下游许可。
五个选项中的每一个都允许项目使用贡献提交日期时的出站项目许可证，但这通常是项目无论如何都会做的事情。（这与入站=出站不同，因为 Harmony 下的许可方是入站项目实体，而不是贡献者。）五个选项中的四个为项目提供了使用现有项目许可证的替代方案。在这四种情况中的一种情况下，替代方案是不受限制的，明确允许项目实体选择任何许可证，无论是自由许可证还是专有许可证。（项目做出象征性的承诺，要“额外地”根据现有项目许可证许可贡献。）其余三个选项下的替代方案包括项目指定的许可证列表、任何 OSI 批准的许可证以及任何 FSF 推荐的著作权保留许可证。
关于这些出站许可选项，值得注意的是，它们没有意义，除非在选项仅承诺项目实体在出站方面使用著作权保留许可证的情况下。这种情况只会发生在现有出站许可证是著作权保留许可证并且，如果项目可以选择替代许可证，则替代方案要么是仅由著作权保留许可证组成的列表，要么是“FSF 推荐的著作权保留”类别的情况下。在所有其他情况下，出站条件本质上是名义上的。那是因为，即使未选择“不受限制”选项，项目始终可以根据非著作权保留 FLOSS 许可证许可贡献，根据定义，这将不对代码的使用施加任何出站许可约束，包括项目实体本身的使用。
我不是在质疑宽松许可的合法性；事实上，我一直鼓励 Red Hat 开发人员使用标准的非著作权保留许可证。令我担忧的是，Harmony 煞费苦心地给人一种约束出站许可的表象，但实际上只有在一种特殊（且可能罕见）的情况下才会如此。
举一个简单的例子，假设一家公司启动了一个新的 GPL 许可的项目，并要求贡献者签署 Harmony 版权转让协议，并选择了“仅限 OSI 批准的许可证”出站选项。然后，该公司完全可以自由地根据例如（OSI 批准的）3 条款 BSD 许可证许可所有贡献，而这反过来又不会阻止该公司根据专有的闭源许可证私下许可项目代码，包括贡献。这不是什么新鲜的场景，但 Harmony 添加的是约束的幻觉，我担心这可能会误导那些对开源许可相对不熟悉的贡献者。
Harmony 和 GPL 的可执行性
我已经暗示，Harmony 对出站许可的约束表象只有在项目同意仅根据像 GPL 这样的著作权保留许可证许可贡献时才是真实的。但即使在这种情况下，最大化主义模型仍然存在，就像在所有其他 Harmony 排列中一样。通过将版权转让给项目实体，或授予其尽可能广泛的版权许可，Harmony 协议贡献者放弃了所有监管从项目下游使用贡献的权利。这是与历史悠久的入站=出站传统的最大决裂：贡献者完全与项目代码的下游用户断绝了任何真正的法律关系。相反，贡献者只剩下针对项目实体的索赔，如果它违反了授予条件。
这足够好吗？也许对于某些贡献者来说，在某些情况下是这样。但是，如果贡献者关心下游对 GPL 的遵守情况，如果项目实体不努力执行这种遵守情况，贡献者将无能为力。贡献者的期望将无法实现，但贡献者将无能为力。Harmony 没有创造这个问题；它在 GPL 项目对最大化主义模型的所有现有使用中都是固有的。但是，面向 GPL 的贡献者不应假定具有 GPL 出站约束的 Harmony 协议会满足他们的政策目标。
我将在本文的 第二部分 中继续我对 Harmony 的批评。
22 条评论