In many people’s eyes, “open source” is a fashionable and sentimental term, always with an idealistic tinge, so many companies have started to label themselves as “open source”. But a good open source project is much more than simply opening up the source code. It needs to be implemented as a corporate strategy to build an unbreakable bridge of trust.

PingCAP has accumulated some experience and lessons from the first line of open source code in the past six years. In the popular Science of Open Source Knowledge column, we will share and communicate with you our thoughts and feelings on the growth path of open source, as well as the correct attitude to participate in open source projects. This issue topic from the basis of open source – open source license, I hope to understand open source, open source participation has certain help.

In recent years, open source is becoming more and more popular. We often see “some enterprise announces open source”, “some open source conference is held”, “some open source project gets financing”. Individual developers and enterprises are more willing to participate in the construction and contribution of open source projects than ever before, and open source has gained unprecedented heat in the domestic IT field, and also received extensive attention from the industry and investment circle. But there are always people who, when they hear the word open source, mistakenly think “open source software is free, so I can use it as I please.” At the beginning of the birth of open source, free software was the mainstream term at that time. Looking back at the development history of open source, there is a great leap from free software to open source movement. The former is more of a spiritual advocacy, while the latter focuses on the collaborative opening of software, so there are very strict rules and restrictions of open source license. Open source software can go to today’s level of development, is because of such a set of rules to comply with the spirit of open source, can be healthy development. One of the carriers of the open source spirit is the open source license. Today we will pick the relationship between the source license and open source, and the problems reflected behind it.

What is an open source license? (Open Source License)

To be clear, the copyright of the source code of open source software is neither waived nor expired, and its modification and distribution are still subject to copyright law or open source software licenses.

Open Source licenses generally restrict the use, copying, modification, and re-distribution of Open Source software. A license is a license clause, and an open source license is a legal document guaranteeing these restrictions on open source software, with the purpose of regulating the use or distribution of copyrighted software. Open source licenses are the foundation of the open source software ecosystem and facilitate the collaborative development of software.

Common Open Source Licenses

Common open source licenses include Apache, MIT, BSD, GPL, LGPL, MPL, SSPL, etc., which can be roughly divided into two categories: A Permissive Free Software license (Permissive Free Software License) and a copyleft license (Copyleft license).

The Permissive free software license is a type of free software license that applies minimum restrictions on the use, modification, and dissemination of software. This type of software license agreement will not guarantee that derivative works of the original work will continue to maintain exactly the same relevant conditions as the original work, thus providing more room for the free use, modification and dissemination of the original work. A Copyleft License is free to use, modify, and distribute in a limited space without violating the restrictions of the original work. If a piece of software is licensed under a Copyleft type license that says the software must not be used for commercial purposes and must not be closed source, then subsequent versions of the software must also comply with the terms.The biggest difference between the two isWhen the software is modified and redistributed, the Copyleft License still requires open source (derivative software needs to be open source), while the Permissive Free Software License does not require open source (derivative software can become proprietary software). Among them, Apache, MIT and BSD are all loose licenses. GPL is a typical strong copyleft license, while LGPL and MPL are weak copyleft licenses. SSPL is a new license created by MongoDB in recent years, which is quite controversial. OSI even thinks that SSPL is not an open source license. Another category is Creative Commons (CC). The protocols are not really open source in the strictest sense, they are mostly used for design-based projects. There are a wide variety of CC protocols, each of which grants specific rights. Most strict CC agreements state a “right of authorship, non-commercial use, no derivative” clause, which means you are free to share the work, but you cannot change it or charge for it, and you must claim ownership of the work. This license agreement can be very useful as it allows your work to be distributed while retaining partial or total control over the use of your work. The least restrictive type of CC agreement is a “signature” agreement, which means people can use your work however they want as long as they maintain your reputation.

Source: moqod.com/mobile-web-…

As you can see, there are huge variations from license to license, and you might wonder, what’s the purpose of all this complexity? This has to start with the history of open source. The term open source originally meant open source software (OSS). Open source software is computer software where the source code is freely available and anyone can view, modify, and distribute the code as they see fit. In Open Source, there are two camps: FSF (Free Software Foundation) and OSI (Open Source Initiative), which have different philosophies of Open Source. FSF is an important open source software foundation founded by RMS (1985/10/04). FSF was founded mainly to raise funds to build GNU kernel Hurd project and tool chain. Although the GNU project itself was not completed, a large number of software tools were created in the process. Later became an important part of GNU/Linux. In keeping with RMS’s understanding of “free” and “open source,” the FSF created the first “copyleft” License for open source — the GNU Public License (GPL). OSI was founded in 1998 by open source luminaries Bruce Perens and Eric S. Raymond (ESR) to seek a more balanced system and governance mechanism in the fierce conflict between fundamentalist open source (the original originators and promoters of the open source movement) and the software industry/business. The OSI has approved about 80 licenses, including Apache License V2, GPL V2, MIT/BSD, and so on. The FSF and OSI are non-profit organizations that promote and maintain the open source order, maintaining the definition of “open source” and the submission, discussion and review of major open source software agreements. Software that uses open source to distribute licenses is open source software. If a commercial product contains open source software, it can be packaged with the open Source Promotion Council certification stamp. Consumers who recognize the logo will know that open source software is used in the product and will buy the product because of its unique advantages.

Here’s a quick look at the differences between common open source licenses:

Source: www.ruanyifeng.com/blog/2011/0…

The Apache License is a free software License issued by the Apache Software Foundation. It was originally written for the Apache HTTP server. The latest version of this license is version 2, which was released in January 2004. The Apache license encourages code sharing and ultimate authorship, allowing source code modification and redistribution. However, the following conditions should be followed:

  • You need to give the user of your code an Apache Licence;
  • If the code is modified, it needs to be explained in the modified file.
  • In derived code (modified and derived code with source code) it is necessary to carry the agreements, trademarks, patent claims and other instructions required by the original author in the original code;
  • If the product to be released contains a Notice file, the Apache Licence must be included in the Notice file. You can add your license to the Notice, but it should not be a change to the Apache License.
  • Apache Licence is also a business-friendly license. Users can also modify the code as needed and distribute/sell it as an open source or commercial product.

For example, in an open source project using Apache license, the downstream Fork not only did not give back to the upstream open source project, but changed the derived code to the SSPL Licence, which is not approved by OSI, and separately announced it as a new open source project, misleading many people who do not know the truth. A new open source project has sprung up. But this behavior has actually caused infringement on the legitimate rights and interests of the original open source project, and also has the spirit of backtracking open source. As an open source infrastructure software company built on open source from day one, PingCAP is clearly opposed to practices that “violate the spirit of open source and break the rules of the game” in open source software. PingCAP’s current open source projects include TiDB, TiKV and Chaos Mesh®, which are all developed and operated based on the Apache 2.0 protocol. Any individual, company or cloud vendor who does not violate the relevant provisions of the Apache 2.0 protocol, They are free to download, read, rewrite, compile source code, and even release their own distributions for commercial purposes. When we designed this company, PingCAP was preparing for the design of open source to make continuous contributions. For example, in the open source governance system, we consider ourselves part of the open source technology system and have a dedicated team to run the open source community continuously. In the open source technology system, the open source community is the upstream source of the whole new technology innovation, but also the incubator of innovative technology. The open source community drives open source projects and enables rapid iterations of products through global collaboration. Through this source innovation approach, innovative technologies can be continuously “produced” through global community collaboration, and the open source community has effectively become the innovation engine of new technologies. In the just-released “Open Source Community Maturity Study Report” 2.0, TiDB community is studied as a model of open source community operation and governance practices to explore the healthy and sustainable development of open source community. The report also puts forward the open source community maturity model and open source community measurement system for the first time. Students who are interested in open source can click the link to download the original text. As a member of the open source ecosystem, we welcome anyone to participate in the cause of open source and jointly prosper the open source field. The situation of open source today is not easy, and it needs all the people involved to jointly maintain it, Revere the rules of the game and follow the open source spirit, so as to create a better future of open source.

The attached:

Common open source licenses:

  • Apache: The Apache License is a free software License published by the Apache Software Foundation and originally written for the Apache HTTP server. The Apache license requires the licensee to retain the copyright and waive the claim, but it is not an anti-copyright license. The latest version of this license is version 2, which was released in January 2004. The Apache license is lax because it does not force derivative and modified works to be distributed under the same license.
  • MIT: The MIT License is named after the Massachusetts Institute of Technology (MIT). It is also known as “X License” or “X11 License”. MIT content is similar to that of a 3-clause BSD license, but gives the software licensee greater rights and fewer restrictions. There are many groups that use MIT licenses. For example, the famous SSH connection software PuTTY and X Window System (X11) are examples. Expat, Mono Dev Library, Ruby on Rails, Lua 5.0 Avoid to name a few also use MIT licensing terms.
  • BSD: The Berkeley Software Distribution License (BSD) is one of the most widely used licenses in free Software. BSD is distributed under this license, hence the name BSD License agreement. The original owner of the BSD package was the Board of trustees of the University of California, as BSD originated at the University of California, Berkeley. After BSD began, the BSD license agreement was amended so that many subsequent BSD variants had similar terms. Compared with other terms, from the GNU General Public License (GPL) to heavily restricted Copyrights, the BSD license is looser and even closer to the Public Domain. In fact, a BSD license is considered a copycenter, somewhere between a standard copyright and a GPL copyleft. Take it down to the copy center and make as many copies as you want. Arguably, the GPL forces subsequent versions to be free software as well, and subsequent versions of BSD can choose to remain BSD or other free software terms or closed source software, etc.
  • GPL: The GPL is very different from the BSD, Apache Licence and other licenses that encourage code reuse. The GPL’s intent is to make code open source/free to use and reference/modify/derive code open source/free to use, but does not permit the distribution and sale of modified and derived code as closed source commercial software. Since the GPL strictly requires software products using the GPL class library to use the GPL, it is not appropriate for commercial software or departments with confidentiality requirements to integrate/adopt the OPEN source code using the GPL as a basis for class libraries and secondary development.
  • LGPL: LGPL is an open source protocol of the GPL designed primarily for use by class libraries. Unlike the GPL’s requirement that any software that uses/modifies/derives from the GPL class library be licensed under the GPL. LGPL allows commercial software to use LGPL libraries through library references without the need for open source commercial software code. This allows open source code under the LGPL protocol to be referenced, distributed and sold by commercial software as a class library. However, if LGPL code is modified or derived from it, then all modified code, additional code involving modified parts, and derived code must be LGPL. Therefore, LGPL open source code is suitable for commercial software to reference as a third-party library, but not for commercial software that wants to use LGPL code as a basis for secondary development through modification and derivation.
  • SSPL: SSPL is a source code available license created by MongoDB to embody the principles of open source and to provide protection against public cloud vendors offering open source work as a service without giving it back. SSPL allows the free and unrestricted use and modification of open source works, but if you offer the open source works as a service to others, you must also publicly distribute any modifications and management source code under SSPL. OSI, the open Source initiative, is critical of SSPL, arguing that it is not an open source license, but actually a license to make source code available.
  • Elastic License: Elastic License is a non-commercial License that requires a commercial License to use the product as a SaaS.