The Oracle-backed OpenJDK Governing Board approved an interim policy barring contributions containing content generated wholly or partly by LLMs, diffusion models, or similar systems, covering code, pull requests, emails, wiki pages, and issue reports. Contributors may still use generative AI for analysis, debugging, and review, but may not include its output in official contributions. Secondary reports attribute the restriction to intellectual-property, provenance, security, and maintainability concerns; the supplied snippets do not establish specific enforcement mechanisms, and Oracle-backed GraalVM reportedly follows a contrasting policy that permits AI-assisted contributions.
OpenJDK’s categorical exclusion of generated output challenges Scott’s position that authorship and trustworthy AI-assisted code can be established through owned intent, provenance, testing, and acceptance rather than personal typing. It creates a strong publishing and systems-design question—whether repositories should prohibit AI output outright or admit it through attestations and deterministic quality gates—while extending the policy trend already tracked for Linux and Rust.
ip:concept.authorship-without-typingip:framework.agent-provenance-stackip:concept.test-first-agent-workflowip:framework.provenance-coupled-workip:concept.execution-attestationradar:linux-drivers-llm-code-policyradar:rust-llm-contribution-policyradar:concept.open-source-maintenance
queries asked of Scott's wikis
- AI-generated code provenance and contributor attestations
- coding agents in open-source contribution workflows
- software supply-chain controls for generated code
- AI code licensing and authorship risk
- maintainability standards for agent-generated patches
- repository policy enforcement for coding assistants
2026-08-13T14:40:20Z
Repeated event-driven checks have produced no evidence that OpenJDK has enforced, operationalized, or revised the months-old interim restriction. The announcement remains established, but the enforcement hypothesis has faded without a concrete application and should reopen only on a rejected contribution or first-party policy change.
2026-08-11T13:54:04Z
The refreshed discussion is repetitive amplification and adds no evidence of enforcement, rejected contributions, operational mechanisms, practical impact, or policy revision. Keep the case event-driven pending a concrete application or first-party change to the interim rule.
2026-08-10T01:33:02Z
The additional discussion is repetitive amplification of the established interim policy, not evidence of enforcement, rejected contributions, operational mechanisms, practical impact, or revision. Keep the case event-driven pending a concrete application or first-party change to the rule.
2026-08-08T13:25:33Z
The refreshed comments are repetitive amplification, not evidence that OpenJDK has enforced, operationalized, or revised the interim restriction. Keep the case event-driven and await a rejected contribution, enforcement mechanism, or first-party policy change.
2026-08-08T12:32:11Z
The refreshed discussion is repetitive amplification of the established interim ban and adds no evidence of enforcement, rejected contributions, operational mechanisms, practical impact, or policy revision. Keep this event-driven pending a concrete application or change to the rule.
2026-08-08T11:26:42Z
The refreshed comments remain repetitive reaction and add no evidence of enforcement, rejected contributions, operational mechanisms, practical impact, or policy revision. Keep the case event-driven pending a concrete application or change to the interim rule.
2026-08-08T10:28:34Z
The refreshed discussion remains repetitive amplification and adds no evidence of enforcement, rejected contributions, operational mechanisms, practical impact, or policy revision. Keep the case event-driven pending a concrete application or change to the interim rule.
2026-08-08T09:23:31Z
The refreshed comments are repetitive reaction and add no evidence of enforcement, rejected contributions, implementation details, practical impact, or policy revision. Keep the case event-driven, awaiting operationalization or a change to the interim rule.
2026-08-08T07:25:02Z
The refreshed comments remain repetitive reaction to the established interim policy and add no evidence of enforcement, rejected contributions, implementation details, practical impact, or revision. Keep the case event-driven, awaiting operationalization or a policy change.
2026-08-08T06:28:12Z
The refreshed comments add no enforcement, rejected contribution, implementation detail, or policy revision; they are repetitive amplification of the already-established interim ban. Keep the case event-driven, awaiting evidence that OpenJDK operationalizes or changes the rule.
2026-08-08T05:28:40Z
The latest discussion remains repetitive reaction and adds no evidence of enforcement, rejected contributions, practical impact, or policy revision. The case should now be checked on an event-driven cadence for operationalization rather than recurring comment refreshes.
2026-08-08T04:29:50Z
The refreshed comments remain repetitive opinion around the established interim policy and add no evidence of enforcement, rejected contributions, practical impact, or revision. Further hourly discussion checks are unlikely to change the case; it remains a watch for operationalization.
2026-08-08T03:22:39Z
The refreshed discussion is repetitive amplification of the established interim policy and adds no evidence of enforcement, rejected contributions, practical impact, or revision. The case remains a watch for operationalization rather than commentary.
2026-08-08T02:26:44Z
The refreshed comments remain repetitive reaction to the established interim policy and add no evidence of enforcement, rejected contributions, practical impact, or revision. The case still hinges on OpenJDK operationalizing the restriction.
2026-08-08T01:23:01Z
The refreshed comments remain speculative reaction and add no evidence of enforcement, rejected contributions, practical impact, or policy revision. The case still hinges on OpenJDK operationalizing its established interim restriction.
2026-08-08T00:31:31Z
The latest comments are further reaction to the established interim policy, not evidence of enforcement, rejected contributions, practical impact, or revision. The case still hinges on OpenJDK operationalizing the restriction.
2026-08-07T23:28:44Z
The refreshed discussion remains opinion and extrapolation, with no evidence of enforcement, contributor rejection, practical impact, or policy revision. The case still depends on OpenJDK operationalizing its interim restriction.
2026-08-07T22:31:26Z
The refreshed comments remain repetitive reaction rather than evidence of enforcement, implementation, practical impact, or policy revision; the case still hinges on OpenJDK operationalizing its interim restriction.
2026-08-07T21:36:18Z
Refreshed discussion remains speculative and repetitive, adding no evidence that OpenJDK has enforced the interim policy or encountered practical consequences. The case still hinges on implementation, enforcement, or a policy revision rather than further reaction to the announcement.
2026-08-07T20:30:20Z
The first-party policy establishes a real categorical restriction, but refreshed discussion only surfaces predictable boundary questions and supplies no evidence of enforcement or practical impact. The case now rests on whether OpenJDK operationalizes the interim rule, not on further amplification of its announcement.
2026-08-07T18:28:45Z
grounded: contradicts/high — OpenJDK’s categorical exclusion of generated output challenges Scott’s position that authorship and trustworthy AI-assisted code can be established through owne
2026-08-07T18:25:51Z
origin walked (codex/luna, conf 0.98): anchor hn.story.49213754 -> echo.other.de0c8b1bf4 by OpenJDK Governing Board
2026-08-07T18:24:16Z
case created — The reported policy is a concrete, consequential restriction on AI-assisted contributions to critical open-source infrastructure, but it still needs first-party confirmation and evidence of enforcement.