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

[Joshua Gay]

Hi all,

I usually just lurk here, but this license proposal touches two of my pet
peeves: overreading Thaler v. Perlmutter, and treating per file notices as
if they define the scope of a licensed work.

On Thaler and "fully AI generated"

This license proposal assumes that a file labeled "fully AI generated" can
simply be treated as public domain. That conclusion seems much stronger
than current law supports.

Thaler v. Perlmutter clarified only one narrow point: a work created with
no human authorship at all is not eligible for copyright. But that case
turned on very specific facts. Thaler argued that the artwork was produced
autonomously by his system with no human creative contribution. The court
rejected the idea that the machine itself could be the author.

Stephen Thaler's "creativity machines" are neural systems designed to
generate novel patterns autonomously by letting networks interact and
produce unexpected outputs, often with noise or feedback loops. They do not
rely on prompts, large text datasets, or conversational input. This work
dates back to around 2018 and was not based on LLMs. Modern AI coding
agents are very different. They are usually LLM based systems trained on
massive corpora that generate code in response to prompts and rich context
such as existing repositories, tests, and developer instructions.

When outputs are produced through modern LLM-based workflows it becomes
much harder to characterize the result as lacking human authorship entirely.

Other sources sometimes cited in this area do not really resolve the issue
either. Zarya of the Dawn involved image outputs and a compilation
decision, not a literary work like software. The Naruto "monkey selfie"
case likewise addressed authorship of a photograph. Neither maps neatly
onto code generation workflows.

Even the US Copyright Office guidance is fairly high level and still
developing. It recognizes that human authorship may arise through
selection, arrangement, editing, or other creative control, but it does not
provide a clear framework for evaluating prompt driven or context driven
systems.

On file level rules

Relatedly, framing authorship and licensing at the level of individual
files does not reflect how software authorship actually works. Files are
implementation artifacts, not reliable boundaries of authorship nor even a
reliable way to distinguish between modular components of a work.

A "file" in the context of software is a helpful metaphor for computer
users but not a useful way to discuss a literary work in a legal sense.

Conclusion

I agree with Shuji that the threshold questions here are legal ones about
authorship and enforceability. Those probably need clearer answers before
evaluating whether a license design like this fits within the Open Source
Definition. I encourage moving this license proposal over to the
license-discuss listserv.

[In the spirit of this license, Gmail's AI tool made about 80 minor changes
to word choice and punctuation of the above and so I don't think it would
arise to a joint-authorship claim even if gmail's AI were a human]

Best,

Josh


Joshua Gay
Sr. Manager SA Open Source Community & Infrastructure
https://saopen.ieee.org
m: +1 617.966.9792
meet: https://calendly.com/jgay-ieee

On Sat, Mar 14, 2026, 3:47 AM Shuji Sado <shujisado at gmail.com> wrote:

> 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/
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260314/d80c8c2b/attachment-0001.htm>