Shulou(Shulou.com)05/31 Report--

Today, I would like to talk to you about the legal risks of changing open source software license agreements from MongoDB. Many people may not know much about it. In order to make you understand better, the editor summarized the following contents. I hope you can get something from this article.

(1) background of the incident

As open source software plays a more and more important role in cloud computing, big data, artificial intelligence and other emerging areas of ICT, enterprises have gradually become the main driving force of open source. Open source is not only a production mode that can bring together industrial forces for collaborative development, but also an important means for enterprises to compete. Some enterprises that maintain open source projects modify the license agreements of open source projects in order to reduce product risk and attack competitors. In October 2018, MongoDB announced the switch of its open source license agreement from AGPL v3 to Server Side Public License (SSPL). MongoDB community server versions released before October 16, 2018 are licensed under the AGPL v3 license, and all MongoDB community server patches and new versions released on or after October 16, 2018 are licensed under the SSPL license agreement, including future patches for the old version.

(2) interpretation of SSPL license agreement

1. Basic introduction of SSPL license agreement

The SSPL license agreement is modified on the basis of GPL v3. The SSPL license Agreement has a total of 17 terms, with the exception of Clause 13 which differs from GPL v3, the rest of which are substantially the same as GPL v3. The SSPL license agreement has the following characteristics:

*, like open source license agreements such as GPL, SSPL gives the licensee four basic rights, including: free operation of the program, free access to the source code, free release of the copied program, freedom to modify the program and release of the improved version to the public.

Second, SSPL is a highly infectious license agreement. This means that if you redistribute a work of SSPL-licensed software or SSPL-licensed software, you must redistribute it under a SSPL license agreement.

Third, when redistributing a program under the SSPL license or providing the program as a service, the source code must be provided. Source code must be provided when SSPL-constrained software is copied or distributed in object code or executable programs.

Fourth, SSPL explicitly indicates the patent authorization. In exactly the same way as GPL v3, clause 11 of the SSPL license agreement expressly states the patent license. Even if the program publisher applies for a patent for the published contribution, after obtaining the patent license, the relevant patent license must be granted free of charge to everyone who uses the program.

Fifth, there is a non-guarantee clause in SSPL. Almost all open source license agreements have a non-warranty clause that does not provide any express or implied warranties, including, but not limited to, warranties of merchantability and fitness for a particular purpose. Neither the copyright owner nor any other third party shall be held responsible for any loss arising from the use of open source programs. Because open source software is already licensed for free, there is no warranty obligation on the software copyright owner.

2. Comparative analysis of SSPL, GPL v3 and AGPL v3

The differences among GPL v3, AGPL v3 and SSPL are mainly reflected in clause 13. Clause 13 of GPL v3 is the provision of the relevant provisions of "use with AGPL". Clause 13 of AGPL v3 is the relevant provision of "remote Network interaction: use with the GPL license Agreement". Clause 13 of the SSPL is about the provision of the program as a service. By comparing the provisions of Section 13 of the three license agreements, it can be found that:

AGPL and SSPL license agreements are more stringent than GPL. According to the GPL license agreement, anyone can run privately modified GPL licensed programs for the purpose of providing technical services, as long as the software is not released and does not need to release the source code. However, the AGPL license agreement extends the concept of Copyleft to services delivered by free software on the web. According to AGPL, if the licensed program interacts remotely with the user over the network, the source code needs to be provided to the user, and all modifications need to be provided to the user. Common scenarios of "remote network interaction through computers" are: network and mail servers, interaction-based network applications and online game servers. In the SSPL license agreement, it is clearly stipulated that the "service source code" is required when the function of the program or the modified version of the program is provided to a third party as a service. The most typical scenario is that cloud platform providers package software hosting products into services.

Second, GPL, AGPL and SSPL are all strong licensing agreements. Clause 13 of the GPL and AGPL license agreements respectively provides for the use of programs under the GPL license and those under the AGPL license. Therefore, the GPL and AGPL license agreements are compatible. However, the SSPL license agreement is not compatible with GPL or AGPL, that is, SSPL-licensed code cannot be released as a program with GPL or AGPL-licensed code.

II. Analysis of the reasons for MangoDB's change of license agreement

(1) legal analysis

The ambiguity of the AGPL v3 license agreement has led many companies to test the boundaries of AGPL. Article 13 of AGPL v3 sets out the limitations of "remote network interaction". However, the triggering conditions and scope of AGPL remote network interaction are controversial in the industry. Therefore, SSPL clearly defines the conditional restrictions on the provision of programs as a service.

The judgment of the infectious range of AGPL v3 is also vague. GPL v3/AGPL v3 proposes the concept of "polymer" and believes that the inclusion of GPL-licensed programs in the polymer will not result in the application of the GPL v3/AGPL v3 license agreement to other parts of the polymer, that is, it will not be "contagious". However, there is still a great deal of controversy in the industry as to whether the two procedures constitute a "polymer", and there is no relevant precedent in the judicial community. This directly causes many enterprises to wander in the grey area that violates the AGPL license agreement.

(II) Business level analysis

The rise of "software as a service" has impacted MangoDB's business model. Open source is not only a software development model, but also represents a unique business model. MangoDB open source software adopts the business model of dual license. MangoDB is divided into two versions: enterprise version and open source community version. The open source community version is licensed to users free of charge under the SSPL license agreement, which makes it easy to test the software, get improvement information, get the support of developers, win reputation, and contribute to marketing. The enterprise version adopts commercial license to provide enterprise users with more functions as well as technical support, guarantee and other services. MangoDB makes money by charging business users licensing fees. Open source companies that adopt the dual licensing model usually choose strong licensing agreements such as GPL and AGPL for their community versions, which to a certain extent restrict other enterprises from modifying and selling software on the basis of the community version.

In recent years, the concept of "software as a service" is deeply rooted in the hearts of the people, and the IT industry is gradually transforming to service. Users do not need to purchase hardware and software, but order their application software services from manufacturers through the Internet. IT manufacturers increasingly tend to charge through services rather than by selling software and hardware. Some cloud service vendors modify the community version of MangoDB and provide users with a managed commercial version of their database without releasing the modified source code to the community. In this way, these cloud service vendors are equivalent to taking a share of MangoDB Enterprise Edition sales and grabbing their sales share. MangoDB's change of license agreement is designed to curb cloud service providers from grabbing the value of open source software without giving anything in return to the open source community.

III. Analysis of the impact of MangoDB's change of license agreement

(I) the impact of changes in license agreements on the open source community

License agreement changes do not affect regular users of the MangoDB community server. In the open source community, SSPL gives users the same freedom as MongoDB under the AGPL license-users are still free to use, review, modify, and redistribute the source code. If a company uses MangoDB only within the company, or provides it as a service to a subsidiary, it does not belong to the provision of services to a third party, is not subject to Clause 13, and is not affected by the replacement license agreement. In addition, after the license agreement is changed, cloud service providers are required to feedback their changes to the MangoDB to the open source community, which will contribute to the continuous improvement of open source software and have long-term significance for the development of the open source community.

(II) the impact of changes in license agreements on cloud service providers

After MangoDB changes the license agreement, cloud service vendors either need to fully disclose the source code of their services or purchase commercial licenses from MangoDB if they want to sell MangoDB-based cloud services. In the MangoDB license agreement, the scope of "service source code" is very broad, including not only the source code corresponding to MangoDB or its modified version, but also the management software, user interface, application program interface, automation software, monitoring software, backup software, storage software and managed software source code. The full disclosure of these "service source code" means that these cloud service vendors have lost the ability to differentiate their products. As a result, other cloud service vendors may not be motivated to sell MangoDB-based cloud services.

IV. The enlightenment of MangoDB changing the license agreement to the open source of Chinese enterprises.

(1) understand the rules of the open source game

As commercial companies gradually become the main force of open source, open source is becoming less and less "pure" and has gradually become a way for enterprises to make money. The choice of open source software development mode, the choice of open source license agreement, and the choice of profit model of open source software are all in one continuous line and closely related. For example, open source software dominated by open source foundations often choose loose open source license agreements such as Apache, BSD and MIT to attract more commercial companies to participate. Commercial enterprise-led open source software often chooses strong licensing agreements such as GPL to ensure the realization of its dual licensing business model. Only when enterprises understand the rules of the open source game, can they profit from the open source and effectively reduce the risk of intellectual property infringement.

(2) careful selection of open source software

Open source is not a "free lunch". Enterprise-led open source projects are often full of traps. If an open source software is dominated by an enterprise, and the enterprise owns the copyright of all the open source code, then the enterprise can change the open source license agreement of the open source software at any time, or even turn it into a closed source. For example, Redis changes the license agreement for self-built Redis modules-- RediSearch,Redis Graph,ReJSON,ReBloom and Redis-ML-- from AGPL v3 to a license agreement that combines Apache v2 with Commons Clause. In fact, these self-built modules are no longer open source software, but only have access to source code. Such a sudden change in license agreements will put companies using these open source software in a dilemma. Replacing open source software in one's own products can be costly; if open source software is not replaced, new license agreements often require private code to be made public or even not allowed to be sold commercially. Therefore, enterprises choose open source software cautiously from the beginning, not only to test its performance, but also to fully consider its intellectual property risk.

(3) the use of open source software shall comply with the open source license agreement

Open source software is not public domain software and cannot be used arbitrarily. Most open source software is copyrighted and protected by copyright law. The copyright owner of open source software transfers part of the rights of reproduction, modification and distribution of open source software to the licensee through the open source license agreement, and the licensee can exercise these rights only on the premise of complying with the provisions of the open source license agreement. If enterprises do not use open source software in accordance with the provisions of the open source license agreement, there is a great risk of copyright infringement.

(4) do a good job in risk prevention and control of open source software

Open source license agreements often have a "no guarantee" clause, which means that companies use open source software at their own risk. In this case, the risk prevention and control of open source software is particularly important. On the one hand, it is necessary to improve the management process of enterprise open source software, standardize the use of open source software within enterprises, and reduce the legal risks caused by the non-compliant use of open source software; on the other hand, we should pay attention to the relevant legal disputes over the use of open source software, establish a risk early warning mechanism, and replace risky open source code in the product in time.

After reading the above, do you have any further understanding of the legal risks of open source software from MongoDB changing open source license agreements? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.