Loading story…
Oracle said OpenJDK does not accept code generated by generative AI tools, citing unresolved legal and provenance issues around authorship, ownership, and compliance with the project’s contribution requirements. The project requires contributors to certify that submitted code is their own work or that they have the necessary rights to provide it, and Oracle said AI-produced output makes those assurances difficult because the origin of training data and the resulting copyright status may be unclear.
The policy, published as an interim legal position by OpenJDK, reflects broader concern in open-source development over whether AI-assisted patches can satisfy licensing and attribution obligations. Reporting on the issue also pointed to similar resistance in other projects, including NetworkManager, where maintainers reportedly rejected AI-generated patches because uncertain copyright provenance could conflict with the project’s LGPLv2.1 licensing requirements.
Track how attackers are adapting to this technology.
1 event from the most recent confirmed update back to the earliest known activity.
OpenJDK published an interim policy stating that AI-generated code contributions are not accepted because contributors must be able to certify authorship, rights, and provenance, and generative AI creates unresolved legal and licensing uncertainty.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Debian developers have opened a formal debate over whether contributions created with large language models and other generative AI tools should be banned from the project or accepted only under strict controls. Proposals under discussion would either prohibit AI-created or AI-assisted material across source packages, software, documentation, translations, web resources, and official communications, or permit such submissions if they meet requirements for legal compatibility, licensing, attribution, accountability, and disclosure. The discussion reflects broader concerns inside the project about provenance, policy compliance, and operational risk. Debian contributors have argued that developers remain responsible for package quality and licensing even when AI is used as a tool, while AI-generated code and text may introduce fabricated content, weak-quality changes, or unclear copyright status. The proposals also call for stronger scrutiny of AI-produced material, including possible disclosure in commits and documentation of provenance, amid complaints that AI-related crawling activity has also strained Debian infrastructure.
Aug 16, 2026
AI coding tools are accelerating software contribution and vulnerability remediation, but they are also expanding the volume of code that maintainers and enterprise engineering teams must validate. Open-source projects—many operating with limited funding and staff—face added exposure from AI-assisted flaw discovery and exploitation, malicious packages, incomplete software bill of materials adoption, and poor visibility into the dependencies organizations rely on. Security leaders are being urged to treat AI-generated code as disposable implementation governed by explicit requirements, specifications, and tests rather than trusting it as inherently reviewable. AI-assisted review can help identify defects, including a generated regular expression vulnerable to catastrophic backtracking and application denial of service, but it does not remove the need for governance. Recommended controls include investing in project maintenance, documentation, secure packaging, dependency inventories, fundraising, and requirements-focused review while using automated tools to remediate issues and remove obsolete code.
Sep 18, 2026
GNOME's security team changed its vulnerability-handling process by cutting the default disclosure deadline for new reports from 90 days to 30 days and by declining to forward reports to projects that prohibit AI-generated submissions. The policy shift, discussed widely on the `oss-sec` mailing list, reflects the view that most embargoed fixes are completed within the first month and that AI-assisted reporting has become common enough that many submissions now contain at least some machine-generated material. Participants also noted that some projects, including the Linux kernel, have moved away from embargoes for AI-generated reports because such findings can be easily reproduced and redistributed. The change triggered a broader dispute over open-source security governance, with maintainers arguing that low-quality, verbose, or impractical AI-assisted reports are consuming scarce triage capacity and pushing burnout onto already overstretched teams. Mailing-list contributors said many externally submitted bugs are real defects but not necessarily exploitable vulnerabilities, while others warned that rejecting accurate reports could still increase user risk. The debate expanded to the Linux Foundation's **Akrites** initiative, described by critics as an attempt to coordinate AI-era vulnerability response and potentially serve as a "maintainer of last resort" for abandoned critical packages, though others stressed that such a role would not override project ownership or maintainer authority.
Aug 6, 2026