我开发了一个开源 CMS,它在 GPLv3 下获得许可,我想打开插件/模块架构,让任何人都可以贡献自己的扩展。但是,我想让贡献者自由选择他们想要的扩展许可证,而不是强迫他们使用主应用程序的许可证。
我的理解是,普通的 GPL 许可证也会迫使他们将扩展作为 GPL 代码发布,但是由于这些是扩展而不是应用程序的核心功能,所以我不清楚 GPL 的立场是什么,或者如果有更合适的开源许可证。
我开发了一个开源 CMS,它在 GPLv3 下获得许可,我想打开插件/模块架构,让任何人都可以贡献自己的扩展。但是,我想让贡献者自由选择他们想要的扩展许可证,而不是强迫他们使用主应用程序的许可证。
我的理解是,普通的 GPL 许可证也会迫使他们将扩展作为 GPL 代码发布,但是由于这些是扩展而不是应用程序的核心功能,所以我不清楚 GPL 的立场是什么,或者如果有更合适的开源许可证。
我相信标准的做法是在您的许可证中写入例外条款。GCC 这样做,例如:
作为一个特殊的例外,您可以不受限制地将此文件用作自由软件库的一部分。具体来说,如果其他文件实例化模板或使用此文件中的宏或内联函数,或者您编译此文件并将其与其他文件链接以生成可执行文件,则此文件本身不会导致生成的可执行文件被 GNU General 覆盖公共许可证。但是,此例外不会使可执行文件可能被 GNU 通用公共许可证涵盖的任何其他原因无效。
这里有一张图表总结了各种不同的 FOSS 许可证,第一列对专有软件链接的评论。它看起来不是特别最新,并且不包括许可证版本,但它可能仍然是一个开始的地方。
由于您拥有代码,因此您拥有版权,并且可以在以后将许可证更改为 LGPL(较小的 gpl 或库 gpl)或 bsd/mit 许可证,在这种情况下更允许。
仅仅因为您最初将代码许可为 GPL 并不意味着您将来必须继续将其许可为 GPL。
如果你打算在修改后的 GPL 下发布它,那么称它为 GPL 是不正确的,因为它违反了所有 GPL 规则。那么,如果它不是真正的 gpl 精神许可证,为什么要称它为修改后的 GPL 呢?
您在这里遇到的是 GPL 的问题。它可以像病毒一样感染代码,而您并不打算让它感染。不选择 gpl 是一个很好的理由,因为它不像 MIT/BSD 等其他许可证那样提供自由。