Open-source protocols

There was no clear concept of open-source protocols before, and I always thought that open-source is free or even free of charge. I spent a day reading open-source protocols a few days ago.

Common Open Source protocol analysis

Let's have a look at 'open source!

Common Open Source protocols

Sun shot GPL open source Protocol

Open source protocol list

I also read some details about cpl1.0:
Common Public License (CPL) Frequently Asked Questions

Common Public License Version 1.0

What open source license is openlaszlo available under?

I have a rough understanding of open-source protocols. Let's talk about some of my rough understanding of open-source protocols. If you have any mistakes, please advise.

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 accessors of open-source software or projects. Obviously, subsequent contributors also belongs to the recipients column.

(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, ativex, OCX controls. (I don't know if this is correct)

The purpose of these two concepts is to make it clear that some open-source systems only release object code. Of course, most of them release source code. Many protocols also have explicit constraints 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.

Next, let's talk about several common protocols. In fact, some common open-source protocols have been clearly described in the links of the articles I have provided above. I am just adding some personal understanding here, I hope it will be helpful to those who have little contact with me.

GPL (GUN General Public License) vesion 2.0 1991

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

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 mixed with the source code authorized by GPL must comply with the GPL protocol. Just like a virus, it is "poisoned" when the relationship is attached. 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 on the link I provided above. 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 GPL on the software release version is that your release version must provide the complete source code together.

BSD (Berkeley Software Distribution
)

Unlike GPL, BSD is an open-source protocol that gives people great freedom. Its biggest feature is that recipients can "Do whatever you want" the source code, modify it, use it freely, and release it in other ways (commercial or open-source) after modification ). However, when you do these things, you must follow the following rules:

1. If the re-release product contains the original "source code", the original "source code" must contain the BSD Protocol in the original code.
2. If only binary class libraries/software (object code/product) are released, 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 and come 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 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 vesion 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: (the original English text is provided to facilitate more accurate understanding)

1. A copy of Apache licence is required for the recipients.

(You must give any other recipients of the work or derivative works a copy of this License)
2. If you have modified the code, you must describe it in the modified file.

(You must cause any modified files to carry prominent notices stating that you changed the files)

3. In the derivative module (Code derived from modification and inclusion of source code), the protocols, trademarks, patent statements and other instructions required by the original author must be included.

(You must retain, in the source form of any derivative works that you distristri, all copyright, patent, trademark, and attribution notices from the source form of the work, excluding those notices that do not pertain to any part of the derivative
Works)
4. If the product to be released 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.

(If the work nodes des a "Notice" text file as part of its distribution, then any derivative works that you distribute must include a readable copy of the attribution notices contained within such notice file, excluding those notices that do not pertain
To any part of the derivative works, in at least one of the following places: within a notice text file distributed as part of the derivative works; Within the source form or documentation, if provided along with the derivative works; or, within a display
Generated by the derivative works, if and wherever such third-party notices normally appear. the contents of the notice file are for informational purposes only and do not modify the license. you may add your own attribution notices within derivative works
That you distriense, alongside or as an addendum to the notice text from the work, provided that such additional attribution notices cannot be construed as modifying the license .)

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.

Lgpl

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 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.

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.

(Does the CPL allow me to take the source code for a program licensed under it and include all or part of it in another program licensed under the GNU General Public License (GPL), Berkeley
Software Distribution (BSD) license or other open source license?
No. only the owner of software can decide whether and how to license it to others. contributors to a program licensed under the CPL understand that source code for the program will be made available under the terms of the CPL. unless you are the owner of
Software or have specified ed permission from the owner, you are not authorized to apply the terms of another license to the program by including it in a program licensed under another open source license. by the way, the same answer applies if you want to include
Source code licensed under another open source license in a program licensed under the CPL)

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, and you need to inform the Retrieval Method

( Can I take a program licensed under the CPL, compile it without modification, and commercially license the result?

Yes. You may compile a program licensed under the CPL without modification and must cially license the result in accordance with the terms of the CPL. Do I need to include the source code for such program with the object code distribution?

No. But you do need to include a statement that the source code is available from you and information on how to obtain it. What happens if I make a modification to the platform under the CPL but choose not to distribute it to anyone else?Under the CPL, in this circumstance you do not need to make the source code available to others. If I modify a program licensed under the CPL and distribute the object code of the modified program for free, must I make the source code available?

Yes. by distributing the modified program, even if it is only a free version of the object code, you are obligated to make the source code to the modified program available to others .) 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. ( When I inereate a portion of a program licensed under the CPL into my own proprietary product distributed in object code form, can I use a single License for the full product, in other words, covering
The portion of the program plus my own code?
Yes. The object code for the product may be distributed under a single license as long as it references the CPL portion and complies, for that portion, with the terms of the CPL.

) 4. independent modules (separate module), no need to open source

(If I write a module to add to a program licensed under the CPL and distribute the object code of the module along with the rest of the program, must I make the source code to my module available in
Accordance with the terms of the CPL?
No, as long as the module is not a derivative work of the program .)

In conclusion, my understanding of open-source protocols is just a preliminary understanding. In particular, CPL is still confused. In addition, I have always felt that the derivative module and separate module are difficult to have a clear boundary. To some extent, I always feel that they have an ambiguous location. But if you have some experience, write it down first. We sincerely welcome your comments and discussions.