diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" index b0efeb40494e34175bd9a74d139ee6780c378020..e9b982d6e907b06b341a6d99b97efdffa2686b1d 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" @@ -5,48 +5,104 @@ 本章需补充更多与“开源误区”相关的内容 ``` +## 前言 -> 本篇内容将会为开发者们解释一些有关开源的误区，以下方两个问题为例，欢迎开发者们补充更多内容 +本篇内容将会为开发者们**解释有关开源的常见误区**，欢迎开发者们补充更多内容！ -### 开源就意味着完全免费和随意使用吗？ +## 常见误区 +### 开源 = 免费 -在使用开源软件时，您需要**严格遵守**项目的开源协议。 +开源并不等于完全免费和随意使用。 -GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，但是**不允许**修改版权信息。 +在使用开源软件时，您需要**严格遵守**项目的开源许可证（又称开源许可协议）。开源许可证是对开源软件著作人版权的保护，在开放源代码的同时，也确保了开源软件的权利是受到保护的。例如：GPL、MIT、BSD 等比较流行的开源许可证允许使用者修改源代码，但是**不允许**修改版权信息。 -而部分开源协议则对于商业应用需要购买并支付费用。 - -还有部分开源协议表明不能将软件用作任何政治相关的用途，特别是政治宣传。 +而部分开源许可证则对于商业应用需要购买并支付费用。还有部分开源许可证表明不能将软件用作任何政治相关的用途，特别是政治宣传。 所以开源**并不意味着**完全免费和随意使用源代码！ -### 开源就意味着作者没有版权吗？ +### OSI 组织与 OSI 网络模型 + + + +### 开源是好的，闭源是不好的 + +开源与闭源各有优劣，一般是根据个人需求来选择采用哪种方式。 + +开源项目因为开放源代码，参与人数较多，在快速促进项目成长，为良好的行业发展起到了重要的作用。与此同时，也正是因为参与人较多，这就导致开源社区的维护需要投入更多的精力，如果维护者精力不足，很容易导致项目停止维护，这也是开源项目不稳定的原因。 + +而闭源项目参与人数较少，在项目迭代和项目质量的管理较为明确，如果是商用软件，还会为客户提供长期的运维服务，更加标准和稳定。也正是因为参与人数较少，闭源软件的迭代周期会比较慢，在项目成长曲线上略显不足，这也是闭源软件有时会被开源软件弯道超车的原因。 + +### 开源项目不能商用 + +开源项目能不能商用，这取决于开源项目使用的哪种开源许可证。比如：Apache License 2.0、BSD 等开源许可证就允许使用者可以进行商业使用。 +### 开源项目的作者没有版权 -**开源项目采用开源许可并不意味作者没有版权/著作权。** +**项目的开源并不意味作者没有版权/著作权。** -开源项目的源代码版权是归原作者所有，使用者在使用时需要遵守开源软件根目录下的 **LICENSE** 相关规定，如果没有放置 **LICENSE** 则代表保留所有权利。 +开源项目的源代码版权是归原作者所有，使用者在使用时需要遵守开源软件根目录下的 **LICENSE** 相关规定，如果没有放置 **LICENSE** 则代表保留所有权利。但为了避免纠纷和误解，建议最好还是标明项目的开源许可。 -### 开源过程中不能转为闭源？ +### 开源项目不能转为闭源 -认识开源首先的一点是要认识各种开源许可证，不同开源许可对待开源转闭源有不同的规定： +认识开源首先的一点是要认识各种开源许可证，不同开源许可证对待开源转闭源有不同的规定： -* LGPL、GPL、Mozilla 许可（MPL）这类许可证禁止开源软件转为闭源软件。 +* LGPL、GPL、MPL 这类许可证禁止开源软件转为闭源软件。 * BSD、MIT、Apache 这类许可证允许开源软件转为闭源软件。 > 参考：[如何选择开源许可证？](http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html) -### “半开源”和“伪开源”也是开源吗？ +### “半开源”和“伪开源”不是开源 + +这个问题其实是有争议的，一部分人认为不属于开源，而另一部分人认为属于开源。在这里，我们认为开源可以分为两种开源：广义的开源、狭义的开源。下面，我们从项目规范性和完整性两个方面来探讨这两者区别。 + +从项目规范性来看，只要开放源代码就可以认为是广义的开源，而狭义的开源在广义的开源基础上，增加了一定限制——需要符合国际社区公认的规范和定义。 + +- 广义的开源，使用非国际社区公认的开源许可证，或者没有采用任何开源许可证，**只要开放源代码**就属于开源项目。 +- 狭义的开源，除了开放源代码以外，还需要**符合一些国际社区公认的定义**（比如：采用 OSI 批准的开源许可证），满足开源的一些条件才是真正意义的开源。我们平时说开源社区，一般指的是狭义的开源。 + +从项目完整性来看，狭义的开源一般对项目完整性有严格的要求。而广义的开源，对项目的完整性要求较为宽松。 + +- 狭义的开源，**对项目完整性有严格的要求**，比如：公开代码完整、可以编译和再发行、符合国际开源规范、拥有开源许可证、维护和治理开源社区，以及接受贡献（允许外部贡献）等。 +- 广义的开源，不严格要求狭义的开源中提及的一系列约束，**完整性要求较为宽松**，可以忽略上述提到的各类要求，按照自己的想法来维护项目。 + +此外，需要明确的一点是：**OSI 批准的许可证并不是划分是不是开源项目的唯一标准**。 OSI 只是国际开源许可证的一个组织机构，由于被其认可的开源许可证较为清晰严谨，所以一般国际认可的许可证都需要经过 OSI 批准。但并不是说只有 OSI 才能制定和批准开源许可证，一个本地的开源项目也可以使用或者定义自己的开源许可证。比如：我国第一个被 OSI 批准的**木兰许可证**，在被批准前也只是木兰本地的开源协议。**虽然木兰许可证在此之前并没有被 OSI 批准，但是基于其规范性和完整性而言，都具备狭义上开源的标准。因此，采用木兰许可证的项目不管是在被批准前还是批准后，都属于狭义上的开源。** + +最后总结一下，“半开源”和“伪开源”都违反了狭义上开源的其中某些条款，因此，不算标准的开源形式。但因为贡献出源码，所以也可以认为属于广义的开源。广义的开源和狭义的开源只是概念上的区分，而广义的开源项目如果符合狭义的开源标准，也可以转变为狭义的开源。在秉承“吃水不忘挖井人”的优良传统下，哪怕“井”挖的不够好不够深，也要吃水怀恩，因此，“半开源”和“伪开源”可以被认为广义的开源。 + +### 开源项目只需要开放源代码就可以了 -开源不只是开放源代码，根据 OSI 的定义，开源必须满足一系列条款。 -半开源和伪开源都违反了开源的其中某些条款，因此不是开源。 +一个开源项目**不仅仅要开放源代码，还要有一套完整的项目管理流程以支撑开源项目的健康推进**。 -### 只开放源代码算开源项目么？ +一个优秀的开源项目，开放源代码只是第一步，更重要的是维护一个开源社区。开源社区包含了一套完整的项目管理流程，它包括开放源代码、社区协作流程、项目质量管理为一体的系统管理，绝对不逊色于公司企业的项目管理流程。同时开源发起人还需要考虑社区传承等重大问题，大量的开源项目就是因为无法传承而被取代或者失败。或者由于项目管理本身的问题，导致问题频出被社区放弃。因此，开源项目并非开放和维护源代码这么简单。 -真正的开源社区是一套完整的项目管理流程，它包括开放源代码、社区协作流程、项目质量管理为一体的系统，绝对不逊色于公司企业的项目管理流程。同时开源发起人还需要考虑社区传承等重大问题，大量的开源项目就是因为无法传承而被取代或者失败。或者由于项目管理本身的问题，导致问题频出被社区放弃。因此，一个开源项目不仅仅要开放源代码，还要有一套完整的项目管理流程以支撑开源项目的健康推进 +### 开源是安全的 or 开源是不安全的 + +身处全球信息化的今日，在经历了熊猫烧香、信息泄露等一系列网络安全问题之后，希望大家对“安全”保持一份谨慎的认知：“这天底下没有不透风的墙”，也就是说，**安全是相对的，没有绝对意义上的安全**。 + +我们来看一下 [走出误区 正确认识开源](https://searchvirtual.techtarget.com.cn/10-20427/) 一文中的描述： + +> 首先，我们来看一下封闭式平台或专有平台是怎么运作安全补丁的：安全漏洞必须由有权访问源代码的人员识别（通常只是供应商），这首先就要耗费大量时间。随后，他们必须对修复补丁进行编码、测试并交付使用，这就再次延迟了修复时间。 +> +> 相反，再看看基于标准且开放的开发模式：它有助于快速识别潜在的安全漏洞。举个栗子，在 2014 年，常用的 OpenSSL 加密软件库发现了 Heartbleed。已经订阅红帽软件的客户都在第一时间收到了红帽安全响应团队的即时回应。随即，该部门进行了后续漏洞测试、打补丁和安全修复等工作，以确保客户始终处在安全的网络环境中。 +> +> 红帽公司总裁兼 CEO Jim Whitehurst 在一次采访中表示：“在 Heartbleed 发生时，每个人都收到通知，同时红帽在第一时间做出了响应。在红帽，我们有专门的安全响应团队，来迅速、专注处理这类问题。” + +我们有理由认为：**一个软件是否安全，并不在于软件的一个瞬时状态，而是看其是否能够提供及时的维护和修复漏洞**。闭源软件和商业软件也存在安全问题，相对安全的闭源模式和专业的维护质量可以帮助它们降低安全隐患。开源软件会被认为不安全，主要是因为开放源代码会更容易暴露漏洞，并且开源软件的健康完全取决于开源社区的网络安全水平。因此，在对待开源的安全性问题上，正确的态度是：正视其开源所带来的问题，共同维护开源社区的安全性。 + +### 开源没有技术支持 + +一般较小的开源项目（如个人项目）只能依赖于维护者的技术支持，支持力度较小。因此，经常会被大家误认为开源项目是没有技术支持的，但其实不然。开源项目的技术支持和开源社区的发展息息相关，一个发展良好的开源社区，能够为开源项目带来比较多的贡献者，通过共同建设，也会带来比较完善的技术支持。 + +此外，企业也会支持开源项目，为开源项目保驾护航。比如 RedHat 的开源版本 Centos。目前国内的大型企业也密切关注开源发展，维护自己的开源项目，指定专门的开源项目负责人。 + +开源项目需要技术支持且至关重要！技术支持的程度，在项目的技术选型方面也是一个重要的指标。 + +### 开源项目的质量不够好 + +回顾开源历史，能够流传至今的开源项目中，无一不是业内最顶级的技术专家参与研发的，目前国内比较知名的开源软件也是顶级的技术专家负责。之所以大家会对开源项目质量有疑问，主要是因为开源的蓬勃发展，开源者越来越多，但由于水平的参差不齐，以及不完善的项目维护机制，很多开源项目都因“一时兴起而生，一时兴起而亡”。因此，开源项目质量不够好，更像是一个“以管窥豹”的看法。我们需要做的，是对优秀开源项目的贡献，以及对糟糕开源项目的辨识。 ### 开源项目必须用英文命名标识符吗？ @@ -54,7 +110,7 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码， 虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见“如果项目开源的话还是要用英文命名”的说法。2007 年 Python3 决定支持非 ASCII 码标识符的 [增强建议书](https://www.python.org/dev/peps/pep-3131/) 中指出： > A developer wishing to make a library widely available needs to make a number of explicit choices (such as publication, licensing, language of documentation, and language of identifiers). It should always be the choice of the author to make these decisions - not the choice of the language designers. -> +> > 希望使库广泛可用的开发人员需要做出许多抉择（例如发布、许可、用何种语言编写文档和命名标识符）。决定权都应在项目作者而不是语言设计者手中。 这段话同样适用于开源项目。无论是文档还是源码中标识符使用的语言，项目作者都可以根据实际需求来灵活决定，而非简单的一刀切用英文。实际上，开源项目往往是在开发者业余的碎片时间进行，文档和测试往往从简。这种情况下，代码的清晰度和可维护性对于项目可持续性尤显重要，这恰恰是母语命名标识符的优势。正如同一文档指出： @@ -91,14 +147,6 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码， 总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的“新技术”。 -### 开源不够安全？ - -* 第一种误解也引发了另一种说法，即开源中“古老而优秀”的部分并不安全。首先，我们来看一下封闭式平台或专有平台是怎么运作安全补丁的：安全漏洞必须由有权访问源代码的人员识别（通常只是供应商），这首先就要耗费大量时间。随后，他们必须对修复补丁进行编码、测试并交付使用，这就再次延迟了修复时间。 - -* 相反，再看看基于标准且开放的开发模式：它有助于快速识别潜在的安全漏洞。举个栗子，在 2014 年，常用的 OpenSSL 加密软件库发现了 Heartbleed。已经订阅红帽软件的客户都在第一时间收到了红帽安全响应团队的即时回应。随即，该部门进行了后续漏洞测试、打补丁和安全修复等工作，以确保客户始终处在安全的网络环境中。 - -* 红帽公司总裁兼 CEO Jim Whitehurst 在一次采访中表示：“在 Heartbleed 发生时，每个人都收到通知，同时红帽在第一时间做出了响应。在红帽，我们有专门的安全响应团队，来迅速、专注处理这类问题。” - ## 参考资料 - [走出误区 正确认识开源](https://searchvirtual.techtarget.com.cn/10-20427/)