Manufacturing
Customer BOMs, Gerbers and test specs at an EMS: who owns them?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Who owns Gerber files at an EMS is usually settled by contract: the customer owns its Gerbers, BOMs, schematics and test specifications, and the EMS gets a limited right to use them to build that product. The EMS generally controls records it creates on its own lines, such as yields and process settings, while mixed records need a clause-by-clause check.
Key takeaways
- Customer design data, including Gerbers, BOMs, schematics and test specs, stays the customer's property and confidential information.
- An EMS's limited right to use design data is usually tied to building that customer's product and nothing else.
- Records the EMS creates, such as BOM scrubs, yields and line settings, are generally its own but may still embed customer information.
- Ownership of paid NRE such as test programs turns on the assignment language, not on who paid.
- Export-controlled programs belong outside any reuse or licensing scope from the start.
Who owns the Gerbers and the BOM?#
The customer usually owns the Gerbers and the BOM in an EMS relationship, because they describe the customer's product design. Fabrication data in Gerber, ODB++ or IPC-2581 form, the bill of materials, the approved vendor list, schematics, assembly drawings, test specifications and firmware images arrive as the customer's confidential information under the master supply agreement or an NDA.
What the EMS receives is a limited right to use that data for a purpose, typically quoting, sourcing, building and testing the customer's product. That purpose limit is the clause that matters most. Even internal uses that feel harmless, such as reusing a customer's BOM to train a quoting tool for other customers, can fall outside it.
Engineering change orders and revision packages follow the same rule. Each new revision of the BOM or fabrication data is still the customer's design, and the EMS's redlines, deviation requests and markups sit in the mixed group because they combine customer content with the EMS's own engineering judgment.
What does the EMS create on its own?#
An EMS creates a large body of records on its own lines: BOM scrub and MPN cleanse results, SPI and AOI settings, reflow profiles, pick-and-place programs, first-pass yields, defect paretos, process FMEAs, maintenance and calibration logs, and work instructions for its standard processes. These reflect the EMS's engineering skill and are generally treated as its own process knowledge.
Created by the EMS does not always mean free of customer information. A placement program is built from the customer's centroid data, an AOI library may mirror the customer's component choices, and a yield report names the customer's board. The record can be the EMS's work product and still carry content the EMS promised to keep confidential.
Customer-owned, EMS-generated and mixed: the three-column view#
The three-column view sorts common EMS records by their usual position. Read across each row as related record types, and treat the mixed column as the list to check against your specific agreements before any reuse.
| Customer-owned | EMS-generated | Mixed: check the contract |
|---|---|---|
| Gerber, ODB++ or IPC-2581 fabrication data | BOM scrub and MPN cleanse results | Pick-and-place programs built from customer centroid data |
| Bill of materials and approved vendor list | SPI, AOI and reflow process settings | Test fixtures and programs paid as NRE |
| Schematics and assembly drawings | First-pass yield and defect paretos by line | DFM and DFT reports on the customer's design |
| Test specifications and acceptance limits | Work instructions for standard processes | Failure analysis and RMA reports |
| Firmware images and programming files | Equipment maintenance and calibration records | Serial-level traceability and traveler records |
Who owns paid NRE such as test programs and fixtures?#
Ownership of paid NRE depends on the assignment language, not on who paid the invoice. Under US copyright law, a work prepared by an employee within the scope of employment is a work made for hire owned by the employer, while a commissioned work counts as one only if it falls into specific statutory categories and the parties sign a written agreement. A test program written by the EMS's own employees may therefore remain the EMS's copyright unless the contract assigns it, although other terms, such as a broad IP or confidentiality clause, can still limit what the EMS may do with it.
Physical items follow different logic. Title to an ICT fixture, a functional test rack or a stencil usually follows the PO and the NRE quote, and many customers ask for them back at the end of a program. Spell out software, fixtures and stencils separately in the NRE clause so a transfer request does not become a dispute.
Which contract clauses decide ownership?#
Ownership questions at an EMS are decided by a handful of clauses spread across several documents. Read them together, because a quality agreement or a customer flowdown can narrow what the master agreement appears to allow.
- Definition of confidential information: whether it covers only data the customer discloses or also information the EMS generates about the customer's product.
- Purpose limitation: what the EMS may use design data for, and whether internal improvement is allowed.
- IP ownership: how background IP, new IP and improvements to the EMS's processes are split.
- NRE and tooling: who owns fixtures, programs and stencils, and what happens at program end.
- Return or destroy: obligations for design data when the relationship ends.
- Records retention: how long the quality agreement requires build and test records to be kept.
- Flowdowns: terms passed down from the customer's own customers, common in regulated markets.
Export-controlled programs stay out of scope#
Export-controlled programs sit outside any reuse or licensing discussion. Under ITAR, technical data includes information required for the design, production, assembly, testing or repair of defense articles, including blueprints, drawings and instructions, so Gerbers and test specifications for a defense board can fall within it. The EAR separately defines technology as information necessary for the development, production or use of an item.
Flag these programs in your inventory at the program level, not file by file, and exclude them entirely. Counsel or your export compliance lead should confirm classifications.
Illustrative: an EMS sorts its records before a review#
Illustrative: a fictional EMS that builds industrial control boards wants to know which records it could reuse internally and potentially license. Its CEO and outside counsel review master agreements for its largest customers and sort records into the three columns. Customer Gerbers, BOMs and test specs are excluded outright, and one program for a defense prime is removed at the program level.
Yields, defect paretos, reflow and AOI settings, and maintenance logs stay in scope after customer names and part numbers are replaced with internal codes. Two customers define confidential information broadly enough to cover EMS-generated data about their boards, so the EMS asks them for written consent and leaves their records out until it arrives.
How SourceX approaches EMS records#
SourceX treats customer design data as out of scope. In the Rights step of the SourceX five-step transaction, agreements are reviewed with the supplier's counsel to separate customer-owned, EMS-generated and mixed records, and mixed records proceed only where the contracts or a customer's consent allow. Preparation removes customer names, part numbers and identifying details from what remains.
The SourceX Evidence Packet then records provenance, licensing rights, permitted use, the privacy record and release authorization, so the EMS can show exactly what was licensed and on what basis. Licensed records stay the EMS's property; the license grants defined use, not ownership.
Frequently asked questions
Can we keep a customer's Gerbers after the customer leaves?
Check the return-or-destroy clause. Many agreements require returning or destroying design data at the end of the relationship, while quality agreements may require keeping build and test records for a period. Keep only what an obligation requires, restrict access, and record the reason.
Does removing the customer's name make a BOM ours?
No. Stripping the name does not change who owns the design choices in the BOM, which remain the customer's confidential information. Aggregated statistics across many customers can be treated differently, but only if your agreements allow aggregation and the result cannot identify any customer's product.
Can we use customer BOMs to improve our own quoting tool?
It depends on the purpose limitation. Using a customer's BOM to quote that customer's next revision usually fits. Training a tool used for other customers may not, especially where confidential information is defined broadly. Read the clause and ask counsel before mixing customer data across accounts.
What if our contract is silent on test program ownership?
Default copyright and trade secret rules then apply, and outcomes depend on facts such as who wrote the code and what was agreed in emails or quotes. Treat silence as a risk, raise the point at the next renewal, and get counsel's view before transferring or reusing the program.
Who owns yield data on a customer's board?
The EMS generates it, and it is often treated as the EMS's process data for internal improvement. But yield data describes the customer's product, and a broad confidentiality definition can restrict sharing it outside the company. Check the agreement before any external use.
Sources
- 17 U.S.C. 101 defines a work made for hire as a work prepared by an employee within the scope of employment, or a specially ordered or commissioned work in listed categories if the parties expressly agree in a signed written instrument. Source
- 17 U.S.C. 201(b) provides that for a work made for hire the employer or person for whom the work was prepared is considered the author and owns the copyright unless the parties expressly agree otherwise in a signed written instrument. Source
- 22 CFR 120.33(a)(1) defines ITAR technical data to include information required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles, including blueprints, drawings, plans, instructions or documentation. Source
- BIS describes EAR technology (15 CFR 772.1) as information necessary for the development, production, use, operation, installation, maintenance, repair, overhaul, or refurbishing of an item. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.