Practical article: Detailed Analysis of Common Open Source protocols

Open source is already widely used in today's software industry, but does open source mean that users can do whatever they want to do with open source code? The answer is no. open-source sports also have their own game rules and ethics. failing to comply with these rules will not only damage the healthy development of the open-source movement, but also cause reputational and market losses to violators, and more likely fall into legal disputes and compensation.

　　First, you need to understand several concepts:

　　1. contributors and recipients

Contributors refers to the person or entity (Team, company, organization, etc.) who provides code (including initial or modified) for an open source software or project ), contributors can be divided into an initial contributor and subsequent contributors according to the time sequence involved in a software open source.

Recipients refers to the winners of open-source software or projects. Obviously, subsequent contributors also belongs to recipients.

　　2. source code and object code

Source Code refers to the source code written in various languages. By using source code and documents, you can understand the architecture of the entire software and the implementation methods of a specific function.

Object Code refers to the object code generated after the source code is compiled, similar to the "class library". It provides various interfaces for others to use. According to my understanding, it is something like common DLL, ActiveX, OCX controls. (I don't know if this is correct)

The purpose of these two concepts is to make it clear that some of them are open-source and only post object code. Of course, most of them are post source code. many protocols also have clear restrictions on "What code should you publish.

　　3. Derivative module and separate module

Derivative module refers to the code generated based on or containing the "initial" or "obtained from others" open source code, which is an enhancement of the original "source code" (not equal to the increase), improve and continue the module, meaning "derivative module ".

The separate module refers to an independent module developed by referring to or using the original "source code", which does not contain or depend on the original "Source code module", meaning "independent module ". the purpose of understanding these two concepts is that many protocols have clear commercial release regulations regarding what is derivative and independent when it comes to commercial release.

There are many open-source protocols, and there are currently 58 open-source protocols approved by the Open Source Initiative Organization. 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 (Berkeley Software Distribution)

BSD open source protocol is a protocol that gives users great freedom. basically, users can "do whatever they want" to use it freely, modify the source code, or use the modified Code as open-source or proprietary software for release. but the premise of "do whatever you want" is that when you publish code that uses the BSD Protocol, or perform secondary development of your own product based on the BSD Protocol code, three conditions must be met:

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. Open-source author/organization name and original product name cannot be used for marketing.

In fact, the purpose of these rules is only to achieve one goal: it is something of others. If someone else is open-source with BSD, you cannot make any declaration and take possession of yourself, it cannot be used for commercial promotion in the name of another person. you only have absolute control over your own things.

For example, after you use open source code (A) to modify or add other products, product B is generated. At this time, your control over B is determined by yourself, you can use any protocol to make it open-source, or close the source for commercial release. however, if B contains a part of A or a (not included at all), then in the copyright statement of product B, it must be mentioned that you have used a with the Open Source protocol of. in addition, B cannot be named as the original open-source author to promote commercial promotion.

BSD Code encourages code sharing, but it must respect the copyright of the Code author. BSD allows users to modify and re-release code, or use it on BSD code.
Developing Commercial Software Release and sales is a friendly protocol for commercial integration. 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 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, you need to modify it in the file.

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 shall be included.

4. if the published product contains a notice file, Apache licence is required in the notice file. you can add your own license in notice, but it cannot be expressed as a change to the 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 (GUN General Public License) vesion 2.0 1991

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 cannot be released and sold as commercial software with closed source. that's why we can use free Linux, including various free software developed by individuals, organizations, and commercial software companies on Linux and Linux.

The main content of the GPL protocol is as long as it is used in a software ("use" refers to the class library reference, modified code or derivative code, 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 is 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.

The most common open-source protocol, which is used as an authorization protocol for a well-known Linux. two of the most notable characteristics of GPL are the "virus sexual transmission" and "commercial release of closed source is not allowed" on the Internet ".

The so-called "virus transmission" refers to the GPL rules that all sources derived from the GPL protocol authorization (that is, the derivative module mentioned above ), or projects that are mixed with the source code authorized by GPL must follow the GPL protocol. Just like a virus, if the relationship is attached, the project will be "poisoned. the purpose of GPL is to ensure that products under the protection of GPL are no longer subject to any other agreement or authorization. that is, the source code related to GPL can be obtained for free. for example, if your improved Linux system uses the open-source module authorized by GPL (which must also be used, you cannot re-build the kernel by yourself. If so, you don't have to call it Linux either .), in this case, your entire Linux product must follow the GPL protocol to open source, and cannot be released in other ways. in this way, there will be no such Linux-this function is authorized by the GPL protocol, and the source code can be obtained for free. Another function is under other protocols and cannot obtain the source code. this provision is a great convenience for those who use or study the product.

"Closed-source commercial release is not allowed" means that, under the GPL authorization, your software products can be commercially released and sold for money. However, at the same time, you must also publish the source code of the product in the form of GPL protocol for free. some people may be confused, sell, and open source at the same time. Who will buy it? How can this product make money ?? This involves the business model of open-source products. If you want to learn more about the business model, you can refer to some of the articles I have provided. later, I may write an article about the business model of open-source projects.

A key aspect of commercial release under the GPL protocol, as Robbin of the Java sight Forum said, GPL is the copyright of the software source code, not the copyright of the binary version after the software is compiled. you have the right to obtain the source code of the software for free, but you do not have the right to obtain the binary release version of the software for free. the only restriction of GP on the software release version is that your release version must provide the complete source code together.

For details, such as the GPL protocol and BSD/Apache, need to be added during the re-release.

Lgpl

Lgpl is an open-source protocol designed mainly for class libraries. different from 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 by commercial software as class libraries for concurrent release and sales.

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.

　　Cpl (common public liecense) vesion 1.0

CPL is an open source protocol proposed by IBM and approved by OSI (Open Source Initiative. it is mainly used in some open-source software/projects related to IBM or IBM. such as the well-known Java Development Environment eclipse and the RIA development platform open Laszlo.

CPL is also a friendly protocol for commercial applications. it allows recipients to use, copy, distribute, disseminate, present, modify source code, and implement secondary commercial release of closed source after modification. This is similar to BSD, it is also an open-source protocol with high degrees of freedom. however, you must follow the following steps:

1. when a contributors releases the entire or part of the source code again, it must continue to follow the CPL open-source protocol for release, rather than using other protocols for release. unless you are authorized by the original "source code" Owner.

2. under the CPL protocol, you can release the source code without any modification. however, if you want to open the source code after the modification, and when you release the object code, you must declare that its source code can be obtained, also, you need to inform the retrieval method.

3. when you need to mix the source code under CPL as a part with other private source codes into a project for release, you can publish the entire project/product in a private protocol, however, you need to declare which part of the Code is under CPL, and declare that the part of the Code continues to follow Cpl.

4. Independent module (separate module), which does not need to be open-source.