选择最严格的开源许可证

解答动态

• 

  没有满足您需求的免费软件/开源许可证。这些许可证通常侧重于最终用户的，它们并不试图任何人。将软件用于任何目的（包括与您的产品竞争）的被认为是必不可少的。
  以为目的使用保留的许可证在某种程度上可以起作用，但通常会以失望告终。如果您的软件不是开源的，那么这是完全可以接受的，只要它没有被错误地标记。
  AGPL是一个copyleft许可证，在SaaS软件的上下文中有助于保护最终用户的。如果软件操作员修改软件，他们必须使源代码对所有远程用户可用。这个许可曾经在“我们是开源的，但不想与SaaS竞争”的领域很流行。但这是行不通的：这个许可根本不能阻止SaaS产品。它只要求用户能够访问源代码，但前提是源代码已被修改。
  cryptographic Autonomy License（CAL）是这种方法的扩展。它还允许用户访问SaaS产品存储的数据，这样他们就可以实际迁移到自托管解决方案。虽然这了SaaS的锁定效应，但这也不能阻止SaaS的竞争。
  CC-BY-NC/CC-BY-SA-NC许可证不被认为是免费的或开源的。它们是创作作品非常好的许可证，但有两个问题：它们不太适合计算机程序，因为它们不区分源代码和其他形式的程序。而且“非商业性”条款的确切范围还相当不清楚。
  还有其他许可证提供了一些性，而没有源码所暗示的。这些有时被称为源可用。其中一种方法是在没有任何许可证的情况下发布，保留所有权利（请参阅：什么是默认许可证？）。SSPL是一个非免费的许可证，它强烈反对SaaS的使用，但在其他方面与GPL类似。业务源代码许可证只允许非生产性使用，但在将来的某个时候会自动转换为源代码许可证。
  您可以自己创建一个合适的许可证吗？我求你不要这样做。开源许可必须考虑版权和合同法。他们通常必须在国际司法体系中工作，而不仅仅是在国内的法律体系中。它们必须在版权有效期内有效，而版权有效期通常超过一个世纪。起草一个好的许可证是困难的。
  有许多许可证是由善意的业余爱好者写的，但这可能会在他们的许可机制中引入重要的疏忽，甚至致命的。有时，他们可能无法适当地强加一些许可证条件。或者他们写得太不清楚，以至于他们可能不会授予他们打算授予的权利。有时，这些许可证是通过将现有许可证中的短语和部分以一种货物崇拜的方式重新组合而创建的，而不了解它们之间的联系。这样的DIY许可证通常被称为蜡笔许可证。
  如果您想在不损害商业利益的情况下创建源代码，最好从许可证问题转移到哪些部分可以发布的问题。您的软件的某些部分实际上可能对您很有价值—这些功能将您与竞争对手区分开来。而且有些代码是针对您的情况的—不管它是否是开源的，因为它对其他任何人都是无用的。但是，可能有一些模块对您很有用，但不是特别有价值，例如配置库或某些前端小部件。式采购可能不会带来重大问题。您很可能已经在使用许多开源工具和库。除了创建新的项目，您还可以考虑维护这些项目（因为这最终也会使您受益），或者您也可以上游新的特性来帮助您的工作。
  
• 

  GNU Affero General Public License v3.0是朝着正确的方向迈出的一步，但不幸的是，它没有完全达到目标。尽管它确实要求通过网络与许可材料交互的用户有权接收源代码的副本，但它并不要求发布数据。
  
• End