[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-openjdk-interim-ai-policy-no-llm-code":3,"news-related-e4d0579a-1cc9-4064-a86d-a8c8e338e687":38},{"id":4,"title":5,"summary":6,"content":7,"original_url":8,"source_id":9,"tags":10,"translations":24,"news_slug":31,"published_at":32,"created_at":33,"modified_at":34,"is_published":35,"publish_type":36,"image_url":14,"view_count":37},"e4d0579a-1cc9-4064-a86d-a8c8e338e687","OpenJDK 发布生成式 AI 临时政策:零容忍,LLM 生成代码一律不准进社区贡献","OpenJDK《生成式 AI 临时政策》禁止任何由 LLM 或扩散模型\\\"全部或部分\\\"生成的内容进入社区贡献,即使 100 行 AI 写、10 行手改也算违规;仅私下用 AI 做调试与评审被允许。","# OpenJDK 发布生成式 AI 临时政策:零容忍,LLM 生成代码一律不准进社区贡献\n\n2026 年 8 月 3 日,The Register 报道,Oracle 名下的 OpenJDK 项目在官方站点 `openjdk.org\u002Flegal\u002Fai` 悄悄上线了一份《生成式 AI 临时政策》(Interim Policy on Generative AI)。政策的核心句很短、也几乎没有回旋空间:**\"OpenJDK 社区的贡献中,不得包含任何由大语言模型、扩散模型或类似深度学习系统生成的内容,无论是全部还是部分。\"** 这一条覆盖范围包含 OpenJDK 的 Git 仓库、GitHub pull request、邮件列表、wiki 页面和 JBS 工单,所有这些渠道提交的代码、文本、图片都按同一把尺子量。\n\n## 政策到底放开了什么\n\n临时政策只留出一条窄通道:贡献者可以**私下**用生成式 AI 工具来帮助理解、调试、评审 OpenJDK 现有的代码与文档,也可以拿它做与项目相关的研究,**前提是 AI 生成的内容不能落到贡献物里**。`openjdk.org\u002Flegal\u002Fai` 的 FAQ 进一步把这条线画死:如果你用生成式 AI 工具写出 100 行代码,然后亲手改掉其中 10 行,这份贡献**仍然不合规**,因为整段贡献里依然包含 AI 生成的部分。编辑器里那些传统的非 LLM 功能——拼写检查、语法检查、自动补全、重构——仍然允许,但前提是它们底层不是 LLM 或类似的深度学习模型。这份政策明确定位为\"临时\",Oracle 作为 OpenJDK 社区的企业发起方,将向 OpenJDK 治理委员会提出完整版政策,在那之前先用这份临时稿顶着。\n\n## 为什么 OpenJDK 比同行走得更远\n\n政策明确给出三条理由。第一,版权与 IP 来源:Oracle Contributor Agreement 要求贡献者拥有或能合法授予每一份贡献的知识产权,而 AI 生成内容在多数司法管辖区的版权归属仍未定论,让来源模糊的代码永久沉淀到被广泛分发的 JDK 里,会留下结构性法律风险。第二,审核者带宽:AI 生成补丁看起来\"像那么回事\"、却藏着细微缺陷,会大量吞噬本就稀缺的志愿者审核时间。第三,基础设施风险:JDK 是大量企业与政府关键系统的底层,基础性、安全敏感的代码库选择零容忍,是一种站得住脚的保守姿态。横向对比,GCC 指导委员会 7 月底给出的政策拒绝\"具有法律意义\"的 LLM 内容、按 GNU 规则设了约 15 行的阈值,留了 LLM 测试用例的裁量空间;OpenJDK 这版没有任何\"行数容忍\"或\"测试用例例外\",是迄今为止主流开源项目里最严的一份。Rust 项目在 8 月 5 日发布的生成式 AI 贡献指南则相对宽松,允许分析与评审类使用,只限制纯 AI 生成的\"创造\"。同一周,三家顶级项目各画了一条互不重叠的红线。\n\n## Oracle 自身的反差,与行业坐标\n\nThe Register 把这件事从政策脚注变成头条,靠的是 Oracle 内部的反差。联合创始人 Larry Ellison 公开发言中已经说\"AI 在替 Oracle 写代码\";联席 CEO Mike Sicilia 也把更精简的工程团队归功于 AI 工具。Oracle 今年的 AI 数据中心投入大约 700 亿美元,这笔赌注大到 S&P 把 Oracle 的信用评级下调到 BBB-,距垃圾级仅一档,理由之一就是这笔投资回报前景不确定。所以,同一家一边对投资人讲\"AI 在替我们写产品代码\"的公司,另一边却在告诉 OpenJDK 的贡献者\"社区维护的 Java 核心不接受一行 AI 生成的代码,哪怕你亲手改过也行不通\"。刻薄地读,这像\"AI 代码对我们够好,对你不够好\";善意地读,这是法律风险管理——Oracle 在 IP 诉讼史上是个凶悍的玩家(它跟 Google 那场围绕 Java API 的多年版权官司就是教科书级案例),一家有这种诉讼历史的公司,有充分动机避免在一个被广泛 fork 的社区代码库里制造\"AI 出身\"的模糊地带,也不愿意立\"人手大幅改写过就算 OK\"这种内部都解释不清的标准。\n\n同一周,Anthropic 把 Claude Code 的 auto-mode 设为 Pro、Max、Team 用户的默认,把手动审批提示换成自动权限分类器,影响数百万开发者日常编程会话。Anthropic 自己受控研究给出的数字是:人类评审员只能在大约 13.6% 的情况下抓到预设的危险命令,而 auto-mode 分类器能抓到 89%——也就是说,在这种场景下,自动化守门员比人类扫 diff 更可信。把 OpenJDK 和 Anthropic 这两条新闻并排摆,真正值得记下来的结论不是\"AI 代码糟糕\"或\"AI 代码没问题\":**对 AI 写或 AI 协助写的代码的信任,完全是语境相关的**。在公司内部产品工程里,有权限分类器、会话日志、CI 在背后兜着,AI 协助的提速是可以接受的默认选项;在社区评审、底层基础设施、每份外部补丁 IP 来源都不清晰、志愿者评审员又没法规模化扩编的环境里,同样的 AI 协助被当成独立的法律和质量负债。底层模型的能力没变,变的是谁为这段代码负责、谁可能因为它被告、谁要永远维护它。\n\n## 对贡献者的实操含义\n\n要往 OpenJDK 上游提 patch,现在的实操红线很清楚。**披露,不要伪装**:哪怕只是用 LLM 起草过一段,哪怕后来你又重写了,政策都把这笔贡献判出局。别想着\"把 AI 输出洗干净直到看起来像人写的\"——OpenJDK 的措辞(\"全部或部分\")就是为了堵这条路写的。**非 LLM 工具仍然能用**,但先确认一下 IDE 的自动补全引擎是不是 LLM 驱动的——很多现代 IDE 已经悄悄把 LLM 自动补全做成默认了。**AI 拿来做研究、做理解,可以**——分析一段堆栈、读懂一个子系统、探索一个 API——只要别让 AI 输出落到提交内容里就行。政策明确定位为\"临时\",在 OpenJDK 和 Oracle 推进完整版治理委员会政策的过程中,这条线还会动。\n\n对更大的 AI × 开源生态,OpenJDK 这条线把\"AI 安全的贡献基线\"抬高了一截。三大项目在一周里画了三条互不重叠的线,这种碎片化本身就是真正的信号:**业界还没在\"贡献里有多少 AI 算太多\"上达成共识**。每个项目都在按自己的风险偏好、诉讼历史、审核能力划线,在至少一家主要基金会发布一份能引用、可对照的共享标准之前,这种碎片化不会收敛。\n\n## 资料来源\n\n- OpenJDK — Interim Policy on Generative AI:`https:\u002F\u002Fopenjdk.org\u002Flegal\u002Fai`\n- The Register, August 3, 2026:`https:\u002F\u002Fwww.theregister.com\u002F2026\u002F08\u002F03\u002Fas-larry-ellison-bets-the-farm-oracle-says-it-loves-ai-written-code-just-not-in-openjdk\u002F`\n- explainx.ai 中文\u002F英文分析(8\u002F8):`https:\u002F\u002Fwww.explainx.ai\u002Fblog\u002Fopenjdk-bans-ai-generated-code-oracle-policy-august-2026`\n- Solidot 中文版(转载):`https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85041`","https:\u002F\u002Fopenjdk.org\u002Flegal\u002Fai","eadee57a-635e-43e1-91e9-267ff00707a3",[11,15,18,21],{"id":12,"name":13,"slug":13,"description":14,"color":14},"c33b1bbc-d6ce-4f61-9d5d-1a0704a6a09b","ai-policy",null,{"id":16,"name":17,"slug":17,"description":14,"color":14},"1fcfaaf2-67de-43d3-9e35-5784852fec60","ai-safety",{"id":19,"name":20,"slug":20,"description":14,"color":14},"01598627-1ea6-4b27-a5d8-874971571a71","llm",{"id":22,"name":23,"slug":23,"description":14,"color":14},"b9bd9039-fcdb-41a8-b85b-fc1587def2b9","open-source",[25],{"id":26,"lang":27,"title":28,"summary":29,"content":30},"24a9d35c-819c-4564-a21f-36d757e1bd0b","en","OpenJDK interim AI policy: no LLM code in contributions","OpenJDK's Interim Policy on Generative AI bans any content generated in part or in full by LLMs or diffusion models from community contributions. The rule disqualifies even patches where 10 of 100 AI-written lines are hand-edited; only private AI-assisted debugging and review are allowed.","# OpenJDK's Interim Generative AI Policy: Zero Tolerance for LLM-Generated Code in Community Contributions\n\nOn August 3, 2026, The Register reported that Oracle's OpenJDK project quietly published an Interim Policy on Generative AI on its official website at `openjdk.org\u002Flegal\u002Fai`. The policy's core sentence is short and uncompromising: *\"Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems.\"* It treats code, text, and images submitted to OpenJDK Git repositories, GitHub pull requests, mailing lists, wiki pages, and JBS issues as one surface, and it applies the same zero-tolerance bar to all of them.\n\n## What the policy actually allows\n\nThe interim text keeps one narrow lane open. Contributors may use generative AI tools privately to help comprehend, debug, and review existing OpenJDK code and to do research on the project, as long as the AI-generated content does not end up in a contribution. The FAQ at `openjdk.org\u002Flegal\u002Fai` clarifies the bar with a worked example: if a contributor uses a generative AI tool to create 100 lines of code and then hand-edits ten of those lines, the result is still ineligible, because the contribution still includes AI-generated content in part. Classic non-LLM editor features — spell-check, grammar-check, autocompletion, and refactoring — remain allowed, but only when the underlying engine is not an LLM or a similar deep-learning model. The policy was issued as an interim step; Oracle, as the corporate sponsor of the OpenJDK Community, will propose a full policy to the OpenJDK Governing Board in due course.\n\n## Why OpenJDK went further than peers\n\nThe policy names three explicit reasons. First, copyright and IP provenance: the Oracle Contributor Agreement requires a contributor to own or control the IP rights in each contribution, and the legal status of AI-generated output remains unsettled. Second, reviewer bandwidth: AI-generated patches are easy to mass-produce and look plausible while hiding subtle defects, so they consume scarce human reviewer time. Third, infrastructure risk: the JDK underpins a large share of enterprise and government systems, so OpenJDK treats zero-tolerance for AI-authored foundational code as a defensible security posture. Compared with the GCC steering committee's late-July policy that declines legally significant LLM content with a roughly 15-line threshold, OpenJDK's rule is the strictest published threshold from a major open-source project so far. Rust's August 5 generative-AI contribution guidelines took a more permissive shape, allowing analysis and review-style AI use while restricting pure AI-generated authorship — a meaningfully different cut of the same problem.\n\n## The Oracle irony, and the industry context\n\nThe Register's report made this a story rather than a policy footnote because of the contrast inside Oracle itself. Co-founder Larry Ellison has publicly said AI models now write Oracle's code; co-CEO Mike Sicilia has credited AI tools with letting smaller engineering teams ship faster. Oracle is mid-buildout on roughly 70 billion USD in AI data-center spending this year, a bet large enough that S&P downgraded Oracle's credit rating to BBB-, one notch above junk, citing uncertain returns on that investment. So the same company telling investors that AI writes its product code is telling OpenJDK contributors that the community-maintained Java core will not accept a single AI-generated line, edited or not. Read uncharitably, that looks like \"AI code is good enough for us, not good enough for you.\" Read charitably, it is legal risk management: Oracle's history as an aggressive IP litigant, including its multi-year copyright fight with Google over the Java API, gives the company a strong incentive to avoid fuzzy authorship standards in a widely-forked community tree.\n\nThe same week Anthropic made Claude Code's auto-mode the default for Pro, Max, and Team users, replacing manual approval prompts with a permission classifier for millions of developers' day-to-day sessions. Anthropic's own controlled study reported that human reviewers catch a planted dangerous command only about 13.6% of the time, versus 89% for the auto-mode classifier — an argument that automated guardrails can be more trustworthy than a human skimming a diff, not less. Put OpenJDK and Anthropic side by side and the lesson is not \"AI code is bad\" or \"AI code is fine.\" Trust in AI-written or AI-assisted code is context-dependent. Inside a single company's product engineering, with a permission classifier, session logging, and CI behind it, AI-assisted velocity is an acceptable trade-off. Inside a community-reviewed, foundational platform with unclear IP provenance on every external patch and volunteer reviewers who cannot scale, the same AI assistance is treated as a distinct legal and quality liability. The capability of the underlying models did not change; what changed is who is accountable for the code, who can be sued over it, and who has to maintain it forever.\n\n## What this means for contributors\n\nThe practical takeaways for anyone sending patches upstream are sharp. Disclose, don't disguise: if an LLM was used anywhere in drafting a patch, even for a snippet that was later rewritten, the policy considers the contribution ineligible. Don't try to \"clean up\" AI output until it looks human; OpenJDK's language — \"in part or in full\" — is written to close exactly that loophole. Non-LLM tooling stays fine, but contributors should verify whether their IDE's autocomplete engine is LLM-backed before assuming it is compliant. AI is acceptable for research and comprehension of a stack trace, a subsystem, or an API, but not for any content that ends up in the contribution. The policy is explicitly labeled interim; expect the bar to move as OpenJDK and Oracle gain more experience with full-policy drafting at the Governing Board level.\n\nFor the broader AI-and-open-source ecosystem, OpenJDK's choice raises the floor on what an \"AI-safe\" baseline contribution policy looks like. The fact that three major projects — OpenJDK, GCC, and Rust — drew three different lines within roughly a week of each other, with no two thresholds matching, is the actual signal. The industry has not converged on \"how much AI involvement in a contribution is too much.\" Each project is drawing its own line based on its own risk tolerance, litigation history, and reviewer capacity, and that fragmentation is going to stay until at least one of the major foundations publishes a shared standard that the rest can cite.\n\n## Sources\n\n- OpenJDK — Interim Policy on Generative AI: `https:\u002F\u002Fopenjdk.org\u002Flegal\u002Fai`\n- The Register, August 3, 2026: `https:\u002F\u002Fwww.theregister.com\u002F2026\u002F08\u002F03\u002Fas-larry-ellison-bets-the-farm-oracle-says-it-loves-ai-written-code-just-not-in-openjdk\u002F`\n- explainx.ai analysis (8\u002F8): `https:\u002F\u002Fwww.explainx.ai\u002Fblog\u002Fopenjdk-bans-ai-generated-code-oracle-policy-august-2026`\n- Solidot Chinese (republish): `https:\u002F\u002Fwww.solidot.org\u002Fstory?sid=85041`","openjdk-interim-ai-policy-no-llm-code","2026-08-09T02:00:00Z","2026-08-09T02:12:08.687956Z","2026-08-09T02:12:08.687970Z",true,"agent",156,{"items":39},[40,45,50,54,59,64],{"id":41,"title":42,"news_slug":43,"published_at":44},"144fa9dc-de03-4972-a695-3d392f334772","PubMed 中央库研究:2025 年生物医学论文 77% 有 LLM 写作痕迹","pubmed-77-percent-llm-writing-2025","2026-08-26T01:00:00+00:00",{"id":46,"title":47,"news_slug":48,"published_at":49},"97c97b9c-e6e4-4982-aa57-0c0da814fb19","Anthropic 的欧盟答卷四小时即被撕开：Claude 文本水印为什么怕改写","claude-synthid-70-percent-threshold-bypass","2026-08-21T08:00:00+00:00",{"id":51,"title":52,"news_slug":53,"published_at":49},"e8965513-b56f-475b-b15f-22a5ea2d2a4e","Agent 取代人成为 HF Hub 一号用户:Claude Code 占 44.4%,还有一次 4.5 天未察觉的入侵","hf-hub-agent-user-claude-code-4-5-day-intrusion",{"id":55,"title":56,"news_slug":57,"published_at":58},"1b1ecd4c-0439-4734-ac5b-b038172da8b1","Apache 比 MIT 多 37%:HF 报告拆出中美开源权重的「许可证分岔」","open-llm-licensing-divergence-hf-2026","2026-08-19T03:00:00+00:00",{"id":60,"title":61,"news_slug":62,"published_at":63},"99916419-0f68-4a6a-a4cf-8bbe353b4d75","康涅狄格法官开出美国首例 prompt injection 制裁令:法庭文件里的隐藏 LLM 暗口令","us-court-prompt-injection-sanctions","2026-08-18T03:00:00+00:00",{"id":65,"title":66,"news_slug":67,"published_at":68},"0c581f4f-468e-4272-bba3-2dcc4746e328","Suno 跟版权纠纷赛跑:8 月 6 日上线音频水印和歌词指纹化,押注「只标不评」的设计中立","suno-audio-watermarking-music-ai-policy","2026-08-17T12:30:00+00:00"]