Open Source开源软件的授权问题

最近公司里面经常会提到开源(open source)这个名词,很让人感觉新奇。开源与Free并不完全等同,开源也不是没有限制,今天秀楠爸爸就聊聊开源软件的授权问题(license)。

开源要什么授权,代码都放出来了用就是了,这是我们国内不少linux从业者的言论行为,包装了或者使用了Linux的代码,却不开放自己的代码,殊不知,这是违法的,如果LInux的相关代码拥有人对中国公司进行法律诉讼,保证这帮无知法盲全部完蛋。

为何呢?Linux使用的是GPL授权,这种授权充分保证了Open Source不被商业公司进行滥用,它的授权是具有强传染性和强迫性的,任何使用了GPL授权源代码的软件,也就是承认了自己软件遵循GPL授权(这个是很容易理解的,没有人强迫你用,但使用了就代表使用者承认授权),然后,必须开放自己使用了GPL授权源代码的那部分源代码。所以,大部分的商业公司对于GPL授权是敬而远之的,如果被人发现自己使用了GPL授权,那就只有开源一条路可以走。简单而言,大部分软件公司都喜欢copyright版权协议,而GPL这种授权是copyleft,恰恰相反。

当然,世界上并不是只有GPL这一种授权,虽然它是现在开源世界使用最广泛的。如果商业用户想选择,BSD授权或者MIT、Apache授权都是比较合适的选择。他们都可以允许不开放使用一方的源代码,这对于商业公司的保密想法是一种最佳选择。

关于授权的问题,比较经典的例子就是一些黑客程序员因为不满KDE使用了商业授权协议,而自行组织起来开发了GNome。黑客好像多少都有些浪漫气息,对于一点点地不完美都不允许。KDE的基础是QT跨平台GUI库,虽然开发QT的公司最后以双重授权解决了这个争端,保证对于开源软件的使用永远免费,而且有linus这个linux上帝的力挺,GNome还是越来越完善,占据了Linux桌面环境的大部分市场。

跟人找事挑刺,关于“C++开源程序库评话”的回复

在孟岩的blog上看到这篇文章,一时心痒,就写了回复,然后就有了下面这些话。实话实说,我眼高手低,技术水平不高,也不可能写出孟岩这样有文采的文章的。

****所有这些文字都是对文不对人,请勿误解。****

sunxiunan 发表于2006-04-27 11:09 AM

不知道有没有数据上的比较,比如说c++多少开源项目,c多少开源项目。这样空口白说,没有说服力。

说的这些观点,哪些是有“典”的,哪些是自己的,应该说清楚一点。

立论不坚实,煽动性感性的词汇太多,文章总体感觉一般。

myan 发表于2006-04-27 11:33 AM

to sunxiunan:

得出数据很容易,到sourceforge上搜一下就行了,得出观点就难了,因为你从搜到的数据中根本看不出问题。跟在数据后头永远都是迟钝的。你要立论坚实,不过坚实的立论基本上都是马后炮。

文章是我写的,观点当然是我自己的。

风格问题,尊重你的个人的感觉。写东西表达观点而已,风格只是装饰,不求讨天下人喜欢。

sunxiunan 发表于2006-04-29 3:08 PM

十年磨一剑,对于一篇blog来说当然不必如此。

不过,对于一些基本的数据还是应该有一个说明的,我做研究生论文的时候就受过老师的此类批评,比如是否借鉴了别人的观点,不可能都是全新的,整篇文章都是观点未免有些不通,怎么也是有前言、现状、观点、结论这样的一些大结构。

或许我说的有些刻薄,不过既然是一篇稿件,自然要求和blog文章应该有所不同,是要读者花钱的,自己写着爽和让读者有收获还是有区别的吧。

sunxiunan 发表于2006-04-29 3:19 PM

挑一挑刺,我认为应该有论据的地方,

1)如果说在2000年以前,由于C++在工业界的统治地位,这种差距对C++的影响还不大的话,今天,C++在开源领域里薄弱的基础就非常要命了。

sunxiunan:应该有具体数据对比,怎么就要命了?

2)大量的C++开源项目质量不佳,而且经常以一种粗暴的方式要求使用者改变自己程序的风格

sunxiunan:是否有相关的数据评估,这个不佳是从何而来?

3)因为实践证明,没有良好的基础设施支持,C++开发成功的可能性异乎寻常的低。

sunxiunan:这个是最应该有数据证明的地方。

4)在Java、C、Perl、Python、Ruby中,一个优秀的应用程序开发者在积累一定经验之后,不难写出高质量的可复用代码。而在C+
+中,这种事情是非常罕见的,即使是天资卓越、经验丰富的大师级人物,也需要花费多年的打磨,历经几次反复,才能够最终推出受到一致认可的可复用程序库。

sunxiunan:抱歉,这里我并不同意这种观点,说得太过煽情,缺少说服力,难道C++就是一种不同星球的编程语言?程序质量的好坏还是在于写程序的人吧?语言只是工具。

5)以至于Andrei Alexandrescu感叹道,十几岁的少年天才满目皆是,满鬓斑白的优秀程序库设计者凤毛麟角。而在另一个地方,一本C++可复用技术图书的作者总结道,所谓可复用的C++程序库,不可能是设计出来的,只可能是复用出来的。

sunxiunan:我真的想知道大师在哪篇文章里说的这个话。

6)这也就是为什么在2000年后,Bjarne Stroustrup无数次地呼吁社群专注程序库的开发。

sunxiunan:要是有大师说话的原文链接或者书籍页码就更爽了。

抱歉我这样苛刻,或许这些都没有必要,但是如果有这些说明的话,这篇文章会更有说服力,现在网络如此发达,作者搜索原文应该要方便很多。

文章链接在此:

C++开源程序库评话(节选) – 孟岩

C++开源程序库评话(节选)

(本文是即将发表于2006年第6期《程序员》杂志的同名文章的节选。全文请见杂志)

C语言天生就与开放结缘。C最初是作为UNIX的系统编程语言而流行起来的,而UNIX可以被认为是第一个产生重大影响的“开源”软件。随着UNIX的流行,C语言逐渐被人们认识和喜爱。很快的,在各个平台上C语言都成为了流行的甚至是统治性的程序设计语言。大约到1980年代中期,C已经成为人类历史上第一种工业级程序设计世界语。很多人都知道,正是C这样一种世界语的出现,才使开源运动的出现和最初发展成为可能,从这个意义上讲,说C语言是开源运动之母并不十分过分。
但人们不太能够认识到的是,事实上C语言统治地位的获得,却也是早期开放软件运动的直接结果。多数人在回顾这段历史的时候,经常会感染中国文人的不严肃的浪漫主义史观,喜欢把C语言的成功归结为汉高祖斩白蛇般的天赋神格,描述为遥想公瑾当年,谈笑间樯橹灰飞烟灭的轻飘飘。然而如果我们对历史作一些细致的调查,我们会发现C语言绝非有什么天命,而只不过是幸运地扒上了早期开放运动的快车而已。在C语言“小人乍富”的那几年,也还有其它不少程序设计语言具有高性能、可移植、系统开发能力强的特点,决不是只有C骨骼特异,貌若天仙。如果Pascal也能借助一个像UNIX那样的开放的幽灵在欧美大学校园里徘徊,那么我们今天很可能要把begin和end直接映射到键盘上。
如果IBM不是在1970年代极端保守地把一种叫做PL/X的语言牢牢地限定在自己的研究所里,也许整个程序员社群的图腾就不是贝尔试验室的那两个大胡子,而是小沃森实验室里的IBM某院士。事实上,C语言的成功,更须拜开放软件运动之时势所赐,或者更确切地说,C与开放软件是一对共生体,它们相互扶持,相互成就,共同成长兴旺,共同创造历史。

在c++项目中使用opensource library

前两天,cleveland的开发组发来一封群信,意思是说公司的法律顾问已经研究通过了,允许在公司产品中使用boost库。

对于这件事当然是高兴加上赞成。不过也有一些个人看法。

boost号称是c++标准库的预备役,因为里面不少library的质量相当高,比如正则表达式和智能指针,还有线程库socket库等等。不过强大的武器需要操作它的人更加有能力,也就是说,如果不十分熟悉这些库的优点缺点局限性,到时候会出大问题的。

我就在工作中遇到过很搞笑的设计。一个读取配置controllogix gateway信息的dll,将底层通讯部分剥离到另一个dll中,这种设计本身没有大问题,关键是使用了COM的连接点connection point技术,但是数据却使用内存指针直接传递。我只能对设计这种方案的人举双手赞成,实在是高,真没有想到COM技术与内存直接共享都能放到一起。

当初的设计方案毫无疑问是只能启动一个dialog,这时候负责界面的dll和负责通讯的dll都活的好好的,可是总有不如意的地方,有的用户发现竟然能同时启动多个对话框,还认为这是应该的,于是我的噩梦就来了,修改这个设计方案费了我好大的劲,其实可以做的很简单,使用一个线程去进行通讯工作,去掉所有不必要的COM设计,保证稳定。

从DDE到COM技术,到现在的DotNET Platform,我都无法信任它们,能不用就不用。最根本的原因是这些库或框架的代码不开放,出现问题以后,在COM与调用代码之间就形成了无法跨越的障碍。到底是COM的局限?还是我们代码写的有问题?无法进一步跟踪下去,只能想方设法的查找MSDN或者修改COM相关的代码。我就遇到过COM延迟二十几秒的恶心问题,频繁的调用接口的初始化就会导致COM初始化的失败,大约要停止20多秒。这应该是类似于内存碎片这样的问题,就是不能频繁调用new/delete申请释放小块内存,具体原因应该是操作系统自身的毛病,可是不能修改COM方面的代码,只能想法修改自己的。

有人看过Windows2000泄漏出来的代码,里面大多数都是用c写就。也就是说,没有c++的继承多态,当然更不可能有什么COM了。主要的原因应该不难猜测,C++与COM不可控制的东西太多了,而对于操作系统来说,不可控制因素的存在是致命的。当然,对于应用软件来说,这些就不太算是问题,不过用的不熟练的,还是不如不用。(我也见过用的相当熟练的设计方案,简直是帅呆了,自叹不如啊,比如custom moniker,没听说谁用过,潘爱民的书里介绍的也是简单,但是我们一个组件里就大量的使用了这些高级的COM概念,而且设计相当稳定)

回到boost这个话题,如果大连campus有C++标准库的大牛,使用boost肯定会提高代码质量,提高开发水平。但是现状是大家对STL用的都不熟,如果加上Boost,那只能是另一个噩梦的开始。另外,boost毕竟不是标准,稳定性和向后兼容性要差一些,这对于商业软件来说,都是值得仔细考虑的地方。

我的建议是用熟STL,在熟练的基础上再去尝试Loki或者Boost,但是不要将其引入legacy project,可以把它用在一些单独组件中,将其不可预知的风险降低到最小。

这也只是想想而已,就如郭德纲说的那样,谁认识我呀。

宝宝网站更新记录

删掉了某些链接,因为对等原则。
另外,移动了部分链接到“友情链接”页面。

加入“最新更新”功能,大家可以到这里来看
友情链接的最新更新

有些朋友没有列在里面,那是因为没找到RSS Feed链接,如果您有这个链接,请回复通知我,一定加上。像是菲菲妈妈放在了iyaya主页,我也没有找到,真是抱歉了,希望以后有机会开发一个专门的程序。

下一步打算还是丰富宝宝主页的内容,适当地做一些搜索引擎优化(SEO)。因为现在看统计,大部分还是从baidu或者google来的。

因为流量并不大,所以爸爸的技术笔记和妈妈的育儿日记还是会间杂在一起,或许合适的时候还是要另开blog的好,那样结构更清晰,现在日平均独立ip大概一百至二百左右,暂时还不动。

妈妈没有时间写,其实现在关于育婴方面的文章很受欢迎,她写的关于如何让宝宝晚上睡得好,带来了不少访问量呢。

周杰伦真tmd火啊

今天收到了网站服务商的邮件,说我网站上某个目录的访问导致了服务器的崩溃,然后把我这个目录给停掉了。
于是登陆上去找原因,主要就是查流量,一看周杰伦《霍元甲》的下载两天竟然达到了20多G,幸好现在流量足够。
没法,删掉这首歌。