写开源软件之前请先确认你知道你的版权权利 已翻译 100%

oschina 投递于 2013/03/26 23:57 (共 16 段, 翻译完成于 03-29)
阅读 5660
收藏 103
6
加载中

know your open source copyright laws


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

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

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

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

Lax
Lax
翻译于 2013/03/27 10:29
2

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

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

DW_GYT
翻译于 2013/03/27 11:12
1

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

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

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

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

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

Tysver接着说道:

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

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

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

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

super0555
翻译于 2013/03/29 12:58
1

copyright

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

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

super0555
翻译于 2013/03/29 13:22
1

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

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

super0555
翻译于 2013/03/29 13:48
1

现在,加入开源贡献

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

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

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

super0555
翻译于 2013/03/27 11:03
1

举个例子,最近的一个关于版权的烦恼,是在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的开发。”

super0555
翻译于 2013/03/27 11:35
1

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

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

super0555
翻译于 2013/03/27 15:57
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(14)

super0555
super0555
个人感觉Apache比较适中,兼顾了各方的利益,也具有开源精神
超级兵
超级兵
很多程序员都懒得看这些条条框框的。
哈士奇想
哈士奇想
看的一头雾水,求原文地址
方凯
方凯
要看什么东西了,
泡不烂的凉粉
泡不烂的凉粉
FreeBSD 已经被版权之争已经害了半死。所以伯克利软件里面有一个接近苛刻的条件。
贡献代码必然会放弃很多权利。
虽然从某方面限制了它自身的发展。从另一方面,却让它更纯洁。
很多人批评 商业公司在FreeBSD系统上牟利,损害了贡献者的权益。
我个人认为这样没有违背开源精神,没必要这么强烈的谴责,虽然可以小小的鄙视类似行为。
开源和商业并非矛盾的对立体,任何商业软件都有很多开源免费的附属品提供给我们。
应该学会看到优点而不是一味的瞅着某软件封闭自私利己主义的缺点。
KrizeChan
KrizeChan

引用来自“keengo”的评论

引用来自“wenshao”的评论

支持开源,但是不喜欢GPL协议,既然是分享,何必那么多限制呢!

喜欢GPL,既然开源,就大家一起开源,别我开源,你不开源。

+1024
沙枣
沙枣
开源本是让大家分享,但确成为某些人牟利的工具,而且不择手段。要关注的首先不是版权,而是你的合作伙伴。
keengo
keengo

引用来自“wenshao”的评论

支持开源,但是不喜欢GPL协议,既然是分享,何必那么多限制呢!

喜欢GPL,既然开源,就大家一起开源,别我开源,你不开源。
wenshao
wenshao
支持开源,但是不喜欢GPL协议,既然是分享,何必那么多限制呢!
壮哉我大东北
壮哉我大东北
lgpl
返回顶部
顶部
返回顶部
顶部