收购后软件使用权受到质疑时的应对

1 确定受影响的主体和活动

首先确认交易形式。在股份收购中，目标公司仍是同一法人，其作为当事人的许可通常继续有效。但需另行核查在控制权变更时要求通知或同意、或允许解除合同的条款。在业务转让中，合同地位的转让通常需要合同相对方的同意。应核查现有协议中是否已事先给予同意。在公司分立中，权利义务按照分立合同或分立计划承继，因此应核查承继范围及相关合同条款。

以下讨论和表格以股份收购为重点。对于业务转让或公司分立，应区分原合同当事人与承接业务的公司。

其次，应将目标公司既有的使用与向买方或集团公司的推广使用区分开来。确定谁将为内部使用、向客户提供、修改或其他活动而使用哪个版本或功能。交易后由同一主体继续提供，还是由其他法人接收代码，所需核查的权限和条件不同。

关于临时措施，应结合第三方的主张以及停止使用的影响，确定继续使用的法律依据以及尚未核实的事项。决定继续使用的范围、拟另行请求许可的范围以及暂停的活动。记录作出决定所依据的前提以及何时重新审视。同时保全相关资料，并核查收购协议规定的通知期限。

下表按业务活动列出了需核查的事项及需立即作出的决定。

业务活动	需核查的权利和条件	主要资料	需立即作出的决定
目标公司既有的使用及向客户提供	允许当前使用和提供的范围、期限与终止，以及尚未满足的条件。	许可协议、客户合同、正在运行或正在提供的版本，以及许可声明。	继续使用或提供的功能及对象，以及是否需要临时许可或限制。
目标公司的新销售或新提供	涵盖新客户或新交付模式的许可，以及第三方组件的条件。	计划的版本、交付方式、许可条款，以及客户合同和声明。	继续推进的新订单、发货及发布的范围，以及需要暂缓的事项。
修改、维护或更换开发方	修改及使用修改后软件、外包工作以及披露代码的许可。	开发及维护协议、源代码、变更历史，以及分包条款。	拟开始的修改、向受托方提供的资料，以及是否需要另行达成协议。
买方或集团公司的使用、开发或提供	所涵盖的主体、地域及目的；合同或许可的承继；以及再许可。	转让对象清单、许可协议，以及集团内部的转移和交付计划。	转移、共同开发及提供的范围，以及所需的同意或追加许可。

上表各行并未就能否使用给出统一的答案。既有的使用和提供也需要审查，同属一个企业集团本身并不构成使用的授权。本分析以日本法为前提；也请核查合同的准据法。

2 比对合同与实际实现，核实权利依据

卖方称著作权已转让，开发方称通用组件已被排除，如果不确定各自所指的对象，这两种说法就无法比较。首先应确定谁就哪份合同、哪些代码和哪个版本主张了什么。

将合同约定的交付物与实际交付的内容及当前的实现相对照。利用开发协议、规格书和交付物清单，确定已交付的代码和版本，并将其与收购时及当前的实现相对应。区分追加开发部分、既有的通用组件、分包商制作的部分，以及第三方库和开源软件（OSS）。与技术人员合作，确定哪些合同措辞对应实现中的哪一部分。在这一阶段，还应将收购后的追加部分与收购时已存在的问题区分开来。

将当时的记录与现在的说明相比较，找出支持、矛盾和缺失之处。按时间顺序整理开发邮件、问题跟踪记录、交付清单、验收文件和变更历史，并与相关人员的说法进行比较。核查“某项内容属于初次交付”的说法是否与交付记录一致，抑或该内容最早出现在之后的变更历史中。记录无法得出结论时，就具体项目和期间询问直接参与的人员。应将文件的存在与该文件是否支持所提出的主张区分开来。

对于权利归属存在争议的代码或其他资料，应审查对创作性表达的贡献，以及是否适用日本关于职务著作（法人等作为作者）的规则，以确定作者。需要核查的事项包括：是否基于法人等的发意、该人员是否从事其业务、是否在职务上创作，以及创作时有效的合同和就业规则。不应仅根据某人曾是员工或董事等的身份，或变更历史中出现的姓名来判断。对于计算机程序，以法人或其他雇主的名义发表并不是职务著作的要件。

以该原始归属为起点，追溯转让及其他承继，确定现在的著作权人。应将目标公司是否取得著作权与是否存在必要的许可分开考虑，并同时调查任何许可的依据。如果翻译权、改编权等权利以及关于二次作品利用的权利未被特别列明为转让对象，则推定这些权利保留于转让人。

区分“缺少文件”与“缺少权利”，并明确下一步措施。将调查结果分为已确认的权限、认定存在不足的依据，以及尚不明确的事项。然后确定需要另行取得的文件、需要其作出说明的人员，以及需要追加协议或修正条件的事项。目前找不到转让的证据，与得出未发生转让的结论是两回事。仅凭支付开发费用或持有代码，并不能证明已取得著作权或必要的许可。

3 确保使用，并区分过去使用相关的问题

核实现有许可及其他法律依据。如需进一步许可，应与有权授予许可的人商讨临时使用的范围。明确代码和版本、使用主体、提供对象、许可的行为、期限、对价，以及终止时的过渡安排。如果权利归属或过去的责任仍有争议，应区分已达成一致的事项与未解决的问题。还应明确该协议是暂时不行使请求，还是实际许可使用。

对于将来的使用，应与开发方、前员工或前董事等其他持有必要权利的人，或有权许可这些权利的主体，就转让、追加许可或类似安排达成协议。如果权利由多人分别持有，应核查与其中一人达成的协议能否确保所需范围。不仅要确定目标公司所需的使用方式，还要确定买方和集团公司所需的使用方式，包括修改、外包和向客户提供。取得著作权时，还应核查关于修改及修改后使用的权利范围；源代码和开发资料的交付应另行处理。对于修改，应考虑同一性保持权的例外以及现有协议，判断是否需要作者的同意或其他安排。没有许可权限的卖方作出的承诺，无法弥补第三方权利方面的不足。

将过去的使用与将来的许可分开处理。确保今后能够使用软件，并不一定能解决与此前使用相关的请求。还应核查这些请求的权利人是否为现在的著作权人。与有权主张这些请求的人确定期间、使用主体、代码和版本以及使用行为，并就结算应付金额或放弃请求等事项进行谈判。明确协议解决哪些请求，以及哪些权利人和请求仍在协议范围之外。

如果难以取得缺失的权利，可以考虑替换受影响的部分。与技术人员就替换范围、过渡期以及对现有客户的处理进行协作，并核实替代部分的权利和许可条件以及过渡期间的许可。仅靠替换并不能消除过去的问题；还应保存原有的实现及其历史记录。

对于OSS，应核查适用的许可证中是否有关于与收购相关的代码转移或使用方式变更的条件。履行或补正这些条件，应与文件移交以及与卖方之间的责任分配分开处理。

4 协调补救措施与对卖方的请求

将调查所确认的权利和许可，与收购协议中的陈述与保证、其基准日期以及披露事项进行比较。还应追溯收购后的修改以及使用主体的变化，准确确定实际状况与所保证的状况之间有何差异。

在与权利人等进行补救谈判之前，应核查收购协议中的通知、协商和同意条款。确定是否需要卖方同意、涵盖哪些协议，以及必须在何时发出何种通知，并将这些要求与追加许可或和解的谈判相协调。区分需要请求卖方协助的事项与需要与权利人等解决的事项。

目标公司支出的费用，买方未必能够向卖方追偿。应记录由谁、为何目的支出了费用，以及谁遭受了何种损失，然后考虑买方可以依据哪项合同条款请求什么。明确补救协议解决的范围，以及为向卖方提出请求而保留的事项。

相关文章：并购中的陈述与保证违反及补偿请求（基于违反陈述与保证提出请求的要件和限制）。

卖方与开发方说法相互矛盾，或使用条件的协议与对卖方的请求同时推进时，应将事实与谈判方针结合起来考虑。本所就调查权利归属和许可范围、确定公司立场、与权利人、开发方、前董事等其他相关人员就使用条件进行谈判，以及协调补救谈判与对卖方的请求提供法律意见。

相关业务领域：并购法律支持。

相关文章：系统开发纠纷（涉及开发经过、交付和移交的纠纷）。

Contact

提出咨询

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

联系表单

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

Related information

相关解说与业务领域

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

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

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

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

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