主题：【原创】鸿蒙与盘古 - 智业时代的蒸汽机端倪已现 -- 泉畔人家

最后的判决，小部分和律师能力有关，大多数和当时的局势有关。所举的两个例子，其实和美国的反垄断氛围有关，正想找机会敲打大公司呢，这是大公司必输的局。这点他们做得比我们好，没有南山必胜客这样的主场优势。

但是，有些标准有些库是说明了接口是有版权的，如果这个库没有像微软/苹果那样的全球影响力，一般不会有人去碰那个禁忌，非要自己实现一套，然后到法院上辩个明白。小团体或个人和微软/苹果这样的大公司打官司，就算是输了也是赢了，只要你能把事闹大了。注意看这些胜诉的案例，原作者是没有获利的，完全是活雷锋，兴趣使然。用钱解决不了的问题才是大问题。他走非盈利的学术研究的路子，商业公司下不了口。但如果你为此获利了，那就要被商业公司拿捏了。

比如Android系统，你能不能完全抛开JAVA那一套，基于它底层的服务接口和C++代码库另外实现一套呢？技术上完全没有问题。讲法律的话就知道GOOGLE在里面留有坑。当初阿里OS被一棒打死，没见到法律武器。后来做FFOS的时候，MOZILLA和GOOGLE比较熟，专门托人问了这个问题，答复是你们先做着吧，算是留了一条路。后面FFOS死了，也就不知道GOOGLE藏着啥黑招了。

再有一个例子，LINUX属于GPL2.0 ，那么在其上能不能有不开源的商业软件。因为不论哪个软件都一定要调用LINUX的系统调用。按照原始的说法，调用GPL软件的接口就必须是GPL的，否则不能调用。为这事又争论了好久，最后结论是直接调用才要求GPL传染，LINUX的系统调用属于间接调用，不需要GPL传染。这算是解决了用户空间的闭源软件问题。

但是如果商业驱动想闭源怎么办？在内核空间运行必然是直接调用。最早的解决手法是把商业驱动做在bootloader里，先于LINUX存在，再定制一个LINUX与之交互。但这种方法增加了工作量，还要定制LINUX，不好推广。现在的方案就是LINUX驱动只做简单的薄层，开源，反正你也看不懂他想干啥。干活的是用户空间的一个闭源的代码库。你要是技术特别牛，你基于那个薄层实现一个相同功能的代码库呢？技术上完全没有问题，有人就这么干了，开源了。但是要做商业产品，还是老老实实给商业公司交钱用他们的私有版本，否则谁也不知道有什么坑等着你。