标题：开源
开源概念简介
Open Source（即开放源代码）的定义由Bruce Perens（曾是Debian的创始人之一）定义如下：开源领军人物近照以及部分标志(7张)
●自由再散布（Free Distribution）：获得源代码的人可自由再将此源代码散布。
●源代码（Source Code）：程式的可执行档在散布时，必需随附完整源代码或是可让人方便的事后取得源代码。
●衍生著作（Derived Works）：让人可依此源代码修改后，在依照同一授权条款的情形下再散布。
●原创作者程式源代码的完整性（Integrity of The Author’s Source Code）：意即修改后的版本，需以不同的版本号码以与原始的程式码做分别，保障原始的程式码完整性。
●不得对任何人或团体有差别待遇（No Discrimination Against Persons or Groups）：开放源代码软件不得因性别、团体、国家、族群等设定限制，但若是因为法律规定的情形则为例外（如：美国政府限制高加密软件的出口）。
●对程式在任何领域内的利用不得有差别待遇（No Discrimination Against Fields of Endeavor）：意即不得限制商业使用。
●散布授权条款（Distribution of License）：若软件再散布，必需以同一条款散布之。开源软件(2张)
●授权条款不得专属于特定产品（License Must Not Be Specific to a Product）：若多个程式组合成一套软件，则当某一开放源代码的程式单独散布时，也必需要符合开放源代码的条件。
●授权条款不得限制其他软件（License Must Not Restrict Other Software）：当某一开放源代码软件与其他非开放源代码软件一起散布时（例如放在同一光碟片），不得限制其他软件的授权条件也要遵照开放源代码的授权。
●授权条款必须技术中立（License Must Be Technology-Neutral）：意即授权条款不得限制为电子格式才有效，若是纸本的授权条款也应视为有效。
开源软件与自由软件的区别
许多人将开放源代码与自由软件（Free Software）视为相同，其实不然。以定义条件而言，自由软件仅是开放源代码的一种，也就是说自由软件的定义较开放源代码更为严格。
并非开放源代码的软件就可称为自由软件，要视该软件的授权条件是否合乎自由软件基金会对自由软件所下的定义。
开源定义详解
1.9版中文解释1．自由再发行
许可证不能限制任何团体销售或赠送软件，软件可以是几个不同来源的程序集成后的软件发行版中的其中一个原件。许可证不能要求对这样的销售收取许可证费或其他费用。
2．程序源代码
程序必须包含源代码。必须允许发行版在包含编译形式的同时也包含程序源代码。当产品以某种形式发行时没有包含源代码，必须非常醒目的告知用户，如何通过Internet免费的下载源代码。源代码必须是以当程序员修改程序时优先选用的形式提供。故意地扰乱源代码是不允许的。以预处理程序或翻译器这样的中间 形式作为源代码也是不允许的。
3．派生程序
许可证必须允许更改或派生程序。必须允许这些程序按与初始软件相同的许可证发行。
4．作者源代码的完整性
只有当许可证允许在程序开发阶段，为了调整程序的目的将“修补文件”的发行版与源代码一起发行时，许可证才能限制源代码以更改后的形式发行。许可证必须明确地允许按更改后的源代码所建立的程序发行。许可证可以要求派生的程序使用与初始软件不同的名称或版本号。
5．无个人或团体歧视
许可证不能都有针对任何个人或团体制在专门奋斗领域内的任何人使用该程序。例如不能限制程序应用于商业领域，或者应用于遗传研究。
6．对程式在任何领域内的利用不得有差别待遇
该条款的主要目的是禁止许可证中含有使开放源代码软件无法在商业上使用的规定。我们需要商业用户参与我们的工作，而不让他们感到被排除在外。
7．许可证发行
伴随程序所具有权力必须适用于所有的程序分销商，而不需要这些团体之间再附加许可证签字盖章。
8．许可证不能特制某个产品
如果程序是某个特殊的软件发行版中的一部分，伴随该程序所具有的权力不能只以来于这一发行版。如果程序是从那一发行版中摘录出来的，使用或发行时用的都是那个程序的许可证，分销程序的所有团体都应拥有与初始软件版所允许的所有权力。
9．许可证不能排斥其他软件
许可证不能限制随该许可证软件一起发行的其他软件。例如，许可证不能要求所有与之一起发行的其他软件都是开源软件。
10．许可证实例
GNU GPL、BSD、X Consortiun和Artistic许可证都是我们认为符合开源软件定义的许可证。MPL也是一样。1.9版英文原文The Open Source DefinitionVersion 1.9
The indented, italicized sections below appear as annotations to the Open Source Definition (OSD) and are nota part of the OSD.
Introduction
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: 
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
1. Free Redistribution
Rationale:By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect.
2. Source Code　　
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Rationale:We require access to un-obfuscated source code because you can't evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Rationale:The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
Rationale:Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.
Accordingly, an open-source license mustguarantee that source be readily available, but mayrequire that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
Rationale:In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process.
Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Rationale:The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
Rationale:This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
Rationale:This clause forecloses yet another class of license traps.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
Rationale:Distributors of open-source software have the right to make their own choices about their own software.
Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.
10. License Must Be Technology-NeutralNo provision of the license may be predicated on any individual technology or style of interface.
Rationale:This provision is aimed specifically aimed at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "click-wrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.
开源协议简介
GNU GPLGNUGeneral Public Licence (GPL) 有可能是开源界最常用的许可模式。GPL 保证了所有开发者的权利，同时为使用者提供了足够的复制，分发，修改的权利（国内有名为MacroSkin(2.x)的界面引擎技术采用此份协议开源）：
可自由复制，你可以将软件复制到你的电脑，你客户的电脑，或者任何地方。复制份数没有任何限制。
可自由分发在你的网站提供下载，拷贝到U盘送人，或者将源代码打印出来从窗户扔出去（环保起见，请别这样做）。
可以用来盈利你可以在分发软件的时候收费，但你必须在收费前向你的客户提供该软件的GNU GPL 许可协议，以便让他们知道，他们可以从别的渠道免费得到这份软件，以及你收费的理由。
可自由修改如果你想添加或删除某个功能，没问题，如果你想在别的项目中使用部分代码，也没问题，唯一的要求是，使用了这段代码的项目也必须使用GPL 协议。
需要注意的是，分发的时候，需要明确提供源代码和二进制文件，另外，用于某些程序的某些协议有一些问题和限制，你可以看一下PierreJoye 写的Practical Guide to GPL Compliance 一文。使用GPL 协议，你必须在源代码代码中包含相应信息，以及协议本身。GNU LGPLGNU还有另外一种协议，叫做LGPL （Lesser General Public Licence），它对产品所保留的权利比GPL 少，总的来说，LGPL 适合那些用于非GPL 或非开源产品的开源类库或框架。因为GPL 要求，使用了GPL 代码的产品必须也使用GPL 协议，开发者不允许将GPL 代码用于商业产品。LGPL 绕过了这一限制。MITMIT协议可能是几大开源协议中最宽松的一个，核心条款是：
该软件及其相关文档对所有人免费，可以任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。唯一的限制是，软件中必须包含上述版权和许可提示。
这意味着：
你可以自由使用，复制，修改，可以用于自己的项目。可以免费分发或用来盈利。唯一的限制是必须包含许可声明。MIT 协议是所有开源许可中最宽松的一个，除了必须包含许可声明外，再无任何限制。BSDBSD许可证在软件分发方面的限制比别的开源协议（如GNU GPL）要少。该协议有多种版本，不同项目发行的BSD许可证不同，比如Apple的BSD许可证与4.4BSD Lite衍生操作系统的BSD许可证最主要的版本有两个，新BSD 协议与简单BSD 协议，这两种协议经过修正，都和GPL 兼容，并为开源组织所认可。
新BSD 协议（3条款协议）在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制。另外，该协议还禁止拿开发者的名义为衍生产品背书，但简单BSD 协议删除了这一条款。
其他相关信息
开放源代码定义给出了开放源代码软件的基本性质。不幸的是，术语"开放源代码"遭到了滥用，并且由于它的描述性，它不能作为一个商标（这是我们的首选）被保护。由于社团需要一种可靠的方式以确定一份软件是否真正是开放源代码软件。OSI为此目的而注册了一个认证标志，OSI Certified。如果你在一份软件上看到了该标志，那么该软件就是必定是按照遵从开放源代码定义的许可证发布的，否则，该发行人就是在滥用该标志而且违反了法律。
OSI Certified标志被用于软件而不是许可证：人们需要知道的是组成软件的包和它们的许可证是开放的源代码。此外，单独的许可证可能不是"货物"，它由美国专利和商标局注册认证标志。但是软件的作者显然必须能够在不询问我们的情况下（自我认证）、在适当的时刻确认他们的软件是按照OSI Certified的开放源代码方式发布的。所以认证按照两步进行：
* OSI提供一个满足开放软件源代码定义的开放源代码许可证表。这些许可证经过公众的详细审查并且被我们所批准。如果你有一个希望加入该列表的许可证，请与license-approval @opensource. org联系，它启动了获得许可证批准的程序。
* 如果你希望在你的软件上设置OSI Certified标志，你可以从列表中选择一个获得批准的许可证并根据它发布软件，并且适当地为软件做标志。
上面仅仅是一个概括。下面给出申请批准许可证和把OSI Certified标志应用在你的软件上的详细说明。
获得许可证的批准
1．通过电子邮件把许可证发送给license-approval@ opensource .org。在电子邮件中说明你是否愿意以你的签名或者匿名地把许可证发送到许可证讨论列表中。（我们愿意考虑那些根本不希望被发送的许可证，但由于社团的评审是批准的一个重要组成部分，我们将不得不把该许可证私下地发送给评审者：因此，对没有被发送到许可证讨论列表中的许可证的批准，要花费更长的时间，并且通常要更多地与你交流。）
2．如果我们发现你的许可证不符合开放源代码的定义，我们将与你一同解决这个问题。
3． 同时，我们将关注许可证论坛列表，并且与你一同工作以解决大家提出的任何未包含的问题。
4．作为该过程的一部分，我们还将就许可证问题向外界寻求法律上的建议。
5． 一旦许可证符合了开放源代码定义，并且在许可证论坛上经过了充分的讨论或者其它的评审者没有提出我们认为重要的问题，我们将通知你，许可证已经被批准了，同时它被复制到我们的网站上，并且被加入以下的许可证列表。
使用该标志
你可以在这两种软件的发行上使用OSI Certified标志。该软件的发布包括并且达到了被批准的许可证列表中某个许可证的要求，或者该软件的源代码已经被明确地放到公众可以得到的位置。
为了表明你的软件是按照OSI Certified发布的，你必须不加任何修改地把下面两者之一，按照下述方式加入你的软件。完整的声明是：
This software is OSI Certified Open Source Software.
OSI Certified is a certification mark of the Open Source Initiative.
较简短的声明是：
OSI Certified Open Source Software
你的软件的每种发布形式都有自身的要求：
* 如果软件以电子的形式发布（而不是实物（tangible）的形式），你必须把完整的声明放在README文件或者类似的、人类用户将首先阅读的文件中。
* 如果软件以实物形式发布，你必须完成以下所有可行的任务。
* 如果软件的发布包括印刷品，你必须把完整的声明加入该印刷品。
* 如果软件发布在可擦写的媒体（例如软磁盘）、CD-ROM、磁带等媒体上，它们在物理上可以添加能够被人的裸眼所阅读的简短声明，而不影响它们的功能，你必须把完整的声明或简短的声明标注在该媒体上。
* 如果软件的发布是一个包，从而使其中的声明不能被阅读，你必须在包的外面放置完整的声明。
如果不能把以上任何条款用于发布，请与我们联系，我们将把你选择的位置加入本列表。
获得批准的许可证
以下许可证满足开放源代码的定义，并且已经被批准用于OSI Certified的开放源代码软件。没有给出批准日期的许可证是在1999年1月1日以前批准的。
* The GNU General Public License（GPL）
* The GNU Library（Lesser）General Public License（LGPL）
* The X Consortium License
* The Artistic License
* The Mozilla Public License（MPL）
* The QPL
* Open LDAP Public License
其它符合定义的许可证包括：libpng许可证、zlib许可证、IJG JPEG许可证和BSD许可证。
许可证分类：
按照使用条件的不同，开源软件许可证可以分为三类（严苛程度递减）
1． 使用该开源软件的代码再散布（redistribute）时，源码也必须以相同许可证公开。
代表许可类型：GPL， AGPL
2． 使用该开源软件的代码并且对开源代码有所修改后再散布时，源码必须以相同许可证公开。
代表许可类型：LGPL， CPL，CDDL， CPL，MPL等
3． 使用该开源软件的代码（包括修改）再散布（redistribute）时，没有特殊限制，只需要明记许可。
代表许可类型：ASL， BSD，MIT等开源在中国发展为何如此缓慢？1、中国教育依旧落后
虽然目前中国的IT职业教育学校和全日制的本专科院校每年可以向中国IT界输入大量的新人，但是整个IT教育依旧处在落后地位。大多数的学校的教学内容非常偏重与C/S程序（比如现在非常热门的java，.net）这些内容相比真正的开发真的太过简单。如何让学生可以学到更多复杂的程序开发技术是中国教育界多年来始终无法解决的一大问题，如果中国的教育还是更不是全球的技术发展和全球的消费者行为的话，社区还依然没有机会实现繁荣。
2、个性的缺失是中国oss社区发展最大的悲哀
中国是一个有着五千年文化的传统型国家，个性创新在中国这个特定的环境中并不能得到更好的发展。越来越多的人希望自己可以成为和别人一样的人，这将让这些本有机会个性创新的人才们在他们人生最重要的时刻错过了最重要的事情，所以个性的缺失是中国oss社区发展最大的悲哀。
3、英语水平
目前OSS的概念在国外是最火热的，所以如果没有良好的英语基础是难以推动OSS发展，跟上世界技术潮流的。虽然现在小学从三年级开始就学习英语，但是相比里最基本的OSS英语基础还有了不小的距离。
4、中国人不够主动
很多OSS社区的领导人，oss活动的发起人都是外国人，中国人一般都不太乐意去发起甚至参加这类可以学到更多技术的活动。哪怕要他们作为一名本地的东道主去外国人发起的OSS活动中分享一下自己的经验，他们也会觉得中国人的技术不应该外流，但其实正因为中国人不够主动，中国人也很难通过OSS社区了解到最新的技术。