我们正在进行内部软件审计，并发现了至少一个在Affero GPL下发布的textract组件：EbookLib。
律师们对此有些不安。一般来说，与GPL的兼容性意味着在不同许可(如MIT)下发布的代码与GPL下的代码结合后，必须以GPL发布。这可能会给textract带来不好的情况。
我们通过禁用与EbookLib相关的所有功能来解决这个问题，并从虚拟环境中卸载EbookLib,使其永远不会被使用或与我们的软件捆绑在一起。如果将来我们需要Epub功能，并且假设textract的其他方面没有发生变化，我们会指示用户自己安装。我们也可能为同一目的提供一个点击安装对话框，但警告用户他们正在下载和安装。
我们的情况是：
Apache许可证，代码仍然是私有的，即将发布供开放分发。它依赖于textract和其他工具来完成工作。我们在自我审计过程中发现了GPL代码，需要找出一般情况下应该怎么做；到目前为止，如果我们删除有问题的代码/库/工具，我们的基本功能不会受到影响，所以我们可以跳过。未来可能不是这样。
我们非常喜欢textract,希望帮助所有用户社区的人避免因EbookLib或其他具有苛刻许可证的东西而不小心陷入麻烦。你们有什么想法？
4条答案
按热度按时间uxh89sit1#
感谢你将此问题作为一个议题提出，@pr3d4t0r!我很高兴听到你即将发布；这确实非常令人兴奋：)
正如我在 our twitter conversation 中提到的，也许我们可以分别安装GPL软件包，就像
extra_requires一样，这样我们就可以做一些像pip install textract[GPL]的事情。这不仅可以安装所有非GPL代码(默认情况下将继续发生),还可以安装GPL代码。这看起来是一个很好的解决方案。你怎么看这个方案？ca1c2owp2#
另外，你的代码分发如何处理它所需的Unix命令？这些是否也是GPL?
at0kjp5o3#
@pr3d4t0r,你有没有考虑过这个问题？textract不仅依赖于GPL Python包，还依赖于各种Unix命令。我当然希望在我们分发textract时尊重这些许可证，但如果我们不需要让textract的分发变得复杂，那当然是很好的。
cu6pst1q4#
我刚刚为这个项目设置了
pyup来监控依赖关系，他们有一个很棒的工具用于seeing the licenses of dependent projects。我想在这里提一下，以防它对谈话有所帮助。