Follow the Open Source protocol in Enterprise Application Development

Recently I saw a diagram about open source protocols and thought that we are also using a lot of open source software in enterprise application development. How should we treat these open source software, so I wrote down this blog.

In enterprise application development, open-source software, projects, and components are often used to improve development efficiency. When using these open-source projects, you must first look at their open-source protocols to avoid challenge. There are manyArticleI will not talk about open-source protocols and their comparison here. I just want to explain how to use them.

The enterprise application development here mainly aims to close the source as much as possible to protect the knowledge of your own, and try to reduce costs for free.

For open-source projects with Apache licence, BSD, and MIT protocolsSource codeFor secondary development, you can also reference the DLL compiled by the project or other protocols. These protocols are enterprise-friendly. Our projects do not need to be open-source and do not need to pay for licenses. You only need to specify the license information of the original project in the copyright notice document.

For lgpl, the requirement is for the sourceCodeThe modification must be open-source, but open-source is not required if it is referenced. Therefore, we generally use the lgpl protocol directly.ProgramInstead of using its source code for secondary development. For example, the commonly used Nhibernate protocol is the lgpl protocol. You only need to reference the Nhibernate Assembly during development, our code is still closed source. However, there is a problem here: if the existing lgpl open-source project can meet most of our needs, but there are still a small number of requirements that must be modified, or there are bugs in the original project, we must modify the source code for correction. In this case, the source code must be modified. Based on this source code, I create a project to add the features we need and fix the bugs found in this project, then, the project is open-source using the lgpl protocol and the DLL compiled by the project is used in our enterprise application development. This not only satisfies the requirement that we must modify the source code, but also protects our own projects and still meets the Protocol requirements.

In short, the lgpl protocol is mainly used as a class library. We do not recommend that you perform secondary development directly on the lgpl project. If you have to modify the source code of an open-source project, create an open-source project and modify the source code of the project.

MPL is similar to lgpl, and it is more friendly to reference the class library. However, if the source code is developed twice, the copyright after modification will be the author of the original MPL project, so the solution is to create an open-source project to modify the source code, and then reference it as a class library after modification. In addition, MPL must provide instructions on the changes.

Next, let's talk about the GPL protocol, which is unfriendly to enterprises. The exception is that, even if you reference the GPL class library, your project must be open-source. Therefore, in enterprise applications, GPL is not used as much as possible without GPL. We all say that the GPL protocol is like a virus, and all new projects that use the GPL project are infected with Open-Source GPL projects. Therefore, we want to avoid virus infection and become an Open-Source GPL project. In addition to avoiding GPL usage, if necessary, we cannot find a suitable alternative product, we should try to isolate the module that uses the GPL project. For example, if there are 10 modules in our project, and one module needs to use the GPL project, we can split our project into two projects as much as possible, one project is a project with nine modules completely closed to the source, and the other is an open-source GPL project. In this way, we can at least isolate the code of GPL from other unrelated modules to avoid infection.

Another isolation method is to coordinate the GPL project with the closed source project, and there is no reference relationship. For example, if Project A needs to use GPL Project B, we can first establish project A1, complete our core logic processing, and then release A1 in the form of a closed source, next, we will establish open-source project A. A references project A1 and Project B and combine these two projects to complete the corresponding functions. In short, we should try our best to reduce the scope of use for GPL projects, so as to achieve a minimum degree of open source and meet the needs of enterprise application development.

PS: all open source protocols list: http://www.opensource.org/licenses/alphabetical