Who owns the design and PLC code in a custom machine build?

Why does the contract, not the invoice, decide ownership?#

Ownership of a custom machine's design and PLC code is set by the written terms of the build, not by the price the customer paid. A customer that funds engineering hours often assumes it bought the drawings and source code, and a builder often assumes it kept everything. Either side can be wrong when the quote, the purchase order and the acceptance documents say different things.

US copyright rules give a starting point. Under 17 U.S.C. 201(b), the employer is treated as the author of a work made for hire and owns the copyright unless a signed writing says otherwise, which covers drawings and code a builder's engineers produce as part of their jobs. Copyright Office Circular 30 explains that a commissioned work counts as a work made for hire only in listed statutory categories and with a signed written agreement.

Custom control code and machine drawings rarely fit those commissioned categories, so a customer that wants to own them usually relies on an express assignment clause. Without one, the customer typically holds a license to use, maintain and repair the machine it bought. How those rules apply to a given project is a question for counsel.

Who usually owns each part of a machine build?#

Each deliverable in a machine build has its own default owner, and the clause that can change it sits in a different place in the paperwork. The table shows the usual position when the documents are silent, and the clause that most often moves it.

Which clauses move ownership to the customer?#

Ownership moves to the customer through specific language, and a single clause can transfer more than either side intended. General counsel should read the full contract stack: the quote and its terms, the customer's purchase order terms, any master engineering or supply agreement, change orders and the acceptance certificate.

When the builder's quote and the customer's PO terms conflict, which set controls depends on contract formation rules and how the parties behaved. That analysis is fact-specific, so it belongs with counsel rather than with the project manager who signed the PO acknowledgment.

• 1Assignment of deliverables: wording that the customer owns all work product, designs or documentation created under the order.
• 2Work made for hire language: often copied from service templates; whether it reaches machine designs and code is a legal question.
• 3Source code delivery: a duty to hand over unlocked PLC and HMI source at acceptance, which gives access but not necessarily ownership.
• 4Background IP carve-out: a statement that the builder keeps its pre-existing tools, libraries and standard designs and licenses them for the machine.
• 5Improvements: who owns changes to the builder's standard platform that were made for this customer.
• 6Non-reuse or exclusivity: a promise not to build the same machine for the customer's competitors.
• 7Confidentiality survival: how long the duty to protect customer information lasts after the project closes.

What about locked routines and builder know-how?#

Builder know-how in PLC code is often protected as a trade secret rather than through copyright alone. Many builders lock certain routines, such as motion profiles or tuning logic, and deliver the rest of the program open so the customer's technicians can troubleshoot.

Under 18 U.S.C. 1839(3), information is a trade secret only if its owner has taken reasonable measures to keep it secret and it has value from not being generally known. Handing over unprotected source with no confidentiality terms can weaken that position, so the delivery method matters as much as the ownership clause.

Customers have a fair counterpoint: they must keep the line running long after the warranty ends, or after the builder closes. Source code escrow, or release of locked routines on defined triggers such as the builder ending support, is a common compromise worth raising during negotiation.

Illustrative: a packaging machine builder sorts its project archive#

Illustrative: a fictional builder of case packers and palletizers wants to know which project records it can reuse and which it could license. Its files sit in a PDM vault for mechanical models, an electrical design tool for schematics, a network share of PLC project files, an ERP for jobs and change orders, and a ticketing tool for service calls.

The general counsel pulls the quote terms and customer PO terms for each project and sorts records into three groups. Builder-owned records include standard modules, internal design review minutes, commissioning issue logs and service tickets. Mixed records include project code that a customer contract assigned. Customer material includes product drawings, pallet patterns supplied by customers and recipe parameters.

The decision is to exclude assigned code and customer material, and to consider licensing only builder-owned process records with customer names masked. The outcome is a documented scope the CEO can approve, plus a change to the quote template: every new quote names the builder's background IP and states what is delivered as source.

A checklist before you reuse, share or license project files#

A project-by-project review is the safest way to reuse or license machine-build records, because rights differ between customers and between contract versions. The checklist keeps each review consistent.

Export control deserves its own check. The Bureau of Industry and Security describes EAR technology as information necessary for the development, production, use, operation, installation, maintenance, repair, overhaul or refurbishing of an item, which can reach design and control documentation for some equipment. Treat any classification question as a matter for export counsel.

• 1Collect the contract stack for each project: quote and terms, PO and its terms, any master agreement, change orders and acceptance sign-off.
• 2Record who owns the mechanical design, schematics, code and documentation for that project.
• 3Flag customer-supplied drawings, specifications, recipes and photos of customer products or sites.
• 4Flag defense, nuclear or other export-sensitive work and keep it out of any external scope.
• 5Separate standard modules and libraries from project-specific code.
• 6Note confidentiality periods and any non-reuse or exclusivity promises.
• 7Get written sign-off from the person authorized to approve use of the records.

How SourceX approaches machine-build records#

SourceX treats machine-build records as a rights question first. In the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, the Rights step reviews the contract stack by project, and anything that defines a customer's product or was assigned to a customer stays out of scope.

Nothing is shared during the initial fit check, which collects only metadata such as systems, years of history and record families. For any package that proceeds, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, so the builder can show exactly which projects and records were approved.