Alleged OSS license violations in shipped products or ongoing services: remediation of past deliveries and decisions on future supply

1 The products, versions, and recipients to investigate

First establish the position of the person raising the issue and what they are requesting. Requests may concern missing notices or license texts, or the disclosure or provision of corresponding source code under licenses such as the GPL, LGPL, or AGPL. Identify the products, components, and versions concerned, the conditions relied on, the date the notice was received, and any response deadline. Preserve the items shipped or delivered at the time, notices and license texts, and build records, and distinguish the allegations from facts the company has verified.

Begin with the products and versions identified in the allegation, then extend the investigation to other products and older versions using the same code, common components, or common build settings. Trace recipients through shipment and delivery records. If an item is excluded, retain the supporting materials and reasons, such as evidence that it does not contain the code concerned, and distinguish unverified items. If a software bill of materials exists, treat it as one source for this comparison. Its existence does not replace the assessment of compliance with the applicable conditions. Also check whether the information it reports matches the items actually shipped.

2 Identifying unmet conditions against the actual implementation and supply

Verify the applicable conditions from notices and accompanying documents attached to the files at the time. Conditions may differ between versions of the same component, and exceptions may apply. Then examine whether and how the code was modified, how it was combined with other code, and what was provided to whom. Check supply-related conditions against the terminology and definitions in the original license and the applicable law. Do not decide their application solely by asking whether an act constitutes distribution under Japanese copyright law.

Supply arrangements and conditions to check

Condition to verify in the original license	Technical and supply arrangement	Specific facts to investigate	Possible response for past deliveries
A requirement to supply materials for recombination with a modified library, for example under the LGPL.	Products shipped with a statically linked library.	Whether source code, object files, and build instructions for the delivered version remain available.	Supply the relevant source and relinking materials, adding installation information where required.
Conditions fulfilled through a replaceable shared-library mechanism, for example under the LGPL.	Products shipped using dynamic linking.	Whether the mechanism permits replacement with an interface-compatible modified version that operates properly.	Consider updating to a replaceable configuration and supplying necessary source and installation information.
Different treatment of a combined whole and an aggregate of independent works, for example under the GPL.	Programs running as separate processes within one product.	Incorporation and sharing of code, the nature of calls between programs, and the overall configuration.	Check whether addressing the OSS alone is sufficient or whether source provision and revised licensing terms are needed for the combined scope.
A source-provision condition for remote interaction with a modified version, for example under the AGPL.	Users interact with a program running on a server.	Whether modifications were made, their scope, and the program with which users interact.	Provide all users interacting remotely with that modified version with a means of obtaining the corresponding source at no charge and a prominent notice of that option.
Notice, source, or other conditions on provision of copies.	Code sent to browsers or images delivered into customers' environments.	Files and versions actually provided, accompanying notices, and supplied materials.	Provide supplementary notices and necessary source corresponding to the versions received.

Note: each row assumes that the condition in the first column has been verified. The responses are possible measures, not a complete statement of all conditions to be fulfilled. The method of combination alone does not determine the applicable scope; separate processes also require individual assessment. Check correction of past deficiencies and reinstatement of permission separately.

For each product and version, organize the findings into three categories: applicable conditions, established deficiencies, and facts necessary for a decision but not yet verified. Explicitly identify matters that cannot be resolved solely by a technical feature, such as operation as separate processes within the same product.

3 Remediating past deliveries and deciding whether future supply may continue

Specify the necessary response to each established deficiency. Some may be addressed by adding notices or license texts; others require corresponding source code or consideration of component replacement. Providing only the latest source or the portions modified by the company may be insufficient. Check whether the source corresponds to the version already delivered, whether the necessary build materials are complete, and to whom, by what method, and for how long they must be provided. Depending on the applicable conditions, also check whether recipients must be licensed to modify or redistribute the software and whether the company's own terms obstruct those permissions.

The affected items are not uniform. Distinguish units held by customers, older versions that remain unupdated, distribution inventory, replacement parts for maintenance, and update files awaiting release. Do not base the response solely on the existence of an update mechanism; consider whether notices and materials can be delivered without updating the code. Even for products capable of being updated, versions left unupdated still need to be addressed.

Remediation is not the same as securing permission for future use. Separately identify what has been corrected through notices, source provision, or component replacement and whether a terminated license must be reinstated or separate permission obtained. For a commercial license, also verify its coverage and effect, including whether it covers past deliveries.

Check termination for breach and reinstatement following cure under the terms of the applicable license version. Even where reinstatement provisions exist, the outcome may depend on cure, whether and when notice was received from a right holder, and the history of prior notices. When reviewing prior notices from the same right holder concerning a breach of the same license, do not exclude them merely because they concern a different product or type of breach. Check reinstatement separately for each relevant right holder. If the applicable terms distinguish provisional from permanent reinstatement, preserve that distinction.

A period specified in a reinstatement provision is not a general grace period permitting violations throughout that period. Where the original license does not provide for automatic reinstatement, automatic reinstatement cannot be asserted solely on the basis of that text, although separate permission may be considered.

Accordingly, retain records showing whether a termination provision applies, whether a reinstatement provision applies to that ground for termination, whether violations have been cured to the extent required by that reinstatement provision, who sent notice and when, whether it concerned an allegation of breach or termination of permission, and when remediation was completed.

Record separately the response to past deliveries, the status of permission, and ongoing obligations such as source provision. Then decide whether to continue supply, narrow its scope, or suspend it temporarily. Even reinstatement does not automatically resolve past liability or claims.

Disputes over permission to use software or the scope of remediation are addressed in Disputes over intellectual property licenses.

4 What to tell customers and recipients, and when

Decide customer communications by reference to contractual notice provisions and deadlines, onward supply by customers, and the cooperation needed for remediation. Check the company's own permission separately from the conditions governing customers' use and onward supply. Do not assume that termination of the company's permission automatically prevents customers from continuing to use the software.

Explain the delivered versions concerned, established deficiencies, matters under investigation, supplementary notices and materials, actions requested of customers, and the timing of the next update. If customers are supplying the software onward, check whether their recipients also need information or supplementary materials. Do not adopt a blanket policy of waiting for remediation to be completed before making contact.

5 Cooperation and allocation of costs with contractors

Check contractual provisions on OSS use and disclosure, warranties, indemnities, and cooperation, and compare them with records of component selection and integration and the company's instructions and approvals. Request source code and build materials corresponding to past deliveries without waiting for final agreement on allocation of responsibility.

Examine the requirements for contractual indemnity claims separately from those for damages for non-performance. For the latter, also consider whether responsibility is attributable to the contractor and the causal connection with the loss. Check liability limitations, notice and claim deadlines, and any requirement for prior consent to costs. Pursue contractor claims and the company's remediation in parallel.

Remediation of past deliveries and securing permission for future supply must be assessed separately against the applicable terms and the actual supply arrangements. We advise on investigations into applicable conditions and supply arrangements, negotiations with complainants and right holders concerning remediation and permission, customer explanations, and allocation of responsibility with contractors.

Related article: When software use rights are called into question after an acquisition (checking use rights for acquired or transferred software).

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 Form

Related information

Related explainers and practice areas

Intellectual property, IT and data: overview

Individual guides, according to the situation, on disputes over rights, the removal of trade secrets, and system development and the management of data.

Intellectual property, IT and data (practice areas)

Our practice areas covering the acquisition and use of intellectual property rights and responding to infringement, contracts relating to IT and systems, and the handling of data.

This 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.