在每个代码文件中放置许可证?[关闭]


93

我发现不必要地将其复制到每个代码文件中,但是在大多数开源项目中都可以看到它。我应该这样做还是只在代码之外包含一个许可证?



1
您必须在每个源文件中排除保修,否则您可能会陷入困境。(请注意,可以轻松配置适当的编辑器,例如Vim,以自动折叠看不见保修单的样板。)
Evgeni Sergeev

Answers:


74

请在代码外添加一个!我对其他人一无所知,但是我讨厌在每个文件的顶部都看到相同的东西。

我想我已经读过几次了,只是通过page_down-through它。


10
我不同意齐弗尔。最高处的任何重复执照对我来说都是令人讨厌的。
斯特拉格

49
确定每个源文件的发布许可证是合理且明智的,因为该文件可能与其余代码分开(重复使用-通常由开放源鼓励使用),并且该文件是否不包含有关许可证的信息。 ,要追溯到正确的许可证就比较棘手。但是每个文件中的整个许可证-不;对于GPL或LGPL而言,这将是怪诞的。正如已经建议的那样,对于短许可证,在文件中包含实际的许可证文本是很麻烦的,但这是一个判断。但是,明智的做法是确定它以哪个许可证发布。
乔纳森·勒夫勒

14
我刚刚将项目中的文件头更新为只有三行:版权,许可证名称和许可证文本的URL。它使我的标题从26行(BSD)缩短到3行。:)
Esko Luontola,2009年

3
@Esko:能否请您发布样本?我不知道您为版权写了什么。谢谢。
琼·芬格

6
这个答案被标记为解决方案,但在我看来,只要我们没有答案,这个问题仍然悬而未决evidence for the legal situationPerhaps a lawyer can add a link to a court decision
乔纳斯·斯坦因

25

EULA是错误的术语,因为查看源代码的人员通常不是最终用户。

从法律上讲,这也没有区别。版权不需要明确声明。

基本上,您获得的所有结果都是人们意外违反许可条款的风险较低。您必须决定这对您来说有多重要。

我想说的最好的折衷方法是在每个源代码文件中放置一个非常短的标头,其中包含指向完整许可证文本的链接(绝对URL以及项目中的相对URL)。这样,任何关心许可证的人都知道在哪里可以找到它(理想情况下,愿意支付巨额许可证费用的人;您当然希望那些人能够与您联系!)


版权可能不需要明确,但是copy-left呢?
Kekoa

1
@kekoav:copyleft的限制不及版权限制。默认情况下,您不能使派生作品。
Zifre

3
在争执中,这将是无效的论点。如果被告知存在许可证以及如何获取许可证,您将无法找到由于技术原因而导致您无法查看许可证的技术障碍。
拉瑟五世卡尔森

1
“ Copyleft”是GPL从内部“颠覆”版权限制的基本思想的语,即使用您作为版权持有者的权利向任何人授予许可以自由使用您的代码,但强迫他们释放其代码。根据您的相同许可
Michael Borgwardt

2
正确; 但是在这种情况下,正如齐弗尔(Zifre)所说,这没有关系。如果您不知道发布特定代码所依据的许可证,则必须假定根本不允许使用它。因此,作为发布者,您无需花太多精力就可以使人们阅读许可证。
Michael Borgwardt,2009年

14

不,您不必将许可证放在每个源代码文件中。

如果您仔细观察,大多数FOSS应用程序也不会这样做。他们在每个文件的顶部放置了版权声明,并在简短的句子中告诉您该文件所处的许可证以及在何处可以找到许可证的全文。他们通常会将您指向包含许可证全文的COPYING或LICENSE文件,和/或指向包含全文的网站(以防COPYING文件不再存在)。

就像迈克尔·伯格沃德(Michael Borgwardt)在回答中所说的那样,从法律上讲,您不必这样做。但是建议您打算分发源代码,因为人们可以立即看到谁拥有版权以及许可证是什么。


1
这个。版权声明应包括对许可证名称的引用(如果是标准名称)以及对如何在源代码树中查找许可证文件的描述。
jmucchiello,2009年

13

它可能取决于许可证。在GPL区分preamblelicense。它明确指出,(烦人的)前导必须是代码的一部分

我可以省略GPL的序言或如何在自己的程序中使用它的说明,以节省空间吗?

序言和指令是GNU GPL不可或缺的部分,不能省略。实际上,GPL受版权保护,并且其许可证仅允许逐字复制整个GPL。(您可以使用法律条款制作其他许可,但它不是GNU GPL。)(1)

来源:1)http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

另请参阅http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html

ifrOSS提供的免费电子书以德语解释和评论了GPL 2。GPL 3还有另外一个

要找到一个有根据的答案,您应该寻求sx上没有的法律建议。如果找不到您(开放源代码)项目的律师,请查看FSFE法律网络


7
序言和说明完整许可证的一部分,但是没有什么说您必须在每个文件中放入完整许可证。- 以下注意事项只是完整许可的一小部分。- 最安全,不是必需的。 -唯一的要求是版权线以及指向其余内容的指针。可以将完整许可证放在一个单独的文件中。[...] attach the following notices to the program.safest to attach them to the start of each source fileeach file should have at least the "copyright" line and a pointer to where the full notice is found.
toxalot

3
我认为应该!= 必须
toxalot

7

我认为将其放入每个文件的理由是合法的。如果每个文件中都包含该协议,则没有机会在没有许可的情况下跨过一段代码。

它可能不是一个好东西,但是所有大个子男孩都使用它,所以如果只是视觉上的痛苦,我会寻找一个更好的理由不这样做。

如果您使用的是GPL,则更多的是问题,但是如果您使用的是BSD或MIT之类的公共领域许可证,那么我认为您实际上并不关心人们对代码的处理方式。我想这取决于您的许可证有多严格。


1
好吧,在这种情况下,只需指出每个文件,然后继续,即表示您同意licence.txt文件中的许可。但是不要在每个文件中复制/粘贴相同的文本。有时我发现文件的代码比许可证短。
Rook

是的,我同意这种方式同样有效,特别是对于长许可证而言。即使这在法律上可能不是必需的,甚至在法庭上也不受支持,但至少可以参考别人的许可证来告知人们,而无需他们四处寻找代码所依据的许可证。
Kekoa,

3

IANAL,

假设您在谈论许可证而不是EULA,则可以将许可证放在外面。这几乎总是使用非常长的许可证(例如GPL)来完成的。将整个GPL许可证放在每个文件中是很愚蠢的。通常,您只会收到某种通知,说明可以在哪里找到实际的许可证。这是完全合法的。但是,对于真正简短的许可证(例如BSD / Apache / MIT /任何文件),仅在每个文件中包含许可证会更简单,因为通知中指出在何处可以找到许可证几乎与许可证本身一样长。


2

这取决于许可证的规定。例如,GPL指示您在每个源文件中放一个简短的通知,将整个许可证包括在源分发中的某个位置,并使源分发对任何获得二进制分发副本的人可用。

如果您不同意这,而这是您的代码,则可以自由选择一个更合意的许可证,也可以创建自己的许可证。


1

如果您的代码将要编译,那么您只是分发二进制文件,那么实际上就没有关系。因为当您创建二进制文件时,注释会在编译过程之前被删除。仅当您要分发开放源代码或封闭源代码的实际源代码时,这才有意义。如果您将使用无法编译的脚本语言来分发应用程序,那么这通常很重要。


谢谢。它将会是开源的。
琼·芬格

您可以创建一个包含许可证的硬编码字符串,因此它将显示在二进制文件上,但这可能太多了:)。
Liran Orevi

1

您不需要许可证就可以使用它,只要清除了它涵盖的文件,就可以使用一个外部文件。

但是对于版权,您应该在每段文本上都有版权声明。


谢谢,所以版权有所不同?
Joan Venge

INAL,但许可是您与用户/客户之间的合同。版权是对书面作品的所有权的主张。有人可以提取您的代码片段,并合理地声称它不具有版权,因为缺少该通知。尽管您只需要“ Copyright Joe Soap(Cleansoft Inc.)”,请不要担心。
詹姆斯·安德森

10
你错了。通常,为了清楚起见,确实在所有地方添加版权声明是一件好事,但这并不能使“假设它没有版权”成为公平的游戏,因为您知道所有内容都受版权保护。当某人获得源代码时,他可能会找到允许其使用的许可声明,或者出于某种原因,他可能会发现它在公共领域中。如果他没有,那它就是受版权保护的,不能被复制。版权是自动的,值得一提,但是不这样做并不意味着您就失去了版权……
Jasper 2010年

1

我要做的是在文件顶部加两行注释,注明我公司的名称,最新修订日期和源文件具有的许可证名称,然后在文件的最底部放一个简短的版本。执照。

当然,完整的许可证(如果有多个许可证,则全部包含在内)始终包含在源文件和发行目录中。


3
您如何自动化上次修订日期?
Dustin Getz 2010年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.