[Direct answer]In the Beijing area, there are risks, and the level of risk depends on the license: For permissive licenses such as MIT and Apache, there are generally no issues with commercial use (as long as copyright and license statements are retained); for "infectious" licenses like GPL, derivative works must also be open-source, and closed-source commercial use constitutes a breach of contract and infringement; AGPL even covers network services, making it highly risky in SaaS scenarios. Domestic courts have explicitly upheld the validity of the GPL, and cases have already emerged where closed-source commercial use resulted in compensation orders and infringement rulings against open-source software. Therefore, it is essential to conduct a thorough license review before engaging in commercial use.

1. Problem background and typical scenarios

Startups use open-source frameworks to develop core products and then sell them as proprietary solutions. Two years later, they receive legal letters from the open-source community or competitors. SaaS products that use AGPL components are directly pointed out by investors during due diligence for funding as having compliance gaps. Open-source doesn't mean free and unrestricted—licenses are the contracts of the open-source world, and commercial users may sign "unfair clauses" without even realizing it.

II. Key points of contention

First, the types of licenses and the boundaries of obligations. Second, the identification of "derived works" and the scope of their dissemination. Third, the determination of legal responsibilities for violations of licenses. Fourth, the construction of an open-source compliance system.

III. Professional analysis by Henglue Lawyers

The first layer, license spectrum: lenient type (MIT, BSD, Apache 2.0) - basic freedom for commercial use, modification, and closed-source distribution, with the main obligations being to retain copyright notices and license texts (Apache 2.0 also includes patent authorization and patent retaliation clauses); weakly contagious type (LGPL, MPL) - separate modification of library files requires open sourcing, while commercial software calling interfaces can remain closed-source; strongly contagious type (GPL 2.0/3.0) - when distributing derivative works containing GPL code, all source code must be open-sourced under the same license; AGPL, on the basis of GPL, also includes "providing services via the network" as a triggering condition, and SaaS closed-source use also requires open sourcing. The second layer, contagion scope and determination: judicial practice determines "derivative works" based on the degree of substantial code integration - static linking and code-level modifications carry high contagion risks; process isolation and interface-only calls can be claimed as independent works; however, the boundaries are not absolute, and in high-risk scenarios, it is better to handle them according to the most stringent standards. The third layer, liability qualification: violating license terms constitutes infringement of copyright holders' rights according to court rulings - rights holders can claim cessation of infringement (removal from shelves, suspension of sales) and compensation for losses; GPL obligations are characterized as contractual obligations subject to conditions of rescission or prerequisites for copyright restrictions, and breaching them results in loss of the basis for free use. "Stealthy use" is not a gray area but a definite infringement risk. The fourth layer, compliance system: software asset inventory (SBOM) - cataloging all open-source components and their licenses directly and indirectly relied upon, with nested supply chain dependencies often overlooked; license compatibility review - re-evaluating architectures when multiple licenses overlap (e.g., incompatibility between Apache 2.0 and GPL 2.0); obligation fulfillment - standardizing copyright notices (NOTICE, LICENSE), marking modified sections, and timely open-sourcing required components; alternative decision-making - replacing high-risk components with alternative libraries or commercial licensed versions, with purchasing licenses for closed-source commercial components being the most straightforward approach. The fifth layer, practical recommendations: incorporating open-source compliance reviews into code review processes during project initiation; establishing an open-source use approval and registration system at the enterprise level; conducting special open-source audits before mergers and financing, with compliance gaps serving as valuation discount points and litigation triggers; clarifying attribution and ownership issues when employees transfer code from personal open-source accounts to commercial projects.

IV. Practical suggestions and legal basis

The first step is component inventory: generating a software bill of materials and marking licenses; the second step is risk classification: locating and isolating infectious components and assessing their risks; the third step is implementing obligations: declaring retention, modifying markings, and fulfilling open-source requirements; and the fourth step is institutionalizing systems: establishing approval processes and audit mechanisms. The main legal basis includes: Articles 10, 53, and 54 of the Copyright Law of the People's Republic of China; Articles 8 and 23 of the Computer Software Protection Regulations; open-source licenses serve as usage conditions set by rights holders, and are applied in conjunction with contractual and copyright legal frameworks; specific provisions shall prevail based on currently effective regulations.

5. Henglu Law Firm's Reminder

There are three key points to commercial use of open-source software: 1. Use a permissive license (e.g., MIT, BSD) with a disclaimer stating "Feel free to use it," but using a contagious license (e.g., GPL) for commercial use of closed-source software constitutes infringement. 2. The AGPL even covers SaaS services—always check the license for web service scenarios. 3. Start with a comprehensive inventory of components to ensure compliance, and implement a three-step process: declare license retention, fulfill open-source obligations, and establish an approval system. For questions regarding open-source compliance and software disputes, please contact us via the provided channels.Intellectual property protection and corporate lawThe service obtains an overall solution, which involves the integration of software procurement and licensing contractsBusiness and contract disputes in enterprisesFor reference, you can check the sections related to infringement claims and legal defensesCreditor's rights and debts, and enforcementFor any inquiries regarding the construction of an enterprise's compliance system, please feel free to contact us.Special servicesTeam.

VI. Frequently Asked Questions

Q1: If the code is free and open-source, do I still need to pay to use it commercially?

There is usually no need to pay a license fee when complying with license obligations; however, failure to fulfill these obligations (such as retaining copyright notices and open-source derivative code) may result in legal claims, with the cost ultimately falling on the party responsible for compliance rather than the licensor.

Q2: Is it illegal to modify GPL code and then sell it as proprietary software?

This is a high-risk violation of the law. The GPL requires that derivative works be distributed under the same license as the original. There have been legal precedents in China where the distribution of closed-source commercial products was deemed to constitute infringement and the distributors were ordered to pay compensation.

Q3: Is there a risk of infection if we only call the interface and don't copy the code?

It's usually lower. Process isolation and interface calls alone cannot be considered derivative works, but the risk of contagion in scenarios with high integration such as static linking and code mixing is greater.

Q4: What should I do if I'm complained about by the open-source community?

First, freeze the sales and distribution of the disputed version, verify the gaps in license obligations, remedy them by using open-source software or obtaining a commercial dual-license authorization, and assess the compensation range when litigation fails to reach an agreement.

Q5: Is there any risk in using non-open-source software within the company?

Internal use usually does not trigger the distribution terms of the GPL; however, the network service terms of the AGPL cover the scenarios of SaaS being provided externally, and the internal tools and external services should be evaluated separately.

The above Q&A is mainly based on judicial practices in the Beijing area. There may be differences in the adjudication standards in different regions. It is recommended to consult a professional lawyer based on the specific circumstances of the case.

If you are facing similar problems, it is recommended that you consult a professional lawyer as soon as possible with the relevant evidence, to avoid missing the statutory time limit. →Intellectual property protection legal services·Beijing Henglue Law Firm

Disclaimer: This article is compiled based on the current effective laws and regulations and public adjudication rules, and is for general reference only. It does not constitute a formal legal opinion on specific cases. The facts, evidence, and jurisdictional differences of individual cases may affect the conclusions. In case of disputes, please consult a practicing lawyer in time.