Software and SaaS Procurement and Licensing Pages on Changzhou Manufacturer Websites: How Should They Be Accepted?

Direct answer: A software/SaaS procurement and licensing page is not a line saying "buy a licence/open an account". The page should state: the licence model (perpetual/subscription, named/concurrent user, CPU/core, site, SaaS, OEM/embedded, open source, trial/POC); the licence metric (users/cores/devices/environments/affiliates/contractors/cloud); the contract (scope, term, renewal/price escalation, payment/tax, delivery/acceptance, SLA/support/updates, source-code escrow, data ownership, security/export, termination/transition, audit); acceptance/UAT (requirements, test cases, data migration, integration, performance, security, training, go-live, acceptance criteria, remedies); data/privacy/security (ownership, access, export, deletion, subprocessors, cross-border, incidents, certification); open source/SBOM; exit/transition (data export, source-code escrow, transition assistance, perpetual licence continuation, deletion); and what must not be published. On the law: software is a work protected by the Copyright Law; the Computer Software Protection Regulations require a licence/transfer contract for software copyright, prohibit exercising rights not expressly licensed, and recommend written exclusive licences/transfers and registration; the Civil Code governs performance and breach. This article is current to 2026-11-08 and is a summary of public rules and page method, not legal, software-licence-audit or procurement advice; contracts, entitlement documents, copyright registration and court/arbitration findings control.

This article is for procurement, IT, finance, legal, internal-control, supply-chain and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby. It covers how to write and accept a software/SaaS procurement and licensing page. The usual gap is "licence metric, renewal price increase, acceptance/UAT, data ownership, source-code escrow, open source/SBOM and exit", ending with a page that only says "genuine licence/annual subscription", while procurement does not know how much to buy, IT does not know what to accept, and legal does not know how to get data back on exit.

How does this page relate to AI RFP, build-vs-buy, IT cost, information security, contract signing and supplier exit pages?

A software procurement page answers "what licence to buy, how to accept, who owns the data, how to exit"; the AI RFP page answers "requirements/POC/pricing"; the build-vs-buy page answers "build or buy SaaS"; the IT cost page answers "TCO/pricing"; the information-security page answers "data exchange/access"; the contract signing page answers "document priority/signature"; the supplier exit page answers "termination/transition". Software procurement is a combination of "licence + services + data" and cannot be replaced by a cost or contract-signing page.

Common breaks: only "genuine licence"; unclear licence metric; production/test/DR/cloud/affiliates missed; auto-renewal/price increase; no acceptance criteria; data migration not accepted; unclear SLA/support; no source-code escrow; unclear data ownership/export/deletion; open source/SBOM not checked; no exit transition; the website publishes prices/customers/deployment details. The page separates "licence—contract—acceptance—data—open source—exit—public boundary" so procurement/IT/finance/legal share one vocabulary.

Page relationships are editorial; contracts, entitlement documents, copyright registration and court/arbitration findings control.

What licence models exist, and how to choose?

Common: (1) perpetual licence (one-time + annual maintenance); (2) subscription/SaaS (annual/monthly, per user/usage/module); (3) named/concurrent user; (4) CPU/core/server/site; (5) OEM/embedded/distribution; (6) open source (GPL/LGPL/Apache/MIT etc.); (7) trial/POC/sandbox; (8) enterprise agreement/unlimited/business metric. Choose by users/concurrency, deployment (on-prem/cloud/hybrid), environments (production/test/DR), affiliates/contractors, data sensitivity, integration/customisation, exit/migration and total cost. A licence is not "the cheaper the better"; calculate "used/unused/future expansion/audit risk".

Acceptance checks: model; metric; users/cores; environments; cloud; affiliates; contractors; term; renewal; expansion; audit. Common gaps: only "licence"; unclear metric; test/DR missed; cloud/affiliates missed; unlimited subscription increase; no expansion clause.

Licence models are editorial; contracts, entitlement documents, licence texts and vendor policy control.

How should licence metrics and audits be accepted?

State the metric: named user/concurrent/employees/monthly active/devices/cores/CPU/servers/sites/transactions/usage; environments: production/test/DR/sandbox/cloud/hybrid; entities: HQ/branches/affiliates/contractors/outsourcing/customers; time: term/renewal/grace/post-termination use; audit: notice/scope/method/frequency/evidence/true-up/fees/dispute. Common traps: treating "concurrent" as "named"; missing test/DR/cloud; missing affiliates/contractors; not reclaiming leavers; not true-up after overuse; audit clause too broad/no notice; true-up without cap. Procurement/IT should keep user lists/deployment diagrams/contracts/orders/invoices/audit reports.

Acceptance checks: metric; environments; entities; time; audit; true-up; evidence; reclamation; overuse; dispute. Common gaps: mixed metric; missed environments/entities; no reclamation; no true-up; unbounded audit; no evidence.

Licence metrics are editorial; contracts, entitlement documents, vendor audit rules and law control.

Which contract clauses should be included?

At least: licence model/scope/metric/environments/entities; term/renewal/auto-renewal/price cap/advance notice; payment/tax/invoice/currency; delivery/acceptance/UAT/acceptance criteria/remedies; SLA/support/response/fix/availability/credits; updates/upgrades/version/compatibility/end-of-support (EOL); source-code escrow/triggers/release; data ownership/access/export/deletion/subprocessors/cross-border/security/incidents; IP/open source/SBOM/indemnity; audit/true-up; confidentiality; termination/transition/perpetual licence continuation/data deletion; dispute resolution. The clause should answer "how much, when accepted, what if it breaks, who owns data, how to exit".

Acceptance checks: scope; metric; term; renewal; price increase; payment; acceptance; SLA; updates; EOL; escrow; data; IP/open source; audit; termination; dispute. Common gaps: no metric; auto-renewal; no price cap; no acceptance criteria; no SLA credits; no EOL plan; no escrow; unclear data; no open-source check.

The clause list is editorial and is not a contract template or legal advice; legal/IT/finance/procurement review before signing.

How should acceptance/UAT be accepted?

Acceptance at least: requirements/scope baseline; cases/scripts (function/permissions/integration/interfaces/reports/mobile/multilingual); data migration (fields/mapping/cleansing/volume/sampling/rollback); integration (ERP/MES/PLM/CRM/SSO/API); performance/capacity/concurrency; security (permissions/encryption/logs/vulnerabilities/penetration); availability/backup/DR; training/documentation/admin handover; go-live/cutover/rollback; acceptance criteria (pass/conditional pass/fail); defect grading/fix/retest; payment milestones tied to acceptance; remedies for failure (remediation/extension/refund/termination). UAT is not "IT says it works"; it needs business sign-off/case evidence/defect closure.

Acceptance checks: requirements; cases; data; integration; performance; security; DR; training; go-live; criteria; defects; payment; remedies. Common gaps: no cases; data not tested; integration fails; performance untested; security unchecked; no training; no criteria; payment before acceptance.

Acceptance/UAT is editorial; contracts, requirements, acceptance plan and company policy control.

How should data, security and source-code escrow be accepted?

Data: ownership (customer/vendor/joint), access (least privilege/logs), export (format/frequency/cost/completeness), deletion (post-termination period/proof), subprocessors (list/responsibility), cross-border (path/assessment/consent), security (encryption/backup/vulnerabilities/incident notification/drills), certification (ISO 27001/MLPS/SOC 2). Source-code escrow: triggers (bankruptcy/end-of-support/material breach/acquisition), scope (source/build/documentation/keys), verification (periodic build/integrity), release (conditions/method/licence), fees. Data/escrow is not "written in the contract"; it needs export drills/escrow verification/deletion proof.

Acceptance checks: ownership; access; export; deletion; subprocessors; cross-border; security; certification; escrow triggers; scope; verification; release; fees. Common gaps: vendor owns data; export fees; no deletion proof; unclear subprocessors; no cross-border assessment; no escrow; no verification.

Data/escrow is editorial; contracts, DPA, data-security/PIPL requirements and escrow agreement control.

How should open source/SBOM and exit be accepted?

Open source: require the supplier to disclose open-source components/versions/licences (SBOM), explain GPL/LGPL/Apache/MIT obligations (distribution/disclosure/derivative/patent/trademark), confirm whether it contaminates proprietary code/requires disclosure, whether there is copyleft risk, known vulnerabilities/maintenance status, and indemnity/replacement/fix obligations; embedded/distribution scenarios are especially important. Exit: data export/migration; source-code escrow release; transition assistance (documentation/training/interfaces/migration); perpetual licence continuation/subscription termination; account/permission closure; data deletion/proof; unsettled payment/refund; dispute. Exit is not "do not renew"; you must be able to get data back/keep running/migrate.

Acceptance checks: SBOM; licence; obligations; copyleft; vulnerabilities; maintenance; indemnity; replacement; data export; escrow; transition; licence continuation; deletion; refund. Common gaps: no SBOM; no GPL check; unaware of copyleft; vulnerabilities unfixed; no data on exit; no transition.

Open source/exit is editorial; licence texts, contracts, SBOM and escrow agreement control.

How should the website page be written, and what must not be published?

Suggested sections: (1) licence model/metric/environments; (2) contract/renewal/price increase/SLA; (3) acceptance/UAT/data migration/go-live; (4) data/security/escrow; (5) open source/SBOM; (6) exit/transition; (7) contact/version/update date. The public page explains "licence, acceptance, data, exit and boundaries", and does not publish specific prices/discounts/contracts, customer lists, deployment architecture/vulnerabilities, source code/escrow content, personal data or pending disputes; specifics are handled under NDA/controlled systems/contract annexes.

The English page should use consistent terms (perpetual, subscription, named/concurrent user, core/CPU, SaaS, OEM/embedded, open source, SBOM, UAT, acceptance, SLA, escrow, data export/deletion, transition) and state the cut-off date. It can link to AI RFP, build-vs-buy, IT cost, information security, contract signing and supplier exit pages, but must not become a "genuine licence" advertisement.

The page structure is editorial; public statements must be true and verifiable, and contracts, licence texts and law control.

Go-live acceptance checklist

Ten checks: licence model/metric; environments/entities; contract/renewal/price increase; acceptance/UAT; SLA/support/EOL; data/security; source-code escrow; open source/SBOM; exit/transition; public boundary/version. Each needs evidence and a review date. The pass standard is not "the page says genuine licence", but that procurement/IT/finance/legal can use the page to judge how much to buy, how to accept, who owns data, what remedy applies, and how to exit at expiry/termination.

Before go-live, run a tabletop exercise with a real (redacted) software purchase: licence → contract → acceptance/UAT → data migration → go-live → SLA → renewal/price increase → exit/data export/escrow. Then simulate a licence audit, a vendor end-of-support and a data-export failure to see whether the page and clause work.

The acceptance list is editorial; contracts, licence texts, acceptance plan and company policy control.

Who should read it, who should not, and what decisions does it support?

For procurement, IT, finance, legal, internal-control, supply-chain and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby; also for companies buying ERP/MES/PLM/OA/CRM/SaaS, facing renewal price increases, licence audits, or worried about "data locked in, no source-code escrow, open-source contamination". Not for teams that do not buy software/SaaS, or that want one page to replace legal/licence-audit/IT-architecture advice.

Read it if: building a software procurement page; only writing "genuine licence"; unclear licence metric; missing test/DR/cloud/affiliates; auto-renewal; no acceptance criteria; no SLA credits; no EOL plan; unclear data; no escrow; no open-source check; no exit transition. Not suitable if: treating "subscription" as "perpetual"; treating "concurrent" as "named"; treating "acceptance" as "go-live"; treating "expiry" as "exit". Supports: licence/metric, contract/renewal, acceptance/UAT, SLA/EOL, data/security, escrow, open source/SBOM, exit and page wording self-checks.

FAQ

How to choose software licensing by user/CPU/core?

Look at usage/deployment/environments/entities. Named user suits fixed staff; concurrent suits shifts/shared use; CPU/core/server suits on-premise; SaaS usually per user/usage/module; OEM/embedded per distributed quantity. State whether production/test/DR/cloud/affiliates/contractors are counted, whether leavers/transfers/idle users are reclaimed, and how overuse/audit/true-up are handled. Do not just write "a certain number of users".

How to control subscription auto-renewal/price increases?

State the renewal cycle, auto-renewal/advance notice, price cap/formula, early termination/non-renewal notice, data export/transition; procurement should keep a ledger (expiry/amount/owner), assess usage/substitution/renewal before expiry; avoid "default auto-renewal + unlimited price increase". Renewal is not a click; re-confirm licence/price/data/exit.

How to handle a licence audit/true-up?

First check the audit clause (notice/scope/method/frequency/evidence/true-up/cap/dispute); keep user lists/deployment diagrams/contracts/orders/invoices/monitoring data; if overuse is found, reconcile internally (test/DR/cloud/affiliates/contractors/leavers not reclaimed), then confirm true-up/optimise licences with the vendor; do not accept unbounded audits/uncapped true-up. Do not destroy/alter evidence before an audit.

How to set acceptance/UAT?

Center on the requirements baseline/cases: function/permissions/integration/interfaces/reports/mobile/multilingual; data migration (fields/mapping/cleansing/volume/sampling/rollback); integration (ERP/MES/PLM/CRM/SSO/API); performance/capacity/concurrency; security (permissions/encryption/logs/vulnerabilities); availability/backup/DR; training/documentation/admin handover; go-live/cutover/rollback; acceptance criteria (pass/conditional/fail), defect grading/fix/retest, payment tied to acceptance, remedies for failure.

How to protect data/source-code escrow/exit?

Data: ownership, access, export (format/frequency/cost/completeness), deletion (period/proof), subprocessors/cross-border/security/certification. Source-code escrow: triggers (bankruptcy/end-of-support/material breach/acquisition), scope (source/build/documentation/keys), verification (periodic build/integrity), release (conditions/method/licence), fees. Exit: data export/migration, escrow release, transition assistance, perpetual licence continuation/subscription termination, account closure, deletion proof, unsettled payment/refund.

How to accept open source/SBOM?

Require an SBOM (components/versions/licences), explain GPL/LGPL/Apache/MIT obligations (distribution/disclosure/derivative/patent/trademark), copyleft risk, known vulnerabilities/maintenance status, indemnity/replacement/fix obligations; embedded/distribution scenarios are especially important. An SBOM is not "an Excel"; it must correspond to versions/builds/vulnerability scans/fix records; non-compliance may require open-sourcing proprietary code or lead to claims.

One-sentence takeaway

The software/SaaS procurement and licensing page on a Changzhou manufacturer's website is not about "genuine licence"; it is about turning licence model/metric/environments, contract/renewal/price increase, acceptance/UAT, SLA/EOL, data/security, source-code escrow, open source/SBOM, exit/transition and public boundaries into a checkable list, so procurement/IT/finance/legal can judge how much to buy, how to accept, who owns data, what remedy applies, and how to exit at expiry/termination.

Research method and limitations

This article is a summary of public rules and page method, not legal, software-licence-audit or procurement advice. It uses no unpublished price, contract, customer, deployment-architecture, vulnerability, source-code or dispute data; the tables and acceptance items are editorial and not legal conclusions. The Copyright Law, Computer Software Protection Regulations and Civil Code; contracts, entitlement documents, licence texts, copyright registration and court/arbitration findings control. This article does not decide whether any specific licence/acceptance/data/escrow/open-source clause is lawful or enforceable; companies should review item by item and consult professional lawyers/IT architects.

Sources and basis

Current to 2026-11-08; the official pages below control.

1. Copyright Law of the People's Republic of China: gov.cn. Computer software as a protected work, licence/transfer contracts and rights not expressly licensed.
2. Computer Software Protection Regulations (2013 amendment): gov.cn. Software copyright licence/transfer contract, written exclusive licence and registration.
3. Civil Code of the People's Republic of China: Supreme People's Court. Contract performance, breach liability and dispute resolution.