过去谈软件法律问题，很多企业首先想到的是“有没有软件著作权登记”。登记具有重要意义，能够在权属证明、维权谈判和诉讼中发挥作用。但在当前环境里，软件相关法律问题的复杂性已经远远不局限于软件著作权登记，而软件相关一系列问题会对企业的研发组织、产品交付、商业合作、数据流动、融资并购、出海经营和争议解决产生实质影响。

当前，软件已不再主要表现为孤立产品。一个看似普通的业务系统，背后可能同时包含自研代码、开源组件、第三方 SDK、云服务接口、低代码平台配置、客户数据、日志数据、模型参数、AI 生成代码、跨境运维链路和多个供应商的服务承诺。软件也不一定以副本形式交付给客户。在更多场景中，客户仅通过登录一个 SaaS 平台、调用一个 API、订阅一个模型能力，或者在企业微信、钉钉、飞书、微信小程序里使用某个功能。

由此，企业需要关注的问题发生了变化：过去主要问“这套软件是谁写的”，现在还要问“使用了哪些组件”“数据来源是否合法”“接口能否复用”“算法能否保密或申请专利”“客户终止合同时可以取回哪些数据和材料”“AI生成代码是否存在权利负担”“争议发生时企业能够证明哪些事实”。

当下，软件已经成为一组持续运行、持续迭代、持续调用外部资源的关键商业能力。围绕这组能力，知识产权、合同、数据合规、开源许可证、商业秘密、不正当竞争和证据规则会同时出现。

本文试图回答一个更贴近企业实务的问题：当软件成为企业经营的基础设施时，法务和业务团队应如何重新理解软件资产、使用权、合规边界和争议证据。

点击可查看大图

一、权利人到底拥有什么

许多软件相关法律争议的第一步，并不是判断谁对谁错，而是明确“软件”所包含的资产构成。

在中国法下，《计算机软件保护条例》把计算机软件定义为计算机程序及其有关文档。程序包括源程序和目标程序；同一计算机程序的源程序和目标程序被视为同一作品。条例也明确，软件著作权保护不延及开发软件所用的思想、处理过程、操作方法或者数学概念等。

上述规定在实务中具有基础性意义。它意味着，软件法律保护至少要分成几层：

点击可查看大图

第一层是代码表达。源代码、目标代码、脚本、配置代码、注释、测试用例中具有独创性的表达，主要进入著作权保护框架。

第二层是文档和界面。设计说明、API 文档、流程图、用户手册、具有独创性的UI表达，可能单独构成作品，也可能作为软件有关文档受到保护。

第三层是算法和流程。推荐算法、风控规则、调度逻辑、仿真流程、数据清洗方法、模型训练策略，本身往往不是软件著作权直接保护的对象。它们可能通过商业秘密、专利或合同获得保护。

第四层是技术方案。如果软件中的算法特征、数据处理流程或商业规则与具体技术手段结合，解决了技术问题并取得技术效果，就可能进入专利审查框架。

第五层是秘密信息。未公开源代码、核心参数、模型权重、客户化规则、数据库结构、接口协议、性能优化方法、工程经验和研发文档，都可能成为商业秘密，但前提是企业能够明确说明秘密点、商业价值和保密措施。

第六层是数据和运营利益。客户数据、日志、标注数据、平台积累的数据集合、用户关系、流量分发机制、模型能力和平台规则，在不少场景下并非传统著作权能够完整解释的对象，需要结合个人信息保护法、数据安全法、合同法和反不正当竞争法来判断。

因此，仅完成软件著作权登记并不足以覆盖软件资产治理需求。登记可以证明某一版本代码或文档的完成时间和权属线索，但不能自动证明算法属于企业商业秘密，也不能证明开源组件使用合规，更不能解决客户数据、SaaS退出或AI生成代码的权利边界。

企业需要建立一张“软件资产分层表”：哪些是公司自研表达，哪些是外部授权组件，哪些是保密技术信息，哪些是客户数据，哪些是平台生成数据，哪些仅是合同上的访问权。只有先厘清资产构成，后续的保护、交易、融资、并购和诉讼才有基础。

二、软件著作权保护表达，但“表达”和“功能”的边界并不总是清楚

软件与传统作品不同。例如小说的表达和功能通常容易区分，软件却天然具有功能性。一段代码既是程序员写下的文本表达，也是驱动机器完成任务的工具。正因为如此，软件著作权案件常常围绕一个问题展开：被复制的究竟是受保护的表达，还是不受保护的思想、方法、功能和通用规则。

美国最高法院的软件API著作权侵权纠纷案，是理解这一问题的重要案例。

案例信息

美国联邦最高法院，案号 No. 18-956，判决载于 593 U.S. 1，判决日期为2021年4月5日。结论为最高法院以特定事实下的 fair use 规则认定上诉人（一审被告）胜诉。

这起案件并不是一个简单的“复制源代码”案件。被上诉人（一审原告）认为上诉人（一审被告）在Android中复制了Java SE API的一部分，侵犯其版权。美国最高法院在判决中区分了两类代码：一种是 implementing code，即实际执行任务的实现代码；另一种是 declaring code，即把开发者输入的方法调用连接到相应任务的声明代码。上诉人（一审被告）为 Android 自行编写了大量实现代码，但在37个Java API包中复制了约11,500行声明代码及相关的包、类、方法组织结构，使熟悉Java的开发者可以在Android上沿用既有的方法调用体系。

最高法院最终认定，在该案特定事实下，上诉人（一审被告）的复制构成合理使用。判决强调了几个事实：复制内容具有较强的功能性和组织性；上诉人（一审被告）取用的是让开发者沿用既有技能所需要的部分；Android是新的智能手机平台；法院为限缩争点，假定相关API材料具有版权适格性，但没有最终解决API是否受版权保护的问题。

点击可查看大图

该案在中国企业语境下有两点启示。

第一，不能将其理解为“API可以任意复制”。本案的结论建立在美国合理使用制度、特定复制范围和特定产业背景上。中国法没有完全相同的fair use框架。企业复用接口、SDK、API文档或中间件设计时，仍需分别判断是否复制实现代码、声明代码、文档表达、组织结构，是否违反合同或许可证，是否规避技术措施，是否造成替代性竞争损害。

第二，也不能将所有接口、命名、调用方式都简单归为“软件著作权垄断”。兼容开发、互操作、标准接口、行业协议和开发者迁移，均具有正当的产业价值。过度保护接口可能阻碍兼容和创新；完全不保护又可能削弱原创平台和工具的投入激励。争议的核心，不是抽象地问“API 是否受保护”，而是回到具体事实：复制了什么，为什么复制，复制到什么程度，是否有替代实现方式，是否保留了独立开发证据。

企业开展兼容开发时，更审慎的做法通常不是让开发者直接阅读和复刻竞争对手代码，而是采用清洁室开发：一组人员基于合法公开材料和运行行为整理功能规范，另一组人员独立实现；同时保留输入材料、人员隔离、设计讨论、提交记录和测试记录。争议发生时，这些证据通常比一句“仅为兼容”更有证明力。

三、复制比例较低并不当然排除侵权风险

软件著作权案件中，另一个常见误区是用总体代码比例判断风险。研发团队有时会认为：“复制内容只占很小比例，法律风险应当较低。”但司法判断并不以总体比例作为唯一依据。

案例信息

深圳某科技公司诉杭州某科技公司计算机软件著作权纠纷。公开案例资料对当事人作匿名处理。一审法院为浙江省杭州市中级人民法院，案号（2020）浙01知民初272号；二审法院为最高人民法院，案号（2022）最高法知民终1605号。最高人民法院于2023年6月27日作出二审判决，撤销一审判决，判令停止侵权并赔偿经济损失20万元及合理开支5万元。

公开案例资料显示，在该案中，鉴定意见显示被诉软件与权利软件相同或实质性相似的代码只涉及 9 个文件，占整体代码比例约 1.085%。一审法院据此倾向于认为相似比例较低、代码较分散，不构成整体实质性相似。但最高人民法院二审改变了这一思路，认为计算机软件中能够实现相对独立功能的独创性表达可以受到保护，复制数量或比例并不当然决定侵权性质。二审最终认定侵权成立，并判令赔偿经济损失和合理开支。

点击可查看大图

这类案件对企业研发管理具有较强提示意义。判断软件侵权时，比例只是一个入口，不是结论。更关键的问题包括：被复制部分是否承担独立功能，是否体现了开发者的表达选择，是否在被诉软件中实际运行，是否属于通用代码、开源代码、标准接口或功能必需表达，是否有独立开发的过程记录。

因此，企业不能仅依赖“改变量足够大”来降低风险。所谓“重写一遍”“改变量名”“换语言实现”“拆成几个文件”等操作，并不当然消除侵权风险。如果核心结构、流程、独创性模块或特定表达仍然来自他人软件，仍可能被认定为实质性相似。

对企业而言，基础合规规则是：禁止在没有授权、没有来源说明、没有合规审查的情况下，把外部代码片段、前雇主代码、客户代码、竞品反编译代码或网络示例直接放入生产仓库。内部代码复用也要分清来源：公司自有组件、外包交付组件、第三方开源组件、员工个人历史代码、客户项目代码，法律属性并不相同。

四、算法不受著作权直接保护，但可能成为商业秘密或专利资产

讨论软件IP，算法是不可回避的问题。许多企业较高价值的资产并不是界面或普通业务代码，而是推荐逻辑、风控模型、工业仿真方法、压缩算法、调度策略或训练参数。

需要注意的是，算法本身通常更接近思想、方法、处理过程或数学概念，不能简单纳入软件著作权保护，但这并不意味着算法无法保护。它可能通过两条路径获得保护：商业秘密和专利。

商业秘密路径的优势是保护期限不固定，只要秘密性没有丧失并且企业采取了保密措施，就可以持续保护。局限在于，一旦公开或被他人独立研发、合法反向工程，权利人通常难以阻止他人使用相同思路。专利路径的优势是排他性更强，即使他人独立研发，只要落入专利权利要求范围，也可能构成侵权。局限在于必须公开技术方案，保护期限有限，还要通过新颖性、创造性、实用性和专利客体审查。

点击可查看大图

工业软件领域的高额赔偿案件说明了这种组合保护的重要性。

案例信息

公开资料通常以“离心压缩机选型”软件著作权及技术秘密侵权案指称该案。二审法院为最高人民法院知识产权法庭，案号（2022）最高法知民终1592号；公开资料显示裁判年份为2024年，二审改判赔偿额为1.66亿元。

公开资料显示，该案同时涉及软件著作权和技术秘密问题，法院围绕源代码、算法逻辑、技术文档、历史版本、研发投入和侵权获利等因素作出评价。该案的价值不只在金额，更在于它提示工业软件、仿真软件和研发设计工具的保护不能只看代码表达。较高价值通常体现为源代码背后的工程经验、参数体系、数据库结构和算法流程。

点击可查看大图

另一个值得注意的案例是北京某科技公司诉北京某智慧公司技术秘密纠纷。

案例信息

北京某科技公司诉北京某智慧公司技术秘密纠纷。公开资料对当事人作匿名处理。一审法院为北京知识产权法院，案号（2017）京73民初1259号，裁判日期为2020年6月28日；二审法院为最高人民法院，案号（2020）最高法知民终1472号，裁判日期为2021年12月20日。二审维持原判，关键意义在于明确源代码、流程、逻辑关系、算法等可分别构成相对独立的技术信息。

最高人民法院在该案中强调，计算机软件的源代码与流程、逻辑关系、算法等内容虽有相互表征关系，但通常可以构成相对独立的技术信息。当事人如果同时主张源代码和对应流程、逻辑关系、算法均构成技术秘密，应当分别明确请求保护的具体技术信息，并分别证明其符合法律保护条件。

上述分析思路对企业非常有参考价值。不少企业在商业秘密管理中倾向于把“系统源代码、算法、数据库、业务逻辑”笼统列为秘密，但在诉讼中，这种概括往往不够。企业需要提前把秘密点拆细：例如某个特定的风险评分变量组合、某套模型训练数据清洗流程、某个工业参数校准方法、某类异常工况处理规则、某个调度算法的优化路径。每一项秘密点均应能够说明“不为公众所知悉”“具有商业价值”“采取了相应保密措施”。

有关构成商业秘密的主张的成立，不是简单靠主张其为“公司机密”而能够在法律上成立的，而需要通过制度和证据证明相应信息符合秘密性、价值性和保密措施要求。源代码仓库权限、下载审批、访问日志、离职交接、外包隔离、密钥管理、生产数据脱敏、研发文档分级、模型权重访问控制，都是诉讼中证明保密措施的重要材料。

专利路径则需要另一套分析框架。中国现行专利审查框架对包含算法特征或商业规则和方法特征的发明，不宜简单割裂技术特征和算法特征，而应把权利要求记载的内容作为整体，判断其是否解决技术问题、采用技术手段并取得技术效果。换言之，算法不会仅因其被称为算法就当然被排除，但也不会因为写入计算机系统就当然具备可专利性。

2025年国家知识产权局第84号令修改《专利审查指南》，自2026年1月1日起施行。与软件企业关系密切的是，涉及人工智能、大数据等包含算法特征或商业规则和方法特征的发明专利申请，新增了对数据采集、标签管理、规则设置、推荐决策等内容的合法性、公德和公共利益审查。换言之，即使一个算法方案具有技术性，如果其数据采集方式、推荐决策或标签设计违反法律、社会公德或公共利益，也可能无法授权。

这对企业提出新的合规要求：算法专利布局不能只交给专利工程师在申请阶段“包装技术效果”，还要在研发阶段同步评估个人信息保护、数据来源合法性、歧视性标签、伦理风险和业务合规性。

五、从“购买软件”到“订阅服务”：许可、权利用尽和SaaS的分野

企业采购软件时，经常需要判断：“我们取得的是何种权利或服务？”这个问题在盒装软件时代相对直观。用户购买光盘或永久授权，取得某个软件副本及其使用权。在数字下载时代，软件副本不再依附物理载体，但仍可能存在本地安装、本地运行和永久使用。而到了SaaS时代，用户通常不取得任何软件副本，只是通过账号访问供应商托管的功能。

三种模式对应的法律关系存在显著差异。

点击可查看大图

欧盟法院二手软件转售著作权侵权纠纷案是理解永久许可和 SaaS 分野的重要案例。

案例信息

欧盟法院，案号 C-128/11，判决日期为2012年7月3日。结论为在一次性付费、永久使用软件副本的特定交易结构下，下载软件的发行权可以穷竭，但原购买者转售时须使自己的副本不可用。

原告通过网络提供软件下载，并向客户授予永久使用许可。被告从原告客户处购买“二手许可”后再转售。本案争议焦点是：软件以数字化下载方式提供、合同定性为使用许可时，是否仍可适用发行权穷竭原则。

欧盟法院认为，如果权利人以一次性费用授予客户永久使用软件副本的权利，且该费用对应软件经济价值，那么交易在经济实质上类似销售，发行权可以穷竭。原购买者在转售时必须使自己手中的副本不可用。

该结论对数字软件交易具有重要意义，但不能机械扩张到SaaS。SaaS用户通常没有取得可处分的软件副本，没有永久使用权，也无法把某个“软件副本”转售给第三方。SaaS的核心法律关系是持续服务访问、数据托管、服务等级、安全责任和退出迁移。

因此，企业采购SaaS时，不应把谈判重心放在“软件所有权”上，而应放在以下问题上：

第一，服务是否可用。供应商承诺99.9%可用性，但排除了哪些维护窗口、网络故障、第三方云故障和不可抗力？服务中断后，客户只能拿服务积分，还是可以要求赔偿实际损失？服务积分是否被约定为唯一和排他救济？

第二，数据是否可控。客户数据归谁控制？供应商能否用于训练通用模型、改进产品或进行匿名统计？终止合同时，客户能否以通用格式导出全部数据、配置、日志和附件？供应商多久删除备份？是否提供删除证明？

第三，系统能否迁移。SaaS退出时，是否提供过渡期、接口文档、数据字典、迁移协助和合理收费标准？如果供应商涨价、停服、被收购或违反安全承诺，客户是否有提前退出和迁移权？

第四，第三方风险是否透明。SaaS背后可能使用云服务商、短信服务商、支付机构、地图 API、AI模型供应商和开源组件。合同是否披露关键分包商？分包商变化是否通知？安全事故由谁负责？

点击可查看大图

综上，SaaS合同本质上并非“软件许可条款的云端版本”，而是一份持续运营合同、数据处理合同和业务连续性合同的组合。

除辨析企业取得的是软件副本、访问权还是持续服务外，SaaS采购还需要把数据流向纳入同一审查框架。境外SaaS或全球云服务通常涉及境内用户、境外供应商、云基础设施、客服和技术支持团队之间的数据传输。

跨境数据是否合规

在这一背景下，使用境外SaaS或全球云服务时，日志、账号、工单、客户数据和运维数据可能跨境流转。国家网信办2024年《促进和规范数据跨境流动规定》对不同规模个人信息出境、敏感个人信息、重要数据和关键信息基础设施运营者设定了不同路径。企业不能简单地把“采购境外SaaS”一概视为禁止，也不能忽视个人信息影响评估、单独同意、标准合同、认证或安全评估等义务。

下篇预告：

下篇将从开源软件供应链合规切入，深入剖析不同许可证的义务强度、技术架构对合规边界的影响，以及企业如何建立软件物料清单（SBOM）。随后还将探讨数据抓取的竞争法边界、AI 辅助编程的输入输出风险，以及软件争议中的证据链管理与全生命周期治理框架，为相关企业提供软件法律治理完整框架。