Skip to main content

《贡献者许可协议》是“人魔”般的怪物? | Linux 中国


当我开启作为开源律师的职业生涯时,面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增,正如我的同事 Scott Peterson 在其文章中所述,“开源许可协议是共享资源[1]”:
专注于少数许可协议更有好处。通过对少数许可协议达成更广泛共识所积累的经验和讨论更容易减少不确定性,而不是在成千上百的许可协议之间进行有关行动和辩论。
过去多年开源社区对许可协议扩散的反应持积极态度,我很高兴看到大多数开源项目都从一组被工程师和律师熟知的许可协议(例如 GPL、LGPL、AGPL、BSD、MIT、Apache 2)中进行选择。因此,不用将时间浪费在解释许可协议条款上,完全开启了一个低摩擦的生态系统。
一旦项目采用开源许可协议,它通常采用标准的“入站=出站inbound=outbound”模式,创造该短语的 Richard Fontana 将其描述为贡献者不言自明地获得出站项目适用的许可协议的许可,使得贡献者可以轻松参与项目,无需担心繁文缛节和受到威胁[2]。这是一个非常简单的模式,能够非常聪明地进行上面提到的许可协议选择。
不幸的是,许多项目不选择采用“入站=出站”模式,而是采用某种形式的《贡献者许可协议Contributor License Agreement》(CLA)。CLA 的范围和目的各不相同。读者们可以在 Ben Cotton 的文章《CLA 与 DCO 有什么不同?[3]》中具体了解《贡献者许可协议》与《开发者原创证书Developer Certificates of Origin》(DCO)的区别。
采用 CLA 的项目在接受贡献之前,要求贡献者提交作为个人或所在公司签署的 CLA 存档。除非是其条款能够被工程师和其代理律师很好理解的标准 CLA(例如下文提到的 Apache 软件基金会非实质性定制的 CLA),否则因为需要非常仔细阅读 CLA 以确保能够完全理解其条款,贡献者通常放弃去深究 CLA。理解非标准 CLA 的过程需要数天或上周才能完成,具体取决于工作负荷以及是否需要与许可协议提交人进行协商。根据我的经验,最终结果是回到标准的 CLA 条款!这个曲折的过程导致大量的时间和精力被浪费。此外,CLA 需要某种形式的签名,增添了许多在大型官僚组织可能更严重的延迟性和复杂性。这并不是一条令人开心的路径,对开源/协作开发模式具有高度侵蚀性。
请注意,当我提到“标准 CLA”时,我所指的是基于众所周知 CLA(例如 Apache 软件基金会个人或企业 CLA)的 CLA。虽然 Apache 软件基金会的 CLA 由基金会本身以其原始形式使用,但它们通常被以非实质性方式进行修改以供其他组织使用。例如,大多数组织在开始时都小心翼翼地摆脱了许可协议的慈善使命,还定制了许可协议名称。Apache 软件基金会这类非实质性变体需要与本文中描述的类似“人魔”怪物的变体区分开。
我对最近 CLA 数量的激增表示担忧,我们似乎正在经历十年前在开源许可协议扩散方面遇到的相同现象。事实上,在过去的一年里,在我的办公桌上至少看到 20 种不同的 CLA,它们与常见的 Apache 软件基金会个人或企业 CLA 存在细微但实质性的偏差。这些偏差通常小到无助于澄清条款语言或权利,但其中有些偏差会比较大,这种混合的可憎之物让我想起了 Moreau 博士通过他的活体解剖过程创造的新动物(参见维基百科上的《冲出人魔岛[4]》)。无论偏差是小还是大,它们造成的影响可能很大,经常导致混淆、更多的审查时间以及谈判。
例如,律师普遍接受的做法是对许可协议或合同中的术语使用初始定义。无意中使用同一术语的小写形式会导致是否应该使用该术语在标准/字典中定义或协议中更窄或更宽泛定义的模糊性。尽管这对于不经意的观察者来说似乎是一个微不足道的偏差,但这通常会导致许可协议接收/授予的权限显著减少或扩大,或者导致不可接受的歧义。其他偏差起草得如此之差,以至于它们的意义不明确,因此必须彻底拒绝。
在最近的例子中,有一种 CLA 的专利许可语言以令人困惑的方式将术语“衍生作品”derivative works包括在内,偏离了 Apache 软件基金会 CLA 版本。此 CLA 授予专利许可的范围似乎过于宽泛且可能无限制,它是如此模糊,以至于我被迫拒绝使用它。我不确定这是否是这个特定 CLA 的起草人所预期的结果,但是这次审查花费了大量的时间和成本,最终限制了我们的工程师为该项目做出贡献。这是一个令人伤心的结果,没有人从中受益。
作为一个社区,让我们从之前关于开源许可协议扩散的错误中吸取教训,采用“入站=出站”模式,最好使用 DCO[5] 而不是 CLA。如果您选择使用 CLA,那么强烈建议使用 Apache 软件基金会个人或企业 CLA 等标准 CLA,而不是创建新的、幻想的或荒谬的类似“人魔”怪物的许可协议。

作者简介:Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 Red Hat 公司的开源知识产权律师,还担任托马斯杰斐逊法学院Thomas Jefferson School of Law的兼职教授。在任职 Red Hat 之前,Jeffrey 曾担任高通公司Qualcomm Incorporated的专利顾问,为首席科学家办公室Office of the Chief Scientist提供开源事务咨询。

Comments

Popular posts from this blog

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checking a shared sec

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into /opt/course/1/context_default_no_kubectl.sh , but without the use of k

标 题: 关于Daniel Guo 律师

发信人: q123452017 (水天一色), 信区: I140 标  题: 关于Daniel Guo 律师 关键字: Daniel Guo 发信站: BBS 未名空间站 (Thu Apr 26 02:11:35 2018, 美东) 这些是lz根据亲身经历在 Immigration版上发的帖以及一些关于Daniel Guo 律师的回 帖,希望大家不要被一些马甲帖广告帖所骗,慎重考虑选择律师。 WG 和Guo两家律师对比 1. fully refund的合约上的区别 wegreened家是case不过只要第二次没有file就可以fully refund。郭家是要两次case 没过才给refund,而且只要第二次pl draft好律师就可以不退任何律师费。 2. 回信速度 wegreened家一般24小时内回信。郭律师是在可以快速回复的时候才回复很快,对于需 要时间回复或者是不愿意给出确切答复的时候就回复的比较慢。 比如:lz问过郭律师他们律所在nsc区域最近eb1a的通过率,大家也知道nsc现在杀手如 云,但是郭律师过了两天只回复说让秘书update最近的case然后去网页上查,但是上面 并没有写明tsc还是nsc。 lz还问过郭律师关于准备ps (他要求的文件)的一些问题,模版上有的东西不是很清 楚,但是他一般就是把模版上的东西再copy一遍发过来。 3. 材料区别 (推荐信) 因为我只收到郭律师写的推荐信,所以可以比下两家推荐信 wegreened家推荐信写的比较长,而且每封推荐信会用不同的语气和风格,会包含lz写 的research summary里面的某个方面 郭家四封推荐信都是一个格式,一种语气,连地址,信的称呼都是一样的,怎么看四封 推荐信都是同一个人写出来的。套路基本都是第一段目的,第二段介绍推荐人,第三段 某篇或几篇文章的abstract,最后结论 4. 前期材料准备 wegreened家要按照他们的模版准备一个十几页的research summary。 郭律师在签约之前说的是只需要准备五页左右的summary,但是在lz签完约收到推荐信 ,郭律师又发来一个很长的ps要lz自己填,而且和pl的格式基本差不多。 总结下来,申请自己上心最重要。但是如果选律师,lz更倾向于wegreened,