Comparison of five open source protocols-zz

Address: http://blog.csdn.net/jiazhen/archive/2009/09/29/4619081.aspx

Comparison of five open source protocols

There are many open-source protocols today, and there are currently 58 open-source protocols approved by the Open Source Initiative Organization (http://www.opensource.org/licenses/alphabetical ). Common open-source protocols such as BSD, GPL, lgpl, and MIT are OSI-approved protocols. If you want to open up your own code, it is best to select these approved Open Source protocols.

Here we will look at the four most commonly used open-source protocols and their applicability for the reference of developers/manufacturers who are preparing to open-source or use open-source products.

BSD open source protocol (Original BSD license,FreeBSD license,Original BSD license)

BSD open source protocol is a protocol that gives users great freedom. Basically, users can "do whatever they want" and use it freely, modify the source code, or release the modified Code as open source or proprietary software.

However, when you publish code using the BSD Protocol or develop your own product based on the BSD Protocol code, you must meet the following three conditions:

1. If the released product contains the source code, the BSD Protocol in the original code must be included in the source code.
2. If you only release binary class libraries/software, you must include the BSD Protocol in the original code in the Library/software documentation and copyright statement.
3. You cannot use the author/Organization Name of the open source code or the name of the original product for marketing.

BSD Code encourages code sharing, but it must respect the copyright of the Code author. BSD is a friendly protocol for business integration because it allows users to modify and re-release code, and also allows users to use or develop commercial software release and sales on BSD code. Many companies prefer the BSD Protocol when selecting open-source products, because they have full control over these third-party code and can modify or perform secondary development as necessary.

Apache licence 2.0 (Apache license, version 2.0, Apache license, Version 1.1, Apache license, Version 1.0)

Apache licence is a well-known non-profit open-source Apache protocol. Similar to BSD, this Protocol also encourages code sharing and respect for the copyright of the original author. It also allows code modification and re-release (as an open source or commercial software ). The conditions to be met are similar to those of BSD:

1. A copy of Apache licence is required for the code user.
2. If you have modified the code, it is described in the file to be modified.
3. In the extended code (Modification and code derived from source code), the Protocol, trademark, patent statement in the original code and other instructions required by the original author must be included.
4. If the published product contains a notice file, Apache licence must be included in the notice file. You can add your own license to notice, but it cannot be expressed as a change to Apache licence.

Apache licence is also a friendly license for commercial applications. Users can also modify the code as needed to meet their needs and release/sell as open-source or commercial products.

GPL (GNU General Public License)

We are familiar with the use of GPL in Linux. The GPL protocol and BSD, Apache licence, and other licenses that encourage code reuse are very different. The starting point of GPL is the open-source/free use of code and the open-source/free use of reference/modification/derivative code, however, modification and derivative code generation cannot be released and sold as commercial software with closed source. That's why we can use a variety of free Linux, including commercial companies' Linux and Linux various free software developed by individuals, organizations, and commercial software companies.

The main content of the GPL protocol is as long as you use ("use" refers to the class library reference, modified code or derivative code) the GPL protocol in a software product, the software must also adopt the GPL protocol, which is both open-source and free.This is the so-called "contagious". The GPL protocol product can be used as a separate product without any problems. You can also enjoy the free advantage.

Because GPL strictly requires that software products that use the GPL class library use the GPL protocol, for open source code that uses the GPL protocol, commercial software or departments that require code confidentiality are not suitable for integration/adoption as the basis for class libraries and secondary development.

Other details, such as the GPL Protocol, must be similar to BSD/Apache.

Lgpl (GNU lesser General Public License)

Lgpl is an open-source protocol designed mainly for class libraries. Unlike GPL, any software that uses/Modifies/derives the GPL class library must use the GPL protocol. Lgpl allows commercial software to use the lgpl class library through class library reference (Link) without the need for open source commercial software code. This allows open source code using the lgpl protocol to be referenced and published and sold by commercial software as class libraries.

However, if you modify or derive the lgpl protocol code, all the modified Code, the additional code involved in the modification part, and the derived code must adopt the lgpl protocol. Therefore, the open-source code of the lgpl protocol is suitable for being referenced by commercial software as a third-party class library, but it is not suitable for the lgpl protocol code, secondary Development of commercial software is implemented through modification and derivative methods.

GPL and lgpl both protect the intellectual property rights of the original author and prevent people from copying and developing similar products using open-source code.

MIT (MIT)

MIT is the same as BSD's wide-range license agreement. The author only wants to retain the copyright without any other restrictions. that is to say, you must include the original license agreement statement in your release, whether published in binary or source code.