|
“革命的基本问题，是政权问题“ 这是我上小学学的第一堂课的内容，在那个疯狂的年代，让不到7岁的我体会到什么叫学习的痛苦, 因此至今印象深刻。 要组建一个开放源码硬件社区，首先要面临的是License问题。 在开放源码软件世界，有太多的License可以选择， 比如GPL, BSD, LGPL, MIT等等。 而开放源码硬件的License, 由于历史比较短， 至今没有正式文本出来，大多数是直接借鉴开源软件的协议。 以开放源码硬件网站opencores为例，目前，使用最多的是LGPL协议。 2001年我在加拿大的Hyperchip热火朝天地造超级路由器的时候， 操作系统选用的不是Linux, 而是看上去怪怪的NetBSD。有一天我忍不住跑去问我们头（一个罗马尼亚人），为什么要选NetBSD做操作系统，他给我的答案有两条：1。Juniper 在用 2。好移植性到其他CPU. 第二条理由很充分， 当时linux只支持很有限的几种CPU, 而NetBSD支持十多种。 而第一条理由就显得不那么充分了， 老奸巨猾的罗马尼亚人给了我一个递归的答案，呵呵。 现在想来，真正的理由是BSD协议比GPL宽松的多， 公司可以随心所欲的修改而不需要把源代码重新发布， 保护自己的知识产权。 当然，也不是真正的为所欲为，起码代码文件头上的BSD说明和一代一代的作者名需要保留。 GPL要严格地多，通俗地说， 具有传染性，如果你的代码中不小心引用了GPL代码， 那你的其他代码也要公开。 退一步， 如果你的代码中没有GPL源代码， 但是你的代码必须和GPL的库静态连接在一起， 那么你的代码也要公开。 在LGPL出来之前，比如说，你的代码中用到了glibc中的库函数， 而又必须和glibc静态编译， 那么这段代码也要公开。 再退一步， 如果你的代码没有引用GPL源代码，但是你目前在发布可执行文件（二进制），这个可执行性文件是在GCC编译的，并可以在linux下运行，这样，你很有可能引用了GCC的库，那对不起，你的源码仍然要公开。* GPL的严格性使许多商业公司望而却步，不利于社区的进一步发展， 因此，LGPL 应运而生。在开放源码硬件社区，用GPL的几乎没有。 LGPL 的意思是允许用库的形式进行引用。 比如说，欧洲航天局大名鼎鼎开放源代码处理器LEON, 就是用的LGPL协议。 如果你的SOC 设计中仅仅是采用 LEON 作为CPU而不对它的内部进行改动，那么你的其他部分无须公开。 当然，如果你修改了LEON, 或者把它的内部实现代码混在你的代码中，那你必须公开你的源代码。 当然，最宽松的是MIT协议，和BSD协议一样你可以为所欲为，甚至不需要费劲在头文件中引用BSD协议，但是，新代码中，你必须提到原有作者的名字，体现一种尊重。 开放源码硬件中MIT协议的例子是 OpenFire, 这种开放源码的处理器和Xilinx的Microblaze 兼容，甚至可以使用大多数Xilinx ＥＤＫ提供的工具。 如果你自己建立一个开放源码硬件项目，从头开始起步，一行别人的具有license 的代码都没有抄，那么你需要什么license呢？ 这时候，我强烈推荐你从LGPL和MIT 中选一个。做选择的主要根据是你对我国知识产权保护的信心和程度。 如果你选了LGPL（既然大多数开源硬件这么选，我们也这么选）, 然后公布你的代码，几个月后， 如果发现哪个个公司的板子上跑的东东是你设计的，经过一番调查，发现他的芯片中或FPGA 中竟然改了你的流水线设计， 呵呵，找法庭告他去！法庭经过一番调查，你居然在弹尽粮绝银两耗尽之前，打嬴了官司（这种情况发生的可能性太低了）。 因此，现实可操作的，反倒是BSD或MIT。 在目前情况，国内的开源迷们大多只有索取，没有回馈，干脆好人做到底，选MIT 协议算了。 那意思就是要抄就抄吧，求求你告诉别人是从俺这里抄的行不？ 最后一种情况 如果我很懒，嫌烦，我的代码都公开，我也不想要任何license声明， 可不可以？．．．．．．答案是： 坚决不行！ 比如说， 你辛辛苦苦开发了一款开放源码的游戏机，让某个公司抄去做了SOC赚了大钱，原因是用的是开源的硬件设计， 能做到价钱便宜量也足。不久，你收到一封措词严厉的律师函，让你停止在网上发布你的代码，因为你侵犯了该公司的知识产权（一天前刚注册并登记的）。他注册了倒打一耙，这时候，你岂不是比窦娥还冤 ？ 还是毛主席说得好，“革命的基本问题，是政权问题“ 。 *修改历史 |