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

Question

因为我们自己的Alaukik问我把一个 小 脚本根据GPL许可证我不知道如果我做正确。我关心的点是：

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

---

更新：

有一个关于“如何为您自己的软件使用 GNU 许可证”的非常好的页面。gnu 网站还提供了有关如何将许可证应用于您的项目( ™Flimm ) 的建议。这涵盖了 GPL 的很多内容。

底线 - 许可证选择：
如果您想支持免费软件，请不要使用过于免费的许可证。禁止专有使用使自由软件比专有程序更具优势。理论上，某些许可证重用您的代码必须归功于您的原始代码。但是重复使用很难证明，有些公司可能只是不信任你。但是，如果您确实希望尽可能广泛地传播您的软件，即您不关心使用您的软件的专有产品，那么请使用 MIT 或 LGPL。如果有疑问，请使用更严格的许可证并添加一行，说明您可以根据具体情况考虑允许超出许可条款的使用。这样，拥有值得您工作的项目的商业用户就有机会了。

底线 - 版权纠纷：
包括尽可能多的信息，以证明它确实是您的心血结晶。对你脑后的所有权提起诉讼。穷人的版权是将您来源的印刷版邮寄到您的家庭住址。如果信封完好无损，则邮戳是法庭上的有效证据，并提供日期和经过验证的地址。用电子邮件代替您的全名来识别您的身份应该没问题并且有足够的证据，但是：安全总比抱歉好。

Answer 1

我应该在前面加上：我不是版权律师。如果您真的很担心某事，请联系一位。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、专有许可等下重新发布它。

“GPL vs MIT”是一场永恒的战斗。选择你真正最满意的，而不是最方便的。如果您对潜在邪恶的人拿走您的代码并将其用于潜在的邪恶或有利可图的目的不满意，请使用 GPL 等您有一些追索权的东西。如果您真的不关心并且您自己没有使用任何 GPL 代码，那么像 MIT 这样更自由的许可证会很好。

请记住，病毒式开源许可证不仅对您有好处，它们还确保您的工作，无论它是如何改编和重新发布的，在相同的条款下对每个人都是免费的。即使你放弃代码而没有兴趣维护它，GPL 也给了它一个保持免费的更好希望。

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

Answer 2

在 GPLv2 许可的末尾，有一个关于如何将许可条款应用于您的项目的指南。FSF 付出了很多努力来编写该文件并使其尽可能具有法律效力，因此我会遵循他们的建议。

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

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

在 GPL 许可证和 MIT 许可证之间做出决定既是道德上的也是战略上的决定，并且有很多论据支持其中之一。