英文原文：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许可 任意一个之下。如果你不知道在向你要什么，征询专家的意见。
对所有这些怎么处理版权的不一致之处，你可能奇怪为什么人们没有试图用一个通用的办法来处理它们。好吧，他们曾经做过：它被称为和谐计划。然而，和谐计划没有获得许多支持，而且它的版权模版没有被广泛接受。
底线并非是你必须成为一个律师——尽管我理解你会这样认为！——但你的确需要仔细检查你对你代码的权利。你需要了解在使用开源协议或针对一个特定项目时，你放弃了那些权利。如果你仍然疑惑，却找专业法律帮助吧。
你不会希望陷入版权的泥沼之中的。祝好运。
