GPL Open-Source Code in a Chinese Commercial Product

A Suzhou technology company sells an industrial controller. Its proprietary software includes third-party open-source components licensed under the GNU General Public License. The engineering team has modified some components and linked others to proprietary modules.

A customer or competitor alleges that distribution violates the GPL and demands source code.

The company says it owns the code written by its engineers.

The issue#

That does not answer the licensing question.

The specific issue is: how should a Chinese technology company determine whether its commercial distribution complies with GPL obligations while protecting genuinely proprietary secondary development?

1. Chinese copyright law protects computer software#

Article 3 of the Copyright Law expressly includes computer software within protected works.^[1]

The Computer Software Protection Regulations provide the specific regulatory framework for software copyright.^[2]

Ownership of original proprietary code is therefore legally meaningful.

But use of third-party code is governed by license.

2. Open source is a license model#

Open-source software is not ownerless.

The copyright holder grants rights subject to license terms.

The legal analysis asks:

• what component;
• what version;
• what license;
• what use;
• what distribution.

3. Build a software bill of materials#

Every product should have SBOM data:

• component;
• version;
• source;
• license;
• modifications;
• linking;
• distribution.

Without this, compliance is guesswork.

4. GPL risk is distribution-specific#

Internal use may differ from external distribution.

The company should identify:

• firmware shipment;
• downloadable software;
• SaaS;
• appliance.

5. Separate GPL components from proprietary modules#

Architecture matters.

Legal counsel needs engineering explanation of:

• static linking;
• dynamic linking;
• IPC;
• separate processes;
• modifications.

Do not make legal conclusions from package names alone.

6. Modified GPL code#

If the company modifies GPL code and distributes it, obligations may apply to that modified work under the license terms.

The company should preserve:

• original;
• modifications;
• notices.

7. Secondary development#

A key issue is whether proprietary code constitutes a derivative or separate work.

This can be fact-intensive.

Chinese software copyright law protects original expression, while the license determines permission to use upstream code.

8. Copyright ownership is not enough#

The company may own its new code but still breach the upstream license in distribution.

Due diligence should separate:

• copyright ownership;
• license compliance.

9. Employee code ownership#

The Software Protection Regulations address software developed in employment and related ownership questions.^[2]

The company should have:

• employment IP clauses;
• contractor assignments.

10. Contractor code risk#

Outsourced developers may introduce open-source code without disclosure.

Contracts should require:

• SBOM;
• approval;
• warranties.

11. License notices#

Many open-source licenses require notices.

Create automated notice generation.

12. Source-code offer#

For GPL-governed distribution, the compliance team should identify applicable source-code obligations.

The offer process should be operational.

13. Build pipeline controls#

CI/CD should scan dependencies.

High-risk licenses should trigger legal review.

14. Repository evidence#

Preserve:

• commits;
• branch history;
• authors;
• license files.

This matters in litigation.

15. Product acquisition due diligence#

Buyer should request:

• SBOM;
• license policy;
• scan report;
• source offer;
• disputes.

16. IPO risk#

A technology company preparing for listing should resolve open-source compliance before filing.

Core software ownership/disputes can affect disclosure.

17. Medical device example#

Embedded Linux in device:

• kernel modules;
• proprietary application;
• drivers.

Analyze each separately.

18. AI software#

AI products may use many libraries.

Model licenses and dataset terms are separate from software licenses.

Do not combine.

19. Customer contract representations#

Avoid broad warranty that product contains no open source.

Use accurate language.

20. Enforcement response#

If demand received:

• preserve versions;
• identify distribution;
• confirm license;
• engage technical team.

Do not immediately disclose whole proprietary repository.

21. Scope the requested source#

Determine exactly what code license requires.

Protect unrelated proprietary code.

22. Injunction risk#

Copyright owners may seek remedies under Copyright Law.

Early remediation can reduce dispute.

23. Compliance cure#

Possible steps:

• provide notices;
• source;
• replace component;
• redesign architecture.

Depends on license and facts.

24. Open-source committee#

Members:

• legal;
• engineering;
• security;
• product.

Approve high-risk components.

25. License categories#

Classify:

• permissive;
• weak copyleft;
• strong copyleft;
• unknown.

Unknown is unacceptable.

26. M&A SPA#

Include open-source representations:

• policy;
• disclosure;
• no known violations;
• SBOM.

Specific indemnity for known issue.

27. Litigation evidence#

Court may need technical comparison.

Use expert evidence.

28. Chinese legal basis#

Copyright Law protects software as work.^[1]

Software Regulations define computer programs and documents and protection rights.^[2]

Open-source disputes operate through copyright plus contract/license interpretation.

29. Avoid overclaiming GPL consequences#

Do not assume every GPL component forces all product code to be disclosed.

Architecture and license terms matter.

30. Case study#

Industrial robot controller uses GPL library.

Engineer modified library and statically linked proprietary module.

Company should:

• reconstruct source;
• identify license version;
• analyze derivative relationship;
• prepare compliance.

31. Customer procurement#

Enterprise customers may require OSS questionnaire.

Maintain current answers.

32. Vendor code#

Third-party firmware supplier should disclose OSS.

Flow obligations down.

33. Security updates#

Replacing components can change license profile.

SBOM should update per release.

34. End-of-life#

Source obligations may survive product discontinuation.

Retain source and build materials.

35. Compliance evidence pack#

Include:

• SBOM;
• scan;
• approval;
• notices;
• source archive;
• distribution record.

36. Final test#

Ask:

Can we identify every open-source component in the shipped product and explain what license obligation applies to that specific distribution?

If not, the product is not diligence-ready.

Additional implementation detail: component approval workflow#

Engineering should not be allowed to add third-party components to production code without recording license information. A lightweight approval system can distinguish low-risk permissive licenses from copyleft or unknown licenses that require legal review. The workflow should integrate with repository tooling rather than rely on annual questionnaires.

Unknown license status should block release until resolved.

Additional implementation detail: source-code separation#

Where GPL code and proprietary code coexist, architecture documentation should explain technical boundaries. Counsel should review how components communicate, how they are distributed and what modifications were made. The legal conclusion depends on facts, so engineering diagrams are often more useful than product marketing descriptions.

Preserve the exact source tree corresponding to each shipped version. Litigation years later is difficult if the company can reproduce only the newest release.

Additional implementation detail: acquisition remediation#

If due diligence identifies a material open-source issue, the buyer should not automatically walk away. Possible remediation may include replacing a library, publishing required source, providing missing notices, obtaining alternative commercial licensing or redesigning component separation.

The SPA can make remediation a closing condition where risk is material. For lower-risk issues, a specific indemnity or covenant may be sufficient.

Additional implementation detail: enforcement response protocol#

When an open-source compliance demand arrives, do not allow developers to delete components or rewrite repository history. Freeze the relevant release, identify the upstream copyright holder, confirm license version and engage technical and legal teams. An accurate factual reconstruction should precede any public or customer response.

Conclusion#

Chinese software copyright law protects proprietary development, but open-source components remain subject to their licenses.

A company should not frame the issue as open source versus ownership.

The practical rule is:

separate what the company owns from what it has permission to distribute.

Operational appendix: implementation controls#

This issue should be managed through a written project tracker rather than informal email. For each legal requirement, assign an owner, evidence file, deadline, decision status and escalation trigger. Management should distinguish legal requirements, commercial preferences and unresolved factual assumptions. That distinction reduces the risk that a business assumption is later treated as a legal conclusion.

The legal file should preserve the facts supporting each decision. If the company relies on an exemption, transfer mechanism, termination basis, ownership position or contractual remedy, retain the documents and analysis showing why. A later dispute or regulatory review often turns on evidence of what the company knew and how it reached the decision.

Before implementation, counsel should conduct a final consistency review across corporate documents, employment records, contracts, data systems and external communications. Many failures occur because separate workstreams use inconsistent dates, entities or descriptions. One master chronology and one controlled document set should be used.

After implementation, schedule a post-completion audit. Confirm that registrations, payments, system access, notices, records and contractual actions were actually completed. Legal projects fail when signed documents do not become operational reality.

Legal sources#

^[1] Copyright Law of the PRC (2020 Revision): https://www.npc.gov.cn/c2/c30834/202011/t20201119_308796.html ^[2] Regulations on Computer Software Protection: https://www.cac.gov.cn/2013-02/08/c_12648744.htm