已交付产品或持续提供的服务被指违反开源软件许可证时：补救既往交付并决定今后的供应安排

1 需要调查的产品、版本及接收方

首先，确认提出问题者的立场及其具体要求。相关要求可能涉及通知或许可文本的缺失，也可能涉及依据GPL、LGPL或AGPL等许可证披露或提供相应源代码。应确认所涉及的产品、组件和版本、对方所依据的条件、收到通知的日期以及任何答复期限。应保存当时发货或交付的物品、通知和许可文本以及构建记录，并将对方的指控与公司已核实的事实区分开来。

应从指控中指明的产品和版本入手，再将调查扩展到使用相同代码、通用组件或通用构建设置的其他产品和旧版本。通过发货和交付记录追溯接收方。如将某一项目排除在外，应保留支持该判断的材料和理由（例如其不包含相关代码的证据），并将未经核实的项目区分出来。如存在软件物料清单，可将其作为此项比对的来源之一。但其存在并不能替代对是否遵守适用条件的评估。还应核对其记载的信息是否与实际发货的物品一致。

2 对照实际实现与供应情况，确定未满足的条件

应根据当时随文件附带的通知及附随文件，核实适用的条件。同一组件的不同版本之间条件可能不同，也可能适用例外。然后，审查代码是否经过修改及修改方式、如何与其他代码结合，以及向何人提供了什么内容。与供应相关的条件，应对照原始许可证中的用语和定义以及适用法律进行核对，不应仅凭某一行为是否构成日本著作权法上的“分发”来判断其适用。

需核对的供应方式与条件

需在原始许可证中核实的条件	技术及供应方式	需要调查的具体事实	针对过去交付的可能应对措施
要求提供可与修改后的库重新组合所需的材料，例如LGPL中的要求。	附带静态链接库发货的产品。	所交付版本的源代码、目标文件和构建说明是否仍可获取。	提供相关源代码及重新链接所需的材料，必要时附加安装信息。
通过可替换的共享库机制满足的条件，例如LGPL下的条件。	采用动态链接方式发货的产品。	该机制是否允许替换为接口兼容且能正常运行的修改版本。	考虑更新为可替换的配置，并提供必要的源代码及安装信息。
对组合而成的整体与独立作品的聚合体作不同处理，例如GPL下的区分。	在一个产品中作为单独的进程运行的程序。	代码的纳入与共享、程序之间调用的性质以及整体配置。	确认仅处理该OSS是否足够，还是需要针对组合后的整体范围提供源代码并修订许可条款。
针对通过远程与修改版本交互的源代码提供条件，例如AGPL下的条件。	用户与在服务器上运行的程序进行交互。	是否进行了修改、修改的范围，以及用户与之交互的程序。	向所有通过远程与该修改版本交互的用户提供免费获取相应源代码的途径，并以显著方式告知该选项。
关于提供副本时的通知、源代码或其他条件。	发送至浏览器的代码，或交付至客户环境的镜像。	实际提供的文件和版本、附带的通知以及所提供的材料。	提供与对方所收到版本相对应的补充通知及必要的源代码。

注：每一行均以第一列中的条件已经核实为前提。所列应对措施为可能采取的措施，并非需要满足的全部条件的完整说明。仅凭结合方式本身并不能确定适用范围；即使是单独的进程，也需要逐一评估。对过去缺陷的纠正和许可的恢复，应分别确认。

针对每个产品和版本，将调查结果整理为三类：适用的条件、已确认的缺陷，以及作出判断所需但尚未核实的事实。对于无法仅凭技术特征解决的事项（例如在同一产品中作为单独进程运行），应明确指出。

3 补救过去的交付，并判断今后能否继续供应

针对每一项已确认的缺陷，明确所需的应对措施。有些可通过补充通知或许可文本解决；另一些则需要提供相应源代码或考虑更换组件。仅提供最新版源代码或公司修改过的部分可能并不充分。应确认源代码是否与已交付的版本相对应、必要的构建材料是否齐全，以及必须向谁、以何种方式、在多长期间内提供。根据适用的条件，还应确认是否必须许可接收方修改或再分发该软件，以及公司自身的条款是否妨碍这些许可。

受影响的对象并不一致。应区分客户持有的设备、仍未更新的旧版本、流通库存、维修用替换部件以及待发布的更新文件。不应仅以存在更新机制为由决定应对方式；应考虑能否在不更新代码的情况下交付通知和材料。即使是可以更新的产品，对于仍未更新的版本也需要予以处理。

补救与取得今后使用的许可并不相同。应分别确认通过通知、提供源代码或更换组件已纠正了哪些内容，以及是否必须恢复已终止的许可或另行取得许可。如为商业许可证，还应核实其适用范围和效力，包括其是否涵盖过去的交付。

应根据适用许可证版本的条款，确认因违反而终止许可以及纠正后恢复许可的规定。即使存在恢复许可的规定，结果也可能取决于是否已纠正、是否及何时收到权利人的通知，以及此前通知的经过。在审查同一权利人就违反同一许可证发出的此前通知时，不应仅因其涉及不同产品或不同类型的违反而将其排除。应针对每一相关权利人分别确认恢复情况。如适用条款区分暂时恢复与永久恢复，应保留这一区别。

恢复条款中规定的期间，并不是允许在整个期间内持续违反的一般宽限期。如原始许可证未规定自动恢复，则不能仅凭该文本主张自动恢复，但可以考虑另行取得许可。

因此，应保留以下记录：终止条款是否适用；恢复条款是否适用于该终止事由；违反行为是否已按该恢复条款要求的程度得到纠正；由谁、于何时发出通知；该通知涉及的是违反的指控还是许可的终止；以及补救于何时完成。

应分别记录对过去交付的应对、许可的状态，以及提供源代码等持续性义务。然后决定是继续供应、缩小供应范围，还是暂时停止供应。即使许可得到恢复，也不会自动解决过去的责任或请求。

有关软件使用许可或补救范围的争议，请参阅“知识产权许可争议”。

4 应在何时向客户及接收方说明哪些内容

向客户进行沟通的方式，应参考合同中的通知条款和期限、客户的再供应情况以及补救所需的协作来决定。应将公司自身的许可与规范客户使用及再供应的条件分开确认。不应认为公司许可的终止会自动导致客户无法继续使用该软件。

应说明所涉及的交付版本、已确认的缺陷、正在调查的事项、补充通知和材料、要求客户采取的行动，以及下一次更新的时间。如客户正在将软件进一步提供给他人，应确认其接收方是否也需要相关信息或补充材料。不应一律采取待补救完成后再联系的方针。

5 与承包方的协作及费用分担

应确认合同中关于OSS使用和披露、保证、补偿以及协作的条款，并与组件选择和集成的记录以及公司的指示和批准进行对照。不必等待责任分配达成最终协议，即应要求对方提供与过去交付相对应的源代码和构建材料。

合同补偿请求的要件，应与债务不履行损害赔偿的要件分开审查。对于后者，还应考虑责任是否可归责于承包方，以及与损失之间的因果关系。应确认责任限制、通知和请求期限，以及费用是否须事先取得同意等要求。对承包方的请求与公司自身的补救应并行推进。

对过去交付的补救与今后供应许可的取得，必须分别对照适用条款和实际供应方式进行评估。我们就适用条件和供应方式的调查、与投诉方及权利人就补救和许可进行的谈判、对客户的说明，以及与承包方之间的责任分配提供咨询。

相关文章：收购后软件使用权受到质疑时（确认通过收购或转让取得的软件的使用权）。

Contact

提出咨询

请告知情况概要、已收到的通知及其日期，以及需要遵守的任何期限。

联系表单

我们可以通过中文电子邮件与您沟通。由于能够使用中文进行面谈的人员有限，安排面谈日程可能需要较长时间。

Related information

相关解说与业务领域

知识产权、IT与数据：概览

根据不同情况，分别介绍权利纠纷、商业秘密被带走以及系统开发和数据管理的个别指南。

知识产权、IT与数据（业务领域）

本所业务领域，涵盖知识产权的取得与运用及侵权应对、IT与系统相关合同以及数据处理。

本文仅提供一般性信息，不构成针对任何具体事项的法律意见。有关您的具体情况，请与我们咨询。内容依据最后更新日期时有效的法律法规编写。