<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Nik,</p>
    <p>You can't change a license while it's being considered, it makes
      it a nightmare for the license committee and its recordkeeping.
      The proper approach is to withdraw the previous version and
      resubmit a newer version. But before you do that I would suggest
      waiting some more for more comments, because there may be other
      ways in which you want to change it, so you can do it
      cumulatively. I've also seen a suggestion that it should be
      discussed on the license-discuss list, instead of the
      license-review list, given the novelty of the concept, so you
      might want to see where that goes. The license review process is
      by consensus and people contributing on their spare time, so you
      need to give adequate time for feedback.</p>
    <p>Pam</p>
    <div class="moz-signature">Pamela S. Chestek<br>
      Chestek Legal<br>
      4641 Post St.<br>
      Unit 4316<br>
      El Dorado Hills, CA 95762<br>
      +1 919-800-8033<br>
      <a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
      <a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
      <br>
      <br>
    </div>
    <div class="moz-cite-prefix">On 3/13/2026 11:54 AM, Nik wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CALoGuP33x+Egm5aV6V0a52FgT=Xh-wjtp=g2w9P_yYZg2JzN8g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Thank you for the substantive feedback. Both points
        are well taken and I want to<br>
        address them directly. I attach new license text according to
        raised questions and propositions.<br>
        <br>
        \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501<br>
        <br>
        POINT 1 \u2014 THE NAME<br>
        <br>
        You are correct that "MIT" is a registered trademark of the
        Massachusetts Institute<br>
        of Technology, and using it in a new license name creates
        ambiguity at best and<br>
        trademark risk at worst.<br>
        <br>
        It is good idea to rename it to:<br>
        <br>
          AI-Attribution License (AIAL)<br>
        <br>
        The new name reflects what the license actually does \u2014 extends
        attribution<br>
        requirements to cover AI authorship \u2014 without borrowing the MIT
        name. <br>
        It is also more descriptive for developers choosing a license.<br>
        <br>
        The SPDX identifier would become: AIAL-1.0<br>
        <br>
        I welcome any alternative name suggestions from the community if
        there are<br>
        objections to "AI-Attribution License" as well.<br>
        <br>
        \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501<br>
        <br>
        POINT 2 \u2014 PER-FILE ATTRIBUTION<br>
        <br>
        This is the more substantive point and I agree with it
        completely.<br>
        <br>
        You correctly identified that a single project-level Authorship
        Declaration is<br>
        insufficient for any real-world project with a development
        history. <br>
        Real projects can contain:<br>
          - files written entirely by humans (pre-AI era)<br>
          - files generated by AI, never touched by humans<br>
          - files where a human wrote 80% and AI generated 20%<br>
          - files inherited from third-party OSS projects<br>
          - files modified by multiple AI tools across multiple years<br>
        <br>
        A single checkbox in a root LICENSE file cannot honestly
        describe this mix.<br>
        <br>
        The solution, as you suggested (referencing APL2.0), is per-file
        attribution.<br>
        The good news is that the ecosystem for this already exists and
        is widely<br>
        adopted: the REUSE Specification (reuse.software, FSFE) combined
        with SPDX<br>
        per-file headers.<br>
        <br>
        REUSE already defines two standard tags per file:<br>
        <br>
          # SPDX-FileCopyrightText: 2026 Jane Doe<br>
          # SPDX-License-Identifier: GPL-3.0-or-later<br>
        <br>
        The revised license extends this with <br>
        two new optional-but-recommended AI-specific SPDX tags:<br>
        <br>
          SPDX-AI-Authorship: [fully-generated | ai-assisted |
        human-authored]<br>
          SPDX-AI-Tool:       [tool name and version]<br>
        <br>
        These tags are:<br>
          - Consistent with existing SPDX tag-value syntax<br>
          - Backward-compatible (they are optional for human-authored
        files where<br>
            no AI was involved at all)<br>
          - Machine-readable and scannable with standard grep/REUSE
        tooling<br>
          - Compatible with the REUSE specification \u2014 they sit alongside
        existing<br>
            SPDX-FileCopyrightText and SPDX-License-Identifier tags<br>
        <br>
        The project-level LICENSE file retains a simplified Authorship<br>
        Declaration as a default/fallback for projects that have not yet
        adopted<br>
        per-file headers, but per-file headers take precedence where
        present.<br>
        <br>
        \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501<br>
        <br>
        REVISED LICENSE \u2014 AI-Attribution License (AIAL) v1.0<br>
        <br>
        The revised license text is attached as AIAL-1.0.txt. Key
        changes:<br>
          1. Name changed from "AI-MIT License" to "AI-Attribution
        License (AIAL)"<br>
          2. SPDX identifier changed from AI-MIT-1.0 to AIAL-1.0<br>
          3. Project-level Authorship Declaration retained as fallback
        default<br>
          4. Per-file attribution via new SPDX tags defined and required
        for<br>
             files where the project-level declaration does not apply
        uniformly<br>
          5. Precedence rule: per-file tags override project-level
        declaration<br>
          6. Inherited OSS files: explicit provision for files where AI
        authorship<br>
             status is unknown (SPDX-AI-Authorship: unknown)<br>
        <br>
        \u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501<br>
        <br>
        Thank you again for the careful reading. This kind of feedback
        is exactly<br>
        what makes the process valuable.<br>
        <br>
        Nik<br>
        <a href="mailto:nik.sharky@gmail.com" moz-do-not-send="true"
          class="moz-txt-link-freetext">nik.sharky@gmail.com</a></div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">\u043f\u0442, 13 \u043c\u0430\u0440. 2026\u202f\u0433. \u0432 18:35,
          Josh Berkus &lt;<a href="mailto:josh.berkus@opensource.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">josh.berkus@opensource.org</a>&gt;:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
          3/12/26 5:30 PM, Nik wrote:<br>
          &gt; I am submitting the AI-MIT License, Version 1.0 for OSI
          approval. The <br>
          &gt; full license text is attached to this email as a plain
          text file (AI- <br>
          &gt; MIT-License-1.0.txt).<br>
          <br>
          So this is interesting, but will need some iterations I think
          <br>
          (completely aside from any requirements the attorneys have).<br>
          <br>
          The first part is the name; we may not be able to call it MIT,
          which is <br>
          after all a trademark of the folks in Cambridge and this is
          not their <br>
          license.  So we might need to call it AI-Attribution or
          something (which <br>
          would be a good name considering the purpose of the license).<br>
          <br>
          The second, larger problem occurs in the actual construction
          of software <br>
          with AI assistance.  As written, this license targets only
          brand-new <br>
          projects which are created "from scratch" and never modified
          again. <br>
          This is fine for those, but I think project creators want to
          plan for <br>
          success.<br>
          <br>
          For any substantial project which has a history of
          development, there is <br>
          going to be a mix, including: files that are wholly
          AI-generated, files <br>
          which are AI-assisted, files which were written by humans, and
          files <br>
          which were inherited from other OSS projects whose licenses do
          not <br>
          require AI attribution so we don't know. Further, files which
          have been <br>
          modified several times are going to have been modified by
          several AI tools.<br>
          <br>
          If you want to follow this concept, I really think that some
          kind of <br>
          per-file attribution (ala APL2.0) is going to be necessary,
          rather than <br>
          a single statement of authorship over the whole project.<br>
          <br>
          -- <br>
          -- Josh Berkus<br>
          OSI Board Member<br>
        </blockquote>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
    </blockquote>
  </body>
</html>