简介软件著作权申请表填写样例主要面向软件开发者、企业法务人员以及需要办理作品著作权登记的个人用于解决著作权登记申请表中栏目多、易漏填误填的问题。内容覆盖软件基本信息、著作权人信息、软件作品说明、权利说明、软件鉴别材料、软件功能和技术特点等核心模块清晰展示开发完成日期、发表状态、开发方式、权利取得方式、源程序量等字段的参考填写方式便于申报者对照实际操作降低补正和驳回概率。压缩包内共1个doc文件大小约48KB采用表格化结构呈现翻开即可找到对应栏目参考值适合初次申请或希望规范填写材料的用户使用。目前已有1389人学习可作为项目申报、材料归档和内部培训的辅助样例帮助提升软件著作权申请的一次性通过率。1. 软件著作权申请表填错一个字段拿证时间就多等一个月去版权保护中心官网申请软件著作权多数人会把精力放在准备源代码和软件说明书上直到收到补正通知才发现问题出在申请表里那几个不起眼的字段。版本号写了 V1.0.0 被退回、开发完成日期比代码仓库里最早一次提交还早、源程序量跟实际行数对不上这些都是真实的返回原因。软件著作权申请表不是简单登记一下软件叫什么它直接决定审查员第一眼读到的权属信息是否完整。开发方式是独立开发还是合作开发权利取得方式是原始取得还是继受取得这些字段背后对应的是合同、证据链和签章要求。没有提前排好后面补材料会非常被动。这篇文章以可复现的填写样例为主线把软件著作权申请表的字段规则、源程序量统计方法、与作品著作权申请表的区别讲清楚最后给一份提交前自检清单。整个软件著作权申请流程中申请表是最后才需要上传的一页却决定了前面所有准备材料的一致性命门。适合准备自己走流程的研发、运维以及要替公司搭申请模板的法务。2. 软件著作权申请表核心字段从软件全称到权利范围的填写规则2.1 软件全称与简称名称一致性是初审的第一道关软件全称要按“产品/品牌 功能/用途 软件/系统/平台”的结构来填不能只写品牌名。比如“云速协同”这种简称在申请表里不能作为全称。常见的通过写法是“云速项目协同管理软件”。全称一旦提交后续说明书封面、源代码文件头部注释页脚页码等所有材料都要保持一致。审查员会拿着全称逐页找证据哪怕说明书里出现一次不带后缀的称呼都可能触发补正。简称为可选项如果产品在市场上确实有通用简称可以填但必须是全称的有机组成部分不能是另一套名字。很多驳回是因为简称里带了商标符号、英文字母间距不一致等这类问题只要在填表时统一规格就能避免。我一般会建议客户项目的 README 第一行就直接写“软件全称XXXX”然后从 README 里复制名称避免二次输入产生差异。2.2 版本号与发布日期的写法V1.0.0 不能直接抄版本号在申请表中建议使用纯数字加点的格式例如 1.0.0 或 1.0。版权中心的电子申请表对版本号有格式校验很多人在软件安装包上写 V1.0.0就原样粘进去结果系统提示版本号格式不正确。常见做法是在版本号栏只保留 1.0.0至于软件里显示为 V1.0.0那是产品命名的事不写到申请表里。开发完成日期指软件通过测试、具备完整功能的日期不能简单填项目立项日期。首次发表日期更严格系统里如果选“已发表”需要能拿出在应用商店上架、官网发布或者线下交付的日期证据。如果软件完全没有对外发表就选择“未发表”后续不需要材料如果填写了发表日期但说明里没有对应的发表渠道基本会被打回。日期粒度要具体到日格式统一成 YYYY-MM-DD。2.3 开发方式与权利取得方式合同比文本框更能说明问题开发方式四选一独立开发、合作开发、委托开发、下达任务开发。独立开发最省事只要代码和材料是你自己的。合作开发必须附合作协议协议里要写明软件权属是共同所有还是按份所有。委托开发要附委托开发合同合同中需要明确著作权归属于委托方还是受托方。常见的坑是合同签得含糊只写了“开发内容”没写“著作权归属”到登记时无法判定审查员会要求补充说明。权利取得方式通常是原始取得或继受取得。自己写的代码、员工职务开发都是原始取得。继受取得包括继承、转让、赠与等需要上传转让合同或继承证明。值得注意的是单纯购买了软件使用权不等于取得著作权申请表里权利范围如果写“全部权利”意味着你拥有复制、发行、修改、信息网络传播等全部权项如果只买代码但没签转让协议权利范围不能按全部权利填。字段必填常见错误正确样例软件全称是只填品牌名云速项目协同管理软件版本号是写成 V1.0.01.0.0首次发表日期否填开发完成日期未发表或按发布证据填开发方式是合作开发不附协议独立开发/附协议权利范围是使用权与著作权混淆全部权利这里可以看一个最小字段样例对应提交前的数据准备{ 软件全称: 云速项目协同管理软件, 软件简称: 云速协同, 版本号: 1.0.0, 开发完成日期: 2025-03-10, 首次发表日期: 未发表, 开发方式: 独立开发, 权利取得方式: 原始取得, 权利范围: 全部权利, 编程语言: Java, 源程序量: 86254行, 主要功能与技术特点: 项目任务分配、进度跟踪、文件共享 }说明这段 JSON 是字段层面的填写样例每个字段值在提交前都要有对应证明材料。源程序量不是随便估算的下一章会给出准确统计命令编程语言填主要语言申请附件中的源代码文件应当以该语言为主。主要功能与技术特点建议控制在 100 字以内是审查员形成第一印象的地方不要写营销话术直接写功能名和业务场景。3. 从代码仓库到软件著作权申请表源程序量、完成日期与样本文件的复现方法3.1 用 cloc 统计源程序量并核对语言占比源程序量不需要数文件行数而是用 cloc 按语言类型统计。以下是当前项目根目录里的可执行命令cloc . --exclude-dirnode_modules,vendor,dist,target,.git --report-filecloc_report.txt逻辑说明cloc 会递归扫描当前目录排除依赖目录后输出 TXT 报告。--report-file参数把结果写到文件中方便后续粘贴到申请表。若项目中包含自动生成代码例如 proto 生成、API client 生成应该用--exclude-langANTLR,Gradle或直接删除后统计因为这些代码不属于人工写的源代码。不要简单地统计.git因为空目录和依赖会被计入。常见做法是把 cloc 报告中的SUM行作为源程序量填到申请表中。有些代理机构要求源代码总量不少于 50 行且含注释其实没有硬性下限但材料尽量真实。注意如果项目不是原生开发而是低代码平台导出源程序量要填平台导出的实质代码量不要填编译产物。3.2 从 Git 提交历史反推开发完成日期与首次发表日期开发完成日期可以基于 Git 提交时间来确定但要有选择。以最近一次非文档提交时间为准更贴近“功能完成”git log --pretty%cs --grepdocs:\|chore:\|build:\|CI --invert-grep -1参数说明--pretty%cs只输出提交日期--grep过滤掉文档、杂务、构建类提交--invert-grep取反-1取最近一条。这条命令的返回值就是候选的开发完成日期。接着用git tag --list --sort-creatordate | head -1确认最近发布标签该标签日期可以辅助核对首次发表日期。但标签是团队内部打的不等同于对外发表如果应用商店或官网有明确上架记录以该记录日期为准。注意Git 时间可以改所以在提交申请表前建议把该日期的不可变证据存好例如 CI 构建产物压缩包、发布工单截图。遇到“开发完成日期比立项日期早”的提示就说明日期逻辑错了。用途命令/工具输出结果源程序量clocSUM 行最近功能提交日期git log --invert-grep2025-03-10最近发布标签git tag --sort-creatordatev1.0.0前后 30 页样本Python 脚本带页码的 txt 文件3.3 生成符合格式要求的源代码前后 30 页版权保护中心要求源代码一般提交前、后各连续 30 页每页 50 行如果总量不足 3000 行则提交全部代码。这里用 Python 将所有源文件拼成按页分割的文本from pathlib import Path project_dir Path(/path/to/project) exts {.java, .xml, .properties} allowed_kws {src, main, java} # 按项目实际情况调整 pages [] code_lines [] for p in sorted(project_dir.rglob(*)): if p.suffix not in exts: continue if not any(kw in p.parts for kw in allowed_kws): continue code_lines.extend(p.read_text(encodingutf-8, errorsignore).splitlines()) pages [code_lines[i:i50] for i in range(0, len(code_lines), 50)] sample pages[:30] pages[-30:] if len(pages) 60 else pages out project_dir / rict_source_60pages.txt with out.open(w, encodingutf-8) as f: for i, page in enumerate(sample, 1): f.write(f第{i}页\n \n.join(page) \n\n) print(ftotal lines: {len(code_lines)}, pages: {len(pages)}, saved: {out})参数说明exts是按语言设置的文件后缀集合allowed_kws用来过滤掉目标目录之外的代码。errorsignore是为了防止某些文件编码问题导致脚本中断。输出文件会在每个 50 行页首加页码提交时直接打印即可。需要特别注意的是如果你只提交前后各 30 页页码标注要坚持 1-60不要真的写“第1页到第30页最后几页”这样会导致审查员无法确认材料是否连续。4. 作品著作权申请表与软件著作权申请表的差异字段映射与常见混用4.1 分类不同软件著作权申请表不要套用普通作品模板在中国版权保护中心的登记体系里“作品著作权登记申请表”和“计算机软件著作权登记申请表”是两套录入路径。普通作品按文字、美术、摄影、视听等类别划分软件则归入计算机软件类有独立的填写入口。很多第一次申请的人看到网上下载的“作品著作权申请表”模板就把软件相关信息填进去等交到大厅才发现类别不对。判断标准很简单如果申请表里有“软件全称/版本号/源程序量”这三个字段说明是软件著作权申请表如果没有就换一张表。如果地方平台只有一张“作品著作权申请表”需要先看它的作品类别里是否包含“计算机软件”选项。有的话按软件类别填写没有的话软件不能按文字作品或美术作品提交。代码不属于文字作品不要因为代码是文本就选“文字作品”。4.2 字段映射作品名称、创作完成时间与权利归属同一套业务材料用在软件著作权和作品著作权申请表里字段写法不同。以一份产品操作手册为例如果登记的是文档本身就按普通作品填作品名称写《云速项目协同管理软件操作手册》作品类别选文字作品创作完成日期写文档定稿日发表状态按是否对外发布填写。如果登记的是软件就不能再以手册为对象除了软件全称之外还要补版本号和源程序量。常见混用场景是把软件著作权申请表的“软件全称”直接填成操作手册的名称导致审查员要求在文档和代码中找出与“手册”对应的可执行程序非常难通过。字段映射如下表场景作品著作权申请表软件著作权申请表作品名称手册/图标/界面设计稿名称软件全称如云速项目协同管理软件版本一般不填1.0.0创作完成时间文档定稿日期开发完成日期发表状态已发表/未发表选择是否首次发表权利归属方式原创/职务作品/委托作品独立开发/合作开发/委托开发/下达任务开发用一段 JSON 来直观对比两个申请表在名称字段上的差异{ 软件著作权: { 作品类别: 计算机软件, 名称字段: 软件全称, 版本字段: 版本号, 样例: 云速项目协同管理软件 }, 作品著作权: { 作品类别: 文字作品, 名称字段: 作品名称, 版本字段: 版本号一般不填, 样例: 云速项目协同管理软件操作手册 } }说明JSON 里的“软件著作权”对象对应软件著作权申请表“作品著作权”对象对应普通作品登记表。两者的区别不只是字段名字变了而是审查对象和证据范围完全不同。软件著作权审查的是代码和功能文档普通作品著作权审查的是作品样本本身。所以申请前先确定要保护的是可执行程序还是配套文档/美术素材再选择对应的申请表。4.3 材料侧重点源代码、文档、样本与说明书的对应关系作品著作权申请一般提供作品样本或设计稿软件著作权申请则要求源代码和软件说明书。这里的对应关系不要搞混软件说明书不是可选材料而是用于解释软件功能和运行环境的描述性文件首页要写明软件名称和版本号而源代码是核心审查对象要能让人看出功能逻辑与说明书的对应。以操作手册为对象的作品著作权申请则不需要源代码样本页只需体现手册内容。如果软件里包含了美术图标、界面设计图想要单独保护这些元素常见做法是拆出来单独按美术作品申请作品著作权。这时申请表填的是“云速项目协同管理软件图标”作品类别是美术作品创作日期和发表日期可以与软件首版发布时间相同。不要试图把这些元素覆盖进软件著作权申请表的“主要功能与技术特点”里那样没有拆分保护的效果。等你需要维权时作品著作权登记证与软件著作权登记证在举证上各有作用但前提是申请表类型选对了。5. 提交前自检软件著作权申请表填写后必查的 7 个检查点5.1 检查清单与执行命令最后这一章给出一份可执行的自检清单按从表头到附件的顺序检查每一行都能对应到具体操作。检查项通过标准快速校验方法软件全称说明书、代码头部、申请表完全一致导出 PDF 后用 CtrlF 搜索全称三处命中版本号纯数字加小数点不含 V 字母查看申请表字段不要复制安装包文件名开发完成日期不早于首次代码提交日不晚于申请日git log 命令回查首次发表日期未发表则不填已发表有发布记录检查应用商店/官网时间源程序量与 cloc 报告一致不为空打开 cloc_report.txt 核对 SUM 行源代码样本有页码前后页连续翻看生成的 txt 文件前 10 行和后 10 行说明书首页有软件全称版本号打开文档属性查看标题填写时可以用一个 JSON 文件做字段源用 jq 做非空检查for key in 软件全称 版本号 开发完成日期 源程序量; do jq -e --arg k $key .[$k] | length 0 apply.json /dev/null 21 \ echo $key OK || echo $key MISSING done参数说明jq -e在表达式返回 false 或 null 时退出非 0所以能直接当条件判断用。--arg把 shell 变量传进 jq 表达式。这个命令只检查字段非空真正的格式校验还要用前面表格里的方法人工过一遍。5.2 被驳回后的修改路径收到补正通知后先区分是形式问题还是实质问题。形式问题常见的有版本号带 V、日期格式不对、页码排序错乱直接在系统里改对应字段再重新提交即可。实质问题包括软件全称和附件材料不一致、权利归属证明无效、源程序量统计口径不透明等这类修改需要先改齐证明材料再回头改申请表。一个很实用的技巧所有附件材料统一从同一个文本文件中生成不要手动在申请表和说明书中各抄一遍。先维护一份apply_info.json再写脚本把全称、版本号、开发完成日期批量写入说明书封面和代码头部注释这样从源头杜绝字段不一致。最后在提交前把第 3 章的 cloc 报告、git 日期查询结果和申请表的页面截图放同一个文件夹并在日期旁注明命令和参数一旦被质疑直接把那条命令的输出截图作为佐证日期就能站得住。本文还有配套的精品资源点击获取 软件著作权申请表填写必看：字段规则、源程序量与自检清单
简介软件著作权申请表填写样例主要面向软件开发者、企业法务人员以及需要办理作品著作权登记的个人用于解决著作权登记申请表中栏目多、易漏填误填的问题。内容覆盖软件基本信息、著作权人信息、软件作品说明、权利说明、软件鉴别材料、软件功能和技术特点等核心模块清晰展示开发完成日期、发表状态、开发方式、权利取得方式、源程序量等字段的参考填写方式便于申报者对照实际操作降低补正和驳回概率。压缩包内共1个doc文件大小约48KB采用表格化结构呈现翻开即可找到对应栏目参考值适合初次申请或希望规范填写材料的用户使用。目前已有1389人学习可作为项目申报、材料归档和内部培训的辅助样例帮助提升软件著作权申请的一次性通过率。1. 软件著作权申请表填错一个字段拿证时间就多等一个月去版权保护中心官网申请软件著作权多数人会把精力放在准备源代码和软件说明书上直到收到补正通知才发现问题出在申请表里那几个不起眼的字段。版本号写了 V1.0.0 被退回、开发完成日期比代码仓库里最早一次提交还早、源程序量跟实际行数对不上这些都是真实的返回原因。软件著作权申请表不是简单登记一下软件叫什么它直接决定审查员第一眼读到的权属信息是否完整。开发方式是独立开发还是合作开发权利取得方式是原始取得还是继受取得这些字段背后对应的是合同、证据链和签章要求。没有提前排好后面补材料会非常被动。这篇文章以可复现的填写样例为主线把软件著作权申请表的字段规则、源程序量统计方法、与作品著作权申请表的区别讲清楚最后给一份提交前自检清单。整个软件著作权申请流程中申请表是最后才需要上传的一页却决定了前面所有准备材料的一致性命门。适合准备自己走流程的研发、运维以及要替公司搭申请模板的法务。2. 软件著作权申请表核心字段从软件全称到权利范围的填写规则2.1 软件全称与简称名称一致性是初审的第一道关软件全称要按“产品/品牌 功能/用途 软件/系统/平台”的结构来填不能只写品牌名。比如“云速协同”这种简称在申请表里不能作为全称。常见的通过写法是“云速项目协同管理软件”。全称一旦提交后续说明书封面、源代码文件头部注释页脚页码等所有材料都要保持一致。审查员会拿着全称逐页找证据哪怕说明书里出现一次不带后缀的称呼都可能触发补正。简称为可选项如果产品在市场上确实有通用简称可以填但必须是全称的有机组成部分不能是另一套名字。很多驳回是因为简称里带了商标符号、英文字母间距不一致等这类问题只要在填表时统一规格就能避免。我一般会建议客户项目的 README 第一行就直接写“软件全称XXXX”然后从 README 里复制名称避免二次输入产生差异。2.2 版本号与发布日期的写法V1.0.0 不能直接抄版本号在申请表中建议使用纯数字加点的格式例如 1.0.0 或 1.0。版权中心的电子申请表对版本号有格式校验很多人在软件安装包上写 V1.0.0就原样粘进去结果系统提示版本号格式不正确。常见做法是在版本号栏只保留 1.0.0至于软件里显示为 V1.0.0那是产品命名的事不写到申请表里。开发完成日期指软件通过测试、具备完整功能的日期不能简单填项目立项日期。首次发表日期更严格系统里如果选“已发表”需要能拿出在应用商店上架、官网发布或者线下交付的日期证据。如果软件完全没有对外发表就选择“未发表”后续不需要材料如果填写了发表日期但说明里没有对应的发表渠道基本会被打回。日期粒度要具体到日格式统一成 YYYY-MM-DD。2.3 开发方式与权利取得方式合同比文本框更能说明问题开发方式四选一独立开发、合作开发、委托开发、下达任务开发。独立开发最省事只要代码和材料是你自己的。合作开发必须附合作协议协议里要写明软件权属是共同所有还是按份所有。委托开发要附委托开发合同合同中需要明确著作权归属于委托方还是受托方。常见的坑是合同签得含糊只写了“开发内容”没写“著作权归属”到登记时无法判定审查员会要求补充说明。权利取得方式通常是原始取得或继受取得。自己写的代码、员工职务开发都是原始取得。继受取得包括继承、转让、赠与等需要上传转让合同或继承证明。值得注意的是单纯购买了软件使用权不等于取得著作权申请表里权利范围如果写“全部权利”意味着你拥有复制、发行、修改、信息网络传播等全部权项如果只买代码但没签转让协议权利范围不能按全部权利填。字段必填常见错误正确样例软件全称是只填品牌名云速项目协同管理软件版本号是写成 V1.0.01.0.0首次发表日期否填开发完成日期未发表或按发布证据填开发方式是合作开发不附协议独立开发/附协议权利范围是使用权与著作权混淆全部权利这里可以看一个最小字段样例对应提交前的数据准备{ 软件全称: 云速项目协同管理软件, 软件简称: 云速协同, 版本号: 1.0.0, 开发完成日期: 2025-03-10, 首次发表日期: 未发表, 开发方式: 独立开发, 权利取得方式: 原始取得, 权利范围: 全部权利, 编程语言: Java, 源程序量: 86254行, 主要功能与技术特点: 项目任务分配、进度跟踪、文件共享 }说明这段 JSON 是字段层面的填写样例每个字段值在提交前都要有对应证明材料。源程序量不是随便估算的下一章会给出准确统计命令编程语言填主要语言申请附件中的源代码文件应当以该语言为主。主要功能与技术特点建议控制在 100 字以内是审查员形成第一印象的地方不要写营销话术直接写功能名和业务场景。3. 从代码仓库到软件著作权申请表源程序量、完成日期与样本文件的复现方法3.1 用 cloc 统计源程序量并核对语言占比源程序量不需要数文件行数而是用 cloc 按语言类型统计。以下是当前项目根目录里的可执行命令cloc . --exclude-dirnode_modules,vendor,dist,target,.git --report-filecloc_report.txt逻辑说明cloc 会递归扫描当前目录排除依赖目录后输出 TXT 报告。--report-file参数把结果写到文件中方便后续粘贴到申请表。若项目中包含自动生成代码例如 proto 生成、API client 生成应该用--exclude-langANTLR,Gradle或直接删除后统计因为这些代码不属于人工写的源代码。不要简单地统计.git因为空目录和依赖会被计入。常见做法是把 cloc 报告中的SUM行作为源程序量填到申请表中。有些代理机构要求源代码总量不少于 50 行且含注释其实没有硬性下限但材料尽量真实。注意如果项目不是原生开发而是低代码平台导出源程序量要填平台导出的实质代码量不要填编译产物。3.2 从 Git 提交历史反推开发完成日期与首次发表日期开发完成日期可以基于 Git 提交时间来确定但要有选择。以最近一次非文档提交时间为准更贴近“功能完成”git log --pretty%cs --grepdocs:\|chore:\|build:\|CI --invert-grep -1参数说明--pretty%cs只输出提交日期--grep过滤掉文档、杂务、构建类提交--invert-grep取反-1取最近一条。这条命令的返回值就是候选的开发完成日期。接着用git tag --list --sort-creatordate | head -1确认最近发布标签该标签日期可以辅助核对首次发表日期。但标签是团队内部打的不等同于对外发表如果应用商店或官网有明确上架记录以该记录日期为准。注意Git 时间可以改所以在提交申请表前建议把该日期的不可变证据存好例如 CI 构建产物压缩包、发布工单截图。遇到“开发完成日期比立项日期早”的提示就说明日期逻辑错了。用途命令/工具输出结果源程序量clocSUM 行最近功能提交日期git log --invert-grep2025-03-10最近发布标签git tag --sort-creatordatev1.0.0前后 30 页样本Python 脚本带页码的 txt 文件3.3 生成符合格式要求的源代码前后 30 页版权保护中心要求源代码一般提交前、后各连续 30 页每页 50 行如果总量不足 3000 行则提交全部代码。这里用 Python 将所有源文件拼成按页分割的文本from pathlib import Path project_dir Path(/path/to/project) exts {.java, .xml, .properties} allowed_kws {src, main, java} # 按项目实际情况调整 pages [] code_lines [] for p in sorted(project_dir.rglob(*)): if p.suffix not in exts: continue if not any(kw in p.parts for kw in allowed_kws): continue code_lines.extend(p.read_text(encodingutf-8, errorsignore).splitlines()) pages [code_lines[i:i50] for i in range(0, len(code_lines), 50)] sample pages[:30] pages[-30:] if len(pages) 60 else pages out project_dir / rict_source_60pages.txt with out.open(w, encodingutf-8) as f: for i, page in enumerate(sample, 1): f.write(f第{i}页\n \n.join(page) \n\n) print(ftotal lines: {len(code_lines)}, pages: {len(pages)}, saved: {out})参数说明exts是按语言设置的文件后缀集合allowed_kws用来过滤掉目标目录之外的代码。errorsignore是为了防止某些文件编码问题导致脚本中断。输出文件会在每个 50 行页首加页码提交时直接打印即可。需要特别注意的是如果你只提交前后各 30 页页码标注要坚持 1-60不要真的写“第1页到第30页最后几页”这样会导致审查员无法确认材料是否连续。4. 作品著作权申请表与软件著作权申请表的差异字段映射与常见混用4.1 分类不同软件著作权申请表不要套用普通作品模板在中国版权保护中心的登记体系里“作品著作权登记申请表”和“计算机软件著作权登记申请表”是两套录入路径。普通作品按文字、美术、摄影、视听等类别划分软件则归入计算机软件类有独立的填写入口。很多第一次申请的人看到网上下载的“作品著作权申请表”模板就把软件相关信息填进去等交到大厅才发现类别不对。判断标准很简单如果申请表里有“软件全称/版本号/源程序量”这三个字段说明是软件著作权申请表如果没有就换一张表。如果地方平台只有一张“作品著作权申请表”需要先看它的作品类别里是否包含“计算机软件”选项。有的话按软件类别填写没有的话软件不能按文字作品或美术作品提交。代码不属于文字作品不要因为代码是文本就选“文字作品”。4.2 字段映射作品名称、创作完成时间与权利归属同一套业务材料用在软件著作权和作品著作权申请表里字段写法不同。以一份产品操作手册为例如果登记的是文档本身就按普通作品填作品名称写《云速项目协同管理软件操作手册》作品类别选文字作品创作完成日期写文档定稿日发表状态按是否对外发布填写。如果登记的是软件就不能再以手册为对象除了软件全称之外还要补版本号和源程序量。常见混用场景是把软件著作权申请表的“软件全称”直接填成操作手册的名称导致审查员要求在文档和代码中找出与“手册”对应的可执行程序非常难通过。字段映射如下表场景作品著作权申请表软件著作权申请表作品名称手册/图标/界面设计稿名称软件全称如云速项目协同管理软件版本一般不填1.0.0创作完成时间文档定稿日期开发完成日期发表状态已发表/未发表选择是否首次发表权利归属方式原创/职务作品/委托作品独立开发/合作开发/委托开发/下达任务开发用一段 JSON 来直观对比两个申请表在名称字段上的差异{ 软件著作权: { 作品类别: 计算机软件, 名称字段: 软件全称, 版本字段: 版本号, 样例: 云速项目协同管理软件 }, 作品著作权: { 作品类别: 文字作品, 名称字段: 作品名称, 版本字段: 版本号一般不填, 样例: 云速项目协同管理软件操作手册 } }说明JSON 里的“软件著作权”对象对应软件著作权申请表“作品著作权”对象对应普通作品登记表。两者的区别不只是字段名字变了而是审查对象和证据范围完全不同。软件著作权审查的是代码和功能文档普通作品著作权审查的是作品样本本身。所以申请前先确定要保护的是可执行程序还是配套文档/美术素材再选择对应的申请表。4.3 材料侧重点源代码、文档、样本与说明书的对应关系作品著作权申请一般提供作品样本或设计稿软件著作权申请则要求源代码和软件说明书。这里的对应关系不要搞混软件说明书不是可选材料而是用于解释软件功能和运行环境的描述性文件首页要写明软件名称和版本号而源代码是核心审查对象要能让人看出功能逻辑与说明书的对应。以操作手册为对象的作品著作权申请则不需要源代码样本页只需体现手册内容。如果软件里包含了美术图标、界面设计图想要单独保护这些元素常见做法是拆出来单独按美术作品申请作品著作权。这时申请表填的是“云速项目协同管理软件图标”作品类别是美术作品创作日期和发表日期可以与软件首版发布时间相同。不要试图把这些元素覆盖进软件著作权申请表的“主要功能与技术特点”里那样没有拆分保护的效果。等你需要维权时作品著作权登记证与软件著作权登记证在举证上各有作用但前提是申请表类型选对了。5. 提交前自检软件著作权申请表填写后必查的 7 个检查点5.1 检查清单与执行命令最后这一章给出一份可执行的自检清单按从表头到附件的顺序检查每一行都能对应到具体操作。检查项通过标准快速校验方法软件全称说明书、代码头部、申请表完全一致导出 PDF 后用 CtrlF 搜索全称三处命中版本号纯数字加小数点不含 V 字母查看申请表字段不要复制安装包文件名开发完成日期不早于首次代码提交日不晚于申请日git log 命令回查首次发表日期未发表则不填已发表有发布记录检查应用商店/官网时间源程序量与 cloc 报告一致不为空打开 cloc_report.txt 核对 SUM 行源代码样本有页码前后页连续翻看生成的 txt 文件前 10 行和后 10 行说明书首页有软件全称版本号打开文档属性查看标题填写时可以用一个 JSON 文件做字段源用 jq 做非空检查for key in 软件全称 版本号 开发完成日期 源程序量; do jq -e --arg k $key .[$k] | length 0 apply.json /dev/null 21 \ echo $key OK || echo $key MISSING done参数说明jq -e在表达式返回 false 或 null 时退出非 0所以能直接当条件判断用。--arg把 shell 变量传进 jq 表达式。这个命令只检查字段非空真正的格式校验还要用前面表格里的方法人工过一遍。5.2 被驳回后的修改路径收到补正通知后先区分是形式问题还是实质问题。形式问题常见的有版本号带 V、日期格式不对、页码排序错乱直接在系统里改对应字段再重新提交即可。实质问题包括软件全称和附件材料不一致、权利归属证明无效、源程序量统计口径不透明等这类修改需要先改齐证明材料再回头改申请表。一个很实用的技巧所有附件材料统一从同一个文本文件中生成不要手动在申请表和说明书中各抄一遍。先维护一份apply_info.json再写脚本把全称、版本号、开发完成日期批量写入说明书封面和代码头部注释这样从源头杜绝字段不一致。最后在提交前把第 3 章的 cloc 报告、git 日期查询结果和申请表的页面截图放同一个文件夹并在日期旁注明命令和参数一旦被质疑直接把那条命令的输出截图作为佐证日期就能站得住。本文还有配套的精品资源点击获取