软著申请表里最容易前后打架的 3 个字段：软件名称、版本号、开发完成日期

软著申请表里最容易前后打架的 3 个字段：软件名称、版本号、开发完成日期

说明：软著材料的具体口径以中国版权保护中心的最新要求为准。下面是我自己在整理材料时用的核对顺序，不是官方解释。

前阵子帮一个团队看材料，代码本身写得很规范，60 页也够，结果卡在了一个很不起眼的地方：申请表中的软件名称，和源代码文档页眉里的名称差了两个词。申请表写的是「XX 数据管理系统」，页眉写的是「XX 数据管理平台 V1.0」。

代码没有任何问题，但审查看的是「这一套材料是不是在说同一个软件」。名称对不上，就要补正。

从那之后我整理材料都会先做一件事：把申请表、说明书、源代码文档三份东西摊开，只核对三个字段——软件名称、版本号、开发完成日期。这三处一致了，大部分形式问题就不会出现。

一、软件名称：不是「起个好听的名字」，而是三处逐字一致

软件名称在材料里至少出现四个位置：

核对方法很笨但有效：把申请表里的全称复制出来，在另外三份材料里逐个搜索，看能不能一字不差地搜到。搜不到就是有差异，不要靠肉眼扫。

几个实际遇到过的差异类型：

• 多了或少了「V1.0」。有的材料页眉写「XX系统V1.0」，申请表只写「XX系统」。建议全称里就带上版本号，四处统一。
• 「平台 / 系统 / 软件」混用。这三个词在语义上差不多，但在材料一致性上是三个不同的名字。
• 用了内部代号。代码仓库叫 datahub-next，于是页眉也写了 datahub-next，但申请表写的是中文全称。页眉必须用申请表里的全称。
• 截图是旧版本界面。软件改过名，说明书里的截图还是旧名字，这种最容易被挑出来，因为截图是「证据」。

还有一条经验：名称不要太宽泛。「XX 管理系统」这类名字在形式审查时更容易被要求说明功能范围，写成「XX 设备巡检数据管理系统」这种带业务对象的，反而更省事。

二、版本号：从 V1.0 开始，别在材料里出现两个版本

版本号的问题通常不是「填错」，而是「填了不止一个」。

真实场景是这样的：说明书里写「本系统当前版本 V2.3」，因为开发确实迭代到 2.3 了；但申请表填的是 V1.0，因为这是第一次登记。两边都不算错，但放在一套材料里就是矛盾。

处理原则：这一次登记对应哪个版本，全套材料就只出现那个版本号。

• 申请表填 V1.0，说明书封面和页眉就写 V1.0，源代码文档页眉也写 V1.0
• 说明书正文里如果必须提到迭代历史，用「本版本」表述，不要写「当前线上版本为 V2.3」
• 后续升级如果需要单独登记，那是新的一套材料，版本号再往上走

页眉里的版本号还有个细节：V1.0 和 v1.0、V1.0.0 在形式上不是同一个字符串。选一种写法，全套统一。我一般用大写 V 加一位小数，即 V1.0。

三、开发完成日期：三个日期之间要有逻辑

材料里其实有三个时间概念，很多人只填了其中一个，或者三个互相打架：

最常见的错法是「开发完成日期」随手填了提交申请的那天。这样一旦「首次发表日期」填的是几个月前的上线日，就变成「先上线、后开发完成」。

自查动作只有一句话：把三个日期按时间轴排一遍，确认 开发完成 ≤ 首次发表 ≤ 申请提交。

如果软件确实还没对外发布，首次发表日期一栏按未发表处理，不要为了「看起来完整」硬填一个日期。未发表本身不是问题，日期矛盾才是问题。

四、把核对变成一张表，五分钟能过一遍

我现在固定用下面这张表核对，每一项都要求「能指到具体位置」，而不是「印象里是一致的」：

页眉页码那部分我在另一篇里写过具体设置方法，这里只提醒一点：页眉是每页都有的，一旦名称写错，等于 60 页全部要重出。所以名称和版本号要在生成文档之前就定下来，不要等到导出 PDF 之后再改。

五、一个省时间的顺序

整理材料最怕的是「改一处、全篇重来」。所以顺序应该是：

把「命名」放在最前面，比事后核对十遍都管用。

自查清单

• 软件全称在申请表、说明书封面、说明书页眉、源代码页眉、截图中完全一致
• 全称里是否包含版本号，且与申请表版本号一栏一致
• 版本号写法统一（大小写、小数位数）
• 开发完成日期不晚于首次发表日期
• 未发表的软件，首次发表日期一栏按未发表处理
• 页眉抽查了前 30 页和后 30 页
• 运行截图里的软件名称是当前名称

作者：信可维，整理软件著作权申请材料的格式规范与自查清单，具体口径以中国版权保护中心最新要求为准。