如何选择开源许可协议

来源：互联网发布：金融大数据 pdf 陈云编辑：程序博客网时间：2024/05/16 10:15

http://blog.jobbole.com/44175/

http://blog.jobbole.com/44184/

http://blog.jobbole.com/37493/

了解开源许可协议

选择代码托管平台

版权权利问题

一、了解开源许可协议

目前国内开源项目正在逐渐升温，中国也开始有不少优秀的开源项目突显出来。在大家摩拳擦掌准备加入开源大军时，也要知道这个圈子里的规则。技术人员不能只是研究技术，任何圈子都有规则，要知道了才能玩得好。前段时间有件关于开源软件的事情挺热闹的，关于国内一个开发者把自己作品开源出来被别的公司的人拿去包装成自己的产品高价卖出去。大部分做开源软件的开发者都不太怎么关注版权这些，具体微博如下：

hoowa_sun：
做开源后，发现大部分都被别人拿去学习，然后copy，然后自己闭源卖出去。这里不缺乏大公司，有一家公司拿我的开源系统修改后卖给了一个国内的运营商，卖的还非常贵至少几十万一套。所以我郑重的建议大家，做软件还是要英文版开源，中文版封闭不要开源。

在国内大家习惯了使用盗版、破解，看到这种免费的软件也觉得是理所当然的拿来主义，甚至直接封装到自己的商业组件卖出去。如果你正在这样做，马上停下来研究一下使用的这些开源组件的许可协议，不然某一天你会意外收到一封法院的传票。如果你在开发或者准备开发开源软件，但尚对开源许可协议不了解，也看下这篇文章，选择一种开源许可协议保护你的开源软件。

常见的开源许可协议有：GPL、LGPL、BSD、Apache Licence vesion 2.0、MIT。这些协议有什么区别呢？

GPL，全称 GNU General Public License。它的主要内容为：只要在一个软件中使用(“使用”指类库引用或者修改后的代码) GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这个协议就不太适合商用软件，或者准备使用GPL开源组件的商用项目。基于这个协议的项目，极大的提高了开源软件的数量。上面那个微博的案例，如果作者使用了GPL协议，而使用方没有公开源代码就是违反了协议。目前用的多的是GPLV1，GPLV2。这两个什么区别看后面那张树形图。采用这个协议的开源软件有：Linux、 MySQL.

LGPL，最初是Library GPL的缩写，后来改称作Lesser GPL。由于GPL太严格，限制了很多商用软件使用GPL组件才推出了这个LGPL。LGPL允许商业软件通过引用类库的方式使用LGPL组件（不直接使用源代码），这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码，则涉及修改部分的代码和基于原来代码衍生的代码都必须采用LGPL协议。LGPL不适合以LGPL协议为基础的代码进行二次开发的商业软件，但是商用软件可以采用编译后的类库引用就不需要公开源代码了。采用这个协议的开源软件有： JBoss、 FCKeditor 、 Hibernate。之前extjs就因为从LGPL转换到GPL带来了不少的震动。详情点击。

BSD，全称 Berkeley Software Distribution。这个协议相对上面两个协议宽松很多，允许使用者修改和重新发布代码，也允许使用或在BSD代码基础上开发商业软件发布和销售，因此是适用于商业软件的。使用者别太高兴，使用时还必须做到满足三个条件：

1）如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。适用BSD协议的开源软件有： nginx、CruiseControl、Redis。

apache Licence vesion 2.0，这个协议除了为用户提供版权许可之外，还有专利许可。与BSD协议权限类似，允许代码修改，再发布，适用商业软件。但是也需要满足以下条件：

1）需要给代码的用户一份Apache Licence。
2）如果你修改了代码，需要再被修改的文件中说明。
3）在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4）如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

除了这些条件它还有这些好处：

1）永久权利一旦被授权，永久拥有。
2）全球范围的权利在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
3）授权免费无版税，前期、后期均无任何费用。
4）授权无排他性任何人都可以获得授权
5）授权不可撤消一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码

使用apache Licence vesion 2.0协议的开源软件有：Hadoop 、apache httpserver、Spring Framework、MongoDB 。

MIT，源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。

列出了常用协议，还有一些比较常用的大家就谷歌了，比如： Mozilla Public License、Creative Commons、Eclipse Public License 1.0等。

有一篇博客的树形图很好阐述了当前主流许可协议的区别。

另附一张目前github上项目采用的许可协议比例图：

二、选择代码托管平台

通过《如何选择开源许可协议（一）：了解协议》大概知道了有哪些开源协议和各个协议的作用和区别。我们准备把代码开放出去时，需要了解各个代码托管平台如何设置开源协议。目前常用的平台有：googlecode、github、sourceforge、codeplex。下面分别列一下这些平台如何设置开源协议：

1、googlecode，google推出的代码托管平台，整体可用还是比较强的，如果不是经常被墙用这个也可以。支持svn、git协议。要在这个上面共享代码，

首先需要注册一个google账号，登录。
在url输入 http://code.google.com/intl/zh-CN/ ，打开网页后，最下方有个 create a new project。

点击创建工程后，可以选择自己工程的开源协议。预定义协议支持不是太多，主要有常见的BSD、GPL、MIT、APACHE、ECLIPSE、MPL。没有包含的可以选择other open source 填写。

2、github，这个后期之秀，由于git协议本身的优势这几年也赚足了眼球。更有2011年的报道： Github 的提交次数超过了Sourceforge、Google Code和微软的CodePlex。这么火的代码托管工具我们当然也要在这个上面共享代码，

需要注册一个github账号，登录。
在首页中间有个 create repositories，创建代码工程。和google code 不同的是，github没有直接选择开源协议这一项。这篇文章可以看得出GitHub一族，正在推动开源软件走向无授权时代。如果要在github设置开源协议如何设置呢？其实很简单，在刚创建的工程主页，点击添加文件按钮。
新建一个文件LICENSE（这个命名随意，只要能说明清楚就行），把你需要设置的协议内容复制到对应的文件中去就可以了。当然你想特别说明一下，也可以在项目主页的readme.txt中说明。比如 https://github.com/apache/activemq 的license 设置。
这个license可以根据自己需要设置，不过最好还是标准模板大家更规范一些。
刚写完github没法设置，今天登录却发现github已经增加了开源协议选项，csdn也有了相关的新闻《Github 终于开始认真考虑开源项目许可证了》。看来任何地方都还是需要规范化，毕竟开源本身就是一个社会群体活动，有了大家的积极参与才能长久持续下去。
ps：托管Git （开源或闭源）项目的网站闭源需要收费，最低7$/月起，另有免费的300G空间，超过也要单独收费，不过作为咋普通开源项目也足够了。
3、sourceforge，曾经很辉煌的全球最大开放源代码软件开发平台和仓库，现在虽然有github这样的竞争者追赶，但依然还是老大。它有这些优势：无带宽限制、提供下载统计分析、每天巨大的流量增加你的文件的曝光率、SourceForge 在开源领域可信度高、支持svn和git协议。
- 注册登录到sourceforge。
- 创建project。sourceforge的创建project隐藏的有点深。在登录后的右上角有个me，旁边小三角点击弹出层选中Account。

然后在account页选中projects tab，右边有个 Register a New Project超链接，点击就可以创建项目了。

设置开源协议，点击项目进入项目主页，选择admin tab =》左侧导航Categoryization =》页面 license。

sourceforge的协议支持非常多，有开源协议控的可以多看看，不得不说这个界面操作还是有点复杂。

4、codeplex。最后再看看微软的这个代码托管工具。打开页面设计的还比较直接，显示了几个大按钮，可以很容易就点击到。看到首页界面不知道设置开原协议如何操作？是不是像界面这几个按钮一样简单。

登录codeplex，可以使用微软账号登录。
创建项目，在项目创建页依然没有协议设置，只有googlecode有。
点击创建的project，进入project的设置页面，选择 license tab，点击 tab下方右边一点的 change license链接后找到自己需要的协议设置。它支持的协议和google code差不多，多了微软协议和CDDL。比较了目前最常见的集中开源项目托管平台对开源协议的支持和如何操作，大家按自己需求选择吧。

三、版权权利问题

写开源软件之前请先确认你知道你的版权权利

2013/04/03 · 开发 · 开源, 版权

分享到：5

PHP第三方登录—OAuth2.0协议
JSP常用标签
如何使用iOS SDK进行基于LBS的开发
iOS基础教程之界面初体验

英文原文：Writing Open Source Software? Make Sure You Know Your Copyright Rights、编译：oschina

写开源软件之前请先确认你知道你的版权权利

开源软件再好不过了，但是在将自己的精力和无数代码投入一个项目之前，请确保你准确理解了你的代码的版权将发生什么变化——以及你的职业生涯将发生什么变化。

我知道。如果想成为律师，你会去法学院，而不是整夜钻研K&R。然而，在2013年，如果你是一个开源程序员，你需要知道版权法相关的一些事情。如果不这样做，会发生不好的事情——非常不好的事情。

在开始这个话题之前，我必须指出，我不是一个律师（IANAL）。如果你有一个具体的实际问题，找一个律师谈谈。找一个精通版权法的律师。

每当你写代码，就在创造有版权的成果。当我问到关于版权的陷阱时，正如OSI（开源软件促进会）主席Simon Phipps所说，“最大的一个是年轻开发者完全回避版权证书的趋势。当他们这么做时，就将为所有合作者增加风险，当然自身也面临潜在的赔偿责任。”

开发者需要知道版权是自动受伯尼尔公约保护的，Phipps解释道。自从这个公司付诸实施后，所有软件开发都涉及到拷贝和其他版权相关的活动，Phipps说到，所有没有被许可的开发工作都潜在地侵犯了版权。“或许现在没有造成麻烦，但没有永久的版权许可将会对合作者造成永久的危害”。

“你可以假装你需要的版权不存在，但将来它会反咬你一口，” Phipps接着说道，“这就是为什么[如果你开始一个新项目]你需要申请一个开源授权许可”。如果你想要公共域，请使用MIT许可，它很简单，并能保护你和你的合作者免受这些危害。如果你真的在意，请使用现在专利保护许可，像Apache,MPLv2,或者GPLv3，请确保你得到其中一个许可。

谁拥有那些雇佣工作的代码？可能是你哦

你应该知道当你拥有版权时，你的老板或者咨询客户也拥有这份版权。如果你写的代码属于你老板，归根到底，它不是属于你的。如果它不是你的，那么你就没有权利去给开源项目授权。所以我们这样假设，雇佣或自由职业都自动地属于雇佣行为。

比如，你在工作之余正在开发的那个小项目，完全属于你自己吗？或许属于你，但就像Daniel A.Tysver,一个Beck & Tysver的合伙人，在BitLaw写到：

当招聘程序员时，软件开发商应该密切关注版权所有权问题。在大多数情况下，如果项目是付了薪水的员工做的，那么这个项目就属于雇佣行为下的项目。所以，软件开发商就会认为，这个被员工开发的软件的作者和所有权就理所应当的属于开发商。不过精明的开发商会让程序员签署一份协议，让他们同意授权他们开发出的软件给开发商。开发商这么谨慎是因为决定一个员工是不是合法需要分析很多因素，并且在极个别情况下会引起意想不到的结果。另外，雇佣期间的工作需要在员工在雇佣期间完成。通常，程序员开发的项目都会在雇佣期间完成，但这也是一个模糊的概念，我们最好不做以此做条件。

如果你是一个自由职业者，并且你在雇佣期间编程序，那么即使那些代码也是开源软件的一部分，你的客户也拥有你写的代码的版权吗？实际上，这不好确定。

Tysver接着说道：

当招聘一个程序员时，软件开发商必须十分谨慎。为了确定员工所做的项目属于雇佣期间，必须考虑3个因素：项目必须是事先计划好或者指派的；招聘程序员的合同必须有员工签字，而且必须在明确指出在双方都同意的情况下，员工做的项目是雇佣期间的工作；开发的项目必须属于9个类别中的一个。当一个程序员被招聘来开发一个具体的项目的时候，第一个条件就已经成立了。第二个条件可以通过仔细地制定程序员的合同来解决。然而，第三个条件就比较复杂了。软件工程不属于9个类别中的一个，最好的赌注就是使软件项目符合“视听作品”的定义。虽然有些软件项目很明显属于视听作品，但让法官认为所有的软件项目都属于这一概念是不可能的，因此，软件开发商不能肯定签合同的程序员做的项目属于雇佣期间的工作。最好的方法是签订一份协议来解决这个不确定性。协议中应明确员工做的项目是雇佣期间的工作，也应该明确指出，即使项目不属于雇佣期间的工作，程序员也应该同意把该项目授权给软件开发商。最后，当雇佣一个公司来提供程序员签约服务时，一定得确认程序员把版权的所有者交给了软件开发商，所以软件开发商不仅审查提供签约服务公司的合约，也得审查和程序员签约的协议。

他说的是你签署的雇佣工作合同并不能说明谁会得到代码的版权，也就是意味着你可能仍然拥有版权吗？好吧，是的，事实上他是这个意思。如果你仔细看一下U.S. 版权法 (PDF)，你会发现有九种被描述为“雇佣作品”(WMFH)的作品。它们没有一个是程序代码。

因此，像一个作者在 Law-Forums.org写的，以morcan的笔名，“计算机程序没有逐渐落入委托条件下的WMFH法定类别，因此，应该简单的称它为未被法规确认的。”

他（或她）继续道，“因此，你当然可以有一个书面的WMFH协议（无论什么它很值得），明确的概述双方的意向，就是你是委托工作的‘版权的作者与所有者’，但对所有权力，题名，和在该项目下所创立工作的任何所有部分的承包人的版权利益，你仍然需要一个（单独的）转让与让渡，这一点从在WMFH中他或她是作者中自然显现出来。”用其他话来说，如果在你的合同中没有一个“版权所有权的转移”条款，是你这个程序员，而不是给你这个合同的公司，可能仍然具有版权。

写开源软件之前请先确认你知道你的版权权利

那会导致真正的麻烦。“我确实看到过重要企业的并购被破坏，由于一些目标软件公司的人员，具有雇佣作品(WMFH)协议下的‘合同程序员’身份,使并购不能获得必要的关于签约版权的书面转让。”morcan补充道。

Rich Santalesa,信息法律组织的高级法律顾问，同意morcan的看法。“可能发生的事情是，谨慎的（也就是说：可靠的）软件/版权律师用一种带子与吊带裤的方法，将’在所有方面适用的’一个’雇佣作品’字样加到开发协议当中——结果实际上，美国国税局(IRS)或者一些其他税收主体也会说’不,那个人是一个雇员,不是一个独立的签约者’”Santalesa说。协议也包括了一个一旦执行将立即有效的转让与让渡条款。

“无论何时何地，我们[代表工作缔约方的版权律师]总试图针对雇佣情况做一点工作，“Santalesa解释道。”因此由于版权的目的，作者/程序员不再是‘法定作者’。而且在出炉的合同中最终证据方面，常常在特定事实问题上，它可能会很棘手。“

我陈述所有这些的意思是，你应该试着确定，你和与你签署合同的公司应具有一份法律合约，从字面上明确任何自定义代码的版权会怎样处理。如果只是简单的说一些东西是雇佣作品，这将不符合要求。

现在，加入开源贡献

这些关注点同样适用于开源项目。大多数项目具有某种版权转让协议（CAAs）或版权许可协议（CLAs），你必须在你写的代码提交到项目之前签署。在CAAs，你转让你的版权给一个公司或组织；在CLAs，你将一个广泛的使用你的代码的许可给予该团体。

虽然一些开源组织认为，例如Bradley Kuhn的软件自由保护组织，不要其中任何一个开源软件的版权许可，几乎所有的项目都有它们。

而且它们会经常带来麻烦。

举个例子，最近的一个关于版权的烦恼，是在GnuTLS项目中，那是一个SSL(安全套接层)协议的免费的软件实现。该项目的创立者，它的两个主要作者之一，Nikos Mavrogiannopoulos在2012年12月宣布他在移动该项目到GNU项目的基础设施之外，这是因为对自由软件基金会(FSF)的决策与实践的一个主要的分歧。“我不再认为GnuTLS是一个GNU项目，”他写道，“而且未来的贡献没有必要在FSF的版权下。”

Richard M. Stallman，GNU与FSF的创立者，对此完全不认同！在一封题为GNUTLS不会去任何地方的电子邮件中，Stallman, a.k.a. RMS回复道，“你不能将GNUTLS带出GNU项目。你无法为GNU包指定一个非GNU程序做一个替代。我们将继续GNUTLS的开发。”

你看，当你创建一个GNU项目而没有转让版权给FSF时，FSF将不会在GPL下保护该项目的著作权(IP)，除非你做了转让。并且，回溯到项目开始的时候，Mavrogiannopoulos完成了版权转让。此外，如RMS指出，不管你在世界的何方，如果你选择了这条途径，版权将给予U.S. FSF ，而不是它的姐妹组织。

在许多激烈的争论以后，这个特别的冲突开始安静下来。Mavrogiannopoulos现在希望他曾做出的是一个不同的决定。“我非常后悔转让所有权利给FSF，但看起来我没有什么能去做来使之改变的。”他可以建立代码分支，但不能在项目的名字里加上他，因为那是版权的一部分。

听上去好像那已经离作为一个开源开发者至少需要知道的版权的东西越来越远，但请再忍一会儿。因为它引起了几个麻烦的问题，像Michael Kerrisk, 一个LWN.net 作者说的，“这些问题的第一个已经在上面显示了：谁拥有该项目？ GnuTLS项目是由Nikos作为一个GNU项目诚意的发起的。在该项目的生命周期中，最主要的贡献到项目中的代码是由两个个人写的，现在他们都（推测的）想离开GNU项目。如果该项目是被独立开发的，那么显然 Nikos 和 Simon将被认为拥有该项目的代码与名字。然而，转让版权给FSF时，他们就放弃了他们自己的权利 ”

然而还有更多麻烦。像Kerrisk指出的，“FSF的能耐——作为唯一的版权持有者——控告违背授权者是被当作一个主要的版权转让的优势来招揽顾客。但是，如果由于某一个或另一个原因，FSF选择了不履行它的权利呢？”那么从转让他或她的版权，程序员能得到什么好处呢？

最后，Kerrisk补充说，对企业与非赢利组织，分派时都会有一个问题发生。“签署版权转让协议的要求给参与者设置了一个障碍。一些个人与公司只是不想被这些书面的工作打扰。另一些可能对在一个自由软件许可下贡献代码觉得没有问题，但是他们（或他们的律师）对交出代码的所有权利感到犹豫。”

你能给一个项目做出贡献吗？合法的？

对参与者的障碍不只是理论上的，Kerrisk援引Greg Kroah-Hartman这位著名的Linux内核开发者的例子。在一次关于Gentoo Linux的发布是否要版权转让的谈话中， Greg Kroah-Hartman说，“从个人来说，如果任何版权转让是合适的，我永远也不可能成为一个Gentoo开发者，如果它被放在合适的位置，我不认为我会被允许继续做下去。我确信现在很多其他开发者也处于同样的境地。”

其他非赢利性开源团体采取了不同的处理。例如Apache基金会，要求“一个永久的，世界的，非排他的，免费的，免税的，不可撤销的版权许可，来再生产，准备衍生作品，公开展示，公开表演，转授权，发布你的贡献和它的衍生作品。”

如果你对一个特殊的团体有任何问题——你应该会有问题——在它的贡献者许可协议中检查一下，确切看看这个团体要求了什么权力。然后，如果你仍然有问题（你可能会有），与该组织或一个著作权代理人协商。这不是你在点击那些网站的“我已经阅读并同意该隐私政策”时毫无顾虑的忽略掉的check（对勾）标记。从字面上理解，你在提交你自己，或者至少是在需要三杯咖啡的睡眼惺忪的调试时写下的代码。

权力的转让不仅仅是一个对非盈利性开源团体的版权问题。一些商业开源组织要求你把给他们项目贡献的代码的版权交给他们。其他的，像Oracle (PDF文档)要求你的贡献的联合版权，这是为了它的OpenJDK, GlassFish, 和 MySQL项目。

一些公司，如Ubuntu Linux的母公司， Canonical, 已经对这些说法的要求给予支持。例如，Canonical现在声明“你保留你贡献部分的版权的所有权，而且对你所拥有的在没有进入该协议时的贡献，具有同样使用或许可的权力。”Red Hat, 在它的 Fedora 项目贡献协议中，现在只要求你具有对代码版权的授权的权力，它的许可是在CC 署名-相同方式共享 3.0 Unported 许可或一个变化的MIT许可任意一个之下。如果你不知道在向你要什么，征询专家的意见。

对所有这些怎么处理版权的不一致之处，你可能奇怪为什么人们没有试图用一个通用的办法来处理它们。好吧，他们曾经做过：它被称为和谐计划。然而，和谐计划没有获得许多支持，而且它的版权模版没有被广泛接受。

底线并非是你必须成为一个律师——尽管我理解你会这样认为！——但你的确需要仔细检查你对你代码的权利。你需要了解在使用开源协议或针对一个特定项目时，你放弃了那些权利。如果你仍然疑惑，却找专业法律帮助吧。

你不会希望陷入版权的泥沼之中的。祝好运。

0 0