代码故事
首发于代码故事
当你决定把代码开源之前先选择一个合适的 License

当你决定把代码开源之前先选择一个合适的 License

这几天同事 @LeoAshin 折腾了一个自己的博客,问我选择什么协议。这让我想起了之前我遇到的 2 件事。

第一件事发生在知乎,当时有人邀请我回答一个问题:开源 App 被人抄袭到 iOS App Store 怎么办?

事情的经过大概是,@coderyi 开发了一款开源播放器 ElevenPlayer,并于去年 9 月 21 日在 App Store 上架,没想到被 7 个人“抄袭”,功能与视觉上几乎一样,一个总榜 70 名,还一个是付费分类榜 21 名。

对于此种情况,大多数同学都是声援的态度。由于之前我也在各大网络平台声讨过种种抄袭盗版事件,这次自然也要去支援一下。但是当我去看了作者在 github 开源的代码后,又有些犯难了。

于是我在知乎写道:

说点作者不爱听的。

代码最初使用了 MIT License,这应该是对使用者限制最少的协议了吧。使用者可以闭源分发,可以将代码商用。前提是只需要附带一份原协议。

但是别人如果推广的好,或者修改的好,原作者有可能不会从中收益。

我看了作者的代码库,也看了代码提交历史,其中好几条注释为:“由于某些原因作品从 MIT 协议改变成采用 CC Attribution-NonCommercial 中文:署名-非商业性使用协议”。看来作者也意识到问题了,临时修改了协议,然而并没有什么卵用了,因为开发者依然可以在之前代码基础上进行二次开发。

所以啊:选择开源协议要谨慎。

大家还记得 MacOS 和 BSD 的历史吗?

苹果公司看到 BSD 这么优秀的开源系统后,眼前一亮:

源码可以改。

可以闭源。
好,那我就闭源。

可以商用。
哇,正合我意。

最气人的是,改完的 MacOS 比 BSD 还漂亮、还好用。

这 TM 就尴尬了。
这 TM 就尴尬了。
这 TM 就尴尬了。

那让我们回过头来再看看作者开发的这款软件,是百分之百原创吗?很显然不是,作者使用了 ffmpeg、kxmovie、YiRefresh 等开源代码,由于我没有下载安装作者的这个 APP,也就不评价作者有没有按照开源协议去使用这些开源代码。但是从作者文中体现出来的开源认知水平来看,作者应该“违规”使用了这些开源代码。

那我在上文中提到的 MIT License 到底是什么呢?

License 就是版权许可证,里面详尽表述了你获得代码后拥有的权利,可以对别人的作品进行何种操作,何种操作又是被禁止的。我们常用的开源软件协议大致有GPL、BSD、MIT、Mozilla、Apache 和 LGPL。

那么到底该选择哪一个 License 呢?乌克兰程序员 Paul Bagwell 画了一张分析图(下图为阮一峰汉化版)

还有一张更全面并略带恶搞性质的图片,由 diycode 社区的 @flniu 进行汉化:

第二件事发生在 v2ex 社区,帖子标题为:竟然有人直接复制我代码,而不 fork 的!

看到这个标题我就懵了——难道不可以吗!!??(黑人问号.jpg)

之前开发的亲戚关系计算器竟然让人直接拷走…… 简直无语了,开源就可以随便来么?直接代码拷走,放自己仓库就成自己的了。。。。

????

难道不是吗?!

关键是!为什么唯一的一个提交显示的是我提交的?可界面显示确实不是 fork 我的,难道 github 出错了,fork 会断掉关系吗?

作者开发的“亲戚关系计算器”确实不错,我也用过。对于这种开发者我们应该敬佩。但是作者的言论却暴露了自己根本不懂开源。诚然,作者选择把自己的代码放到 github 或者其他开源社区,当别人 star 或者 fork 了自己的代码,作者也会为自己的努力感到欣慰。

哪个所谓的“抄袭者”到底错在哪里了?答案是,没有任何错误。

“抄袭者”并没有篡改原作者的任何 commit 记录,LICENSE 和版权信息也丝毫没动。

很多人以为在 github 上开源代码就是在推广自己了,当发现别人用自己的代码做的事情比自己还好,就又心里不平衡了。他们把自己的代码放到 github 等待别人 star,等待别人 fork,但是当别人使用了代码却没有 fork 时,心里又不平衡了。

所以做开源,先摆好心态

每周推送原创高质量文章,欢迎关注我的公众号

编辑于 2016-12-27

文章被以下专栏收录