apache2.0开源协议
apache2.0开源协议使用方法
apache2.0开源协议使用方法Apache2.0是一种广泛使用的开源软件协议，它旨在促进软件共享和合作。
该协议允许用户自由地使用、修改和分发源代码，但同时也规定了相应的责任和限制。
二、Apache2.0协议下的开发和使用1. 开发环境设置：确保您的开发环境符合Apache2.0的要求，包括操作系统、编译器和构建工具等。
2. 获取源代码：可以从Apache官方网站或其他可靠的源获取Apache2.0协议下的源代码。
3. 修改源代码：根据您的需求，您可以自由地修改源代码。
请确保遵守Apache2.0协议的规定，不得侵犯他人的知识产权。
4. 分发源代码：您可以将修改后的源代码分发给其他人，并确保他们了解Apache2.0协议的要求。
5. 商业使用：Apache2.0协议不限制商业使用，但您需要遵守相关法律法规和道德规范。
6. 版权声明：在分发源代码时，请确保注明原始版权所有者和Apache2.0协议的版本号。
7. 文档和示例：Apache提供了许多文档和示例，帮助用户更好地理解和使用源代码。
请参考相关文档以获取更多信息。
8. 许可证冲突：如果您使用的其他开源软件使用了不同的协议，请确保它们与Apache2.0协议兼容。
三、常见问题解答1. 我可以随意使用Apache2.0协议下的软件吗？是的，您可以自由地使用该软件，但请遵守协议的规定。
2. 我可以修改Apache2.0协议下的软件并发布吗？当然可以，但请确保遵守协议的规定。
3. 我可以将其集成到我的产品中并销售吗？是的，只要您遵守协议的规定，并遵守相关法律法规和商业道德，您可以这样做。
4. 我需要支付费用吗？Apache2.0是一种免费的开源软件协议，您不需要支付任何费用。
5. 我可以将其用于商业广告用途吗？可以，但请遵守相关法律法规和道德规范。
四、注意事项1. 请确保您完全理解Apache2.0协议的规定，并在使用前仔细阅读相关文档。
2. 请尊重原创，不要复制和分发未经授权的软件或修改过的源代码。
apache licene 2.0协议商用及二次开源的条件和使用方法
Apache License 2.0是一种开源软件许可协议，允许商业使用和进行二次开源。
根据该协议，您可以自由地将受到Apache License 2.0保护的软件用于商业目的，并在满足以下条件的情况下进行二次开源：
1. 版权声明：在您的衍生作品中必须包含原始软件的版权声明，以及对Apache License
2.0的引用。
您需要在适当的位置明确指出您所修改的部分。
2. 许可证通知：您需要在您的衍生作品中包含Apache License 2.0的完整文本或一个指向该许可证的链接。
3. 免责声明：您需要包含一个免责声明，说明原始软件按“ 原样”提供，不提供任何担保或条件，无论是明示还是暗示的。
同时，您还需声明您不对衍生作品的质量、功能或适用性承担责任。
4. 分发方式：如果您选择将衍生作品分发给他人，您需要明确说明原始软件是否已经被修改，以及任何修改的内容。
请注意，Apache License 2.0并不会强制要求您将衍生作品以开源形式发布。
您可以选择仅将衍生作品提供给特定的客户或用户，而无需公开代码。
然而，无论您选择以何种方式分发衍生作品，您仍需要遵守上述条件。
总结起来，商用和二次开源Apache License 2.0许可的条件包括：在衍生作品中包含版权声明、许可证通知和免责声明，并根据分发方式提供相应信息。
1。
Java程序员必须了解的七大开源协议
Java程序员必须了解的七大开源协议下面只列决了个人认为Java程序员必须了解的七大开源协议：Mozilla Public LicenseMPL License，允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
这种授权维护了商业软件的利益，，它要求基于这种软件得修改无偿贡献版权给该软件。
这样，围绕该软件得所有代码得版权都集中在发起开发人得手中。
但MPL是允许修改，无偿使用得。
MPL软件对链接没有要求。
BSD开源协议BSD开源协议是一个给于使用者很大自由的协议。
可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：1. 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。
BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache Licence 2.0Apache Licence是著名的非盈利开源组织Apache采用的协议。
该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。
需要满足的条件：1. 需要给代码的用户一份Apache Licence2. 如果你修改了代码，需要再被修改的文件中说明。
3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
apache2.0 案例
apache2.0 案例
Apache 2.0是一个开源的网页服务器软件，它具有广泛的应用范围和许多成功的案例。
以下是一些使用Apache 2.0的案例：
1. 企业网站，许多大型企业和组织选择使用Apache
2.0作为其网站托管服务器。
例如，美国宇航局（NASA）和亚马逊公司都使用Apache 2.0来托管其网站。
2. 电子商务平台，许多电子商务网站选择使用Apache 2.0来支持其在线交易。
例如，eBay和Alibaba等知名电子商务平台都使用Apache 2.0来处理其网站流量和交易请求。
3. 教育机构，许多大学和学术机构使用Apache 2.0来托管其网站和在线学习平台。
例如，斯坦福大学和麻省理工学院都使用Apache 2.0来支持其在线课程和学术资源。
4. 政府网站，许多政府部门和机构选择使用Apache 2.0来托管其官方网站和在线服务。
例如，美国国家安全局（NSA）和英国政府都使用Apache 2.0来支持其在线服务和信息发布。
5. 社交媒体平台，一些社交媒体平台也选择使用Apache 2.0来支持其网站和用户交互。
例如，Twitter曾经使用Apache 2.0作为其网站服务器。
总的来说，Apache 2.0作为一个稳定、可靠的开源网页服务器软件，在各个领域都有着广泛的应用。
它的灵活性和可定制性使得许多组织和机构选择使用它来支持其网站和在线服务。
因此，Apache 2.0的成功案例遍布各个行业和领域，展现了其在网络基础设施中的重要作用。
openharmony项目结构
一、OpenHarmony项目简介1. OpenHarmony是华为推出的面向全场景、开放原子的分布式操作系统，致力于构建开放、协作、共享的技术生态。
2. OpenHarmony的开源代码由华为公司贡献，基于Apache 2.0开源协议，旨在为全球开发者提供一个自由使用、修改和分发的操作系统评台。
二、OpenHarmony项目结构分析1. 内核层a. 内核层包括鸿蒙微内核和鸿蒙架构，提供了轻量级、高性能、低功耗的操作系统内核。
b. 鸿蒙微内核采用微内核架构，支持多内核调度和轻量级的全局锁管理，实现高效的资源调度和管理。
2. 核心服务层a. 核心服务层包括通用运行时服务框架、分布式软总线等，提供了设备驱动、内核服务和系统服务的支持。
b. 通用运行时服务框架提供了跨评台的应用框架和运行环境，可实现多设备、多场景的统一开发和部署。
3. 基础组件层a. 基础组件层包括基础设施、应用框架、媒体服务和图形引擎等，提供了多媒体、图形、安全等各类基础功能的支持。
b. 基础设施包括文件系统、网络协议栈、硬件抽象层等，实现了操作系统与硬件设备的无缝集成和互操作。
4. 应用框架层a. 应用框架层包括应用环境、交互框架、数据存储等，提供了多样化的应用支持和开发工具。
b. 应用环境包括应用容器、安全容器和容器引擎等，实现了不同应用的安全隔离和多租户共享。
三、OpenHarmony项目优势与特点1. 开放原子a. OpenHarmony支持多种架构和设备类型，包括物联网、智能设备、汽车、智能家居等，构建了一体化的开放原子评台。
b. 开放原子评台提供了统一的开发接口和标准规范，降低了开发者的学习成本和开发成本，实现了软硬件的无缝集成和互操作。
2. 分布式架构a. OpenHarmony基于鸿蒙微内核和架构，实现了轻量级分布式架构和高效的分布式通信。
b. 分布式架构支持多设备、多场景的协同工作和互联互通，实现了智能硬件的一体化管理和智能服务的统一部署。
各种开源协议介绍BSD、ApacheLicence、GPLV2、GPLV3、LGPL、MIT
各种开源协议介绍BSD、ApacheLicence、GPLV2、GPLV3、LGPL、MIT原⽂链接:现今存在的开源协议很多，⽽经过Open Source Initiative组织通过批准的开源协议⽬前有58种（）。
我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。
如果要开源⾃⼰的代码，最好也是选择这些被批准的开源协议。
这⾥我们来看四种最常⽤的开源协议及它们的适⽤范围，供那些准备开源或者使⽤开源产品的开发⼈员/⼚家参考。
BSD开源协议（original BSD license、FreeBSD license、Original BSD license）BSD开源协议是⼀个给于使⽤者很⼤⾃由的协议。
基本上使⽤者可以”为所欲为”,可以⾃由的使⽤，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使⽤了BSD协议的代码，或则以BSD协议代码为基础做⼆次开发⾃⼰的产品时，需要满⾜三个条件：1. 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2. 如果再发布的只是⼆进制类库/软件，则需要在类库/软件的⽂档和版权声明中包含原来代码中的BSD协议。
3. 不可以⽤开源代码的作者/机构名字和原来产品的名字做市场推⼴。
BSD 代码⿎励代码共享，但需要尊重代码作者的著作权。
BSD由于允许使⽤者修改和重新发布代码，也允许使⽤或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
⽽很多的公司企业在选⽤开源产品的时候都⾸选BSD协议，因为可以完全控制这些第三⽅的代码，在必要的时候可以修改或者⼆次开发。
Apache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0）Apache Licence是著名的⾮盈利开源组织Apache采⽤的协议。
开源界的5大开源许可协议
越来越多的开发者与设计者希望将自己的产品开源，以便其他人可以在他们的代码基础上做更多事，开源社区也因此充满生机。
在我们所能想到的应用领域，都有开源软件存在（象WordPress，Drupal 这些开源CMS）。
然而很多人对开源许可并不了解，本文介绍开源领域常用的几种许可协议以及它们之间的区别。
什么是许可协议？什么是许可，当你为你的产品签发许可，你是在出让自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。
不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。
而开源许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。
以下是开源界的5 大许可协议：GNU GPLGNU General Public Licence (GPL) 有可能是开源界最常用的许可模式。
GPL 保证了所有开发者的权利，同时为使用者提供了足够的复制，分发，修改的权利：1.可自由复制你可以将软件复制到你的电脑，你客户的电脑，或者任何地方。
复制份数没有任何限制。
2.可自由分发在你的网站提供下载，拷贝到U盘送人，或者将源代码打印出来从窗户扔出去（环保起见，请别这样做）。
3.可以用来盈利你可以在分发软件的时候收费，但你必须在收费前向你的客户提供该软件的GNU GPL 许可协议，以便让他们知道，他们可以从别的渠道免费得到这份软件，以及你收费的理由。
4.可自由修改如果你想添加或删除某个功能，没问题，如果你想在别的项目中使用部分代码，也没问题，唯一的要求是，使用了这段代码的项目也必须使用GPL 协议。
需要注意的是，分发的时候，需要明确提供源代码和二进制文件，另外，用于某些程序的某些协议有一些问题和限制，你可以看一下@PierreJoye写的Practical Guide to GPL Compliance一文。
apache2.0开源协议使用方法 -回复
apache2.0开源协议使用方法-回复Apache 2.0开源协议使用方法Apache 2.0开源协议是世界上最流行的开源协议之一，被广泛应用于软件、文档和其他知识产权的共享和分发。
本文将一步一步回答关于Apache 2.0开源协议使用方法的问题。
问题1：什么是Apache 2.0开源协议？Apache 2.0开源协议是Apache软件基金会制定的一种开放源代码许可证。
它允许开发者以自由和透明的方式使用、修改和分发开发的软件，同时保留必要的法律条款。
问题2：Apache 2.0协议的主要特点是什么？- Apache 2.0协议鼓励软件的自由使用和分发，允许开发者将其集成到自己的项目中。
- 使用Apache 2.0协议的开发者可以对软件进行修改并分发，无论是以源代码还是二进制形式。
- 开发者可以在Apache协议下发布衍生作品，无论是以衍生作品的原始代码还是衍生作品本身的形式。
- 使用Apache 2.0协议的开发者可以在不修改软件的情况下，将其作为开发工具进行使用。
问题3：如何使用Apache 2.0开源协议？使用Apache 2.0开源协议分发你的软件或其他知识产权时，你需要遵循以下步骤：步骤1：阅读并理解协议内容首先，你需要仔细阅读Apache 2.0协议的内容。
了解协议中的条款和条件，以确保你在使用协议时不会违反任何规定。
步骤2：在项目中包含版权声明在你的项目的源代码和文档中，你需要包含Apache 2.0协议的版权声明。
版权声明应明确指出你使用的是Apache 2.0协议，并包含相应的许可证文本。
例如：Copyright [年份] [作者名]Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License atUnless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions andlimitations under the License.步骤3：说明衍生作品如果你对软件进行了修改或创建了衍生作品，你需要在衍生作品中清楚地说明这一点。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
竭诚为您提供优质文档/双击可除apache2.0开源协议篇一：常见开源协议比较常见的开源协议及它们的适用范围bsdbsd开源协议是一个给于使用者很大自由的协议。
基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了bsd协议的代码，或则以bsd协议代码为基础做二次开发自己的产品时，需要满足三个条件：如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的bsd协议。
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的bsd协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
bsd代码鼓励代码共享，但需要尊重代码作者的著作权。
bsd由于允许使用者修改和重新发布代码，也允许使用或在bsd代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
而很多的公司企业在选用开源产品的时候都首选bsd协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
apachelicence2.0apachelicence是著名的非盈利开源组织apache采用的协议。
该协议和bsd类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。
需要满足的条件也和bsd类似：需要给代码的用户一份apachelicence如果你修改了代码，需要再被修改的文件中说明。
在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
如果再发布的产品中包含一个notice文件，则在notice 文件中需要带有apachelicence。
你可以在notice中增加自己的许可，但不可以表现为对apachelicence构成更改。
apachelicence也是对商业应用友好的许可。
使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
gpl我们很熟悉的linux就是采用了gpl。
gpl协议和bsd,apachelicence等鼓励代码重用的许可很不一样。
gpl的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
gpl协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)gpl协议的产品，则该软件产品必须也采用gpl协议，既必须也是开源和免费。
这就是所谓的”传染性”。
gpl协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于gpl严格要求使用了gpl类库的软件产品必须使用gpl协议，对于使用gpl协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随gpl协议等和bsd/apache等类似。
lgpllgpl是gpl的一个为主要为类库使用设计的开源协议。
和gpl要求任何使用/修改/衍生之gpl类库的的软件必须采用gpl协议不同。
lgpl允许商业软件通过类库引用(link)方式使用lgpl类库而不需要开源商业软件的代码。
这使得采用lgpl协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改lgpl协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用lgpl协议。
因此lgpl协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以lgpl协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
gpl/lgpl都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品关于开源协议gplV2和V3单从开源行业的gpl协议上来看，似乎开源linux产品上的一切是可以无条件的开放和共享的，但是从实际的操作来看，在gpl相对的许可授权之下，又有其相对封闭的一面，就这次的gplv2到gplv3的修订改版来说，正是gpl协议“封闭”一面的具体体现。
根据gplv2的相关规定：只要这种修改文本在整体上或者其某个部分来源于遵循gpl的程序，该修改文本的整体就必须按照gpl流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。
而在gplv3的修订草案中，不仅要求用户公布修改的源代码，还要求公布相关硬件，恰恰是这一条，由于触及和其他相关数字版权管理(dRm)及其产品的关系，并且也由于有和开源精神相违的地方，所以备受争议，甚至因此也遭到了有着“linux之父”之称的托瓦尔兹的反对。
从表面上看，gplv2到gplv3的升级之困只不过是对协议修订过程中某一条款的分歧，而更为严重的是在两种协议都合法存在的前提下，具体的开源软件或者开源产品的所有者有权选择是遵循gplv2协议还是恪守gplv3协议，因此冲突也就来了，这种冲突正如中科红旗的cto郑忠源描述的那样：“世界有如此多软件都在gplv2的约束之下，而自由软件是集合全世界程序员劳动，即使是贡献一行代码，如果该程序员只同意这一代码只遵循gplv2之下，就不能随便去修改协议。
如果计划将软件转移到gplv3之下，理论上讲，必须征得所有代码人的同意。
但是目前还很难确定有多少开发人员愿意转移到新版本之下(apache2.0开源协议)，如果有的人愿意转，有的人不愿意转，这其中就有很多的麻烦；而如果多数人都不愿意改变，那这一事情也许就无声无息……”通过业内人士的精辟描述，相信大家一定对开源行业和开源软件产品有了一个全新的认识吧，就那熟悉的linux系统来说，虽然表面上看起来大家有权按照自己的需要和目的进行任意的改写重组，但是在诸多的独立程序面前，别人是只能共享使用，而无权修改的，当然获得授权就另当别论了。
而就gplv2到gplv3的协议升级来说，这种协议的选择上的分歧实际上也是开源行业里一种观念认知上的相左，到底谁的选择是正确的？绝对不是一两句话能说得清的，尤其是在各种利益交织之下。
情势之下，开源社区的gplv2与gplv3选择之困很现实的会在相当一段时间内给这个行业及其产品造成“兼容问题”，说白了就是两种协议以及两种协议之下的矛盾，不管是人的还是产品的都将会持续下去，而这种僵持对整个开源行业来说未必是一件好事，最起码从“精神”方面来说这个行业已经在开始分道扬镳。
mitmit是和bsd一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.cpal开源许可证——普通公共属性许可证(commonpublicattributionlicense),本质上其是由mozilla公共许可证(mpl)加入新的条款构成.该许可要求开发者对软件进行标记。
mplmpl是themozillapubliclicense的简写，是1998年初netscape的mozilla小组为其开源软件项目设计的软件许可证。
mpllicense（mozillapubliclicense）允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。
这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。
但mpl是允许修改，无偿使用的。
mpl软件对链接没有要求。
(要求假如你修改了一个基于mpl协议的源代码，则必须列入或公开你所做的修改，假如其他源代码不是基于mpl则不需要公开其源代码) mpl许可证出现的最重要原因就是，netscape公司认为gpl许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。
同著名的gpl许可证和bsd许可证相比，mpl在许多权利与义务的约定方面与它们相同（因为都是符合osia认定的开源软件许可证）。
但是，相比而言mpl 还有以下几个显著的不同之处:◆mpl虽然要求对于经mpl许可证发布的源代码的修改也要以mpl许可证的方式再许可出来，以保证其他人可以在mpl的条款下共享源代码。
但是，在mpl许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着mpl允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以mpl许篇二：五种开源协议的比较(bsd,apache,gpl,lgpl,mit) 五种开源协议的比较（bsd,apache,gpl,lgpl,mit）20xx-03-2211:31当adobe、microsoft、sun等一系列巨头开始表现出对”开源”的青睐时，”开源”的时代即将到来！现今存在的开源协议很多，而经过opensourceinitiative组织通过批准的开源协议目前有58种（/licenses/alphabetical）。
我们在常见的开源协议如bsd,gpl,lgpl,mit等都是osi批准的协议。
如果要开源自己的代码，最好也是选择这些被批准的开源协议。
这里我们来看四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员/厂家参考。
bsd开源协议（originalbsdlicense、Freebsdlicense、originalbsdlicense）bsd开源协议是一个给于使用者很大自由的协议。
基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了bsd协议的代码，或则以bsd协议代码为基础做二次开发自己的产品时，需要满足三个条件：。