您为项目选择的开源许可证，或者您选择贡献的项目，可能会对您贡献的内容的使用方式产生重大影响。最近引起相当多关注的一个问题是 copyleft 许可证的受欢迎程度下降，而 宽松许可证 则越来越受欢迎。去年的一篇文章关注了 GitHub 上大量项目没有明确许可证的问题，并提出了我们是否生活在 “后开源软件”世界 中的问题，在这个世界中，看似开源的软件却没有许可证。过了一段时间后，GitHub 意识到许可证的重要性，并努力通过 许可证选择器 来改善这种情况。
Copyleft 引起的复杂性
如果您从辩论中退后一步，思考那些向更广阔的世界贡献代码的人的动机，那么我认为这归结为您认为最重要的是什么——重用还是自由。从 AGPL、GPL、LGPL、MPL 等等，copyleft 和弱 copyleft 许可证都使用相当复杂的语言来合法地强制执行代码的自由，以及在更大或更小的程度上强制执行任何衍生作品的自由。它们努力实现的另一件事是确保不对代码或任何衍生代码施加进一步的条件（超出它们自身的条件）。
这是 GPLv2 与 Apache v2 和 GPLv3 不兼容的主要原因。当您参与了足够多的此类讨论，并查看了 许可证兼容性图表 后，很容易理解为什么有时开源项目的开发人员或其他团队成员会质疑这一切是否值得。这可能会变得非常复杂，尤其是在考虑 LGPL 许可证时，因为它涉及到来自 Eigen 等库的 C++ 模板的扩展（Eigen 最近已迁移到 MPL2 以简化情况）。这也可能导致大型开源 CMS 项目（Drupal、Wordpress）要求 JavaScript 库 从 Apache 2 迁移到 MIT 或双重许可，以便保持 GPLv2 兼容性。我承认，对于 CMS 提供的 HTML 5 Web 应用程序，什么构成衍生作品，我仍然有些模糊。
宽松许可简化了事情
如果最近的文章是正确的，那么商业世界以及越来越多的开发人员偏爱宽松许可证的一个原因是重用的简单性。许可证通常只涉及获得许可的源代码，并且不试图推断任何其他组件的任何条件，因此无需定义什么构成衍生作品。我也从未见过宽松许可证的许可证兼容性图表；似乎它们都是兼容的（如果您知道任何例外情况，请在评论中告诉我）。对我们许多人来说，更令人担忧的是将许多开源项目组合和重用，以及跟踪总体许可/兼容性的复杂性。对于不应共享的专有工作或内部工作，也希望不发布源代码。Copyleft 允许这样做，但您必须密切关注什么构成发行，或者允许哪种类型的链接（例如，LGPL 情况下的静态与动态）。
最后的想法
我作为一名开源开发人员开始我的旅程时，坚定地站在 copyleft、GPL 阵营。在 GPLv3 发布之后，并且我看到许可证兼容性问题影响了我参与的项目（Avogadro、Open Babel 和最近的 Open Chemistry），因为它们仅使用 GPLv2 许可，我花了很多时间思考我的立场。我最希望看到的是我所做的事情尽可能多地在有用的地方使用，并且在加入 Kitware 后，我了解了在与许多协作者开发大型代码（如 VTK 和 ParaView）时存在的许多其他复杂性。
我的感觉是，您必须在释放一些控制权之间取得平衡——其他人可能会重新包装您的作品并在商业项目中出售它（尽管 copyleft 不能保证这种情况永远不会发生，但会使其更加困难）。我也在某种程度上参与了开放获取运动，并看到了那里关于许可证的激烈辩论。Creative Commons 署名-相同方式共享许可证 也存在类似的兼容性问题，并且您会注意到，一旦引入 SA 条款，您的衍生作品许可证选择就会很快减少。
在科学领域，资金和时间通常都很短缺，在我看来，我们花在弄清楚许可证上的时间越少（或者完全忽略它并冒着未来诉讼的风险）就越好。当然，您的特定项目可能有很多理由想要做更多的事情来强制执行您的代码和任何衍生作品的自由。我的建议是，请使用现有的许可证，并考虑 copyleft 和/或相同方式共享许可条款引入的额外复杂性。当然，还有双重许可选项，以及围绕其使用构建的商业模式。以我的经验来看，双重许可的商业模式通常会导致社区缩小，因为公司始终比社区的其他成员拥有更多权利，从而导致共享所有权减少的市场失衡。
8 条评论