2026年11月13日，波兰开发者Jakub T. Jankiewicz在个人博客发表千字短文，主张所有AI生成代码都应强制开源。该文在Hacker News获得968票支持、539条评论。
这触及企业回避的现实：当AI助手每天生成数亿行代码时，其法律归属未有定论。
两把刀：训练数据与版权空白
Jankiewicz的论点有两条逻辑线。
第一条关于训练数据。他指出，主流AI编程助手在海量开源代码上训练，包括采用署名式Creative Commons许可证的Stack Overflow内容。用这些集体贡献训练的模型，却生成闭源商业代码，他称之为“许可证洗白”。
第二条关于版权主体。美国版权局2025年1月发布的AI报告第二部分明确：完全由AI生成且无人类实质性创意投入的作品，不受版权保护。该结论可追溯至“猴子自拍”案——2011年猕猴拍摄的照片因拍摄者非人类，法院与版权局均裁定不受保护，归入公共领域。Wikimedia Commons现要求所有纯AI生成图片标注为公共领域。
两条逻辑叠加，Jankiewicz得出结论：开发者和企业应主动将AI生成代码以开源许可证发布，或采用CC0协议贡献至公共领域。
数据先到一步：问题已经在发生
Black Duck 2026年开源安全与风险分析报告显示，当年度审计的商业代码库中，68%存在开源许可证冲突，较上年56%上升12个百分点，创历史最大单年涨幅。部分代码库出现2675处不同许可证冲突。报告指出，AI编程助手是主要推动因素——模型生成的代码片段可能携带GPL或AGPL等强著佐权许可证的义务，但输出时不附带许可证信息。
治理缺口方面，Black Duck调查显示，76%的企业检查AI生成代码的安全风险，但仅54%评估知识产权和许可证风险，24%进行安全、质量、IP三合一全面评估。
Hacker News上的真实分歧
Jankiewicz的文章同时得罪两批高度重叠的人群。
反对意见中最有力的类比来自高赞评论：AI是工具，如同编译器。程序员的架构决策、提示词工程和代码审查，不能因最后几行由AI输出而被否定。
该类比遭到反驳：若将GPL许可的源代码输入编译器，生成的二进制文件仍受GPL约束；为何输入LLM训练后输出即可豁免？另一论点指出，并非所有开发者都能负担每月200美元订阅费，Anthropic也不支持所有国家和地区。
辩论暴露：当AI代码生成速度远超人类审查速度时，“开发者对输出内容负有实质责任”的前提已难以成立。
法律正在追赶，但还差很远
美国第九巡回上诉法院2026年2月审理Doe v. GitHub案，针对GitHub Copilot等AI编程助手是否侵犯开源许可证，截至发稿尚未宣判。该案关键问题在于AI生成的高度相似代码是否构成对训练数据的“逐字复制”。
英国法律对计算机生成作品给予有限版权保护，美国则认定此类作品不可受版权保护。Jankiewicz认为，主动采用CC0或开源许可证，是在全球法律框架收敛前实现跨司法管辖区一致性的最简洁路径。
谁在推迟这个问题
推动“AI生成代码强制开源”的最大障碍是利益结构。提供AI编程助手的大型科技公司，其商业模式依赖用户生成并保留闭源代码。要求输出物开源将削弱企业客户竞争壁垒。
大量中小型软件企业已在用AI生成代码，却无能力逐行审查许可证合规性，也无资源应对潜在诉讼。Black Duck报告中68%的许可证冲突率，主要描述了这批企业的现状。
独立判断
Jankiewicz的论点在道义上成立，但在操作上存在模糊地带——“多少比例是人写的才算人类作品”，目前无任何法律体系给出可执行定义。
更重要的结论是：强制开源可能不是唯一出路，但“什么都不做”已在制造后果。68%的许可证冲突率、仅54%的企业评估AI代码IP风险，说明当前行业默认状态是在用集体沉默积累法律敞口。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接