<div dir="ltr"><div dir="ltr">Nik-san,<br><br>Your three questions are not unreasonable, but I think there are more fundamental issues before reaching them.<br><br>This revision does seem to reduce or soften some of the fatal concerns in the earlier version. However, I still find it very difficult to see this as a viable candidate for OSI approval. A number of definitions remain unclear, and the legal mechanism itself still appears unstable.<br>More fundamentally, I am not yet convinced that this needs to be a new license at all.<br><br>What you seem to be trying to achieve may be better implemented through an MIT or Apache-style permissive license, accompanied by a separate provenance convention and, where expressly chosen, a contributor-side no-claim or non-assertion statement.<br><br>I do not deny that such a framework could still raise separate OSI questions. But at least as a matter of legal design, that approach seems materially safer and simpler than embedding these ideas into a new standalone license.<br><br>So, to me, the more important question comes before how to structure the provenance syntax. It is whether this really needs to be a new license for OSI review in the first place.<br><br>Shuji</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2026/3/29 0:14 Nik <<a href="mailto:nik.sharky@gmail.com">nik.sharky@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello all,<br><br>Thank you to everyone who commented on the earlier AI-MIT / AIAL submission and the subsequent discussion. <br><br>I decided to start from scratch in a new thread to make it clear.<div>Updated repo with current docs: <a href="https://github.com/aicrafted/AI-Attribution-License" target="_blank">https://github.com/aicrafted/AI-Attribution-License</a></div><div>New edition of license text, provenance and faq also attached to letter.<br><div><br>IMO the most important points from the previous thread were:<br>1. The original AI-MIT name was not appropriate and created avoidable confusion. <br>2. A single project-level authorship declaration is not sufficient for real repositories. <br>3. Per-file or per-artifact provenance may be useful as documentation, but it should not be treated as a conclusive legal determination. <br>4. The earlier draft also relied too heavily on hypothetical SPDX evolution.<br>5. The concept needs a cleaner separation between provenance disclosure and legal effect.<br><br>Based on that feedback, considering a narrower v2 direction:<br><br>- A conservative permissive license core, intentionally close in spirit to MIT/ISC<br>- An optional provenance declaration layer, used as documentation and contributor representation<br>- An optional contributor-limited no-claim / covenant layer for specifically declared generated-origin contributions<br>- An explicit rule that provenance declarations:<br> - do not determine legal status by themselves<br> - do not negate third-party or unknown rights<br> - do not expand permissions beyond the declaring contributor\u2019s own rights<br><br>In other words, the revised direction is not a license that decides whether AI-generated code is public domain but rather: a permissive license framework that allows provenance-aware disclosure and, where expressly chosen, a contributor-limited no-claim posture, without pretending to conclusively resolve unsettled authorship law.<br><br>At this point, I would like to focus on questions:<br>1. Is it preferable to keep provenance syntax entirely in a separate specification, rather than trying to embed those semantics directly in the license text<br>2. Does the "contributor-limited no-claim / covenant" model seem materially safer than the earlier "fully AI-generated => public domain" framing<br>3. Are there obvious pitfalls in treating `mixed`, `unknown`, and `inherited` as explicit conservative states that do not imply any special legal effect<br><br>Thank you again for the comments \u2014 they were useful, and the goal here is to narrow the scope and address the real concerns.<br><br>Best regards, <br>Nik Babichev (Nik the human)</div></div></div>
_______________________________________________<br>
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Shuji Sado</div><div>Chairman, Open Source Group Japan<br><a href="https://opensource.jp/" target="_blank">https://opensource.jp/</a><br>English blog: <a href="https://shujisado.org/" target="_blank">https://shujisado.org/</a></div><div>Japanese blog: <a href="https://shujisado.com/" target="_blank">https://shujisado.com/</a></div><div><br></div></div></div></div>