Re: [DISCUSSION] AIAL v2 (was AI -MIT) discussion — permissive license + provenance decl arations + limited no-claim framework

--===============1868146530734290125==
Content-Type: multipart/alternative; boundary="000000000000e38c36064e29b178"
Content-Transfer-Encoding: 7bit

--000000000000e38c36064e29b178
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 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.

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 for
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, bu=
t
> 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 t=
o
> 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 licen=
se
> 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 th=
e
> 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 special
> legal effect
>
> Thank you again for the comments =E2=80=94 they were useful, and the goal=
 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 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
>


--=20
Shuji Sado
Chairman, Open Source Group Japan
https://opensource.jp/
English blog: https://shujisado.org/
Japanese blog: https://shujisado.com/

--000000000000e38c36064e29b178
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Nik-san,<br><br>Your three questions are =
not unreasonable, but I think there are more fundamental issues before reac=
hing them.<br><br>This revision does seem to reduce or soften some of the f=
atal concerns in the earlier version. However, I still find it very difficu=
lt to see this as a viable candidate for OSI approval. A number of definiti=
ons 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 l=
icense at all.<br><br>What you seem to be trying to achieve may be better i=
mplemented through an MIT or Apache-style permissive license, accompanied b=
y a separate provenance convention and, where expressly chosen, a contribut=
or-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 ma=
tter 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 synta=
x. It is whether this really needs to be a new license for OSI review in th=
e first place.<br><br>Shuji</div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">2026/3/29 0:14 Nik &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&gt;:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hello a=
ll,<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=C2=A0in a new thread to=C2=A0make=C2=A0it clear.<div>Updated repo w=
ith current docs:=C2=A0<a href=3D"https://github.com/aicrafted/AI-Attributi=
on-License" target=3D"_blank">https://github.com/aicrafted/AI-Attribution-L=
icense</a></div><div>New edition of license text, provenance and faq also a=
ttached to letter.<br><div><br>IMO the most important points from the previ=
ous thread were:<br>1. The original AI-MIT name was not appropriate and cre=
ated avoidable confusion. =C2=A0<br>2. A single project-level authorship de=
claration is not sufficient for real repositories. =C2=A0<br>3. Per-file 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 earli=
er 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 sp=
irit to MIT/ISC<br>- An optional provenance declaration layer, used as docu=
mentation and contributor representation<br>- An optional contributor-limit=
ed no-claim / covenant layer for specifically declared generated-origin con=
tributions<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 d=
eclaring contributor=E2=80=99s own rights<br><br>In other words, the revise=
d direction is not a license that decides whether AI-generated code is publ=
ic domain but rather: a permissive license framework that allows provenance=
-aware disclosure and, where expressly chosen, a contributor-limited no-cla=
im 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<b=
r>2. Does the &quot;contributor-limited no-claim / covenant&quot; model see=
m materially safer than the earlier &quot;fully AI-generated =3D&gt; public=
 domain&quot; framing<br>3. Are there obvious pitfalls in treating `mixed`,=
 `unknown`, and `inherited` as explicit conservative states that do not imp=
ly 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 address =
the real concerns.<br><br>Best regards, =C2=A0<br>Nik Babichev (Nik the hum=
an)</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>

--000000000000e38c36064e29b178--


--===============1868146530734290125==
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=

--===============1868146530734290125==--