开源还是闭源?这是个大问题.辛辛苦苦撸出来的代码,怎么用它自然你说了算.出于各人的喜好,大家尽可以选择一个合适的分享或者不分享的方式. 个人觉得这无关道德.

但是, 若是别人用 GPL License 分享了代码,而你却擅自修改 License, 把你的代码设置为闭源, 这就不仅是不道德的问题了, 理论上说, 你已经违反了你和原作者的协议, 是违法的.

在实际使用中, 对于各种传染协议, 尤其是 GPLv3 之类, 我们被要求自己的代码也使用同样的 License. 若有人打算闭源, 或者只是希望使用 MIT License, 那也是不能直接使用的.

但是,这是否表示 MIT License 的工程就完全不能引用GPL呢? 前人告诉我们, 有讨巧的方法. 基本原理是:

  • 源码引用和静态引用都是违反版权的, 但是可以使用动态链接库的方法引用.
  • 版权是持有人主诉才行, 换言之, 若我写了个闭源代码, 然后被人偷了, 但我不去追究, 那对方也不算违法.

所以我可以先写个 wrapper 调用 GPL License 的程序. 这个 wrapper 必须是遵循那个程序 License 的规定. 然后自己的主程序则只调用 wrapper, 不调用原来 GPL 的内容. 那么自己只侵犯了自己, 我们选择不追究自己就行...

比如有 GPL 代码被打包为 xxx.a, 头文件为 xxx.h, 你可以构造一个 xxx_wrapper.h 和 xxx_wrapper.so, xxx_wrapper.h 是独立的, 只在 xxx_wrapper.cc 文件中引用 xxx.h, 编译成 xxx_wrapper.so, 而你的工程只调用 xxx_wrapper.h 和 xxx_wrapper.so 两个文件.

这种情况下,你的 xxx_wrapper.h 和 xxx_wrapper.cc 都是必须遵循 GPL License 的, 而引用 xxx_wrapper.so 因为是动态链接, 所以理论上是合法而不受 GPL 约束.

实现这一点, 有一个问题, 就是 xxx_wrapper.h 不得 include xxx.h 这个头文件, 否则依然是调用了 xxx 这个工程的内容, 所以要自己声明个 struct 类型, 然后在 .cc 中具体定义这个 struct.

leveldb 是一个 MIT License 的工程, 对使用者几乎没有任何约束, 但我还是用它做个 wrapper, 实现一些基本的功能, 从版权上说, 其实并没有什么意义. 就当 helper 用吧.

头文件参考此处, 实现参考此处.

许可证是任何人之间的约定, 是点对点的, 你情我愿的关系 .我从不觉得一个开源的软件就天生高冷一点, 而闭源就格外的罪恶. 我最初做这个 leveldb 的 wrapper 的动机, 其实主要是感觉直接引用 leveldb 每次都需要弄上一堆检查, 所以弄了个简单的宏, 试图把复杂的配置往下埋一下. 但每个人对 leveldb 的使用都有一些自己的想法, 适用于我的一组宏对别人恐怕只是毫无意义的增加个栈, 所以仅介绍下 wrapper 另一个用途.

而且类似这种方法, 还可以构造一些基于 C 的 API, 也就是传说中的 C 调用 C++ 啦.

后记,

开源是一个很严肃, 很奉献的事情. 它是把你的努力放到共有领域, 以供他人使用. 你在放出的时候, 应该很明确知道你给公众授权了什么.

比如 GPL, 它主要是期望能够被非商业地使用, 要求使用者能够把自己的改进也反馈回来. 作为使用者, 你得到了代码, 你被限制把代码藏起来卖钱, 但是你在告诉所有人你的修改后, 可以卖 binary release. 比如我最喜欢的公司, RedHat, 他们卖的就是二进制和服务, 同时 CentOS 则是使用他们放出的代码再编译的结果.

比如 BSD, 它授予了用户使用权, 修改并商业化权, 但是禁止用户使用自己的名字做广告.

比如 Apache v2, 它授予了使用权, 商业修改, 并且显式授予用户专利使用

比如 MIT, 除了显式声明了专利使用, 基本一句话: 随便玩, 随便改, 只要别用坏了找我麻烦就好.

作为开发者, 在开源的时候, 你应该知道你做了什么, 而不是觉得 "妈呀, MIT 好流行的样子", 结果真的被人甚至基本没怎么改动, 直接打个包放 apple store 了, 回头又觉得被人占了便宜. 大哥呀, 这本来就是你送别人的啊.

不用说更遥远的二三十年前的史前了, 哪怕是十几年前, 那个各种公司壁垒森严, 代码重重保护, 敝帚自珍的年代, 妈的每个公司自己搞一套弱逼实现, 还觉得自己特了不起, 简直无语. 正是那群心怀理想的奉献者, 抱着改变这个世界的想法, 用代码, 用法律, 生生创出一条路来. 而今的世界, 连某软那种老古董都开始学着和世界分享更多的实现了.

作为我们, 幸运的后来者, 我觉得很多时候还是请满怀敬意充分利用前人的轮子, 并且努力改变这个世界, 以为回报.

Categories: Code

Yu

Ideals are like the stars: we never reach them, but like the mariners of the sea, we chart our course by them.

4 Comments

hewr · July 27, 2015 at 15:22

Google Chrome 44.0.2403.89 Google Chrome 44.0.2403.89 Mac OS X  10.10.4 Mac OS X 10.10.4

为何动态链接就不违反了?

    yu · July 27, 2015 at 19:37

    Google Chrome 43.0.2357.134 Google Chrome 43.0.2357.134 Mac OS X  10.10.4 Mac OS X 10.10.4

    @hewr
    动态链接和静态引用最大的区别就是,前者是编译好的内容,而后者不是,后者你不管怎么狡辩,你这些代码都只能算是那个库的不可分割的一部分,而前者还可以狡辩下,他们”没有多大关系”.
    我理解下,LGPL仅仅要求你公开你对原始代码的修改,而GPL则要求连衍生产品也公开.但是,动态链接到底算不算”衍生”产品呢?目前还处于争议状态([1],[2])

    但是,无论如何,

    由于迄今为止没有案例表明有人以动态链接的方式来绕过GPL的条款或者并被起诉,动态链接的限制已经是事实上地(de facto)有效,不论它是否是法律上地(de jure)有效。

    所以其实我也不懂啦…就个人,自己的代码基本用MIT,若引用也尽可能引用MIT,或者BSD.GPL什么还是有点怕怕不敢去动

      hewr · July 28, 2015 at 09:57

      Google Chrome 44.0.2403.89 Google Chrome 44.0.2403.89 Mac OS X  10.10.4 Mac OS X 10.10.4

      @yu
      好吧……好详细,但我还是觉得不应该冒这险,LGPL还好,GPL还是自己造个轮子吧

        yu · July 28, 2015 at 14:53

        Google Chrome 43.0.2357.134 Google Chrome 43.0.2357.134 Mac OS X  10.10.4 Mac OS X 10.10.4

        @hewr 我也是这样想的.

        GPL的初衷大约是想要让开源代码能薪火相传,但感觉传染性本身也有点否认继承者的努力,让人不得不开源.主观的愿望和被迫的行为给人的感觉是不一样的.

Leave a Reply to hewr Cancel reply

Your email address will not be published. Required fields are marked *