林砚舟
做过六年技术文档,擅长把散落的办事要求压成一页可执行清单,最怕含糊的「原则上」。
说实话,第一次听到「软著申请」这四个字,很多人脑子里会蹦出两种画面:一种是某个代办中介拍胸脯说包过,另一种是一堆表格和代码行数要求把人劝退。我们站就是夹在这两种想象中间的那张桌子——不卖服务,只摆事实,把能核实的写清楚,核实不了的当场标注「待核」。
我们专注的事很窄:围绕 软著申请 做信息导航与内容解析。谁在什么阶段要做什么、材料怎么算合规、代码和文档怎么对应、自办和代办差在哪、什么样的说法一听就是夸大——这些是日常选题的主轴。你不需要注册、不需要登录、不需要留电话,读完了自己判断就行。
网站由几个做过技术文档、法务助理和产品运营的编辑轮值维护,白天各自上班,晚上凑在文档里改稿。我们不接软著代办业务,也不与任何代理机构有分成关系,正因为没有立场,才敢把「这一步没必要花钱」写进正文。
如果你只是想找一份能拿去照着做的清单,那我们来对了。如果你想要有人保证「一定下证」,那这里帮不上你——登记审查由官方机构依法进行,任何宣称百分百通过的第三方说法,都值得你先打个问号。

不拿第三方背书说事,也不摆查不到的榜单。下面几项是站内可自行翻页验证的规模,主要用来告诉你:这不是一个昨天刚上线、明天就消失的空壳页。
2021 年起整理软著申请相关笔记,逐年校对更新,旧稿不删只改。
覆盖材料清单、代码规范、文档撰写、命名一致性等高频疑问。
个人开发者、软件企业、高校团队、App 上架前合规等场景各有入口。
重点回查官方页面表述是否有变化,改动的段落会标注更新说明。
内容纠错、侵权投诉、广告合作的邮件均在两个工作日内回复。
站内不提供任何代写代码、代盖章、代提交的收费服务。
以上数字仅描述本站在内容维护与响应机制上的自身规模,不构成对任何审查结果、通过率或行业排名的说明;涉及官方流程的时限与要求,请以官方公开信息为准。
每篇稿子后面都挂着具体的人,出错了也找得到。三个人各管一段,交叉复核,避免一个人拍脑袋。
做过六年技术文档,擅长把散落的办事要求压成一页可执行清单,最怕含糊的「原则上」。
法务助理出身,专盯代码行数、前后 30 页、命名一致性这类容易被忽略的细节。
盯后台邮件和评论,把用户真问的问题变成选题,负责把「听不懂」翻译成「看得懂」。
最早只是给自己团队看的软著申请备忘,整理成网页后发现每天有人搜进来,索性认真写。
删掉了所有「包过」「快速下证」类表述,改为按步骤讲材料怎么准备、怎么自查。
明确本站为信息整理站,来源公开、版权归原作者,并开通版权投诉专用邮箱。
把后台收到的真实提问归并去重,形成按场景分类的问答库,减少重复解释。
每篇稿件挂责任人,涉及流程的段落由两人交叉核对,避免单点出错。
逐段排查绝对化措辞与来源不明数字,无法核实的表述统一标注为待核或删除。
先说结论:软著申请通常指计算机软件著作权登记,由权利人向官方登记机构提交材料、经审查后取得登记证书的过程;而本站不是代办机构,只是把这件事的流程与材料讲清楚的信息整理站。我们不出具任何文件、不代交材料、不代替你签署声明。具体办理入口与最新要求,请以官方公开信息为准。
结论是:不需要注册、不需要登录、也不需要留手机号,全站文章打开即读。我们不收集办理所需的身份材料,也没有任何「提交资料换取评估」的环节。如果你在其他地方遇到要求先交身份证、源代码压缩包或盖章的页面,请先确认对方主体身份,别顺手就传。
依据是官方公开的办事说明、法规文本与我们自己核对过的材料样本,再按读者常问的顺序重排成可操作的步骤。更新节奏大约是每月两到四次,重点回查官方表述是否变动;旧稿不删,改动处会留更新说明。涉及具体时限、费用与格式的,我们只做转述并提示核对来源,不替官方下定义。
差别主要在时间成本与材料规范度,而不是「能不能过」这种说法。自己办:材料自己写、格式自己核,省钱但要花几小时甚至几天准备;找代办:省事,但要甄别对方是否正规、收费是否透明、有没有承诺绝对结果这种危险话术。判断方法很简单——凡是把「包过」「内部渠道」当卖点的,直接排除。更细的对比可以看下方深度解读一节。
高频问题集中在三处:一是源代码页数与格式,常见要求是前后各连续若干页、每页行数固定;二是说明书与代码功能对不上,写了一大堆代码里没有的模块;三是软件名称、版本号在申请表、说明书、代码页眉里写法不一致。三处都属可自查项,动手前先把命名统一,能省掉大量返工。
结论是发邮件,别在评论区等。内容纠错请发 feedback@ruanzhusq.cn,附上页面地址和你的依据;版权与侵权处理请发 copyright@ruanzhusq.cn,我们承诺 48 小时内响应,核实后会修改或下架相关内容。我们不托管、不上传任何文件,站内也不会提供盗版或破解资源。
不会推荐具体代理机构,也没有付费课程导流。广告位是独立标注的,广告主不参与内容撰写,编辑也不会因为投放关系改动结论。如果以后开放合作,我们会在页面显著位置标明「广告」字样,并把合作方与内容审核的关系写清楚,这一点先讲在前面。
信息越多,越需要一套自己的筛子。下面这些不是「秘籍」,是我们在核对材料时反复用到的判断动作,你可以直接拿去对照手里的资料。
很多人以为拿到登记证书就等于权利板上钉钉,其实登记更多是一种初步证明,用来在纠纷中降低举证难度。所以准备材料时,重点不只是「交得上」,而是「交上去的内容能不能对应你实际开发的软件」:软件名称、版本号、功能描述、代码片段要能互相印证。反过来,如果你的代码是从别人项目改的,登记本身不会改变权属,这一点在合作开发、外包交付场景里尤其要提前写清楚。
比较稳妥的自查顺序是:先统一命名,再核页数,最后对功能。命名统一指的是申请表、说明书标题、代码文件页眉三处的软件全称与简称写法一致,不要一处写「智能助手」,另一处写「智能助理系统」。页数方面,常见做法是提交源代码前、后各连续若干页,每页固定行数,不足则全部提交,并在末尾注明总页数;具体数字请按官方当期要求核对。功能方面,逐段读说明书,凡是写了「支持某某功能」的地方,回到代码里找对应模块,找不到就删掉或改写——夸大功能描述是最容易在审查中被指出来的地方。
第一看它有没有区分「必须」和「建议」。把格式要求与经验做法混在一起写、通篇用「必须」的,多半是二手转抄。第二看它敢不敢说不知道。涉及费用、时限、格式细节时,愿意写「以官方当期公布为准」并给出核对路径的,通常更可靠。第三看它有没有利益尾巴——文末突然开始推荐某家代办、附上咨询二维码的,前面的内容就要打折看。
把下面几项先在本地备好,再打开任何表格:一是软件的正式全称与版本号;二是能代表核心逻辑的源代码文件,确保没有第三方库、没有明显报错;三是与代码功能一一对应的说明书草稿;四是权利归属的说明材料(个人还是单位、是否合作开发)。这四样齐了,后面填表只是搬运。四样没齐就急着提交,返工概率很高。
凡是出现「百分百通过」「三天出证」「内部加急」这类表述,先停下来问三个问题:承诺人是谁、依据是什么、失败怎么处理。三个问题里有两个答不上来,直接放弃。审查由官方机构依法进行,任何第三方都无法替代或保证结果,这一点不需要专业知识也能判断。我们自己写稿也守着同一条线:能确认的写确认,不能确认的标「待核」,不拿模糊数字凑气势。
以下几条是本站的自我约束,也是你判断内容能否采信的依据。读正文时请把它们放在心里。
App 上架要用的软著申请材料,一次列全,含自查表。
多人合作开发的权属说明怎么写,附常见争议场景拆解。
按功能逐段对照的方法,专治「写了但没有」的老毛病。
把一周内收到的高频提问归并成文,每周四更新一次。
发现错别字、流程写旧了、想补一个场景,都欢迎写信来。我们不设在线客服,邮件是唯一渠道,但每一封都有人看。
软著申请站 · 内容编辑组