常用的一些开源协议的详细解析
相关专题：GPLv3引发广泛争议-开源面临分裂危机
开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢?答案是否定的。开源运动同样有自己的游戏规则和道德准则。不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。
首先，要对几个概念有所了解：
1. Contributors 和 Recipients
Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等)，Contributors 按照参与某个软件开源的时间先后，可以分为 an initial Contributor 和 subsequent Contributors 。
Recipients指的是开源软件或项目的获取者，显然，subsequent Contributors 也属于 Recipients之列。
2. Source Code 和 Object Code
Source Code 指的是各种语言写成的源代码，通过Source Code，结合文档， 可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等。
Object Code 指的是Source Code 经过编译之后，生成的类似于“类库”一样的，提供各种接口供他人使用的目标码，按我的理解，它就是像常见的DLL、ActiveX、OCX控件性质的东西。(不知道这样理解对不对)
分清楚这两个概念的目的在于，有些开源，只发布Object Code ，当然，大多数发布的是Source Code。很多协议也对 “你发布的是哪种Code的时候应该怎样”，有着明确的约束。
3. Derivative Module 和 Separate Module
Derivative Module 指的是，依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码，是原“源代码”的增强(不等于增加)、改善和延续的模块，意为“衍生模块”。
Separate Module 指的是，参考或借助原“源代码”，开发出的独立的，不包含、不依赖于原“源代码模块”，意为“独立的模块”。理解这两个概念的目的在于，很多协议对涉及到商业发布的时候，会有哪些是衍生的，哪些是独立的，有着明确的商业发布规定。
现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。
这里我们来看四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员/厂家参考。
BSD开源协议(Berkeley Software Distribution )
BSD开源协议是一个给予使用者很大自由的协议。基本上使用者可以“为所欲为”可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。但“为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1. 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
其实这几个规则约定的目的也只是达到一个目的：是他人的东西，别人以BSD开源了，你就不能不做任何声明而占为己有，更不能用他人的名义来做商业推广。你只对你自己的东西拥有绝对控制权。
举个例子，你用开源代码(A)修改或做其他增添之后，产生了产品B，这时候，你对B的控制由你自己决定，你可以用任何协议再开源，也可以闭源商业发布。但，因为如果B中包含了A或A的一部分(一点都不包含就不叫修改了)，那你在B产品的版权声明中，必须有提到你有使用到 A ，并且附带上 A 的开源协议。而且不能做商业推广的时候将B 冠以原开源作者的名义以促进商业推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache Licence 2.0
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件也和BSD类似：
1. 需要给代码的用户一份Apache Licence
2. 如果你修改了代码，需要再被修改的文件中说明。
3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4. 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
GPL (Gun General Public License)vesion 2.0 1991
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的“传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
最常见的开源协议，使用它作为授权协议的有大名鼎鼎的 Linux 。GPL最显著的两个特点就是网上称为的“病毒性传播”和“不允许闭源的商业发布”。
所谓的“病毒性传播”，指的是，GPL规定，所有从GPL协议授权的源码衍生出来的(即上面提到的Derivative Module)，或者要跟GPL授权的源码混着用的Project，都要遵循GPL协议，就像病毒一样，粘上了关系，就“中毒”了。GPL这样规定的目的是，保证在GPL协议保护下的产品，不会再受到其他协议或者授权的约束。即让跟GPL有关系的源码都能免费获取。举个例子，如果你的改进的Linux中使用了GPL授权下的开源模块(也必须使用，你不可能自己重新去做个内核吧，如果做出来了，你也没必要叫Linux了。)，那么你整个Linux产品也必须遵循GPL协议去开源，不能以其他方式去开源发布，更不允许闭源发布。这样一来，就不会出现这样一个Linux--这个功能是GPL协议授权的，可以免费获取源码，而另外一个功能是其他协议下的，拿不到源码。这点规定对使用或者研究该产品的人来说，是一个极大的便利。
而“不允许闭源商业发布”指的是，在GPL授权下，你的软件产品可以商业发布，拿去卖钱，但是在这同时，你也必须将该产品的源码以GPL协议方式开源发布出去，供他人免费获取。也许有人会迷惑，拿去卖，又同时开源，那谁来买阿?这个产品怎么赚钱呢??这就涉及到开源产品的商业模式的问题了，想了解相关一些信息的话，可以看看以上我给出链接的一些文章。至于后面，可能会写一篇关于开源项目的商业模式的随笔。
GPL协议下的商业发布的一个关键点就像 Java 视线论坛的 Robbin所说的，GPL是针对软件源代码的版权，而不是针对软件编译后二进制版本的版权。你有权免费获得软件的源代码，但是你没有权力免费获得软件的二进制发行版本。GP对软件发行版本唯一的限制就是：你的发行版本必须把完整的源代码一同提供。
它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
LGPL
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
CPL(Common Public Liecense) vesion 1.0
CPL是IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议。主要用于一些IBM或跟IBM相关的开源软件/项目中。如很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等。
CPL也是一项对商业应用友好的协议。它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布，这点跟 BSD 很类似，也属于自由度比较高的开源协议。但是，需要遵循：
1. 当一个Contributors将源码的整体或部分再次开源发布的时候，必须继续遵循 CPL开源协议来发布，而不能改用其他协议发布。除非你得到了原“源码”Owner 的授权。
2. CPL协议下，你可以将源码不做任何修改来商业发布。但如果你要将修改后的源码其开源，而且当你再发布的是Object Code的时候，你必须声明它的Source Code 是可以获取的，而且要告知获取方法。
3. 当你需要将CPL下的源码作为一部分跟其他私有的源码混和着成为一个 Project 发布的时候，你可以将整个Project/Product 以私人的协议发布，但要声明哪一部分代码是CPL下的，而且声明那部分代码继续遵循CPL。
4. 独立的模块(Separate Module)，不需要开源
您的位置:
Linux时代
>
新闻资讯
>
Google开源“掌门”:如何管理开源代码
日期：2007-05-28 作者：IT168 来自：linux.chinaunix.net
-->
Google开源项目经理Chris DiBona在Google纽约系列演讲活动中发表了一场演讲，题目为“Google开源的一年（A
Year of Open Source at
Google）”。在他演讲之前，这个Google开源掌门接受了媒体的采访，谈论对开源的一系列问题的看法，诸如微软最近发表开源侵犯专利权的事件、
Google的开源开发贡献，以及GPLv3对Google的影响等等，以下是访谈内容。 
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://linux.chinaunix.net/mirror/image.it168.com/cms/2007-5-25/Image/2007525164351.jpg');}" onmousewheel="return imgzoom(this);" alt="" />
Google开源项目经理：Chris DiBona
Google是如何使用开源软件的？
记者：你在Google纽约系列演讲活动中将演讲什么内容？
Dibona：我
将对我的观点进行进一步的阐述，内容包括关于Google是如何使用开源技术、我们内部如何关注开源，还有我们所展现给外界的一些反馈开源社区的活动，诸
如Google Summer of Code开源项目夏令营，我们以后将公开许多源代码到开源社区中。我将围绕这些问题进行讨论。
记者：你能谈一下在Google公司用于软件开发的开源组件吗？
Dibona：我讲演的内容之一就是关于我们所修正的一些开源项目，我们公司内部正在使用它们。这些包括诸如Linux内核、GNU编译器集、Python、Wine、Derby、Aspell、DSpace、Autoconf、MySQL等类似的东西。
记者：请谈一下在Google用于生产或部署的开源软件的情况。
Dibona：我们使用Linux内核。每次你使用Google的时候，你都使用了Google的一台安装了Linux的机器。我们在其上运行了一些常见的开源工具，在其上我们运行了专有软件来支持Google、Gmail和所有其他不同的服务。
记者：你提到的常用工具都是什么？
Dibona：像GNU binutils、如OpenSSL、OpenSSH、某些网络监视工具，一般是操作系统级别的工具。
Google Code项目进行如何？
记者：请问你参与了Google Code项目吗？
Dibona：是的，这是我们部门管理的网站之一。
记者：Google Code项目进行如何？有什么方法来评测进展情况吗？
Dibona： Google Code有两个方面对我们是非常重要的。其中一个是我们在其上放置了很多与Google无关的开源项目。这样我们成为继SourceForge后的第二大开源项目网站。这真的非常有意义。
另一件事情是，我们在其上放置了很多我们的应用程序编程接口API的文档。这使得Google以外的开发者和程序员可以从技术上更深入了解Google，
以及更加清楚他们的程序如何从技术上与Google实现交互，这一方面已经做得非常成功，对于它的进展我们感到非常满意。
Google Summer of Code项目
记者：在你看来， Google Summer of Code项目所带来的影响是什么？
Dibona：SoC所带来的影响中有两个是最重要的，第一个是我们为2000名开发者约定了时间和地点来进行一次聚会交流。今年将有1000名开发者参加，去年是600名，而前年是400名。因此，总体来说，我们介绍了2000名开发者到开源软件开发者中来。
另一方面，通过这些开源项目，以及通过这种方式将更多的机会带到学生群体当中，这些开源项目现在已经非常容易接受新开发者的加入。因此如果你对比一下今天
和三年前的这些项目的话，你会发现它们现在对没有经验的新手具有更大的吸引力和接纳力。我认为这对开源软件来说是一件非常强大和有益处的事情。因此从这两
方面来说，这个项目是非常成功的。
记者：这也是我希望看到的事情，帮助把更多对计算机科学感兴趣的人带入到开源软件的世界中来。
Dibona：对，
如果你认真想一下，在开源世界中有很多伟大的软件，但是让一个年轻人从一个开源用户转变成一个开源开发者并不是一件轻松的事情。因为他们的代码突然被外界
的每一个人看到，他们不得不与自己的职业技能可能相差很远人来进行交流。我认为，Google Summer of Code是一个非常有用的方式。
Google给开源社区反馈了什么？
记者：对于Google反馈了多少开源软件给社区，你有什么数据吗？
Dibona：我
们已经将我们的一百万行代码回报给开源社区。这是评测我们对开源社区共享的一个方法。这是一个非常不错的数字，它是令人印象深刻的，不是吗？但是我认为还
有更重要的，假若你看一下每一个主流的开源软件项目，还有很多相对较小的开源项目，你会发现Google或者对其进行了修补，或者发布新的功能，或者发布
了其代码，或者参与了这些项目。
一个很好的例子是我们最近刚刚发布的一些让人们更好的使用MySQL的工具。因此这些都是非常有意义的事情。我们已经发布了各种各样的工具，从一些难以让
人注意的微小修改到让人难以相信的大的事情，例如Google
Web工具集就是完全开源的。因此我们认为，作为一个公司与外界分享我们的创新成果，这是一个非常好的道路。
记者：有什么Google技术正在变为开源吗？
Dibona：你知道，我们从来不讨论我们还没有发布的事情。顺便说一下，我们不这么做的理由是我们喜欢确信当我们发布某个消息或项目的时候，它已经完成了发布的准备工作。不过可以告诉你，我们将努力在5月31日的Google开发者日推出一些有趣的东西。
GPLv3对Google有什么影响吗？
记者：GPLv3对Google有什么影响吗？
Dibona：如果你是在9个月前问我这个问题，我会说它意味着我们将不能够采用一些GPL 3程序，这是因为在最初版中的一些ASP规定限制。不过，那时候我说过，也是我现在想说的，那不是世界末日。我们不用必须使用外界的每一个开源软件。
但是最近的GPLv3已经去掉了那些规定，因此我们可以很轻松地说，我们欢迎采用GPLv3。
然而在以前，假若人们选择在开源软件中加入那种限制，我们只有在产品中不使用它而且不能使它公开给终端用户。
因此，无论它们基于什么规定，对我们来说都无所谓，因为我们非常善于管理进入到公司中的代码。因此这实际上从来不是一个真正的问题。
最新版的GPLv3实际上是非常不错的。
微软的“专利侵权”论和Java开源
记者：对于微软最近声称的开源软件侵犯了其大量专利的说法，你有什么看法？
Dibona：是的，我们也看到了这件事情。和大多数人一样，我们更希望看到微软能真正列举出哪些专利权被侵犯。这个事情还要进一步观察。抛出这样的说法是一件很容易的事情，而是否有进一步的具体行动是另一回事。
记者：Sun的开源Java举动会对Google产生一定影响吗？比如Google会考虑将Java看作一个开发平台？
Dibona：这
不会改变我们对Sun和Java的看法，但是这可能会增加我们对一些Java工具的使用。在Sun作为GPL发布Java以前，我们就已经与它们签订了源
代码合作协议。按照这个协议，我们能够给它们提供补丁、漏洞和所有其他事情，因为我们拥有很高级的Java开发技术。我们拥有像Joshua
Bloch这样的著名Java开发者，他对Java社区中占有举足轻重的地位。
因此，我们一直可以获得补丁和一些开发的功能，这对于我们是非常不错的。不过对于Java的开源，在很多方面对我们是很有利的，因为我们可以通过以前不可
能的方式来访问某些特定的代码部分。我们可以修正它们，并且可以很简单地提交这些修正补丁。我们可以说，这是一个开源项目，因此我们可以发布这些内容。对
我们来说这是一种难以让人相信的解脱。因此我们很高兴看到Java走向GPL。
Google如何管理开源代码？
记者：你是否对你们的代码进行过类似Black Duck或Palamida的软件兼容测试？
Dibona：没有，原因是我们对进入公司的代码实行了非常严密的控制。而且我们非常非常善于培训我们的工程师。这么和你说吧，我可以查看公司内的任何代码，而且我能告诉你在其中使用了什么开源软件，这是因为我们管理代码的方式非常完善。
因此这类工具在收购过程中非常有趣，而我们通常不谈论关于收购中的具体细节，它们不会引起我们内部的兴趣。我也认为这些代码工具会比较有用。现在我还不能确信它们对我们会多么有用。但是，它们是非常好的项目。
记者：既然你说你们有一些专有代码运行在由开源组件构成的组合之上，我比较好奇你们如何分清哪些是开源哪些是专有代码？
Dibona：值得指出的是，这就像你在Linux上运行一个应用程序一样。按照同样的方式，我们挑选用来运行我们的Web服务器和我们的Web应用程序。而且我们将Linux做一个内核和一个底层的操作系统。
当我们使用一个开源库的时候，我们将代码纳入公司的方式是严格控制的。Google公司有很多纪律来规范代码的进入。
明确的说，当创建了一些代码并将其提交，在其进入代码库前，另一个Google人员会对你的代码进行代码审查，假若一个人突然出来提交了25000行代
码，那么这可能是值得怀疑的。我们有很多方法来有效地处理这种事情。我们告诉人们你需要将代码归入一个目录，你需要明确的标记代码，以便我们更能跟踪分析
它们。因此我们在管理代码进入方面是非常容易做到的。
——————————————————————————————————————————————————
当代，网络把我们每个人连在了一起，越来越多的人融入到网络这个社会。只要用电脑，就开始参与进这个虚拟社会，即使是最不参与的人，那些潜水者，即时通讯的隐身者，他们也会偶尔聊聊天，偶尔回篇贴，偶尔在网上打打游戏。虚拟和现实，也许每个人在其中的地位会有很大的反差，但是我想虚拟和现实社会中的主流是一样的，都喜欢地位和荣耀，光荣和梦想。两个世界，边缘、另类的人也都同样有，也许现实中被人轻贱，在网上被人追捧，现实中被人追捧，也许就是要在网上尝试被人骂的滋味；现实中没有属于自己一耦之地的人，也许在网上沉迷于自己经营的帝国，现实中的富可敌国，也许在网上津津有味的摆弄着自己一分分赚回来的家当。我们就这样在幻梦和现实之间游走，繁累后的放松，昏天昏地后的警醒，宛如隔世。我们总是想去体会和自己现在不一样的生活，现实中对未来的担心和很多无奈，我们寄托在网上，看着别人，看着自己，看着很多人的故事，我们就象身处于其中。
又扯远了，还是回到开源怎么能维持并赚钱上来吧。开源，我想精心写出那一行行代码的人，不是被人强迫所为，不是为了老板打工，被逼着限期交出去。也许和我一样，心里面有点屎不拉出来的话，就很不爽，如坐针毡，不得安宁，一旦把想法慢慢的吐出来就消停了，并且流连于自己拉的屎感觉快乐。我想那些程序员也是类似这样，过后看自己的一行行代码，也觉得很舒服。所以这些开源的人，我想他们对自己拉的是否能带来金钱要求并不高，也许和我一样，希望有一种认同感，就是希望别人用的时候，能引用一下出处，在开源项目的发展日志中能够提到他，不需要现实中的名字，网上社区的id就足够了。就象我幻想的一样，如果突然有一天有人要给俺稿费，那简直就是天上掉馅饼一般，管他多少钱，都会让人很高兴。会不会有馅饼掉俺身上先不管，还是设想一下怎么让这些无私的程序员有馅饼掉在身上再说，毕竟俺拉的，读完就该扔进垃圾堆，而那些程序员做的东西是我们实实在在能够用的软件。
俺用过Linux，近10年前摸过一段时间，图形界面和硬件支持那时候非常得不方便，后来就没接触过了，最近几个月下载最新的某个发行版，发觉和10年前反差太大了。进步太快了，在线更新，软件模块间的关联，硬件的支持，使用得非常方便，特别是装在移动硬盘上，在多台机器上启动都没有问题，并且不同机器的硬件估计在启动中就检测并把驱动装上了，直接就可以进入图形界面，联网使用，简直自己的工作环境可以揣兜随身带了，软件这么多，还让我能够免费的用，真是让人感慨！不知道那些程序员的生活状态，希望能有稳定的生活来源，在自己的业余时间做着这些事。
后来慢慢的又了解一些开源，发现有一批专职做开源的人，不为别的，就是为了开源的推广，一个开源项目，有公司给小小的赞助，对他们都是一个庞大的支持。希望开源所出的东西，能给为开源做出贡献的人带来收入。开源的宗旨是free，智慧自由的交流，代码自由的交流，如果还有什么可以加的，我希望加上快乐和责任，我们智慧的闪光让我们冲动，我们用手指慢慢的把想法用代码实现，反复的玩味，为我们带来快乐，程序员是为了快乐去编程，不是为了金钱，出的东西对别人有用，不断的更新，加入新的功能，都是源于对别人的负责。
这样的一群人，由于没有稳定的收益，实力庞大的一些闭源公司的拉拢，有一些人慢慢的玷污了开源的纯净性，慢慢的把一些项目后继的发展变成了闭源，或者本身就为了自己的私利，慢慢的不再开放。不断的有人远离开源，不断的又有人加入。这样的流转都是因为一个最现实的问题--钱。为了生活，我们面临着诱惑总是放弃了理想，如果有那么一个方便的途径让我们能够支持开源，不知道那么多使用开源成果的并享受的是否愿意提供支持。不知是否有人看过我前面的那篇‘关于软件盗版问题的一些思考’，下面让我继续发挥一下，尝试设想一下开源的商业模式。
在我看来，软件这样的东西，我们买来只是使用。我们现实中买的东西，比如汽车，开始有个一次性投资，后来使用的时候，我们要加油，也要花钱，对于现在很多商业软件，都是一次性买个许可证，以后软件的打补丁和升级有专门的网站维护，一般都是免费的。对于这样的收费模式，如果把一次性的投资分成两块的话，我想软件卖的不会那么贵。比如商业操作系统，买个许可证，从开始使用的那一天开始赠送一年的免费升级，1年过去后，再使用的时候，B服务器验证的时候会提醒需要交钱延续升级打补丁服务了，用户可以通过门户网站A交钱延续升级服务时限。如果不交的话，总是弹出窗口提醒够烦的，这样分开付费，我想升级的钱也不会很贵。
对于商业软件，有个先期的许可证投资，对于开源软件，这部分投资就可以省掉了。对于开源操作系统，比如Linux，各个不同的发行版本可以做一个门户网站A，如果资金不足，至少大家可以合在一起整个一个门户网站A，货架上摆着很多开源闭源软件，对于验证网站B，开源软件的验证不需要商业软件那样的许可证之类的，所以完全可以省掉。安装某个开源软件的时候，统一的网络接口连到A，输入自己在A上的通行证，通行证下就表明在使用这个开源软件。不同人用的软件自己选择是否让别人看到，这样用同一个软件的人很容易标示成一个群体，大家交流提问会很方便。用的不爽的话，完全可以删掉，觉得用得好的话，可以通过A上的付款机制买一段时间的升级服务。当然这些都不是强制，比如试用和没付钱买服务时，某许可证下该软件的标示就是灰的，买了服务就是彩色的，并且买的期限也可以显示出来。摆在门户网站A的货架上的软件，就对应一个开源项目，使用者付的钱直接进入该项目账户，项目组织者自由支配，分给对该项目有贡献的一些人，对于Linux的各个发行版本，各版本在门户网站上的收益，可以拿出一部分给Linux内核开发团队，同样，一些开源软件，如果用到别的项目做的底层的支持，也有义务把收益的一部分分给相关的项目，这样对于不能上货架的底层支持项目，也会有相对稳定的收入。
有了A，B两个服务器，有很多好处：
1、商业软件的B验证服务器，有多少人在使用软件，时段分布等都可以很容易统计，对于开源软件，在A上就实现了统计。
2、能上货架的软件经过广大开源参与者反复检验过代码，要能让人放心使用，门户网站做好了，参与的人多，会有很好的广告收入。
3、商业软件升级服务过期了会经常弹出来提醒，开源软件没必要这样，使用自由，觉得好就开心地给钱，收获的也象掉馅饼那么开心。
4、让愿意支持开源的使用者有一个方便可信的渠道，真正的把支持给到自己喜欢的开源软件项目里。
5、软件编写者有经常掉馅饼的收益，不会在软件中插入广告的形式维持生活，大家自由使用，自由选择，如果编的软件好，自然很多人付钱支持，如果插入广告，估计是自寻死路。
6、对开源项目，一个好的口碑非常重要，如果走向闭源，也许以后的支持一夜之间就不会再有，对于维持开源队伍的稳定和纯净很有好处；当然，如果闭源后软件做的也越来越好的话，可以把它摆在闭源的货架上，不过对于能上货架的闭源软件，估计会有比开源更高的要求。
