Re: [DISCUSSION] AIAL v2 (was AI -MIT) discussion — permissive license + provenance decl arations + limited no-claim framework
Nik <[email protected]> Sun, 29 Mar 2026 23:44:32 +0300
| Newsgroups | gmane.comp.licenses.open-source.general |
|---|---|
| Message-ID | <CALoGuP2kGDsKvOFhpuHpAaMVef11S9BSMtb6Gc-we9EOmBTOtQ@mail.gmail.com> |
--===============4078873451068736050== Content-Type: multipart/alternative; boundary="000000000000cf64aa064e2fcd78" Content-Transfer-Encoding: 7bit --000000000000cf64aa064e2fcd78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Shuji-san, Perhaps this is exactly what I'd like to achieve. As a developer, I'm more interested in attribution and the technologies used than in the legal aspect. I simply assumed from the start that a license is officially part of any repository and can provide this information. And it would be interesting, perhaps even useful, to know how a particular project was created - whether by hand, with the help of AI, or whether it's entirely the product of AI agents. Nik =D0=B2=D1=81, 29 =D0=BC=D0=B0=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 16:52, Shu= ji Sado <[email protected]>: > Nik-san, > > Your three questions are not unreasonable, but I think there are more > fundamental issues before reaching them. > > 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. > More fundamentally, I am not yet convinced that this needs to be a new > license at all. > > What you seem to be trying to achieve may be better implemented through a= n > 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. > > 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. > > 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 fo= r > OSI review in the first place. > > Shuji > > 2026/3/29 0:14 Nik <[email protected]>: > >> Hello all, >> >> Thank you to everyone who commented on the earlier AI-MIT / AIAL >> submission and the subsequent discussion. >> >> I decided to start from scratch in a new thread to make it clear. >> Updated repo with current docs: >> https://github.com/aicrafted/AI-Attribution-License >> New edition of license text, provenance and faq also attached to letter. >> >> IMO the most important points from the previous thread were: >> 1. The original AI-MIT name was not appropriate and created avoidable >> confusion. >> 2. A single project-level authorship declaration is not sufficient for >> real repositories. >> 3. Per-file or per-artifact provenance may be useful as documentation, >> but it should not be treated as a conclusive legal determination. >> 4. The earlier draft also relied too heavily on hypothetical SPDX >> evolution. >> 5. The concept needs a cleaner separation between provenance disclosure >> and legal effect. >> >> Based on that feedback, considering a narrower v2 direction: >> >> - A conservative permissive license core, intentionally close in spirit >> to MIT/ISC >> - An optional provenance declaration layer, used as documentation and >> contributor representation >> - An optional contributor-limited no-claim / covenant layer for >> specifically declared generated-origin contributions >> - An explicit rule that provenance declarations: >> - do not determine legal status by themselves >> - do not negate third-party or unknown rights >> - do not expand permissions beyond the declaring contributor=E2=80=99s= own >> rights >> >> In other words, the revised direction is not a license that decides >> whether AI-generated code is public domain but rather: a permissive lice= nse >> framework that allows provenance-aware disclosure and, where expressly >> chosen, a contributor-limited no-claim posture, without pretending to >> conclusively resolve unsettled authorship law. >> >> At this point, I would like to focus on questions: >> 1. Is it preferable to keep provenance syntax entirely in a separate >> specification, rather than trying to embed those semantics directly in t= he >> license text >> 2. Does the "contributor-limited no-claim / covenant" model seem >> materially safer than the earlier "fully AI-generated =3D> public domain= " >> framing >> 3. Are there obvious pitfalls in treating `mixed`, `unknown`, and >> `inherited` as explicit conservative states that do not imply any specia= l >> legal effect >> >> Thank you again for the comments =E2=80=94 they were useful, and the goa= l here is >> to narrow the scope and address the real concerns. >> >> Best regards, >> Nik Babichev (Nik the human) >> _______________________________________________ >> 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 opensource.org email address= . >> >> License-discuss mailing list >> [email protected] >> >> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opens= ource.org >> > > > -- > Shuji Sado > Chairman, Open Source Group Japan > https://opensource.jp/ > English blog: https://shujisado.org/ > Japanese blog: https://shujisado.com/ > > _______________________________________________ > The opinions expressed in this email are those of the sender and not > necessarily those of the Open Source Initiative. Official statements by t= he > Open Source Initiative will be sent from an opensource.org email address. > > License-discuss mailing list > [email protected] > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.openso= urce.org > --000000000000cf64aa064e2fcd78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello Shuji-san,<div><br><div>Perhaps this is exactly what= I'd like to achieve.=C2=A0</div><div>As a developer, I'm more inte= rested in attribution and the technologies used than in the legal aspect. <= br>I simply assumed from the start that a license is officially part of any= repository and can provide this information. <br>And it would be interesti= ng, perhaps even useful, to know how a particular project was created -=C2= =A0</div><div>whether by hand, with the help of AI, or whether it's ent= irely the product of AI agents.</div></div><div><br></div><div>Nik</div></d= iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl= ass=3D"gmail_attr">=D0=B2=D1=81, 29 =D0=BC=D0=B0=D1=80. 2026=E2=80=AF=D0=B3= . =D0=B2 16:52, Shuji Sado <<a href=3D"mailto:[email protected]">shuji= [email protected]</a>>:<br></div><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Nik-san,<br><br>Your three questi= ons are not unreasonable, but I think there are more fundamental issues bef= ore 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 un= stable.<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, accom= panied by a separate provenance convention and, where expressly chosen, a c= ontributor-side no-claim or non-assertion statement.<br><br>I do not deny t= hat such a framework could still raise separate OSI questions. But at least= as a matter of legal design, that approach seems materially safer and simp= ler than embedding these ideas into a new standalone license.<br><br>So, to= me, the more important question comes before how to structure the provenan= ce syntax. It is whether this really needs to be a new license for OSI revi= ew in the first place.<br><br>Shuji</div><br><div class=3D"gmail_quote"><di= v dir=3D"ltr" class=3D"gmail_attr">2026/3/29 0:14 Nik <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>>:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hel= lo 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 f= rom scratch=C2=A0in a new thread to=C2=A0make=C2=A0it clear.<div>Updated re= po with current docs:=C2=A0<a href=3D"https://github.com/aicrafted/AI-Attri= bution-License" target=3D"_blank">https://github.com/aicrafted/AI-Attributi= on-License</a></div><div>New edition of license text, provenance and faq al= so attached to letter.<br><div><br>IMO the most important points from the p= revious thread were:<br>1. The original AI-MIT name was not appropriate and= created avoidable confusion. =C2=A0<br>2. A single project-level authorshi= p declaration is not sufficient for real repositories. =C2=A0<br>3. Per-fil= e or per-artifact provenance may be useful as documentation, but it should = not be treated as a conclusive legal determination.=C2=A0=C2=A0<br>4. The e= arlier draft also relied too heavily on hypothetical SPDX evolution.<br>5. = The concept needs a cleaner separation between provenance disclosure and le= gal effect.<br><br>Based on that feedback, considering a narrower v2 direct= ion:<br><br>- A conservative permissive license core, intentionally close i= n spirit to MIT/ISC<br>- An optional provenance declaration layer, used as = documentation and contributor representation<br>- An optional contributor-l= imited no-claim / covenant layer for specifically declared generated-origin= contributions<br>- An explicit rule that provenance declarations:<br>=C2= =A0 - do not determine legal status by themselves<br>=C2=A0 - do not negate= third-party or unknown rights<br>=C2=A0 - do not expand permissions beyond= the declaring contributor=E2=80=99s own rights<br><br>In other words, the = revised direction is not a license that decides whether AI-generated code i= s public domain but rather: a permissive license framework that allows prov= enance-aware disclosure and, where expressly chosen, a contributor-limited = no-claim posture, without pretending to conclusively resolve unsettled auth= orship 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 specific= ation, rather than trying to embed those semantics directly in the license = text<br>2. Does the "contributor-limited no-claim / covenant" mod= el seem materially safer than the earlier "fully AI-generated =3D> = public domain" framing<br>3. Are there obvious pitfalls in treating `m= ixed`, `unknown`, and `inherited` as explicit conservative states that do n= ot imply any special legal effect<br><br>Thank you again for the comments = =E2=80=94 they were useful, and the goal here is to narrow the scope and ad= dress the real concerns.<br><br>Best regards, =C2=A0<br>Nik Babichev (Nik t= he human)</div></div></div> _______________________________________________<br> The opinions expressed in this email are those of the sender and not necess= arily those of the Open Source Initiative. Official statements by the Open = Source Initiative will be sent from an <a href=3D"http://opensource.org" re= l=3D"noreferrer" target=3D"_blank">opensource.org</a> email address.<br> <br> License-discuss mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">L= [email protected]</a><br> <a href=3D"http://lists.opensource.org/mailman/listinfo/license-discuss_lis= ts.opensource.org" rel=3D"noreferrer" target=3D"_blank">http://lists.openso= urce.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br> </blockquote></div><div><br clear=3D"all"></div><div><br></div><span class= =3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s= ignature"><div dir=3D"ltr"><div>Shuji Sado</div><div>Chairman, Open Source = Group Japan<br><a href=3D"https://opensource.jp/" target=3D"_blank">https:/= /opensource.jp/</a><br>English blog: <a href=3D"https://shujisado.org/" tar= get=3D"_blank">https://shujisado.org/</a></div><div>Japanese blog:=C2=A0<a = href=3D"https://shujisado.com/" target=3D"_blank">https://shujisado.com/</a= ></div><div><br></div></div></div></div> _______________________________________________<br> The opinions expressed in this email are those of the sender and not necess= arily those of the Open Source Initiative. Official statements by the Open = Source Initiative will be sent from an <a href=3D"http://opensource.org" re= l=3D"noreferrer" target=3D"_blank">opensource.org</a> email address.<br> <br> License-discuss mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">L= [email protected]</a><br> <a href=3D"http://lists.opensource.org/mailman/listinfo/license-discuss_lis= ts.opensource.org" rel=3D"noreferrer" target=3D"_blank">http://lists.openso= urce.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br> </blockquote></div> --000000000000cf64aa064e2fcd78-- --===============4078873451068736050== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGhlIG9waW5p b25zIGV4cHJlc3NlZCBpbiB0aGlzIGVtYWlsIGFyZSB0aG9zZSBvZiB0aGUgc2VuZGVyIGFuZCBu b3QgbmVjZXNzYXJpbHkgdGhvc2Ugb2YgdGhlIE9wZW4gU291cmNlIEluaXRpYXRpdmUuIE9mZmlj aWFsIHN0YXRlbWVudHMgYnkgdGhlIE9wZW4gU291cmNlIEluaXRpYXRpdmUgd2lsbCBiZSBzZW50 IGZyb20gYW4gb3BlbnNvdXJjZS5vcmcgZW1haWwgYWRkcmVzcy4KCkxpY2Vuc2UtZGlzY3VzcyBt YWlsaW5nIGxpc3QKTGljZW5zZS1kaXNjdXNzQGxpc3RzLm9wZW5zb3VyY2Uub3JnCmh0dHA6Ly9s aXN0cy5vcGVuc291cmNlLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpY2Vuc2UtZGlzY3Vzc19saXN0 cy5vcGVuc291cmNlLm9yZwo= --===============4078873451068736050==--