software-copyright-analysis

name	software-copyright-analysis
description	软件著作权侵权分析咨询技能。 分析软件代码是否构成著作权侵权：实质性相似判断（代码比对/创意过滤/抽象测试）、 开源许可证（GPL/Apache/MIT/LGPL）传染性风险评估、软件最终用户侵权认定。 适用情形：软件著作权侵权纠纷、代码抄袭投诉、开源合规风险评估。
argument-hint	[软件类型] [涉嫌侵权行为描述] [权利代码特征]
legal_frame	cn-mainland
last_reviewed	2026-06
version	2.0.0
risk_level	medium
trigger_phrases	["软件著作权侵权","软件抄袭","代码相似","软件侵权分析","software copyright","code similarity","开源合规","software-copyright-analysis"]
legal_sources	[{"name":"中华人民共和国著作权法","effective_date":"2020-11-11","articles":"第三条（作品定义）/第十条（著作权内容）/第四十七条至第四十九条（侵权与法律责任）"},{"name":"计算机软件保护条例","effective_date":"2002-01-01","articles":"第三条（软件著作权）/第八条（软件著作权人权利）/第二十三条至第二十四条（侵权行为）"},{"name":"最高人民法院关于审理著作权民事纠纷案件适用法律若干问题的解释","effective_date":"2002-10-12","articles":"第七条（实质性相似加接触原则）/第二十一条至第二十五条（赔偿）"},{"name":"最高人民法院关于审理侵害信息网络传播权民事纠纷案件适用法律若干问题的规定","effective_date":"2012-12-17"},{"name":"计算机软件保护条例","effective_date":"2002-01-01","articles":"第三十条（最终用户责任）"}]

数据源与判断框架引用

本 skill 引用场景级配置 ../../CLAUDE.md。 来源标注规范（[YD]/[WKL]/[BD]/[GOV]/[model]）参见场景级 references/ 目录。

/software-copyright-analysis — 软件著作权侵权分析

加载上下文

首次使用时，读取 ../CLAUDE.md 获取著作权侵权判断标准和赔偿计算规则。

核心概念

软件著作权侵权判断的核心是"实质性相似+接触可能性"原则。软件保护采取"思想与表达二分法"——只保护代码的创造性表达，不保护功能/算法/操作方法等"思想"层面。开源许可证（GPL/LGPL/Apache/MIT等）对软件使用和分发施加了特定条件，违反开源许可证的条款也可能构成著作权侵权。

工作流程

第一步：著作权保护范围评估

受保护的内容：

• 源代码和目标代码
• 程序结构和组织（Sequence, Structure, Organization — SSO测试，美国判例发展出的方法，中国法院参考适用）
• 用户界面（具有独创性的部分）
• 文档和技术说明书

不受保护的内容：

• 算法和数学方法（属于"思想"层面）
• 功能和技术规范（属于"思想"层面）
• 与硬件接口兼容性要求所限定的表达（必要场景原则）
• 公用领域代码（标准函数、通用算法）

独创性门槛：

• 软件著作权要求最低限度的独创性
• 简单的功能拼凑、通用代码组合可能不满足独创性要求
• API/函数名称的简短命名组合一般不构成受保护表达

第二步：实质性相似判断 [SME 核查]

判断方法——层次分析法（借鉴美国判例的"抽象-过滤-比较"测试，中国法院在适用中参考）：

第一层：抽象（Abstraction）
├── 将软件分解为不同抽象层次（从源代码到功能描述）
├── 排除不受保护的思想层面
└── 确定受保护的表达层面

第二层：过滤（Filtration）
├── 过滤：公用领域代码、标准函数、必要表达
├── 过滤：外部因素决定的内容（接口兼容性）
└── 过滤：来自开源软件的代码（须符合相关许可）

第三层：比较（Comparison）
├── 剩余受保护的表达进行逐行/逐段比对
├── 判断是否实质性相似（整体感觉+量化分析）
└── 得出侵权结论

量化相似度参考：

相似比例	证明力	说明
>80%	极强	几乎可推定抄袭（须排除合法来源）
50-80%	较强	须结合其他证据综合判断
30-50%	中等	须有接触可能性+特定相似结构
<30%	较弱	可能属于独立开发
>85%的非文本结构相似（变量名/注释/错误）	极强	存在共同错误/原作者痕迹

第三步：接触可能性分析

推定接触的情形：

• 被控侵权方曾有机会接触权利人的软件（前员工/合作伙伴/被许可方）
• 权利人的软件已公开发布（市场/开源社区/应用商店）
• 被控侵权软件包含权利软件的独特错误（"指纹"证据）

接触证据类型：

• 雇佣关系：被控侵权方的开发人员曾是权利方员工
• 合同关系：双方有过NDA或技术合作
• 市场公开：权利软件已发布在公开渠道
• 共同错误：两份软件中出现同样的非功能性代码错误

第四步：开源许可证合规性评估 [SME 核查]

常见开源许可证及传染性：