刚刚在 Mol Plant 直播间，夏老师与我一同做了「TBtools-II」的汇报。其中有两个问题值得相对正式的回复，想了想，干脆写个博文，以做记录。两个问题分别是：
- TBtools 开源吗？
- TBtools的一个功能调用了 IQTree，是GPLv2，是否应开源？
TBtools 开源吗？
这个问题可能从 TBtools 开始有一定规模的用户开始即有人不时提出，至今数年。前后回应过几个。我个人主要的观点是：
- 我个人支持开源，也为数个开源项目贡献过代码，具体可以直接看我的github仓库，左侧贡献牌牌。但在 TBtools 这个事情上（并无使用/修改开源代码），没得商量，我不会选择开源。甚至 GSAman 也不会，当然不一定，我确实有想法开源GSAman项目，但还是要考虑（IGV属于MIT协议，因为其实GSAman本身就是里调用TBtools和JIGplot来实现功能）。
- 项目开源的目的让更多人参与开发，基于我的观察，这个目的达成可能性几乎为零。当然，存在非常多优秀生物软件，也无开源。开源是软件的一种形式，并不能与软件质量对等。为此，选择不开源；
- 开源项目的 99% 的贡献由 1% 的人完成。这是一个事实，也是一个现象。往往期望开源的人，并不是期望做贡献，所以情况变得非常复杂。我也遇到过有“要求”我开源的人后来开发的软件并不开源；我也遇到过直接从 TBtools 中拿走功能组件一声不吭的。为此，选择不开源。
所以主程序开源是不可能的，过度的自由，只会让事情变得一团糟。但正如报告时提及，如果是要开发TBtools插件，那其实非常简单，与开源这个事情没有关系。TBtools主打的是任何人都可以轻松转换手上的命令行或者脚本，开发成插件以分析和贡献，这会让整体生态变得更好。
TBtools的一个功能调用了 IQTree，是GPLv2，是否应开源？
事实上，当我看到这个问题的时候，我还是有思考的。主要原因在于，TBtools调用或依赖的软件，我都会做筛选，选择 MIT 协议的软件，如此就不会存在任何协议问题。但 IQtree 这个事情是意料之外。因为这个软件已经有较多软件做了集成，我当然认为不会有问题，即使是有协议的情况下。但直播间也只能直接回复事情。
结束后，我即做了相关确认，大体如图。
对于GPL协议或者其他所有协议都好，违反协议的前提是做了代码修改。但TBtools直接调用 IQ-tree 软件，不涉及到「修改源码」，所以跟报告时回复问题一致，与其他打包 IQ-tree 的软件一样，属于正常操作。
所以不存在违反协议的可能。
事实上，相比于协议，我们更关注的是如何把更多更好的软件部署起来，让更多人可以轻松使用起来，尤其在引用文稿方面，强烈建议用户直接引用依赖软件，而无需引用 TBtools。至于 License，确实是一个需要更多关注的地方。IQtree 此时必然是不存在问题，我们所依赖的软件，由于筛选MIT协议（支持修改源码后闭源，且可以用原始软件名字分发），所以也不存在问题（常常无需修改源码）。
因此，总的来说，「TBtools的一个功能调用了 IQTree，是GPLv2，是否应开源？」这个问题的回复是「不需要」。
我相信，这个回复对于更多 TBtools 插件开发者来说也是一个好事，因为这样就明确，是否插件开发时需要开源。其实...往往不需要，只要不修改源码就不涉及协议问题。如果修改，则应该筛选号协议，如BSD/MIT/Apache。
至于 R 语言或者 Python 语言等，插件本身内容就是开源的，那么完全不存在协议问题。说到此处，如果 TBtools 中真有与协议冲突，那是否？直接做成插件并将插件开源？用户想要使用就安装插件，不想用可以删除，本身跟 TBtools 主程序其实无关。
写在最后
回望初心，TBtools-I 只是通过开发来解决常见的生物数据分析需求；而 TBtools-II 则希望能良好对接丰富的用户需求和用户社群的强大能量。到底，我们想的是让更多人能用上稳定的可靠的软件，简单便捷的完成。至于 Credit，完全不存在需要和必要去索取（TBtools被引已经超过1万），更多的是付出，让更多人用上更优秀的软件。
最后谢谢大伙关注，也期望更多人能一起来贡献插件，我们已经开设了插件开发社群，可以进群一同讨论。
网友评论