The evolution of open source licenses: Let’s start with Elastic’s two changes to open source licenses

Open source has been around for decades since its inception, and open source licenses have played a cornerstone role in the development of the open source movement, both from a cultural and legal point of view, promoting the development of open source.

Last year (2021), Elasticsearch and Kibana, two open source projects of Elastic, changed their open source agreements. Starting from version 7.11, the previous Apache 2.0 license was adjusted to a dual license of SSPL and Elastic License. This adjustment has caused an uproar in the open source community and the technical community. Some people say that it is because of the resistance of cloud manufacturers, and some people say that it is because Elasticsearch no longer needs resources for community collaboration. Finally, Elastic company clarified on the official website that these two projects are no longer open source projects after changing the license, but they still have a certain degree of openness, such as still being able to access the source code and still be able to participate in collaboration. Is Elasticsearch still open source? If not, is there a certain degree of openness?

This article is compiled from the speech shared by Sun Zhenhua, senior legal counsel of ByteDance Intellectual Property, at the DIVE Global Basic Software Innovation Conference 2022 , with the theme of “Changes in Open Source Licenses” .

The sharing is mainly divided into four parts: the first part briefly introduces the relevant content of open source and open source collaboration; the second part is the classification of the current open source license; the third part is how developers can better interpret the open source license; the fourth part It is the business model of open source and an understanding of open source and openness.

The following is the sharing record:

basic concept

Definition of open source

There is no unified definition of open source in the industry at present, and the more mainstream explanations include four or five kinds. For example, the Open Source Initiative (OSI) has defined open source, including ten items, which is an important consensus in the field of open source. But this definition is for open source software licenses, not for “open source” itself.

I think open source is also a development model. Looking back on history, we can see that whether it is an open source project such as Linux, a very successful operating system, or the new generation of cloud-native K8s projects, all rely on the cooperation of individuals and organizations to develop cooperation with partners and other third parties. A common product that is beneficial to all three parties. “Individuals” include developers, document writers, or community building experts; “organizations” include various companies, such as Google, IBM, and Microsoft, which have successively invested in promoting the development of the open source development model.

Second, from a legal perspective, open source focuses on rights related to software distribution. Traditional dedicated software restricts the distribution of related works. The author controls all rights in his own hands. Without the author’s permission, it cannot be modified, copied and distributed. If it is placed in the software industry, it limits the software distribution process to a certain extent. Open source liberates these rights, which facilitates the distribution of software and even makes it more popular, thus becoming a de facto standard.

Is open source a business model? This is rather controversial. Some experts at Microsoft see it as just a development model; but some at IBM, such as the head of its open source office now, insist that open source is a business model. To this end, the two sides debate almost every year.

Copyright

Next, I will introduce the legal knowledge related to open source, with copyright as the basis. The copyright mark is a circle with a letter C in the middle, opening to the right. Some people interpret it as a reserved right, and the author or software developer will control the source code control rights, including the subsequent distribution rights, reproduction rights and modification rights, in their own hands. No one can modify, copy and distribute these codes without the permission of the author. This is not conducive to everyone participating in the subsequent improvement of the software. Because if you want to get the right to improve, you have to sign the relevant agreement with the author or software owner one by one. This objectively limits collaboration from a legal perspective.

“Zuo” right

In order to achieve good collaboration, a hero in the open source field, Richard Stallman, invented a copyright right called copyleft, a copyright-based right that accompanies the rise of the free software movement. Software distributors or authors restrict their rights to ensure that the source code is available to all users and to allow downstream users to modify, copy, and distribute.

Although authorship is associated with the free software movement, with the word “freedom” in it, this “freedom” guarantees the freedom of downstream users to obtain source code, and to modify, copy, and distribute software. This is actually a restriction on the rights of the author or distributor.

Using code like copyleft free software entails an obligation to provide the code to downstream users, and this is the cost of using such free software code.

Copyleft is also a better licensing model differentiated from the original copyright. Among the many rights, the author or distributor has given some rights to downstream users. By default, everyone can freely modify, copy and distribute related software and codes. In the process of continuous modification, the modification can be fed back to the main branch of the upstream open source project, so that the open source project can continue to grow and expand, have more functions, and fix more bugs. Because of this, projects like Linux and K8s continue to grow and expand.

In order to show that it is different from traditional copyright, Richard Stallman turned the C in the original copyright sign to the left, indicating the transfer or waiver of certain rights of the original author, including the distribution of the secondary distribution software. Rights restrictions, so as to ensure the freedom of source code for all downstream users. This guarantee is not for a specific user, but guarantees that all who receive the software have the freedom to obtain the source code.

“?” right

With the continuous development of the free software movement, many people believe that although this freedom guarantees the freedom of source code for downstream users, it restricts the rights of software developers and distributors too much, or is not friendly enough to companies. Therefore, everyone has further developed the traditional free software into the open source software movement. At the same time, the open-source software movement has also chosen a very interesting mark – turning the C in the copyright mark down, indicating that it is not so tight on the restriction and transfer of rights. Specifically, distributing code to downstream users no longer mandates distribution of the associated source code. Many commercial companies prefer this approach. This business-friendly open source software movement has gradually become mainstream, surpassing some of the original free software movement trends and being more widely accepted.

Classification of Open Source Licenses

As mentioned above, the cornerstone of the open source software and free software movement is the assignment or restriction of rights and licensing obligations. Therefore, specific open source licenses can be classified by the assignment and restriction of different rights.

Free software

Before free software, proprietary software prevailed. The software was basically developed in closed source, and downstream users were not allowed to modify, copy or distribute it. Source control is in the hands of some large commercial companies. But wherever there are restrictions, there will be resistance, and gods like Richard Stallman have gradually emerged.

When Stallman was using a printer, he found that there was a problem with the printer software. He wanted to ask the manufacturer for the source code and modify it himself to make the printer work normally. But after a long time, the printer manufacturer did not provide him with the relevant source code. Since then, Stallman has planted a seed in his heart. He believes that users should have greater rights and can obtain relevant source code for improvement, and the rights of both parties will be equal. So he began to gradually promote the free software movement. At the same time, he also cooperated with some lawyers to draw up some relevant license agreements, as well as to recognize other open source software agreements or free software agreements that have been formulated.

These agreements include the well-known GPL, LGPL, AGPL, MPL, EPL and other agreements, their biggest common point is that the corresponding source code is required to be distributed when the software is released. Among them, agreements such as GPL are the most stringent. Generally, when providing or distributing independent software containing GPL code to downstream users, the corresponding source code should be provided, or at least a written offer should be provided, stating that it can be distributed to downstream users within three years. Provide relevant source code consistent with the software.

Later, everyone felt that the GPL was too domineering, and there were too many source codes required. If more changes are made to GPL software, almost all source code must be made available, and commercial companies may lose their competitive advantage. Therefore, another protocol, the LGPL protocol, was born. Distributing software using the LGPL agreement does not require distributing the entire software source code, only the relevant library or part of the source code. Therefore, the LGPL agreement quickly became popular for a period of time.

After entering the Internet era, the distribution software scene has changed. For example, in the scenario of cloud services or SaaS services, although physical software is no longer distributed, they are essentially equivalent to distributing software by providing services. Therefore, the AGPL agreement appeared later, which stipulates that when users interact with the software through the network, there may be a part of the obligation to disclose the source code.

Because every time free software is released, some source code must be provided anyway, so many people also refer to free software as software with reciprocity. That is to say, when improving the source code of others and distributing it to downstream users, as a kind of reciprocity, it is also necessary to provide the source code modified by oneself to downstream users. This restricts certain rights of the distributor or the original author, so in some cases, it is also called a restrictive open source license.

In the early days (about 2003 or before), some large commercial companies believed that the GPL agreement or the Linux system behind the GPL would have a greater impact on their software ecosystem. Especially after the GPL code is introduced into the relevant code repository, they are obliged to provide more source code when redistributing, so they create some panic in the community and technical field, thinking that GPL is contagious. Personally, I don’t think it’s appropriate to say “contagious”, because when using someone else’s software, you should understand that since you don’t have to pay to get the code, you should pay in other ways, such as disclosing some source code. It is more appropriate to describe this as a reciprocity.

Behind every movement is some heroic figure. Take Richard Stallman, the founder of the free software movement mentioned earlier. He believes that proprietary software is unfair to users, because users do not have the right to obtain the source code, which means that they have no control over the purchase of things. He believed that users had a right to the source code, so he created the GNU project to promote the free software movement.

Free software example

As the free software movement continued to grow, some very successful projects were born, such as Linux, GCC, Firefox, and Eclipse, which used the GPL2.0, GPL3.0, MPL2.0, and EPL2.0 protocols, respectively. These protocols are also open source software protocols. Although the open source software agreement no longer emphasizes that the source code must be distributed when distributing software, the free software agreement encourages everyone to participate in the spirit of sharing, or allows modification, copying, and distribution of some rights, which is also in line with the definition of open source software. Therefore, some free software agreements are also recognized as open source software agreements.

open source software

Open source software licenses are certified by the Open Source Initiative, or OSI. The initiative maintains a list of open source licenses, including the common BSD license, the MIT license, the Apache license, and more. Open source software no longer emphasizes user freedom and pays more attention to business friendliness. Therefore, C is changed to open downward, so that users and software developers can choose to share the source code, or protect the source code and distribute only binary software.

There is a historical opportunity here. In 1998, when the open source movement was growing, Linux and some other free software had been quite successful. We found that even if we do not force the distribution of source code, we are willing to participate in the development of upstream open source software or free software. To some extent, we have reached a consensus: do not force too much. If everyone participates in open source collaboration, if they think they can profit from it, for example, developers can research and learn new knowledge; commercial companies can promote a standard, or build commercial products based on open source software, all feasible. This friendly approach may be able to attract more people to participate in the co-construction.

Open source software also has a corresponding driving force behind it. The Open Source Initiative, for example, was founded in 1998 by Eric S. Raymond and Bruce Perence. As a non-profit organization, the Open Source Initiative was formed to spread and defend the open source consensus, or to promote the model for companies.

As mentioned earlier, the Open Source Initiative’s definition of open source software contains ten elements. These ten rules are not strict rules, but consensus, inherited from the Debian community, not created out of thin air. Therefore, from the perspective of free software to open source software, and the definition of open source software, the development of the entire movement is a process of continuous consensus.

In addition to conforming to the OSD definition, open source software has similar benefits to free software in some cases. For example, users will also obtain the source code at the beginning, and there are relatively few restrictions on whether the original developer of the software or the delivery distributor. Therefore, people may be more willing to participate in this open source movement.

Raymond’s view

While promoting open source software, Raymond has also defended proprietary software. He believes that open collaboration is a way, and closed-source R&D is also a way, and you can participate freely. If you want to cooperate with each other, you can cooperate together, and it doesn’t matter if you don’t want to. This softer attitude like water can attract more people to participate in the project development. He made a certain contribution in the process of Firefox against Microsoft, helping Netscape release the source code of Netscape, and also assisted open source lawyers to create the MPL2.0 open source agreement, which promoted the development of the open source movement.

Open Source Software Examples

There are also some very successful examples of open source software, such as the well-known Android system, a series of open source projects under the Apache Foundation, and later languages ​​such as PHP and Python, all of which are successful examples of open source software. With the continuous development of open source software, more and more open source software has appeared in various fields of operating system, database and middleware. Everyone gradually believes that open source can achieve better results in terms of collaboration and consensus in the field of technical software.

History from Free Software to Open Source Software

When it comes to the history from free software to open source software, in addition to Stallman and Raymond, there is another person who has to be mentioned, that is Linus, the father of Linux. He played a very important role in the whole movement. If we only have protocols and consensus, it’s hard to push open source projects forward. The two biggest driving roles of Linus are one is to write the Linux kernel, which has been promoting the continuous progress of the kernel for decades; the other is to develop the Git system, so that everyone can better cooperate through a mechanism to make the system continue to flourish. With these two innovations, he made open source collaboration (or free collaboration) possible.

How to interpret open source licenses

In many cases, everyone starts from using open source projects and gradually transitions to submitting PRs or issues to the open source community and participating in the co-construction process. In the process of using open source, how to better interpret the license without being overly cumbersome?

There is a certain overlap between free software and open source software, such as GPL, MPL, and EPL, which both meet the requirements of open source software licenses and the definition of free software. The URL https://spdx.org/licenses lists some very mainstream open source licenses, marking the licenses recognized by free software and open source software, and abbreviating these licenses with the current SPDX international standard. The specific provisions of each license can be viewed by clicking on the link on the webpage, and it is recommended to read it carefully. Even if you have been working in the field of open source software or free software for a long time, it is still very necessary to pay attention to the details, or the causes and consequences of them, such as what is the historical background, what problems were solved at that time, and whether it is helpful for us to solve the problems now.

Lineage of Free/Open Source Licenses

Interpreting open source licenses often comes from two perspectives. One, from a reciprocal perspective, involves some assignment of rights to one’s own, including possibly distributing source code when distributing code. Second, from a more tolerant perspective, protocols such as MIT and BSD do not have any special requirements for distributors or users, and do not require distribution of source code.

I recommend that you start with the stricter reciprocal licenses when using open source software. When using code under a relevant license, check to see if the license requires disclosure of certain source code. An agreement like GPL requires the disclosure of all modifications or all source code in the program. If the source code contains inconvenient information, it is easy to violate the open source agreement, and community accountability or lawsuits will be difficult to deal with. First, there are laws. The second risk is damage to the company’s reputation. Especially now, regardless of the United States, the European Union or China, there are cases to prove that open source licenses are legally protected and recognized. In the United States, open source licenses are often regarded as a unilateral authorization; in civil law systems, such as China, they are regarded as a contract. The code using GPL must comply with the relevant open source agreement, otherwise it will cause infringement and breach of contract, and the code owner or licensor can file a lawsuit according to the relevant agreement. Last year, many courts in China have recognized the validity of open source licenses. This is very meaningful. It can make everyone face open source licenses more seriously, and attract more people to pay attention to the positive role of licenses in software development and open source freedom movement.

As for permissive agreements, like MIT, its requirements are the most permissive, only requiring that when distributing code or software, it states which open source project is used, the author of the open source project, and what the license is.

BSD subdivides several protocols below, but the requirements are not particularly high. The most demanding ones may emphasize that the trademark of the project developer is not allowed.

The Mulan Protocol is a bit special. It is a protocol launched in China in the past two years, which is looser than the Apache protocol. It does not require the code to be modified after the code is modified. The Mulan Protocol is bilingual in Chinese and English, and both languages ​​are accurate, so it plays a very important role in promoting the open source movement, the spirit of open source, and popularizing open source.

Another important member of the relaxed protocol is the Apache protocol. It has a patent licensing clause, as long as Apache’s software is used, no patent lawsuit can be brought against the software’s originator or all upstream contributors for the software itself. This actually turns everyone into a substantial community to maintain related software. From this point of view, the significance is also very important.

Magnolia Permissive License

Here is a special mention of the Mulan Permissive License, which has many advantages.

First of all, the content of the license is expressed in both Chinese and English, and the two versions have the same legal effect, which is convenient for more local developers to read and use, and can be used as an introduction to learning open source licenses.

Secondly, the Mulan Permissive License has been jointly revised by domestic technical experts and legal experts, and has also been recognized by the Open Source Code Promotion Association OSI, and is now an OSD-compliant agreement recognized by OSI. It clarifies that under the premise of behavior constraints, both parties to the contract should simplify relevant clauses as much as possible, optimize relevant expressions, and at the same time reduce the risk of legal disputes.

Application of Free/Open Source License

You can refer to the image above when using an open source license. There are many very fine details and obscure and vague terms in the license. When developers use it, they need to pay attention to the different requirements from freedom to open source.

When using a strong reciprocal open source license, such as a GPL license, in order to protect the right of downstream users to obtain source code, it is necessary to provide relevant copyright and license information when distributing software, and to disclose relevant source code, or at least to Provide a written offer that promises to provide source code within three years.

Relatively speaking, in order to protect the freedom of part of the source code of downstream users, the weak reciprocity agreement must disclose part of the source code when distributing the software, and also provide the relevant copyright and license statement.

Relatively relaxed licenses often no longer require source code when distributing software, but often require corresponding copyright information, license information, and even some other declaration information.

There are also some, which can be said to be super loose license terms, often maximizing user rights and basically having no obligations.

This is the basic point that developers usually need to pay attention to. However, when the company uses it, it may also pay attention to the requirements of the license trademark or patent to avoid legal risks.

To sum up, although the use license can obtain the code for free, it does not mean that the use or distribution is completely free, and the user also has certain compliance obligations. Related copyright and license information.

Open source based business model

One of the basic points of the business model based on open source is that all open source software requires you to obtain the distribution code. When you distribute the code, it is basically free distribution, so users can get a copy of your code for free.

Support Services

Often we can’t charge for restricting the code itself or selling copies, but for providing other services around the code. For example, Red Hat provides paid technical support and consulting services to users. There are some other charging models, such as trademark licensing.

pull pipe service

The second business model is managed service, which represents the enterprise is Databricks. The supplier will host other open source software as a service on the cloud and charge related fees every month.

Restricted License

The third is a restrictive license, represented by redis. Restrictive licenses are no longer open source licenses and will restrict usage in certain scenarios. For example, using dual licenses, releasing code with GPL agreement, and providing source code when you do not want to release products, you can also buy a commercial agreement version, which removes the restrictions on GPL-related agreements.

open core

The fourth is an open-core approach. The main functions of the software are all developed using open source protocols, but there are also some proprietary parts, packaged as modules or services that connect with open source services, or in some forked versions especially for certain enterprise customers. This is also a way to make a profit, and the representative enterprise is Confluent.

Open Core + Hybrid License

The fifth is called Open Core, and Hybrid Licensing, which stands for Elastic for the enterprise. This is how Elasticsearch and Kibana are licensed from versions 6.3 to 7.10. Most of its source code is released under the Apache 2.0 protocol, and some special core functions use the relatively proprietary Elastic License protocol, which does not allow users to modify or crack the code. This approach uses both proprietary code and open source code in the product, so it is called the open core and hybrid licensing model.

Take Elasticsearch as an example

When Elasticsearch was in version 6.3, the code was divided into two parts in the public code repository (as shown in the figure above). One part is open source code, licensed under the Apache 2.0 protocol, and the other part of the proprietary code is placed in a special folder called “X-pack Code”, which is licensed under the Elastic License. If you want to use this part of the code, you need to pay.

After a while, Elasticsearch found that some cloud vendors were still able to break through the limits. For example, cloud vendors may try to expand their functional limitations based on the Apache protocol, such as using some of their own advantages to gain more customers. Therefore, Elastic has further restricted its open source projects. In the public code repository, the code licensing methods are divided into two types. The second one is to use the Elastic License 2.0 as the license, and make some restrictions for cloud vendors. If To use Elastic License 2.0 on the cloud or as a hosting service, you must pay Elastic; and the first option divides the entire code repository code into two parts, one is the code under the SSPL agreement, and the other is the Elastic License 2.0 code below. If SSPL code is used on a hosted service, the entire code used for the service needs to be disclosed. Perhaps because there are too many code disclosure requirements, the SSPL agreement is not recognized as an open source agreement by the Open Source Initiative.

Based on this change, Elastic no longer calls these two software open source projects, but more open projects.

It should be noted that there are still many projects in Elastic that maintain the Apache2.0 license, so it still has many open source projects.

Summary

First, free software guarantees the freedom of the source code of all downstream users, and the rights of distributors or users of the software (“use” refers to embedding the code into some proprietary code) will be restricted to a certain extent.

Second, open source software is more business-friendly and no longer emphasizes the freedom of users. Users can choose to participate or not to participate in related open source co-construction.

Third, both free software and open source software encourage broad collaboration. Relatively speaking, open source software is more business friendly. Open source collaboration is really helpful for business, so companies tend to be more active in the open source movement.

Fourth, some software does not meet the definition of free software or open source software, but has a certain degree of openness (the source code is available), and imposes certain restrictions on certain usage scenarios or manufacturers. When using these software, carefully screen the requirements of these licenses. First of all, it is necessary to identify whether it is free or open source software, and then ensure that it can be used compliantly according to the relevant license. If you see a non-open source license, you need to carefully analyze, what are the restrictions, whether you need to buy it, or replace it with an open source project.

The text and pictures in this article are from InfoQ