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

由于我们自己的Alaukik要求我在GPL-License下放几个 脚本 ,我想知道我是否正确地做了。 与我有关的要点是:

  1. 我是否必须将整个许可证包含在我的项目中,或者是一个评论如# Copyright by John Doe, 2011 Licensed under the MIT license: http://www.opensource.org/licenses/mit-license.php合法足够吗?
  2. 我是否必须包含我的真实姓名或电子邮件或其他合法防水的别名?
  3. 这一年重要吗? 由于版权在一段时间后在大多数国家到期,我猜是“是”。 如果我不这样做会怎么样?
  4. 我应该在MIT上使用GPL吗? 我倾向于麻省理工学院,因为它更宽松,我不关心我的脚本是否用于闭源软件。

更新

“ 如何为自己的软件使用GNU许可证 ”有一个非常好的页面。 gnu网站还就如何为您的项目 ( ™Flimm ) 申请许可证提出建议。 这对GPL来说很重要。

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

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

我应该在此作为前缀: 我不是版权律师。 如果您真的关心某事,请联系一个。 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. 

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

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

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


版权声明中的年份并不重要,但如果您想在几十年内起诉某人,则必须certificate它何时被创建。 这可能很难。 固定通知可以帮助您,只需几秒钟即可获得成本。


我们应该清楚这里。

  • GPL允许商业再分发,但是购买其副本的任何人都必须(可以更改)整个事物的源代码。
  • LGPL适用于软件库。 这些可以包含在专有项目中,而无需重新分发整个源。 唯一需要发生源分发的时间是编辑代码,即便如此,他们只需要对其进行更改即可。
  • MIT代码可以自由重新许可。 有人可以逐字记录您的代码,并在GPL,专有许可等下重新发布。

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

记住,病毒式开源许可证不仅对你有好处,它们确保你的工作,不管它是如何适应和重新发布的,对于每个人来说都是免费的。 即使你倾向于没有兴趣维护它的代码,GPL也给了它更好的保持自由的希望。

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

在GPLv2许可证的最后,有关于如何将许可条款应用于项目的指南 。 FSF花了很多精力来编写该文档并使其尽可能合法有效,所以我会听从他们的建议。

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

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

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