我已经开始尝试将我的一些东西上传到GitHub，并且我最近阅读了一些文章，其中有一些硬数据表明GitHub 上的大多数存储库都没有得到正确的许可。我希望不是这样。我决定从现在开始在我的大多数项目中包含MIT 许可证，我想知道是否应该命名它LICENSE.txt，或者LICENSE.md（我喜欢这个）会更好？然后我开始想知道一个更普遍的问题：你给持有你的开源许可证的文件起什么名字重要吗？例如，如果您的项目内部有有效的许可证，但文件名为VOIDLICENSE.md? 我知道这有点做作，但它证明了我想要问的问题。对我放置许可证的文件的名称或放置该文件的位置是否有任何限制？如果它深埋在目录结构的某个地方，它仍然算数吗？如果文件中还有其他内容，它仍然计算在内吗？我想如果许可证完全从模板中更改，它将不会被视为有效的 MIT 许可证，但如果文件中有其他内容，它会失效吗？
问问题
4649 次
2 回答
13
没关系，只要你选择明智的。
由于您使用的是开源许可证，您可能希望让其他开发人员更容易发现他实际上可能在 MIT 许可证下使用您的代码。这是通过使您的许可证文件易于发现来完成的。
存储库根目录中的任何诸如 LICENSE、LICENSE.MD、LICENSE.TXT 之类的东西都可以被认为很容易被发现。我想你也可以假设如果一个人没有找到一个 LICENSE 文件，他会寻找别的东西——比如 COPYING。您希望防止有关许可的冲突声明。不要在你的 README 中说某些东西是在 BSD 下获得许可的，而在单独的许可文件中说它是 MIT。
您可能还需要考虑非人类代理的可发现性。npm 在 package.json 中查找“许可证”字段，并将其显示在 npmjs.org 的包信息页面上。
CommonJS 规范实际上谈到了“许可证”字段。我知道 npm 也支持“许可证”这一事实，因为我自己使用它。我也知道 npm 接受 license 字段的简单字符串值。即"license":"MIT"有效。
licenses - 提供软件包的许可证数组。此属性不具有法律约束力，并不一定意味着您的包裹已根据您在此属性中定义的条款获得许可。每个许可证都是一个散列，带有一个“类型”属性，指定许可证的类型和一个链接到实际文本的 url 属性。如果许可证是官方开源许可证之一，则可以使用“类型”属性来说明官方许可证名称或其缩写。如果提供了缩写（在括号中），则必须使用缩写。
http://wiki.commonjs.org/wiki/Packages/1.1
此外，很高兴知道原则上，您保留对您发布的任何内容的版权。如果未指定许可，或者（潜在）用户找不到许可，则他必须假定他没有使用您的作品的许可，但国家版权法规定的任何合理使用条款除外。请参阅讨论：https ://softwareengineering.stackexchange.com/questions/148146/open-source-code-with-no-license-can-i-fork-it http://www.codinghorror.com/blog/2007 /04/pick-a-license-any-license.html
如果许可证完全从模板中更改，则它不会被视为有效的 MIT 许可证，但如果文件中有其他内容，它会失效吗？
同时声称您正在根据 MIT 许可证提供某些东西确实会令人困惑，而实际的许可证文本却（略有）不同。但是，您绝对有权以您想要的任何方式许可您的作品（在法律范围内。某些要求不能被提出 - 并且是无效的）。
我认为许可中轻微歧义的最大风险（如果有的话）是（潜在的）用户可能声称他认为他有权根据 MIT 许可的条款使用您的作品，因为您的许可标题是这样说的. 如果他不遵守任何附加条款，您将更难以在法庭上起诉此人的任何不当行为。他可以声称自己是无辜的。
我想说：除非您想完全按照这些条款进行许可，否则不要使用已建立的许可（MIT、BSD、GPL 等）的名称。或者如果你确实使用这样的名字，总是说“MIT+MY_REQUIREMENTS”左右。“麻省理工学院”就不是一个正确的“总结”。
于 2013-05-19T00:37:44.173 回答
1
您可以毫无顾虑地更改许可证的标题，但对位置有要求。你必须 ：
- 在源项目的根目录中提供许可证的全文（通常在名为 LICENSE.TXT 的文件中）
- 在非源项目分发的根目录中提供许可证的全文（通常在一个名为 LICENSE.TXT 的文件中）。
查看该链接了解更多详情：http ://www.oss-watch.ac.uk/resources/opensourceyourcode#applying-the-licence
于 2013-05-18T18:26:19.813 回答