在开源许可协议下提供代码

2014-09-25 08:42:31       1553    原创
摘要:发布者:Ross Gardler, Elizabeth Tatham, Amir Nettler  日期:2009-09-21  最近更新:2013-05-09 将您的代码作为开放源码提供,仅在项目网页上表明代码根据某个开源许可协议下授权许可,是远远不够的。您不仅需要为人们提供项目代码的下载和/或回馈项目的方法,还需要选择最适当的许可协议,并说明其他法律要求。其中一个最重要的是,您必须能够证明,该代码能在其许可协议下合法发布。另一个就是,您还必须告知代码下载者,他们对项目所有者应付的责任。

本文强调了希望发布开源代码的项目所面临的主要法律问题。但是,一个开源项目想要成功,同样重要的一点是要考虑长期可持续性发展的现实模型,其中很大一部分就是吸引用户和开发群。这些问题不属于本文的讨论范围。


选择许可协议

许可协议规定了第三方在其自己的产品中更改或再使用开源软件时需要承担的责任,因此,选择适当的许可协议,是确保项目所有者依照其选择方式维持项目的关键。我们首先建议您选择开放源代码促进会(OSI)批准的许可协议。对此我们有充分的理由,但是最有说服力的是,如果选择 OSI 许可协议,潜在用户和参与者很可能对您选择的许可协议条款已经非常熟悉。使用不出名的许可协议或者您自己编写的许可协议,就没有这一优势。

可选的 OSI 批准许可协议范围很广。哪项许可协议适用于特定项目,取决于软件的未来计划。更多信息,请查看我们的简报《我应该选择哪种许可协议?》。

另一种使您代码获利的方法是双许可,即以一个强大的“创意著佐权” (Copyleft) 许可协议(如 GNU GPL)发布您的软件,同时在另一个许可协议下发布一个版本,进而允许不想被 GNU GPL 绑定的用户购买非“著佐权” (Copyleft) 。通常,他们这样做的原因,是希望基于代码创建产品,但又不想其受制于“著佐权” (Copyleft) 许可协议。这个模型附带产生的额外管理费用对您来说是否物有所值,取决于您认为客户在多大程度上愿意为创作非“著佐权” (Copyleft) 演绎产品支付费用。请您记住,为了额外提供一个非“著佐权” (Copyleft) 许可协议,您必须与所有参与者达成协议,或者独立拥有代码的所有版权。

选择适当的许可协议是一个复杂的过程。OSS Watch 可帮助您,给您提供许可协议咨询;请联系我们获取更多信息。

有关软件许可必要性的更详尽讨论,请查看我们的简报《开源开发 – 所有权与许可问题介绍》。


许可非软件作品

很重要的一点要记住,自由和开源许可协议是为软件代码而设计的。如果您的项目包括非软件作品,例如图像、声音、文档或数据库,那么有更合适的许可协议专门为其量身定制。对于图像、声音和文档,考虑使用知识公共创意(Creative Commons)许可协议。对于数据库,它同时受到版权和独立的数据库权的保护,可以尝试使用开放数据库许可协议


知识产权

一旦您选择了最适合的 OSI 批准许可协议发布代码,您需要确保您有这样做的法律资格。如能证明,所有代码是您专有的知识产权,您拥有授权许可的所有必要权利;此外,对您的代码进行持续审查,以确保处于上述合法状态。

小项目通常比较简单,因为了解所有参与者以及他们的雇佣情况。只要所有参与者受雇于版权持有人,并且他们的合同不允许他们持有对自己工作成果的版权,只要所有参与者愿意确认他们的工作成果是原创的,而不是复制了其他项目,那么可以肯定的说,所有的知识产权属于版权持有人。

但是,较大的项目会比较复杂,因为有部分参与者可能不是版权持有人的雇员。例如,如果您雇佣承包商从事某项开发工作,您可能无法享有其工作成果的版权。类似地,如果有人捐献了代码或者其代码被复制,他可能并未明确授予版权清算。如果您不能证明自己拥有代码的所有版权就将其发布为开源代码,不仅有悖道德,而且可能面临法律诉讼。

有关该问题的更多信息,请查看《您能为开源项目贡献代码吗?》。该文讨论贡献代码给第三方项目,同时涉及希望在开源许可协议下发布代码的现有项目。


持续审核

核您的知识产权是一项持续的任务。将代码评审和版本控制的工具落到实处,有助于您在贡献代码的同时进行有效的审核,并节省定期审核的开销。贡献代码时持续审核,可以确保将意外损害代码发布的可能性降到最小;同时在项目启动期,第三方还未对您的代码产生兴趣时,建立这一流程会简单的多。我们的文档《代码贡献者许可协议》对此有进一步讨论。

在项目初期建立审核流程并启动相关支持工具,也确保了对来自项目团队的所有代码贡献的审核跟踪。在各种所有权争议中,这种审核跟踪是至关重要的。有关使用版本控制,将其作为知识产权跟踪工具,请查看我们的简报《什么是版本控制?尽职调查为何重要?》。


应用许可协议

一旦您选择了希望使用的许可协议,并确认您拥有许可项目中所有代码的法律资格,您必须应用该许可协议,以便人们查看。只是简单声明在特定的许可协议下可以获取您的代码是不够的,您还需要保证在所有适当位置显著地标示出来。至少,您必须做到以下事项:

•在您的网站上声明应用的许可协议(最好在您的首页和下载页上)

•在您的网站上提供许可协议的全文

•在您源项目的根目录下提供许可协议的全文(通常在“LICENSE.TXT”文件中)

•在源散布的每个文件头提供样本通知(使用的样本正文根据许可协议的不同而变化。您通常能在许可协议的原出处找到有关如何应用该协议的相关讨论。)

•在您的非源项目散布的根目录中提供许可协议的全文(通常在“LICENSE.TXT”文件中)

有工具可帮助您将许可协议应用到源文件。关于工具的帮助信息及其他代码审计练习,请联系 OSS Watch


满足从属关系的要求

如果您的代码包含其他项目的库,确保符合该项目的许可协议要求就非常重要。首先要考虑被捆绑的代码是否授权在一项兼容的许可协议下。这是一个复杂的问题,不属于本文的讨论范围。如果您需要帮助,请联系我们。但是,对于捆绑许可协议的归属申明和通知就相对比较容易,因而在本文范围之内。

不同的许可协议要求不同的归属申明,当然有些则根本不需要。最好的办法是一视同仁,因为比要求更多的归属申明,通常不是问题。最常见的是在根目录中包含“NOTICE.txt”文件,声明有关所使用许可协议和捆绑库的重要信息。例如,下文即是 Apache Forrest 项目中“NOTICE.txt”文件的部分内容:

Apache Forrest 版权所有 2002-2009。Apache 软件基金会。本产品包含 Apache 软件基金会(http://www.apache.org/)开发的软件。请查看文件“LICENSE.txt”。本“NOTICE.txt”文件旨在包含版权所有者及其许可协议所需的各项申明。部分附属产品带有归属申明要求,请查看下文。其他附属产品不要求归属申明,故未在下文列出。本产品包含 OpenSymphony Group(http://www.opensymphony.com/)开发的软件。本产品包含为 Krysalis(http://www.krysalis.org/)项目开发的软件。[等……]

需要注意的是,有一项许可协议——普通公共属性许可协议 (Common Public Attribution License),它对归属申明有特定的要求。这在我们的文档《普通公共属性许可协议 – 概述》中有详细说明。

除了对被捆绑的代码授信之外,还需要包含项目发布的所有代码的完整许可协议。同样,对此并没有固定的方法,但是最常见的是将许可协议包含在与库相同的目录中。使用这种方法时,许可文件要重新命名明确指出它所应用到的库。因此,例如项目捆绑了“jtidy-04aug2000r7-dev.jar”库,与该库在同样位置保存的“jtidy-04aug2000r7-dev.jar.license.txt ”文件中,应包含该库的许可协议。使用完全相同的文件名是非常重要的,这样您便可以轻松地找到文件,同时在更新库时也可提醒开发者查看使用正确的许可协议。


提供代码

将您的代码作为开源代码提供,仅仅应用许可协议是不够的。您还必须允许人们从一个合适的发布点下载获取代码,例如您的网站或者 Google Code、SourceForge 等项目托管网站,切记要包含您在项目中使用的任何其他开源部件的源代码。虽然从法律角度上看已经足够,您需要更进一步,围绕您的项目构建一个参与者和用户群。这种方法叫做开放开发方法,它也是 OSS Watch 能够提供帮助的一个领域。


总结

将代码作为开源代码提供前,首要考虑的法律问题总结如下:

•您对许可协议的选择,取决于您对代码的未来使用规划。推荐使用 OSI 批准的许可协议。

•OSI 批准许可协议分为三大类:著佐权(Copyleft),获准 (Permissive),以及部分著佐权 (Partial Copyleft) 。

•在贡献代码的同时进行持续审核是至关重要的,因为您需要证明您享有绝对的知识产权。

•许可协议必须在所有适当位置显著地标示出来。

•必须确保可从合适的发布点下载获取代码,如 GithubGoogle CodeSourceforge


延伸阅读

链接:

•开源许可:软件自由与知识产权法,作者 Lawrence Rosen [http://rosenlaw.com/oslbook.htm]

•了解开源与自由软件许可,作者 Andrew M. St. Laurent [http://oreilly.com/catalog/osfreesoft/book/]

•开源治理最佳实践:了解企业中的开源许可协议义务(要求注册)[http://www.openlogic.com/resources-library/?Tag=Webinars]

•开放源代码促进会 [http://www.opensource.org/]

•自由软件基金会 [http://www.fsf.org/]

•对重复使用 BSD 许可软件以增强 Linux 无线网络功能的争议 [http://kerneltrap.org/mailarchive/linux-kernel/2007/9/16/261061]

•在 GPL 许可项目中维护获准许可文件:开发者指导方针,出自软件自由法律中心 [http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html]

•评审委员会:代码评审的辅助工具 [http://code.google.com/p/reviewboard/]

•公共创意(Creative Commons)[http://creativecommons.org/]

•开放数据库许可协议 [http://opendatacommons.org/licenses/]


本文由 OSS Watch 原创并经由Creative Commons Attribution-ShareAlike 2.0 England & Wales license许可证发布。


沪ICP备15046442号
蝉知1.6