@woshihoujinxin 可以先用默认的配置

@yigekuyou 在 如果你的开源软件被人分发，应该如何应对 中说：

错误日志应该后提交给我还是提交给开发者

如果是你修改的版本, 一般先提交给你, 如果你发现非修改部分造成的, 你再提交到上游

就算GPL也保留了闭源的能力，传染性让GPL协议可能会和其他开源协议产生冲突，以链接的形成的lgpl反而安全些

重写从开源协议上应该是衍生物，也不需要纯净室开发

@Littlefean 可以搞赞助 vue 好像就这么发展的。但是mit使用好像并不需要手动授权好像

@sunrisepeak 在 开源协议总结 中说：

CC和OSI感觉最主要的冲突点应该是 "是否能商用自由"

确实，NC直接禁止商用了。CC系列感觉范围主要是一些创意作品而非软件了。感觉有人往github上发自己创作的一些“开源文章”可能有用吧。

@Littlefean 在 MIT这个非常宽松的开源协议究竟保留了什么？ 中说：

如果把游戏引擎的runtime打包到游戏里的时候一般就要包含了这部分的MIT协议。

但这个回答是被动的，它是否需要开发者主动在“关于界面”或“开发者界面”里提出使用了这个引擎作为技术支持？

一般来说是不强制要求在界面特别显示, 但是一般建议是在关于中提到。 但似乎这就是属于 "宽松" 区域, 但如果是一个要发行的商业软件, 一般默认尽可能的在关于进行标识比较好

@Littlefean 开源协议 很多时候是为了传播和共享 会偏向 "宽松" , 并再使用上一般默认大家会尽可能的遵守 (似乎某种程度一些协议可能还有故意不想受很多规则的限制甚至包括法律? 但符合要符合现实世界规则一般还是要很多考虑的, 可能也是一个发展的过程...)

确实，忘了版本号的问题了，依赖都是有固定版本号的，同一版本号里开源协议不能变但版本号变了开源协议就可以变了。