Intellectual Property
When a customer requests copyright assignment for custom SaaS development: preserving updates to shared functions and services for other customers
Even a development agreement for a single customer can affect the operation of a shared service if rights in shared components are assigned without permission for the uses needed to supply and update services for other customers. Review the scope of the assignment, the terms of your retained use, and clauses restricting supply to other customers together.
Reviewed by Keishi Yoshikawa, Attorney at Law and Patent Attorney (Dai-Ichi Tokyo Bar Association)
Contents
1 Identifying the work and its impact on other customers
First, establish whether the work affects existing shared components and whether its results are intended to be supplied to other customers as well.
For components that predate the development, first identify what will be excluded from the assignment: the existing service platform, shared libraries, components created for earlier projects, and components obtained from outside the company and incorporated into the service. Check whether the agreement expressly excludes them and whether the exclusions are specific. Even wording such as “works previously owned by the provider” should specify the relevant date and version so that the components can be identified.
Then analyze the work as follows.
The work and the intended supply
| Work to be performed | Intended for this customer only | Intended for other customers as well |
|---|---|---|
| Modifying existing components | Will the modifications also be reflected in other customers' environments? | In addition to retaining rights in the existing components, do the terms permit supply to other customers after modification? |
| Creating new components | Does the description of the assigned components inadvertently include shared components? | Do the terms permit incorporating the new components into the shared service and supplying them to other customers? |
A single project may involve both modifying existing components and creating new ones. Apply the appropriate row to each part of the work. “Supply” includes making a service incorporating the component available for a customer to use. This table organizes the work and intended supply; its categories do not themselves determine copyright ownership or whether a use is permitted.
Begin with the functions and map them to the implementing code, design documents, relevant versions, and changed portions. The final code does not need to be identified at the time of contracting. Agree first on how the relevant components will be identified, then maintain the corresponding records as design and development become more specific.
Copyright protects creative expression, such as code; similarity of function alone does not establish infringement. Separately check whether developing or supplying similar functions is prohibited by the contract.
2 Determining the scope of assignment and the uses you may continue
Establish what the customer seeks to secure through the assignment and consider terms that accommodate both that objective and the uses your company needs. Is the customer seeking continued use, restrictions on supply to other customers, or possession of the source code? Understanding the objective allows you to assess whether accepting the request would still permit continued provision and updating of the shared service.
First consider retaining your rights in shared components. Limit the assignment to customer-specific components and retain the rights belonging to your company in both pre-existing components and shared components created in the present project. This differs from assigning the rights and then obtaining permission to use them. Retaining the rights reduces the terms of use that need to be secured afterward.
For any components to be assigned, examine each act your company needs to continue: reproduction, modification, use of modified versions, incorporation into services for other customers, and work by external development or maintenance contractors. For each act, determine the permitted duration and whether it may continue after the customer contract ends. Check whether wording allowing “use for the provider's own business” covers the acts actually planned.
Distinguish terms permitting supply only to the particular customer from terms also permitting supply to other customers. The former alone do not authorize use of the assigned components for other customers. If modifications to shared components will also be reflected in other customers' environments, check whether that deployment is itself permitted.
For components created by external developers, first check whether you have secured from those developers the rights needed both for assignment to the customer and for your own continued use. If rights remain with an external developer, an assignment agreement with the customer alone will not transfer those rights. Check whether the contractor agreement contemplates assignment to this customer.
If the necessary uses cannot be secured, reconsider the development scope and delivery method as well as the contractual terms. Can the work be implemented without affecting shared components, or supplied only within that customer's environment? If neither is feasible, decide internally whether to accept the project on those terms. Involve sales and development in assessing the effects on supply and updates for existing customers and on future expansion to other customers.
Rules governing business transactions may become relevant if a customer uses its strong bargaining position to demand assignment of copyright without compensation or justifiable grounds, and your company has no practical choice but to agree because of concerns about the effect on the business relationship. A condition that is difficult to accept is not necessarily a violation of those rules.
3 Restrictions on supply to other customers even where you retain copyright
Even where the agreement leaves copyright with your company, check whether other provisions restrict development of similar functions or supply to other customers. Ownership alone does not resolve this issue.
Check three points. First, does the prohibition cover only customer-specific processing, or also shared functions such as existing access controls? Second, does it cover only supply to new customers, or also continued supply and functional updates for existing customers? If updates for existing customers must stop, the effects extend beyond this project. Third, do the restriction's duration and the customers or markets it covers conflict with your planned expansion of the shared service?
If restrictions capture uses you wish to continue, such as supply and updates for existing customers, consider whether their scope can be adjusted and take the outcome into account when deciding whether to accept the order.
Depending on the wording, developing or supplying equivalent functions may breach a contractual promise even if separate code is written. Check compliance with copyright law and compliance with the contract separately.
Confidentiality also requires attention: retaining rights in a component does not necessarily permit using the customer's confidential information for other customers.
4 Checking departures from the agreed scope before adopting specification changes
Internally redesignating something as a shared function does not alter the agreement with the customer. Conversely, the contract may permit supply to other customers even if that was not originally planned. When changing the supply policy, check whether the change falls within the original agreement.
Before adopting a specification change affecting rights or the scope of supply, sales, development, and legal teams should check it against the agreement. Do not wait until completion or immediately before supply to other customers. At the specification stage, check whether the change affects the subject matter of the assignment or the terms of use.
If the change exceeds the agreed scope, return to discussions with the customer. Record the reasons for the decision and who checked it and when, so that you can show which components and uses the agreement was intended to cover. The key is to be able to trace the identification method agreed at signing and how it was applied during subsequent design and development. Making functions shared within the agreed scope does not require fresh customer approval on every occasion.
Whether to accept a copyright assignment request requires a combined assessment of the assignment's scope, the terms of your retained use, and restrictions on supply to other customers. We advise on reviewing rights provisions in development agreements, structuring the scope of assignment and retained uses, and negotiating with customers.
For change control and dispute prevention across the development agreement, see System development disputes.
Contact
Making an inquiry
Please tell us the outline of the situation, any notice you have received and its date, and any deadline you are working to.
Contact FormThis article is provided for general informational purposes only and does not constitute legal advice on any specific matter. Please consult us regarding your specific situation. The content is based on the laws and regulations in effect as of the date of the last update.