是的,您可以在任何许可下发布源代码。根据美国版权法,你有这个权利。

但是,如果您在源代码中合并了任何GPL源代码(或与任何GPL代码一起分发),则必须在整个工作中使用GPL许可证。那是因为你必须同意他们的许可证才能使用他们的代码。

顺便说一句,我不是律师。

MIT许可证也是GPL兼容的,这意味着GPL允许与使用MIT许可证的软件进行组合和重新分发。这个 link

这里的关键问题是:如果你只使用MIT许可证(或者其他一些相当宽松的开放源码许可证),你的软件X能被分发吗?

• 如果X对GPL许可库Y的依赖性是强制的,并且在构建/使用X时无法避免,则否。
• 如果X对GPL许可库的依赖性是可选的Y,并且默认情况下是禁用的,则是。

如果不能避免对Y的依赖,那么在MIT下发布X将基本上阻止任何人(例如Linux发行版、商业供应商或提供预构建软件的网站)在构建中启用GPL许可库的情况下分发您的软件。

因此,虽然你可以决定在麻省理工学院的许可证下授权你自己的软件,但是通过在这个许可证下发布它,你会让你的所有用户头疼。

我猜这不是你想要的。

我的建议是,你要下定决心,在以下两者中作出决定:

• 如果GPL许可的库Y是可选的,那么就在MIT下发布X,但是要知道,在启用Y支持的情况下,没有人能够以任何方式分发您的软件。(给用户带来了潜在的麻烦,但好处并不明确)

我希望这有帮助。

我的理解是,尽管不是律师,但您可以根据您想要的任何一组许可证来授权您的代码,只要您还授权它与您使用的组件兼容。

如果你的代码没有 依赖 在GPL代码中,只要不使用GPL代码分发它,就不需要根据GPL授权。例如,IPython最初使用readline,但他们从显式/必需的依赖项中删除了readline,只在它存在的情况下才使用它,这样他们就可以遵守GPL,但可以根据他们选择的任何许可证授予软件许可证。(对不起,我找不到推荐人。)

是的,您可以使用GPL库;并且只要您 dynamically link 去吧。如果没有的话,内核驱动程序也不会很多。

这意味着您必须有一个单独的可执行文件(和/或关于您使用软件的事实的文档);它在运行时加载,而不是在编译时加载。这也意味着你离 Dependency HELL!!!

有几个领域的依赖地狱,在这里他们没有特别的顺序:

• DLL地狱
• DSO地狱
• 坛子地狱
• RPM地狱
• 扩展冲突

每一种都有多种形式,最终形成最坏的形式:

你脑中的文字会吸干你的灵魂!!!