[License-review] [SUBMISSION] AI-MIT License 1.0 — permissive license for AI-generated code

[Shuji Sado]

Hi Nik-san,

I think this proposal should receive legal review before the community
debates whether it should be approved by OSI. The threshold question is
whether it is actually consistent with the OSD.
I understand the motivation to address new issues raised by AI, but that is
the basic starting point.

In my view, AIAL-1.0 at least raises a substantial question under OSD #10,
because its Transparency clause is triggered not only by redistribution,
but also by use as input for further AI training. Its per-file and
project-level attribution requirements also seem to raise questions under
OSD #3 and #7. In addition, it is not clear how conditions derived from
copyright can be imposed in a stable way on code for which copyright may
not exist at all.

More broadly, this does not look like a matter of community preference.
It looks like a threshold question of legal validity and legal design, and
I think that should be reviewed first.

Best,
Shuji

2026/3/14 4:35 Nik <nik.sharky at gmail.com>:

> Thank you for the substantive feedback. Both points are well taken and I
> want to
> address them directly. I attach new license text according to raised
> questions and propositions.
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> POINT 1 — THE NAME
>
> You are correct that "MIT" is a registered trademark of the Massachusetts
> Institute
> of Technology, and using it in a new license name creates ambiguity at
> best and
> trademark risk at worst.
>
> It is good idea to rename it to:
>
>   AI-Attribution License (AIAL)
>
> The new name reflects what the license actually does — extends attribution
> requirements to cover AI authorship — without borrowing the MIT name.
> It is also more descriptive for developers choosing a license.
>
> The SPDX identifier would become: AIAL-1.0
>
> I welcome any alternative name suggestions from the community if there are
> objections to "AI-Attribution License" as well.
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> POINT 2 — PER-FILE ATTRIBUTION
>
> This is the more substantive point and I agree with it completely.
>
> You correctly identified that a single project-level Authorship
> Declaration is
> insufficient for any real-world project with a development history.
> Real projects can contain:
>   - files written entirely by humans (pre-AI era)
>   - files generated by AI, never touched by humans
>   - files where a human wrote 80% and AI generated 20%
>   - files inherited from third-party OSS projects
>   - files modified by multiple AI tools across multiple years
>
> A single checkbox in a root LICENSE file cannot honestly describe this mix.
>
> The solution, as you suggested (referencing APL2.0), is per-file
> attribution.
> The good news is that the ecosystem for this already exists and is widely
> adopted: the REUSE Specification (reuse.software, FSFE) combined with SPDX
> per-file headers.
>
> REUSE already defines two standard tags per file:
>
>   # SPDX-FileCopyrightText: 2026 Jane Doe
>   # SPDX-License-Identifier: GPL-3.0-or-later
>
> The revised license extends this with
> two new optional-but-recommended AI-specific SPDX tags:
>
>   SPDX-AI-Authorship: [fully-generated | ai-assisted | human-authored]
>   SPDX-AI-Tool:       [tool name and version]
>
> These tags are:
>   - Consistent with existing SPDX tag-value syntax
>   - Backward-compatible (they are optional for human-authored files where
>     no AI was involved at all)
>   - Machine-readable and scannable with standard grep/REUSE tooling
>   - Compatible with the REUSE specification — they sit alongside existing
>     SPDX-FileCopyrightText and SPDX-License-Identifier tags
>
> The project-level LICENSE file retains a simplified Authorship
> Declaration as a default/fallback for projects that have not yet adopted
> per-file headers, but per-file headers take precedence where present.
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> REVISED LICENSE — AI-Attribution License (AIAL) v1.0
>
> The revised license text is attached as AIAL-1.0.txt. Key changes:
>   1. Name changed from "AI-MIT License" to "AI-Attribution License (AIAL)"
>   2. SPDX identifier changed from AI-MIT-1.0 to AIAL-1.0
>   3. Project-level Authorship Declaration retained as fallback default
>   4. Per-file attribution via new SPDX tags defined and required for
>      files where the project-level declaration does not apply uniformly
>   5. Precedence rule: per-file tags override project-level declaration
>   6. Inherited OSS files: explicit provision for files where AI authorship
>      status is unknown (SPDX-AI-Authorship: unknown)
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> Thank you again for the careful reading. This kind of feedback is exactly
> what makes the process valuable.
>
> Nik
> nik.sharky at gmail.com
>
> пт, 13 мар. 2026 г. в 18:35, Josh Berkus <josh.berkus at opensource.org>:
>
>> On 3/12/26 5:30 PM, Nik wrote:
>> > I am submitting the AI-MIT License, Version 1.0 for OSI approval. The
>> > full license text is attached to this email as a plain text file (AI-
>> > MIT-License-1.0.txt).
>>
>> So this is interesting, but will need some iterations I think
>> (completely aside from any requirements the attorneys have).
>>
>> The first part is the name; we may not be able to call it MIT, which is
>> after all a trademark of the folks in Cambridge and this is not their
>> license.  So we might need to call it AI-Attribution or something (which
>> would be a good name considering the purpose of the license).
>>
>> The second, larger problem occurs in the actual construction of software
>> with AI assistance.  As written, this license targets only brand-new
>> projects which are created "from scratch" and never modified again.
>> This is fine for those, but I think project creators want to plan for
>> success.
>>
>> For any substantial project which has a history of development, there is
>> going to be a mix, including: files that are wholly AI-generated, files
>> which are AI-assisted, files which were written by humans, and files
>> which were inherited from other OSS projects whose licenses do not
>> require AI attribution so we don't know. Further, files which have been
>> modified several times are going to have been modified by several AI
>> tools.
>>
>> If you want to follow this concept, I really think that some kind of
>> per-file attribution (ala APL2.0) is going to be necessary, rather than
>> a single statement of authorship over the whole project.
>>
>> --
>> -- Josh Berkus
>> OSI Board Member
>>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not
> necessarily those of the Open Source Initiative. Communication from the
> Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>


-- 
Shuji Sado
Chairman, Open Source Group Japan
https://opensource.jp/
English blog: https://shujisado.org/
Japanese blog: https://shujisado.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260314/a4cc4dad/attachment-0001.htm>