Software Copyright in a China Company Report
Interpret software copyright records by title, version, recorded owner, and dates, then test how the record relates to the software actually being purchased.
A software copyright record can connect a named software version to a recorded right holder. It does not certify that the software works, that the current build is the registered version, or that the vendor owns every component in the product.
That boundary is especially important when reviewing an industrial platform, mobile app, embedded controller, SaaS vendor or smart-device supplier. A company report may surface a useful registration record, but the procurement question is narrower: does this record support the vendor's claimed role in this product?
What is registered?
China's Computer Software Protection Regulations define software as computer programs and their related documentation. Source code and object code of the same program are treated as the same work under that definition. The concept is therefore more specific than a product idea, a cloud service, a brand or an entire technology business.
The WIPO software overview draws another useful line: copyright protects expression, not ideas, procedures, methods of operation or mathematical concepts as such. A registration for `Warehouse Routing Platform V1.0` is not exclusive ownership of every warehouse-routing concept or algorithm described in a sales presentation.
When a company report lists software registrations alongside patents and trademarks, keep their purposes separate. The IP-record use map explains the wider portfolio; this page stays with the software record.
Registration is evidence, not the birth of copyright
The protection regulations say software copyright arises when development is completed. They also allow a right holder to register and describe the resulting registration document as preliminary evidence of the registered matters. China's Software Copyright Registration Measures encourage registration and set out the applicant and document requirements.
So avoid two common statements:
- `The company obtained copyright on the registration date.` The underlying right is not created by that administrative date.
- `No registration was found, so the company has no copyright.` A missing search result does not settle whether protectable software or contractual rights exist.
The distinction also explains why registration volume is not a quality ranking. The National Copyright Administration reported 3,182,829 software copyright registrations in 2025. That is broad administrative context, not evidence that a vendor with 100 records is better than one with five relevant records.
Read six fields as a version card
Availability varies by source, but a useful record extract may contain the following fields. Preserve the Chinese text and retrieval date rather than translating away a version suffix or entity name.
- Full software name and short name
- Compare the exact wording with the quotation, login screen, user manual and contract schedule. Similar names can describe a product family rather than the build being purchased.
- Version number
- `V1.0` is not interchangeable with a demonstrated `V3.2`. Ask how releases, modules and white-label editions relate to the registered version.
- Registrant or recorded right holder
- Match the Chinese legal name to the contracting company. If it names a founder, employee, affiliate or outside developer, document the ownership or licence chain instead of treating the difference as automatically legitimate or suspicious.
- Development completion date
- This is the reported completion point for the registered software. It is not an independent audit of the code repository, feature completeness or release quality.
- First publication date, if shown
- This may help reconstruct chronology. `Unpublished`, blank or unavailable should not be rewritten as `never used` or `never delivered`.
- Registration date and number
- Use these to identify and time the administrative record. Do not substitute the registration date for the completion date, first publication date or current product release date.
The right holder may not be the seller
A mismatch needs a relationship explanation. Software may have been developed by employees, jointly developed, commissioned from a contractor, transferred, licensed, or retained in another group company. The protection regulations contain specific default rules for commissioned and certain employee-developed software, but a buyer should not try to resolve legal ownership from a short public result.
Request the documents that fit the actual story: development agreement, employment IP clauses, transfer instrument, licence, group-company authorisation, merger or name-change record, and a list of third-party and open-source components. Verify every company by its Chinese legal identity. If the seller says the developer is an affiliate, compare the relationship with the contract party and service team rather than collapsing both names into one company.
Business scope can provide context about software development or technology services, but it does not decide copyright ownership. Use the business-scope review for that separate field.
Three dates do not make a release history
A registration may give you a completion date, first publication date and registration date. None necessarily tells you which build is running in the demo today, when a feature was added, who maintains production, or whether the vendor can restore the service after failure.
Build a short chronology from records that were created for software delivery:
- registered title, version and reported completion date;
- release notes and build identifiers for the quoted version;
- dated customer or internal acceptance records;
- repository, deployment or escrow evidence appropriate to the deal;
- current support owner, subcontractors and end-of-life policy.
The objective is not to demand source code for every purchase. It is to make the evidence proportionate to dependence: an offline utility used by one analyst needs less continuity evidence than software controlling a production line or storing regulated data.
Case: the report says V1.0, the demo says V3.2
A fictional vendor demonstrates `PlantWatch 3.2`, a monitoring platform bundled with factory sensors. The company report lists `PlantWatch Equipment Monitoring Platform V1.0`, registered three years earlier to the same Chinese legal entity. The title, owner and chronology are plausible. The record supports continuity between the company and an earlier version of the product.
It does not authenticate V3.2. The buyer asks for release notes linking V1.0 to V3.2, the build number shown in the demo, a feature-to-version list, recent acceptance evidence and disclosure of the mapping component supplied by another developer. The contract then names the deliverable version, support term, data-export method, security obligations, acceptance tests and responsibility for third-party licences.
The resulting conclusion is neither `copyright verified, approve` nor `version mismatch, reject`. It is: `The registration supports an earlier product-to-company relationship; current-version ownership, components and delivery controls require the listed evidence.`
What the registration does not test
- Function: whether promised features work under the buyer's workload.
- Security: vulnerability management, access control, encryption, incident response or secure development.
- Code provenance: whether every module is original, licensed, open source or supplied by a contractor.
- Operations: hosting ownership, backup, disaster recovery, support staffing and uptime.
- Product rights: whether the seller has authority to license the current build in the buyer's territory and use case.
These require technical testing, software composition or security review, contract evidence, and sometimes specialist legal advice. A company record can help target those checks; it cannot perform them.
Write a bounded company-report conclusion
State the exact record, identity match, version relationship, date limit and next action. For example:
The report identifies `PlantWatch Equipment Monitoring Platform V1.0` registered to the verified contracting entity. This supports a software-to-company relationship for the named version as of the recorded dates. It does not establish ownership, security or performance of the quoted V3.2 build. Obtain the release chain, component disclosure, acceptance evidence and contractual licence before approval.
Attach the source extract and supplier response to the supplier approval file. A sample company report shows how the IP module sits beside identity and operating data; it should not be read in isolation.
Escalate high-value custom development, disputed ownership, source-code access, cross-border licensing, infringement concerns or business-critical continuity to qualified technical and legal reviewers. For ordinary procurement, place the result in the pre-contract evidence sequence and record the bounded wording in the internal approval memo.