开源开发语言算自主可控吗？信创项目必须搞清的四条判定线

信创讲的”自主可控”，并不要求编程语言由本国发明。Java、Python、Go、C/C++ 这些境外主导的开源开发语言，同样能通过自主可控审核，判定依据是四条可验证的线：源码可获取、依赖可审查、许可证无高风险、核心代码自主率达标。真正过不了关的项目，是”用了开源却说不清用了什么、改没改过”。

信创的自主可控看四条判定线，与编程语言是否国产无关

开源和自主可控不是对立面，真正对立的是”开源黑盒”。评审关注的从来不是语言的国籍，而是下面四条线能否说得清、验得出。

源码可获取：拿得到、编得出，才谈得上可控

自主可控的起点是源码在手。用开源语言开发的项目，语言本身的源码天然公开，风险不在这里；风险出现在交付物上——只给二进制、不给源码，或者关键模块用闭源库封装，源码拿不到，后续就没有维护和审计的余地。

依赖可审查：每一个组件都要说出出处和版本

开源语言带来的便利与隐患是同一件事：一行依赖声明就能拉进成百上千个组件。可控的前提是这些组件全部可知——名称、版本、来源、许可证、依赖关系，缺一项就算黑盒。这也是越来越多项目要求提供软件物料清单（SBOM）的原因。

许可证无高风险：传染性协议是必须绕开的线

许可证决定了代码的法律归属。GPL-3.0、AGPL-3.0 属于强传染性协议，一旦把这类代码并入商业产品再分发，整个产品可能被要求以同样的协议开源；LGPL 属于弱传染，动态链接通常可以规避；Apache-2.0、MIT、BSD 基本无传染。难点在于直接依赖往往干净，传染性协议藏在更深的传递依赖里。

核心代码自主率达标：看的是自己写了多少

部分信创项目在验收与招标环节，会要求说明核心代码自主率，即自主编写并拥有知识产权的代码占比。这个指标与语言选择无关——用 Java 还是用仓颉都不影响它；它衡量的是核心业务逻辑有没有真正掌握在自己手里。把开源组件的调用量当成自主研发来报，是常见的失分点。

开源语言项目常踩的三个坑：许可证、伪自研与版本失联

四条线看着清楚，落地时却总在同样的地方翻车。以下三种情形，在开源语言项目里出现的频率格外高。

坑一：直接依赖干净，传递依赖里藏着 GPL

项目顶层的依赖清单大多经过挑选，问题出在更深的层级。Java 生态尤其典型：Maven 中央仓库里一个看似普通的工具包，底层可能绑定 GPLv3 组件，单看直接依赖根本发现不了。只扫一层，等于没扫。

坑二：从开源项目 fork 出来删掉版权声明，成了”伪自研”

把国外开源项目整体 fork 下来、删掉原始版权声明、改个名字就宣称自研，是”伪自研”的典型形态。Apache-2.0、BSD 等协议都要求保留原始版权与许可文本，删除声明这一动作本身就构成违约，与后续是否合规无关。

坑三：上游停更或仓库不可达，组件版本失联

选用了社区已停止维护的组件，或者所依赖的境外仓库在特定环境下无法访问，都会让一个原本合规的产品失去可维护性。断供落到具体动作上，就是某个关键组件的上游没有替代、没有镜像，也没人接手。

国产编程语言的进展：仓颉开源释放了什么信号

讨论开源语言与信创，绕不开国产语言的进展。仓颉（Cangjie）是华为自研的通用编程语言，2019 年立项，2024 年 6 月在华为开发者大会首次发布，2025 年 7 月 30 日在 GitCode 开源编译器、运行时与标准库，2026 年 9 月发布 1.2.0 版本，进入稳定的迭代节奏。

仓颉的定位：面向全场景智能，与鸿蒙生态配套

官方把仓颉定位为面向全场景智能的新一代编程语言，强调原生智能化、全场景适配与强安全。鸿蒙生态同时支持 ArkTS、仓颉与 C/C++ 三种语言，三者互补；第三方库的丰富程度，仍是它能否进入生产环境的关键变量。

它说明的问题：国产语言是增量选项，不是自主可控的前提

国产语言的意义在于补齐生态短板、增加可选项，而不是把”是否使用国产语言”变成准入门槛。一个用 Go 写核心系统、但依赖完全透明、许可证干净、核心代码自主率达标的产品，比一个用了国产语言却说不清组件来源的产品更容易通过审查。语言是工具，可控性才是结论。

从标准到送测：开源代码安全评价与 SBOM 给了明确抓手

判断开源风险不再只靠经验，标准已经给出了可执行的维度。GB/T 43848-2024《网络安全技术 软件产品开源代码安全评价方法》从开源代码来源、安全质量、知识产权、管理四个维度提出评价方法，标准全文可在全国标准信息公共服务平台检索；软件物料清单（SBOM）相关国家标准统一了数据结构和文件格式，让依赖信息可以被机器读取、被第三方核验。

开源不等于免责，责任始终在使用方。《中华人民共和国数据安全法》对数据处理活动的界定，覆盖了软件交付的全过程：

“数据处理，包括数据的收集、存储、使用、加工、传输、提供、公开等。”

该法自 2021 年 9 月 1 日起施行，全文可在中国政府网查到。开源组件是别人的，出了问题责任还是自己的。

送测前要备齐的开源安全材料

把上面几条线落到交付物上，送第三方测评之前需要准备的材料大致包括以下几类：

• 开源组件台账与 SBOM：覆盖直接依赖与传递依赖，标明名称、版本与来源
• SCA（软件成分分析）报告：漏洞、许可证与组件版本一次说清
• 许可证合规说明：标明传染性协议的处理方式与替代方案
• 核心代码自主率说明：核心模块的自研边界与代码溯源依据

这些材料适合在开发阶段并行推进，不必等到验收前临时补。尚云软件测评（北京尚拓云测）提供的代码审计与安全测试服务，覆盖开源成分分析与许可证合规核查，出具的报告可直接进入信创验收的材料清单。

信创开源合规常见问题：适用范围、周期与报告效力

只用开源语言开发，信创验收会不会被判不合格？

不会因为语言本身被否决。判定看的是源码可获取、依赖可审查、许可证合规与核心代码自主率。真正会被扣分的，是依赖清单不完整或存在传染性许可证冲突。

开源成分分析报告需要提供源码吗？

两种都可以，结论精度不同。源码成分分析能识别到代码片段级别，适合排查 fork 与复制粘贴；二进制成分分析只能定位到组件与版本，适合无法提供源码的场景。两者结合，覆盖更完整。

CMA/CNAS 报告对开源合规事项有法律效力吗？

取得资质认定的机构出具的检测报告具有相应的证明效力，可用于招投标与验收材料。需要留意的是，报告只对送检版本负责，版本迭代后需针对变更部分重新送检。