红旗与GPL的问题

作者: 阿若
日期: 08-01-03 11:41

长期以来，外界对红旗产品是否遵守GPL有许多责难和质疑，完全答复如下：
1。红旗所开发的产品中，凡是基于GPL软件的部分，将遵守GPL许可，向红旗产品的用户提供源代码。方式为随正式版产品一起发送源代码光盘或从红旗用户支持网站下载源代码包。

2。红旗所开发的产品中，包含有第三方厂商的软件，这部分软件为商业软件，不提供源代码。

3。红旗所开发的产品中，包含有非基于任何GPL软件，而由红旗公司完全自主开发，从而享有完全自主版权的软件。这部分软件将视情况的不同采用不同许可证，有的将被红旗公司开放源代码成为GPL软件，有的则成为商业软件。

红旗产品中使用的字库及输入法版权问题：

东文字库，版权所有:长沙东文软件有限公司；

方正字库，版权所有:北京北大方正电子有限公司。

智能ABC输入法，版权所有:由北京大学科技开发部；

紫光拼音for Linux输入法，由清华紫光公司与红旗公司共同开发，核心引擎版权所有?北京清华紫光软件股份有限公司，用户界面部分版权所有?北京中科红旗软件技术有限公司；

统一码输入法，版权所有:徐万胥。

控制面板是红旗完全自主开发的一个插件，与Konqueror无缝集成。红旗公司享有完全版权。

作者: chase 发布时间: 2003-08-01

作为商业公司，有版权的东东似乎少了一点点。

作者: victor2002 发布时间: 2003-08-01

chase 版主
引用的这个答复太复杂了，如果换一种方式来答复，比如由红旗做出贡献，又可以遵守GPL协议的东西列表如下：
1。..
2。..
估计能简洁不少吧（或许没有吧），哈哈

作者: chainsaw 发布时间: 2003-08-01

红旗如果不遵守GPL就算了，后台硬，谁也不敢怎么样？
何必如此？

"控制面板是红旗完全自主开发的一个插件，与Konqueror无缝集成。红旗公司享有完全版权"

被人骂的多了，知道出来做做样子了？

干脆说kernel和kde也是自由知识产权就OK了。

建议GPL改一条，所有GPL软件禁止红旗使用，为什么，这是一个只知道索取不知道奉献的东西。

错了就是错了.承认错误比掩盖和狡辩更受人尊重。

作者: cjacker 发布时间: 2003-08-02

KDE 是 GPL 协议的软件，所以为 KDE 开发的任何软件，只要使用了KDE的 API
就应当以 GPL 协议发布，并公开源代码。

引用:

最初由 chase 发表
作者: 阿若
日期: 08-01-03 11:41

长期以来，外界对红旗产品是否遵守GPL有许多责难和质疑，完全答复如下：
1。红旗所开发的产品中，凡是基于GPL软件的部分，将遵守GPL许可，向红旗产品的用户提供源代码。方式为随正式版产品一起发送源代码光盘或从红旗用户支持网站下载源代码包。

2。红旗所开发的产品中，包含有第三方厂商的软件，这部分软件为商业软件，不提供源代码。

3。红旗所开发的产品中，包含有非基于任何GPL软件，而由红旗公司完全自主开发，从而享有完全自主版权的软件。这部分软件将视情况的不同采用不同许可证，有的将被红旗公司开放源代码成为GPL软件，有的则成为商业软件。

红旗产品中使用的字库及输入法版权问题：

东文字库，版权所有:长沙东文软件有限公司；

方正字库，版权所有:北京北大方正电子有限公司。

智能ABC输入法，版权所有:由北京大学科技开发部；

紫光拼音for Linux输入法，由清华紫光公司与红旗公司共同开发，核心引擎版权所有?北京清华紫光软件股份有限公司，用户界面部分版权所有?北京中科红旗软件技术有限公司；

统一码输入法，版权所有:徐万胥。

控制面板是红旗完全自主开发的一个插件，与Konqueror无缝集成。红旗公司享有完全版权。

作者: james_su 发布时间: 2003-08-06

引用:

最初由 james_su 发表
KDE 是 GPL 协议的软件，所以为 KDE 开发的任何软件，只要使用了KDE的 API
就应当以 GPL 协议发布，并公开源代码。

不要信口开河。

KDE的库以LGPL发布，应用程序一般以GPL发布，其中一些如kwin等基本上约等于public domain。

作者: singer 发布时间: 2003-08-06

引用:

最初由 singer 发表
不要信口开河。

KDE的库以LGPL发布，应用程序一般以GPL发布，其中一些如kwin等基本上约等于public domain。

老大，谁在信口开河呀？KDE 所有的程序都是基于 qt 的，而 qt 是 GPL 的。所以简单推导 KDE 的所有组件都必须是 GPL 的，否则就违反了 GPL 协议。

作者: james_su 发布时间: 2003-08-07

引用:

最初由 james_su 发表
老大，谁在信口开河呀？KDE 所有的程序都是基于 qt 的，而 qt 是 GPL 的。所以简单推导 KDE 的所有组件都必须是 GPL 的，否则就违反了 GPL 协议。

问题就出在你这个简单推论上。去看看kde的文档吧。

作者: singer 发布时间: 2003-08-07

引用:

最初由 singer 发表
问题就出在你这个简单推论上。去看看kde的文档吧。

qt是GPL的，所有基于QT构建的KDE程序当然是GPL的，
在kde的底层，kdelibs和kdebase中的部分是多许可方式的
我就像问问你了，基于qt的UI实现是不是应该是GPL的？

苏哲的推论当然是正确的，只要基于QT就必须GPLed。
如果代码跟QT无关，kdelibs中肯定是有的，当然可以是多许可的，
如果代码和GPled的代码融合甚至密不可分，你说应该是什么的？
难道是公共域许可，让这一部分GPLed代码编程每个人口袋里自己的东西？

中国绝大部分用linux的人不懂GPL的，所以红旗说什么都行，封闭代码也无所谓了。

后台硬，死不了的。

作者: cjacker 发布时间: 2003-08-07

引用:

最初由 singer 发表
不要信口开河。

KDE的库以LGPL发布，应用程序一般以GPL发布，其中一些如kwin等基本上约等于public domain。

"KDE的库以LGPL发布"这句比较搞笑，你干脆说kde是BSD许可的算了。

基于GPL的软件变成了LGPL,基于LGPL的就变成了红旗的自有知识产权，
比SCO还牛啊。

不能一概而论，但是也不能以偏概全.

封闭代码的接口可以有很多，最简单并且不需要解释的就是：
我就是不愿意公开，你能怎么样？

作者: cjacker 发布时间: 2003-08-07

引用:

最初由 james_su 发表
老大，谁在信口开河呀？KDE 所有的程序都是基于 qt 的，而 qt 是 GPL 的。所以简单推导 KDE 的所有组件都必须是 GPL 的，否则就违反了 GPL 协议。

苏哲，干脆我们去KDE.org游说一下，让KDE也考虑改改许可，加多一条：
禁止redflag come from china使用KDE组织release的任何代码，这样就可以解决问题了，呵呵。

以后我们那里有什么开发，都会加多这一条，我觉得是有必要的。

作者: cjacker 发布时间: 2003-08-07

引用:

最初由 cjacker 发表
苏哲，干脆我们去KDE.org游说一下，让KDE也考虑改改许可，加多一条：
禁止redflag come from china使用KDE组织release的任何代码，这样就可以解决问题了，呵呵。

以后我们那里有什么开发，都会加多这一条，我觉得是有必要的。

如果是那样的话，你就违反你奉为圭臬的GPL了，呵呵。

作者: shyj 发布时间: 2003-08-07

引用:

最初由 cjacker 发表
"KDE的库以LGPL发布"这句比较搞笑，你干脆说kde是BSD许可的算了。

基于GPL的软件变成了LGPL,基于LGPL的就变成了红旗的自有知识产权，
比SCO还牛啊。

不能一概而论，但是也不能以偏概全.

封闭代码的接口可以有很多，最简单并且不需要解释的就是：
我就是不愿意公开，你能怎么样？

19.2. License Usage by KDE
As mentioned earlier, the KDE project does not mandate any single Open Source license as long as the license is Open Source. By far, the most common license for the KDE libraries is LGPL, and the most common for applications is GPL. Code that we may explicitly want people to incorporate into (possibly closed-source) applications may use other licenses.

作者: singer 发布时间: 2003-08-07

引用:

最初由 cjacker 发表
苏哲，干脆我们去KDE.org游说一下，让KDE也考虑改改许可，加多一条：
禁止redflag come from china使用KDE组织release的任何代码，这样就可以解决问题了，呵呵。

以后我们那里有什么开发，都会加多这一条，我觉得是有必要的。

ML里带的fcitx，就参考了rfinput的代码。

作者: shyj 发布时间: 2003-08-07

引用:

最初由 singer 发表
19.2. License Usage by KDE
As mentioned earlier, the KDE project does not mandate any single Open Source license as long as the license is Open Source. By far, the most common license for the KDE libraries is LGPL, and the most common for applications is GPL. Code that we may explicitly want people to incorporate into (possibly closed-source) applications may use other licenses.

注意是kde library不是kde!

kde library严格的讲仅仅限于KDElibs。
而kdelibs基于qt的部分必须是GPLed.
KDE组织没有权利也不会傻到把基于GPLed的东西LGPLed.

作者: cjacker 发布时间: 2003-08-08

引用:

最初由 shyj 发表
如果是那样的话，你就违反你奉为圭臬的GPL了，呵呵。

如果GPL中能加多这一条，我觉得也不错。

GPL是一款license，不是信奉不信奉的问题，是基本的游戏准则。

作者: cjacker 发布时间: 2003-08-08

引用:

最初由 shyj 发表
ML里带的fcitx，就参考了rfinput的代码。

这不可以吗？
看看fcitx的license，没什么吧？

就怕参照甚至使用了之后还封闭代码。

作者: cjacker 发布时间: 2003-08-08

引用:

最初由 cjacker 发表
这不可以吗？
看看fcitx的license，没什么吧？

就怕参照甚至使用了之后还封闭代码。

至少说明红旗对自由软件作出了贡献。而且ML正在使用rf的贡献。

作者: shyj 发布时间: 2003-08-08

引用:

最初由 cjacker 发表
注意是kde library不是kde!

kde library严格的讲仅仅限于KDElibs。
而kdelibs基于qt的部分必须是GPLed.
KDE组织没有权利也不会傻到把基于GPLed的东西LGPLed.

谁告诉你KDE library只限于kdelibs? 出处？请给出原文。

再说了，去学点历史吧。照你的说法，在QT GPL之前，KDE是不是还得采用商业许可啊？

作者: singer 发布时间: 2003-08-08

居然会有与KDE紧密集成而没有用到KDE代码的说法，一个稍有知识的人都知道这几乎是不可能的，除非你告诉我你没有用到一点KDELibs的GPLed代码。当然用没用到，我看不到源代码，我当然不知道。
还有一种无耻的人就是：我只开放用到了GPL的那部分代码!!
按照GPL的条款，既然你整个软件用了GPL的代码，就该GPL你整个软件的代码。
不想GPL源码就直说，不要惺惺作态，更让人恶心。

在KDE的条款加上一条不如直接状告他们来得省事，
好像FSF对违反GPL的起诉有一定的资金支持，不用
自己掏腰包。

作者: theseus 发布时间: 2003-08-08

引用:

最初由 singer 发表
谁告诉你KDE library只限于kdelibs? 出处？请给出原文。

再说了，去学点历史吧。照你的说法，在QT GPL之前，KDE是不是还得采用商业许可啊？

按照你的说法，就可以光明正大的封闭所有代码了，
怎么了,kernel是gpl的，又怎么样，谁说基于GPL就必须GPL，我照样给他商业许可。

KDE Library, Not the whole K Desktop Envirment.
你知道Kdelibs 是什么意思吗？
kde libraries
你知道kdebase是什么意思？
KDE 基本环境，包含了基本的软件和核心组件konqueror.

你一句KDE是LGPL的，很多软件都无法幸免。我想问一问：konqueror是不是kde library? noatun之类的KDE官方发布带的软件是不是也属于kde library?
你的解释太牵强了吧。

至于QT/KDE的老的许可问题，是因为QT许可证不清晰的原因，就好像国内很多软件用VC开发但是不给MS钱一样，可绝对不是GPL软件LGPL化，建议你先好好看看GPL。然后再来回答一个问题，基于GPL的软件是不是可以非GPL.

你的推理太牵强了。
至于历史，我应该不会比你更不清楚。

作者: cjacker 发布时间: 2003-08-08

引用:

最初由 shyj 发表
至少说明红旗对自由软件作出了贡献。而且ML正在使用rf的贡献。

这是不是应该的？
还是我们应该因为又fcitx而对rf感恩戴德？

今天能有红旗也好，任何一个发行版也好，都是借鉴的结果，
关键问题是要有东西可以借鉴。

没有人否认过rfinput.这是红旗对开源世界的唯一贡献并且是历史上的，
前面有文章提过
rf4中的红旗输入法应该就没有source了，

fcitx作者在说明文档中说借鉴，未必直接用起代码，可能是思想。

除此之外，能不能更多一点?如果rf代表中国linux的水平和精神，我觉得中国人想哭都晚了。

作者: cjacker 发布时间: 2003-08-08

引用:

最初由 cjacker 发表
按照你的说法，就可以光明正大的封闭所有代码了，
怎么了,kernel是gpl的，又怎么样，谁说基于GPL就必须GPL，我照样给他商业许可。

KDE Library, Not the whole K Desktop Envirment.
你知道Kdelibs 是什么意思吗？
kde libraries
你知道kdebase是什么意思？
KDE 基本环境，包含了基本的软件和核心组件konqueror.

你一句KDE是LGPL的，很多软件都无法幸免。我想问一问：konqueror是不是kde library? noatun之类的KDE官方发布带的软件是不是也属于kde library?
你的解释太牵强了吧。

至于QT/KDE的老的许可问题，是因为QT许可证不清晰的原因，就好像国内很多软件用VC开发但是不给MS钱一样，可绝对不是GPL软件LGPL化，建议你先好好看看GPL。然后再来回答一个问题，基于GPL的软件是不是可以非GPL.

你的推理太牵强了。
至于历史，我应该不会比你更不清楚。

至少你比苏哲还要进一步，承认使用kde API不一定全是GPL。

好吧，咱们再来看看别的。kdelibs属于kde libraries，但什么地方说kde libraries 只有kdelibs?

konqueror和noatrun都是GPL的，这没错，可是他们的插件也必须GPL么？错了，比如flash，konqueror可以使用macromedia的flash插件，你难道也要求macromedia开放flash插件的代码么？我看了一下红旗的控制面板，与rh曾使用的（和中软现在还在用的)kcp://不同，它是针对一种特定文件扩展名采用的特定插件，和你在konqueror里点击PDF文件自动调kghostview机制应该是一样的。我想他们说无缝集成应该是这个意思。

关于QT与KDE的关系是很复杂的，绝对没有你说的那么简单。QT历史上没有GPL之前也是有许可证的，并非不清晰。可是trolltech与KDE组织之间有比较特殊的关系。例如，kdelibs里，就使用了QT。按你的说法，岂不是kdelibs就不能LGPL了？可事实是它是LGPL的。

kernel是GPL的，可Linus允许有binary only的模块，又怎么解释？模块可是一定要调用内核提供的接口。

现实世界是很复杂的，不能拿条条来套。

作者: singer 发布时间: 2003-08-08

引用:

最初由 cjacker 发表
这是不是应该的？
还是我们应该因为又fcitx而对rf感恩戴德？

今天能有红旗也好，任何一个发行版也好，都是借鉴的结果，
关键问题是要有东西可以借鉴。

没有人否认过rfinput.这是红旗对开源世界的唯一贡献并且是历史上的，
前面有文章提过
rf4中的红旗输入法应该就没有source了，

fcitx作者在说明文档中说借鉴，未必直接用起代码，可能是思想。

除此之外，能不能更多一点?如果rf代表中国linux的水平和精神，我觉得中国人想哭都晚了。

你用了人家的东西（或从人家那里学的东西）就不该有一丝感激之心么？红旗还开放了炎黄中文平台，向glibc贡献了最早的18030补丁（虽然后来有其它人更好的实现）怎么能说rfinput是唯一的贡献？听阿若说他对pixelplus的中文补丁源代码也随产品出去了，相信还有很多。

在fcitx较早的readme里，明确说“有许多代码是直接抄来的”。

作者: shyj 发布时间: 2003-08-08

引用:

最初由 shyj 发表
你用了人家的东西（或从人家那里学的东西）就不该有一丝感激之心么？红旗还开放了炎黄中文平台，向glibc贡献了最早的18030补丁（虽然后来有其它人更好的实现）怎么能说rfinput是唯一的贡献？听阿若说他对pixelplus的中文补丁源代码也随产品出去了，相信还有很多。

在fcitx较早的readme里，明确说“有许多代码是直接抄来的”。

按照你这个说法，惭愧的不是我，而应该是中国人，至少我用了，我承认，我公开source，我注明M是千千万万名志愿者辛勤劳动的结果，我什么时候说过“自有知识产权”？，什么时候close source过？

作者: cjacker 发布时间: 2003-08-09

引用:

最初由 singer 发表
至少你比苏哲还要进一步，承认使用kde API不一定全是GPL。

好吧，咱们再来看看别的。kdelibs属于kde libraries，但什么地方说kde libraries 只有kdelibs?

konqueror和noatrun都是GPL的，这没错，可是他们的插件也必须GPL么？错了，比如flash，konqueror可以使用macromedia的flash插件，你难道也要求macromedia开放flash插件的代码么？我看了一下红旗的控制面板，与rh曾使用的（和中软现在还在用的)kcp://不同，它是针对一种特定文件扩展名采用的特定插件，和你在konqueror里点击PDF文件自动调kghostview机制应该是一样的。我想他们说无缝集成应该是这个意思。

关于QT与KDE的关系是很复杂的，绝对没有你说的那么简单。QT历史上没有GPL之前也是有许可证的，并非不清晰。可是trolltech与KDE组织之间有比较特殊的关系。例如，kdelibs里，就使用了QT。按你的说法，岂不是kdelibs就不能LGPL了？可事实是它是LGPL的。

kernel是GPL的，可Linus允许有binary only的模块，又怎么解释？模块可是一定要调用内核提供的接口。

现实世界是很复杂的，不能拿条条来套。

konqueror通过nsplugin提供对mozilla老插件的支持，比如real, acrobat reader, flash等等，这是没有问题的，但是，红旗的插件不可能是这种方式的吧？他肯定要用到部分的kde代码，这就是说不清的地方。

至于GPL问题，我从来没有否认kde是多许可的，在很早以前很多人明确表示应该支持GNOME，就是因为QT的许可不清晰，或者说是商业的许可方式。

但是LGPL的KDE libraries应该仅仅限于kdelibs的部分, 如果说kdebase及以上软件级别的代码也是LGPL的，我个人认为是牵强的。

至于许可，现在大家基本没有什么太深的概念了，甚至慢慢的不去管他，GPL本身存在问题，不利于保护商业公司，但是这个基本规则还是要遵守的，如果不能，可以使用FreeBSD最基础平台，BSD的license是清晰，没有任何可争论的，可以close所有source,除了GPL软件。

作者: cjacker 发布时间: 2003-08-09

关键在于源码问题，可能红旗没有直接使用基于GPL的源码，所以它可以不公开源码，不过它可能"参考"过^_^

作者: simonhuan 发布时间: 2003-08-09

我觉得大家没有必要再在这个问题上争了。
我对红旗没有什么好感。他仅次于M$（厌恶程度）,但是，至少在国内，红旗已经算是比较遵守GPL&LGPL的公司了。至少在国内各Linux发行公司中（Exclude Turbo Linux），是应该受到我们尊敬的。
还记得蓝点抱着一个控制台汉化技术close不放的事吗？
听说中软的连GCC都不提供（以为自己是Sun吗？）
红旗只不过是close了一个没有多少技术含量的控制台就是了。如果大家看不惯，可以用RedHat的阿？也不见得难用多少。
红旗毕竟的一个商业公司，他的开发人员也许就是那个在论坛上诲人不倦的“高手”。人总是要吃饭的阿。
我们大部分人都是有其他工作，Linux也只不过是玩玩儿已，何必如此认真呢？
就GPL的精神言，从来没有排斥过商用（close source）软件。只要那个程序和GPL的程序不在一起编译就不受GPL的限制。GPL中有，通过用户界面（我理解应该是包括GUI&CLI）使用GPL的软件的软件可以是close src的。我不知到rf' control panel的设计。但是，就我的程序设计经验看。rf是可以绕过GPL协议的。

作者: nzinfo 发布时间: 2003-08-11

引用:

最初由 cjacker 发表
konqueror通过nsplugin提供对mozilla老插件的支持，比如real, acrobat reader, flash等等，这是没有问题的，但是，红旗的插件不可能是这种方式的吧？他肯定要用到部分的kde代码，这就是说不清的地方。

至于GPL问题，我从来没有否认kde是多许可的，在很早以前很多人明确表示应该支持GNOME，就是因为QT的许可不清晰，或者说是商业的许可方式。

但是LGPL的KDE libraries应该仅仅限于kdelibs的部分, 如果说kdebase及以上软件级别的代码也是LGPL的，我个人认为是牵强的。

至于许可，现在大家基本没有什么太深的概念了，甚至慢慢的不去管他，GPL本身存在问题，不利于保护商业公司，但是这个基本规则还是要遵守的，如果不能，可以使用FreeBSD最基础平台，BSD的license是清晰，没有任何可争论的，可以close所有source,除了GPL软件。

你又进了一步，至少说明“个人认为是牵强的”，而不是当作不证自明的公理，看来咱们有希望达成一致，呵呵。

首先，我想红旗的控制面板不使用nsplugin接口，因为在mozilla中好像不能使用。（但是使用nsplugin接口从技术上讲没有什么不可以，如果红旗使用nsplugin接口，咱们是不是就不需要在这里讨论了？）

其次，是否不使用nsplugin接口就一定要使用GPL的kde代码呢？不是这样。konqueror只是一个kparts容器，调用来view各种格式文件时通过kparts接口调用kparts组件，比如kghostview，比如作了kparts包装的vim。而kparts作为kde的组件模型，其接口正是在kdelibs里，而非konqueror独有。你自己写一个kparts容器，一样可以使用这些Kparts组件。因此，kparts组件无需任何konqueror代码，只要使用Kparts接口即可，如同flash插件使用nsplugin接口一样。比如vim，只是用kparts接口包装，就可以在konqueror中使用。而kparts在kdelibs中，为LGPL许可。

我没看见过代码，不能打包票，但从技术上说，确实是可以不使用GPL代码而与konqueror集成的。

GPL规则要遵守，但还是那句话，现实是很复杂的，有各种可能性，不能上来先一棍子打死。linus都允许有binary only的内核模块嘛。

作者: singer 发布时间: 2003-08-11

引用:

最初由 cjacker 发表
红旗如果不遵守GPL就算了，后台硬，谁也不敢怎么样？
何必如此？

"控制面板是红旗完全自主开发的一个插件，与Konqueror无缝集成。红旗公司享有完全版权"

被人骂的多了，知道出来做做样子了？

干脆说kernel和kde也是自由知识产权就OK了。

建议GPL改一条，所有GPL软件禁止红旗使用，为什么，这是一个只知道索取不知道奉献的东西。

错了就是错了.承认错误比掩盖和狡辩更受人尊重。

算了，能到这个程度已经8错了。看以后吧。

作者: 自由狼-台风发布时间: 2003-08-11

真佩服singer

作者: ltkun 发布时间: 2003-08-14

我还记得我当年－2000年还是01年02年忘了，我装了个RedfIaq Linux 服务器版V1.1，这个在中国恐怕最得官方支持的Linux发行版的开机的过程中，不时的可以见到 “Redhat”的字样，甚至在产品内部的文档里，公司的地址还是“Redhat”....云云，还打着民族的旗号，真是让人觉得有种纨绔子弟的感觉..... 恨铁不成钢啊，虽然我们很希望国产的操作系统能出息些.....也不知他们没有汉化好还是忘了.....但这个也留着...是不是拿来骗我们的民族感情啊......既然是简单的汉化了就别吹什么国产...独立.....自主..... 既然是简单的汉化了，汉化好了也行啊，别人家的商号还留着.......
几年过去了，不知道他们现在是否还犯这样的低级错误没有。但愿他们越走越出息。是怎么样说清楚，汉化、美化的，就说是汉化、美化的，本地化做好了，一样不容易，我们也会非常高兴的。

作者: linusware 发布时间: 2003-08-16

任何一家Linux公司如果要生存发展的话，不重视技术是不可能的。

Linux的精神是开放，任何一家以Linux distribution为主业的公司不遵守这个规则能够得逞一时，但是如果不改变，最终是进垃圾堆的。毕竟Redflag已经开始越来越多的遵守游戏规则。

Redhat和SuSE开放了源码，你拿到了源码，就能够做得一样好了？只有不懂技术的白痴才会这么这么认为。因此Turbolinux中国除了商业软件外，要求员工完全遵守游戏规则，要求员工今可能的参与open source的各社区的开发，fix的任何bug或改进完全提交。

我们深刻感到Turbolinux中国技术水平还不高，为社区可作的贡献还太少，技术水平在很多方面根本无法和Redhat、SuSE比。因此争论这个没有意义，大家团结起来提高技术水平才是真的。
========================
Turbolinux R&D Manager

作者: TurboR&D 发布时间: 2003-08-19

那么那些红旗当中不受gpl协议保护的，是不是能够直接抽出来用用呢？比如rfinput，不犯法吧

作者: cbnsjtu 发布时间: 2003-08-21

不想说太多，我很少用他的代码！

作者: sanfeng 发布时间: 2003-08-22