您是否必须在每个源文件中都包含许可证声明?


111

我一直在寻找可以用于我的开源项目的各种许可证,但是我所见过的所有具有各种许可证的项目似乎都有一个巨大,令人讨厌的(我认为)请注意,每个源文件中都指出该文件已在某个许可证下列出。我认为我没有找到不是公共领域的,没有这样的通知的单个源项目。

这似乎只是浪费时间和文件空间。我计划在项目中放置@license@author标记,但是我不明白为什么如果我不想将代码公开,则需要在每个文件中列出如此大的通知。

我有什么理由想要在我的项目中包括这样的通知,或者仅仅在README@license标签中包含一个通知就足够了?这是否会影响大多数许可证的“明确规定”的规则,还是只是过分杀伤,以至于人们不会争论?


10
编辑器应允许您将许可证折叠/隐藏为1行。
Pubby 2011年

1
实际上,如果有人修改您的代码,重命名变量并删除版权,法院是否会认为这两个文件相同?
NoChance 2011年

5
@埃玛德:不,法院不会说它们是相同的。(但是它们可能“基本相同”。)是的,法院会说这是侵犯版权。
2011年


Answers:


39

以我的理解,GPLv3在每个源文件中强烈建议(甚至可能至少要求我了解我如何理解“ 如何将这些术语应用于新程序”一文)版权声明。它说

这样做,请在程序上附加以下注意事项。将它们附加到每个源文件的开头以最有效地声明保修范围是最安全的。并且每个文件应至少具有“版权”行和指向完整通知所在的指针。

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

FSF拥有的GNU项目(例如GCC)在每个文件中都有这样的通知。

我也知道一个程序(J.Pitrat的CAIA系统)在自由软件社区网站上被拒绝,因为它在每个文件中都没有这样的通知。

我不是律师,但我认为,这样的通知实际上在GPLv3程序的每个源文件中都是强制性的

(如果您使用其他许可,尤其是非FSF许可,请仔细阅读有关如何应用的许可; YMMV;但是AFAIK在每个文件中写上通知都不会造成损害。)


16
这不是强制性的,因为某些系统(例如Smalltalk图像)不会将源代码表示为文件。他们说“最安全”和“应该”,而不是“必须”。他们推荐的是容易理解的准则,很少有人犯错,但这绝对不是“实际上是强制性的”。
2011年

我同意,并且我故意说了“源文件”。实际上,CAIA的系统有点像Smalltalk:图像位于数据文件中,而我提到的CAIA“源文件”是生成的C文件。但是,我的GCC MELT(属于FCC版权的GCC分支机构)也已进行元编程,因此我确实会在生成的C文件中生成版权声明注释(并将它们放入手写的C&MELT代码中)。
Basile Starynkevitch 2011年

点了。我现在知道一段关于MELT的内容。通常,最好将生成的文件包含版权声明,因为否则很难“附加”许可证。例如,“ yacc”和“ lex”的作用受到限制。
2011年

1
根据个人经验:要在Savannah上接受一个项目,您必须在每个文件中都有一个许可证。
Mael

1
只是为了根据GPL常见问题解答进行澄清,在撰写本文时,#LicenseCopyOnly#NoticeInSourceFile 并不需要在每个源文件中包括“ 如何应用...”文本;注意该语言使用“应该”而不是“必须”。但是,他们强烈建议您遵循此做法。
ZeroKnight

37

我见过许多项目,这些项目在README或LICENSE或COPYING文件中仅提及许可证。

根据国际法的约定,您的软件将自动受到版权保护。(除非您为美国政府或其他不适用版权的组织工作。)

如果有人使用您的软件,那么他们必须确保遵守许可协议,或遵守对其使用权限的合理使用限制。

假设该人想要使用您的代码分发中的一个文件,该文件当然需要副本,因此适用版权法。默认情况下,根据版权法,他们无权使用您的软件。只有在他们知道并遵守许可限制后,他们才可以使用它。

因此,如果他们使用未经软件许可的文件,则将违反版权法。由于所有许可都说类似“以上版权声明和本许可声明应包含在软件的所有副本或重要部分中”之类的内容,因此它们有义务将该许可放置在某处。

那可以在文件本身中,或者当我使用代码作为库时,我将相关部分放入其自己的目录中,并在该子目录中添加了“ README”或“ LICENSE”。

简而言之,您无需在每个文件中放置许可证。我认为这太过分了。这样做没有额外的法律保护。它确实对下游用户有所帮助,但效果不佳。

我认为很多基于注释的元数据(许可证,每个功能的创建日期,变更日志等)的传统都是非常古老的传统,因为它们易于执行,而且比起有用的保护符更为重要。

例如,默认的Eclipse模板在每个函数之前添加了我认为无用的元数据,我认为版本控制可以更好地捕获它。但是这种做法在许多商店中很普遍。


2
例如,在Rails源文件中根本看不到与许可相关的任何内容。
安东·巴科夫斯基2011年

3
在顶级Python标准库中的200个文件中,只有34个包含单词“ copyright”,而其中只有4个用于控制Python版权的Python Software Foundation。
2011年

是的,我不认为按文件的版权声明会持续下去...太多了..这根本不可能成为未来的方式..考虑一下DRY ...根级别的许可,让我们称它为一天。.我认为npm上的几乎所有内容都已经采用这种方式
ChaseMoskal

13

问题在于,很容易将单个源代码文件从其较大的项目中分解出来,例如,某人只是签出,通过电子邮件发送,下载一个文件,而其余的则不包含全部版权。然后,该文件可以按时间顺序无限次传递给可能不知道文件来源的第N个参与者。

顶部的版权声明提醒运行该单独文件的任何人,该文件实际上是受版权保护的,而不是公共领域的,因此,某些许可证可能会或可能不会涉及其分发或使用。与让发现者自己做出随机假设相对。


21
通过复制粘贴源文件的各个片段进行分解也很容易吗?然后怎样呢?这种说法对我来说似乎前后矛盾。
Travis Griggs,2015年

10
问题在于假定作品的公共领域没有版权声明。如果您遇到没有版权声明的文件,则不应复制该文件并将其发送给他人。
Rich Remer

当然,还有一个问题是“克隆并拥有”文件是合法的,我们直接将开放源代码放入我们的项目存储库中,因为有时很难在上游项目之外修复错误,但是您迫不及待他们要么释放。并不是说这是一个好主意,但我们已经做到了。
xenoterracide

8

地下掩体中没有秘密的超级大国会议,没有说您必须在每个源文件中放入什么。

它确实向用户表明该文件处于任何许可之下,并且实际上大多数GPL软件都包含一个简短的前言,说要阅读license.txt。请记住,项目会被拆分,文件会被重用,因此仅将消息放在单个文件中可能不是一个好主意。

如果在极少数情况下将其归档,如果您已将每个文件清楚地标记为您的工作以及所依据的许可,您可能会有更多的主张-那么没有人可以声称他们认为该特殊文件未被涵盖


6

我几乎贴出了一个非常相似的问题。更少的烦恼,更多的是技术。TL; DR:我相信答案是作者的优先事项。也许意图会比优先顺序更准确...

我相信可以在您的来源中引用许可证,这取决于您对“确定”的定义。让我们同意术语“无人陪伴”表示源文件是属于项目的一部分,该项目已从其喜爱的代码库中进行了无情的分离。所述文件包含这样的一行:

# This file is covered by the LICENSING file in the root of this project.

或更酷的一行是这样的:

* @license OMGBBQ <http://goodlics.com/bbq>

“可是等等!” ,您惊叹道:“您刚刚说过该文件已从项目中分离出来!而且goodlics.com重定向到域名抢注者!别再麻烦了!” 你是对的,我确实是这么说的,但这可能没关系,不要再对我大吼大叫。这是我的非律师推理:

  • 几乎每个国家都同意[感觉]伯尔尼公约,AFAIK意味着,如果您创作某些东西,那么您就拥有该时期的版权。你并不需要一个(C)线之类的任何废话,但那些东西(加上第三方VCS样的GitHub)并使其更容易证明您创建它,你创造了它。
  • 因此,如果您在线发布了一些创建的多汁的1337代码,则该内容具有版权。不允许任何人(合法)复制它。我知道这种情况很少见,而且令人震惊,但我听说人们有时会触犯法律。那还是有可能的。
  • nyancat-bcminer-algo.qbasic不管您相信与否,您在LiveJournal上撰写并发布的精彩文件都不是公共领域。除非您这是公共领域,否则不行。默认情况下,它是您的和您自己的。这是... 珍贵。(除非您是迪士尼,否则至少25-50年以上。)
  • 人们通常会通过许可来传达此意图(单独获得部分或全部权利,而不是您本人和您自己),但是您需要宣布该意图;选择退出(HAHA GET IT?选择退出您的版权?真棒)。拿出您的票,我们快到了!
  • 如果可以确定上述无伴奏文件是私有域,即不能合法复制,则使用可能损坏的引用是完全可以的。但是,如果不行,那么我认为您需要在每个源文件中包括许可证文本。这样,无伴奏文件仍然可以按照您的优先顺序进行许可。是的,那更好。

这种推理提出了两个史诗般且可能无效的假设:

  • “中断的”许可证参考依赖于默认(受版权保护)行为,这可能不是有效的假设。
  • 您在其上发布的网站没有某种发布策略(例如StackExchange)将所有内容都设为公开域。

感谢您乘坐猴脑航空。

免责声明:在我看来,我90%确信自己100%错误是对的。


6

许可证序言之间有区别。

在我的某些项目中,我使用的是GNU通用公共许可证3.0版。GNU GPL使每个源代码文件都有一个序言:

序言和指令是GNU GPL不可或缺的部分,不能省略。

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

所以这是我的工作:

1.添加License.txt

为了遵守规则,我将LICENSE.txt放入项目存储库的根目录中。GitHub也建议这样做(请参阅“ 许可证住在哪里”)。

2.使用自动折叠添加前导

接下来,我在每个源代码文件BUT的顶部都包含GPL序言,以免打扰我将其隐藏在IDE中。大多数IDE具有自动折叠代码块的功能。NetBeans支持自定义代码折叠,而WebStorm也支持折叠注释

所以这是它的样子:

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

我认为这是舒适性和法律安全性之间的很好折衷。

如果您有很多项目需要添加许可证,那么http://www.addalicense.com/可能会有所帮助。

请注意:我的建议涉及GPLv3。其他许可证类型可能不需要序言。


7
«GNU GPL使得必须在每个源代码文件上都有一个序言:»并非如此。您引用的部分只是阻止您从LICENSE文件中删除前导,即,您不能通过删除GPL来更改其文本。
Andrea Lazzarotto

6

这里还没有提到另一种实用的方法。

SPDX-License-Identifier标签。https://spdx.org/using-spdx

使用它,每个源文件头中的“合法样板”都减少为仅两行:

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

此外,自动化软件供应链分析的人员将感谢您坚持使用机器可读许可证描述的通用标准。

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.