如何正确使用GPL和MIT许可证？

问题描述

由于我们自己的Alaukik要求我在GPL-License下放置a few scripts，我想知道我是否正确地进行了操作。与我有关的要点是：

1. 我是否必须将整个许可证包含在我的项目中，或者像# Copyright by John Doe, 2011 Licensed under the MIT license: http://www.opensource.org/licenses/mit-license.php这样的评论是否合法？

2. 我是否必须包含我的真实姓名或者是e-Mail或其他合法防水的别名？

3. 这一年重要吗？我猜’yes’作为版权在一段时间后在大多数国家到期。如果我不这样做会怎么样？

4. 我应该在麻省理工学院使用GPL吗？我倾向于麻省理工学院，因为它更宽松，我不关心我的脚本是否用于闭源软件。

更新：

‘How to use GNU licenses for your own software‘上有一个非常好的页面。 gnu网站还在how to aply the licenses to your project(™Flimm)上进行推荐。这对GPL来说很重要。

底线 – 许可证选择：如果您想支持免费软件，请不要使用太多免费许可证。禁止专有使用使自由软件优于专有程序。理论上，您的代码的某些许可证re-usage必须归功于您的原始版本。但是re-usage很难证明，有些公司可能不会相信你。但是，如果您确实希望尽可能广泛地传播软件，即您不关心使用软件的专有产品，那么请使用MIT或LGPL。如果有疑问，请使用限制性更强的许可证并添加一行，并表示您可以考虑允许在by-case基础上使用许可条款之外的用途。这样，拥有一个值得您工作的项目的商业用户就有机会。

底线 – 版权纠纷：包含尽可能多的信息，你敢于证明它真的是你的想法更容易。在你的脑后对所有权提起诉讼。穷人的版权是将您的来源的打印副本邮寄到您的家庭住址。如果信封未被破坏，则邮戳是法院的有效证据，并提供日期和经过验证的地址。一个e-mail而不是你的全名，以确定你应该是好的和足够的证据但是：更安全，而不是抱歉。

最佳解决方案

我应该在此作为前缀：我不是版权律师。如果你真的关心某事，请联系一个。 FSF的人可能会帮助你。

您应该包含许可证的全文。即使您只是将它粘贴在项目根目录的LICENSE文件中。如果你没有，但从长远来看(版权是)，我认为不会立即发生任何坏事，没有对你的许可证的可靠参考可能是一件坏事。

明确不花费太多时间。

编辑：实际上，WARRANTY部分可能值得包括您的保护，无论您选择哪种许可。我没有证据表明不包括它意味着保修，但同样，安全，不抱歉。

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE. 

版权声明(© <date> <name>)在大多数地方不再是法律要求，但不包括它对任何人都没有帮助。你将难以证明自己拥有版权，对于想要以不同条款授权的人来说，这将更加困难。我肯定会把它放在那里……但我想这不是BSD /MIT风格许可证的问题。

至于使用手柄或昵称，在其他媒体中，人们几个世纪以来一直在使用假名。如果涉及到法律诉讼，你需要能够证明你是那个人，所以很明显这可能会让它变得更难，但这并不是不可克服的。

如果你要去麻省理工学院，你几乎没有法律追索权，这些问题可能永远不会适用于你。

版权声明中的年份并不重要，但如果您想在几十年内起诉某人，则必须证明其创建时间。这可能很难。固定通知可以帮助您，只需几秒钟即可收取费用。

我们应该清楚这里。

• GPL允许商业再分发，但是对于购买它的副本的任何人来说，整个事物的源代码必须是可用的(随着更改)。

• LGPL适用于软件库。这些可以包含在专有项目中，而无需重新分发整个源。需要进行源分发的唯一时间是编辑代码，即便如此，他们只需要对其进行更改即可。

• MIT代码可以自由重新许可。有人可以在GPL，专有许可等情况下接受您的代码，逐字和re-release。

“GPL vs MIT”是一场永恒的战斗。选择你真正最开心的事情，而不是最方便的事情。如果你不喜欢潜在的邪恶的人拿走你的代码并将其用于潜在的邪恶或有利可图的目的，那么就可以使用像GPL那样的追索权。如果你真的不在乎并且你自己没有使用任何GPL代码，那么像麻省理工学院这样更自由的许可证就可以了。

请记住，virally-open-source许可证不仅对您有好处，它们确保您的工作，但它是适应的，re-released对于所有人都是相同的条款免费。即使您倾向于对维护它没有兴趣的代码，GPL也给予它更好的保持免费的希望。

没有必要急于做出这些决定，但你必须考虑最糟糕的情况才能真正知道你是否做出了正确的决定。一旦它在其中一个许可下发布，就是这样，就完成了。

次佳解决方案

在GPLv2许可证的最后，有一个关于how to apply the license terms to your project的指南。 FSF花了很多精力来编写该文档并使其尽可能合法有效，所以我会听从他们的建议。

如果您决定使用GPL许可，请确保包含“版本2或更高版本”条款。这将在以后节省您的麻烦，并使GPLv2项目与GPLv3和vice-versa兼容。

就像Oli所说的那样，您不需要在文件的标题中使用您的真实姓名或电子邮件来保护您的版权，但强烈建议您以后保护您和其他人免于头痛。

在GPL许可证和MIT许可证之间做出决定既是道德和战略决策，也有许多论据支持任何一个。

参考资料

• How do I use GPL and MIT licenses correctly?