Because we are also working on open source, we are more concerned about this issue. Recently, due to the needs of our work, we have summarized and analyzed the knowledge related to open source licenses, and shared them with you for discussion, hoping to get your guidance.
In December 2021, Douyin’s overseas version of TikTok launched an app called TikTok Live Studio, but its download page was deleted soon after. TikTok officially responded to the matter because the APP violated the GPL license. It used the open source software source code under the GPL license, but did not open source according to the GPL license requirements.
With the development of open source software, its number and influence are constantly rising. Open source software has the characteristics of low cost and quick upgrade, so more and more enterprises choose to use open source software. But "there is no free lunch in the world", under the constraints of open source licenses, the use of open source software is not free as imagined. Improper use of open source software may result in the risk of negative public opinion and even economic losses for the enterprise.
What is an Open Source License ("Open Source License")
An open-source license is a constraint on users of open-source software to regulate the use or distribution of copyrighted software.
Common licenses and their differences
Common licenses are GPL, LGPL, AGPL, MPL, MIT, BSD and Apache, and each license also contains different versions. According to different use conditions, these licenses can be roughly divided into two categories: copyleft licenses and permissive licenses, which mainly impose corresponding constraints on the use, modification and distribution scenarios.
1.BSD license – characterized by free use, modification, and redistribution. However, in the process of commercial or personal distribution, the license of the original code must be carried, and the relevant information of the original author cannot be used for publicity.
2. MIT License – Originated from the Massachusetts Institute of Technology (MIT), it is the most widely used open source license. Its characteristics are similar to the BSD license, and no liability is assumed as long as the copyright notice and permission notice are included in all copies of the project.
3. Apache License – As a member of the permissive license, Apache has several restrictions, prohibiting the use of its trademarks and author's related information for commercial activities, and all modified files must be clearly pointed out.
4. GPL license – The difference between GPL and BSD is still very big. GPL advocates open source code and derived code, and does not allow modified and derived code to be released and sold as closed-source commercial software. If the released commercial software source code contains GPL open source software source code, the commercial software must be open sourced or taken off the shelf.
5. AGPL License – AGPL is a supplement to GPL, with some restrictions added on the basis of GPL. The prerequisite for GPL constraints to take effect is that the software is "released". Some companies use GPL components to write web systems, but do not release the system and only use this system to provide services online, thus avoiding open source system code. The AGPL requires that if the code used by the cloud service (ie saas) is under the license, the code of the cloud service must also be open source.
6. LGPL license – LGPL allows commercial software to use LGPL class libraries by means of class library references, without the need for open source commercial software source code.
7. MPL license – In commercial software, if the code containing the MPL license is in a separate file, other additional files can be avoided open source.
We conduct statistics on the distribution of open source component licenses for two common programming languages, C/C++ and Java, and we can find that:
- C/C++ mainly uses MIT, BSD, Apache licenses, GPL/LGPL accounts for about 16%, and the overall use is more strict
- Java mainly uses Apache and MIT licenses, GPL/LGPL accounts for about 1%, and the overall use is more relaxed
Open source licenses are being standardized
SPDX is an open standard launched by the Linux Foundation for exchanging software bill of materials information. SPDX has standardized the names, identifiers and other information of more than 400 open source licenses and is continuously updated.
SPDX also provides guidelines for matching open source licenses, encouraging developers to include a short identifier such as SPDX-License-Identifier: MIT in their code.
It is foreseeable that in the future, open source licenses will become more standard and easier to be recognized and processed by machines.
Open Source Compliance Risk
In 2008, the United States Court of Appeals for the Federal Circuit first asserted the copyright validity of open source licenses in Jacobsen v. Katzer. China acquiesced in the legal effect of the GPL license in the "Youzi Case" in 2019. The emergence of relevant precedents means that the open source license is no longer a gentleman's agreement, and violating the open source license will bring economic and reputational losses to the enterprise.
Like the GPL license and the MPL license, the GPL license requires "the user to use the source code under this license must release the source code of the entire program under the license of the GPL license", while MPL requires "the code of the MPL license is in a separate The other newly added files can avoid open source.” Therefore, when enterprises use open source software with both GPL and MPL licenses, they may face the risk of violating one of them due to the conflict of open source licenses.
Relevant cases at home and abroad
1. In 2019, in the case of Digital Paradise Beijing Network Technology Co., Ltd. v. Grapefruit Beijing Technology Co., Ltd., Grapefruit Beijing failed to comply with the partial source code of the three plug-ins in the HBuilder software tool of Digital Paradise because the developers used part of the source code in 2015. Open source software licenses take software products with open source requirements as commercial products, and the copyright owner of the open source software sues for breach of contract and infringement, and therefore bears legal responsibility.
2. On April 30, 2021, Luohe Company sued Fengling Company for infringement and received 500,000 yuan in compensation, and at the same time asked Fengling Company to stop the infringement.
In this case, the plaintiff, Luohe, independently developed the "Virtual App Plug-in Framework Virtual Engine System V1.0" (referred to as VirtualApp V1.0), introduced the GPL3.0 license in 2016, and obtained it in 2017. Computer software copyright registration certificate, and statement
For commercial use please purchase a commercial license.
In 2018, the plaintiff found that the software named "Dim Sum Desktop" used the code of VirtualApp V1.0. After analyzing and comparing the source code, it was found that the two were highly similar, and they sued the defendant Fujian Fengling Company.
After the court trial, the defendant should compensate the plaintiff for reasonable expenses of 500,000 yuan to stop the infringement. This judgment is the first case in China that clarifies that the GPL3.0 license has legal effect.
3. In mid-December 2021, Douyin’s overseas version of TikTok launched an APP called TikTok Live Studio. Some netizens found that this software violated the GPL license and illegally used the open source software OBS (a free open source video recording and video real-time Streaming software, and allows anyone to use and commercialize the source code for free), since commercial use is allowed, why is it still exposed to violations?
Here we need to learn more about the GPL license. The GPL license is highly contagious. If a software uses the open source software source code of the GPL license, then the software must also use the GPL license to open source.
After the incident came to light, the OBS developer confirmed the incident, and TikTok responded to the incident and deleted the download page of TikTok Live Studio.
Advice for developers/enterprises
Warm reminder: open source ten million articles, compliance first
1. When software developers use open source software, they need to choose open source software carefully, pay attention to the content and related conditions of its open source license, and avoid potential legal risks.
2. Enterprises should establish a complete mechanism to identify the list of open source software used in the enterprise, clarify the corresponding open source licenses and rights constraints, and avoid relevant compliance risks in a timely manner.
3. Avoid open source license infection through isolation mechanism. For the use of code under the MPL license, the code of the license should be placed in a separate file to avoid license infection; the code under LGPL can be called by dynamic link. The library of licenses implements isolation.
Solution: Address this type of risk with murphysec's open source tools
We integrate the compliance detection capabilities of open source licenses into open source tools
Open source project address: https://github.com/murphysecurity
1. Use the murphysec open source tool to scan your code directory, it will help you identify all open source components used in your code project with one click, including the list of directly and indirectly dependent components, and list the corresponding open source licenses of all components certificate information
2. View the report. According to the prompts in the report, you can clearly see the license compliance risk of the license of the corresponding component in which scenario
3. You can judge whether your project has the possibility of violation according to the compliance risk prompt of the license, and adjust the components you introduce to solve this risk.
Some pits that you may accidentally step on:
1) There are some components that have multiple licenses. The license types specified by different directory files may be different. Special attention should be paid. Of course, our open source software also takes this situation into account.
2) Some components you do not directly depend on, but there may be indirect dependencies, you need to pay special attention to check the dependencies of related components