From nik.sharky at gmail.com Thu Mar 12 11:21:11 2026 From: nik.sharky at gmail.com (Nik) Date: Thu, 12 Mar 2026 13:21:11 +0200 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1=2E0_?= =?utf-8?q?=E2=80=94_permissive_license_for_AI-generated_code?= Message-ID: Dear OSI License Review Committee, I am submitting the **AI-MIT License, Version 1.0** for consideration by the Open Source Initiative. ## Summary The AI-MIT License is a permissive open-source license designed to address a genuine gap: existing licenses were written for human authors and handle AI-generated code poorly, creating false implications about authorship and copyright status. The license is deliberately minimal — it preserves the structure and permissiveness of the MIT License while adding three targeted changes for the AI context. ## The problem it solves 1. **False authorship implication.** When `Copyright (c) [year] [author]` is applied to fully AI-generated code, it implies human authorship and copyright that may not legally exist in most jurisdictions. 2. **No standard for disclosure.** There is no widely adopted mechanism for disclosing whether code is AI-generated, AI-assisted, or human-authored. This matters for supply-chain security, regulatory compliance (EU AI Act), and intellectual honesty in open source. 3. **Undefined copyright status.** Fully autonomous AI-generated code (no human creative input) is in a legal grey zone in most jurisdictions. A license that claims copyright over it is at best misleading, at worst invalid. ## What the license does differently from MIT The license adds one structural element (the Authorship Declaration) and three conditions/clauses: **Authorship Declaration** — a required checkbox at the top of the LICENSE file with three modes: - *Fully AI-generated*: no copyright claimed; code dedicated to public domain - *AI-assisted*: human-directed, AI-generated; standard copyright applies - *Human-authored*: AI used as a tool only; identical to MIT posture **Condition 2 — Transparency**: redistribution or use as AI training data must not misrepresent AI origin as human authorship. **Condition 3 — No Copyright Claim**: for fully autonomous code, explicit public domain dedication (with a perpetual irrevocable fallback for jurisdictions where public domain dedication is impossible). **Extended disclaimer**: adds three AI-specific disclaimers about training data provenance, regulatory compliance, and jurisdictional limitations of the authorship declaration. ## OSD compliance analysis 1. **Free Redistribution** ✓ — no restriction on sale or distribution 2. **Source Code** ✓ — no source restriction 3. **Derived Works** ✓ — modification and redistribution permitted 4. **Integrity of the Author's Source Code** ✓ — no patch-file requirement; attribution preserved 5. **No Discrimination Against Persons or Groups** ✓ 6. **No Discrimination Against Fields of Endeavor** ✓ 7. **Distribution of License** ✓ — same rights apply to all recipients 8. **License Must Not Be Specific to a Product** ✓ 9. **License Must Not Restrict Other Software** ✓ 10. **License Must Be Technology-Neutral** ✓ The Transparency condition (Condition 2) requires disclosure of AI origin but does not restrict use in any field — it is an attribution/honesty requirement, not a field-of-endeavor restriction. ## SPDX identifier We are concurrently requesting the SPDX identifier `AI-MIT-1.0` through the SPDX GitHub repository. ## Repository The full license text, README, translations, and supporting materials are available at: https://github.com/ai-mit-license/ai-mit-license ## A note on meta-context This license was initially drafted with AI assistance (Claude, Anthropic) at the direction of a human. We believe this is appropriate and have disclosed it in the repository. The license is itself an example of the category of work it governs. We welcome feedback from the committee and the community at large. Respectfully, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From pamela at chesteklegal.com Thu Mar 12 17:24:08 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Thu, 12 Mar 2026 10:24:08 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: Message-ID: <49d4a8f9-1e73-409b-b11c-d88179e536db@chesteklegal.com> Please review the license submission instructions, https://opensource.org/licenses/review-process, and provide all the information that you are asked to provide when you requesting review of a license. This includes providing a copy as an attachment. Websites change, so we cannot rely on links to accurately reflect what is being submitted. Pam Pamela S. Chestek Chestek Legal 300 Fayetteville Street Unit 2492 Raleigh, NC 27602 pamela at chesteklegal.com (919) 800-8033 www.chesteklegal.com On 3/12/2026 4:21 AM, Nik wrote: > Dear OSI License Review Committee, > > I am submitting the **AI-MIT License, Version 1.0** for consideration > by the Open Source Initiative. > > ## Summary > > The AI-MIT License is a permissive open-source license designed to > address a genuine gap: existing licenses were written for human > authors and handle AI-generated code poorly, creating false > implications about authorship and copyright status. > > The license is deliberately minimal — it preserves the structure and > permissiveness of the MIT License while adding three targeted changes > for the AI context. > > ## The problem it solves > > 1. **False authorship implication.** When `Copyright (c) [year] > [author]` is applied to fully AI-generated code, it implies human > authorship and copyright that may not legally exist in most jurisdictions. > > 2. **No standard for disclosure.** There is no widely adopted > mechanism for disclosing whether code is AI-generated, AI-assisted, or > human-authored. This matters for supply-chain security, regulatory > compliance (EU AI Act), and intellectual honesty in open source. > > 3. **Undefined copyright status.** Fully autonomous AI-generated code > (no human creative input) is in a legal grey zone in most > jurisdictions. A license that claims copyright over it is at best > misleading, at worst invalid. > > ## What the license does differently from MIT > > The license adds one structural element (the Authorship Declaration) > and three conditions/clauses: > > **Authorship Declaration** — a required checkbox at the top of the > LICENSE file with three modes: > - *Fully AI-generated*: no copyright claimed; code dedicated to public > domain > - *AI-assisted*: human-directed, AI-generated; standard copyright applies > - *Human-authored*: AI used as a tool only; identical to MIT posture > > **Condition 2 — Transparency**: redistribution or use as AI training > data must not misrepresent AI origin as human authorship. > > **Condition 3 — No Copyright Claim**: for fully autonomous code, > explicit public domain dedication (with a perpetual irrevocable > fallback for jurisdictions where public domain dedication is impossible). > > **Extended disclaimer**: adds three AI-specific disclaimers about > training data provenance, regulatory compliance, and jurisdictional > limitations of the authorship declaration. > > ## OSD compliance analysis > > 1. **Free Redistribution** ✓ — no restriction on sale or distribution > 2. **Source Code** ✓ — no source restriction > 3. **Derived Works** ✓ — modification and redistribution permitted > 4. **Integrity of the Author's Source Code** ✓ — no patch-file > requirement; attribution preserved > 5. **No Discrimination Against Persons or Groups** ✓ > 6. **No Discrimination Against Fields of Endeavor** ✓ > 7. **Distribution of License** ✓ — same rights apply to all recipients > 8. **License Must Not Be Specific to a Product** ✓ > 9. **License Must Not Restrict Other Software** ✓ > 10. **License Must Be Technology-Neutral** ✓ > > The Transparency condition (Condition 2) requires disclosure of AI > origin but does not restrict use in any field — it is an > attribution/honesty requirement, not a field-of-endeavor restriction. > > ## SPDX identifier > > We are concurrently requesting the SPDX identifier `AI-MIT-1.0` > through the SPDX GitHub repository. > > ## Repository > > The full license text, README, translations, and supporting materials > are available at: > https://github.com/ai-mit-license/ai-mit-license > > ## A note on meta-context > > This license was initially drafted with AI assistance (Claude, > Anthropic) at the direction of a human. We believe this is appropriate > and have disclosed it in the repository. The license is itself an > example of the category of work it governs. > > We welcome feedback from the committee and the community at large. > > Respectfully, > Nik > > _______________________________________________ > 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: From nik.sharky at gmail.com Fri Mar 13 00:30:57 2026 From: nik.sharky at gmail.com (Nik) Date: Fri, 13 Mar 2026 02:30:57 +0200 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1=2E0_?= =?utf-8?q?=E2=80=94_permissive_license_for_AI-generated_code?= Message-ID: Dear OSI License Review Committee, 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). Per the submission requirements at https://opensource.org/licenses/review-process, I provide the following information. 1. LICENSE NAME AND IDENTIFIER Full name: AI-MIT License 1.0 Short name: AI-MIT-1.0 Steward: [Nik / GitHub organization ai-mit-license] Contact: [nik.sharky at gmail.com] Repository: https://github.com/ai-mit-license/ai-mit-license ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. OSD COMPLIANCE — AFFIRMATIVE STATEMENT I affirm that the AI-MIT License 1.0 complies with all ten criteria of the Open Source Definition. Specific affirmations for the historically problematic criteria: OSD #3 — Derived Works The license permits modification and redistribution of derived works without restriction. No conditions are placed on derived works beyond attribution (preserving the Authorship Declaration and license notice) — identical in scope to the standard MIT attribution requirement. ✓ COMPLIANT OSD #5 — No Discrimination Against Persons or Groups The license contains no restrictions based on identity, group membership, or any personal characteristic. ✓ COMPLIANT OSD #6 — No Discrimination Against Fields of Endeavor The Transparency condition (Condition 2) requires that redistribution not misrepresent AI-generated code as human-authored. This is an honesty/ attribution requirement — equivalent in nature to the MIT attribution requirement — and does not restrict use in any field of endeavor. It applies identically to all users regardless of their domain of use. ✓ COMPLIANT OSD #9 — License Must Not Restrict Other Software The license contains no provisions affecting software distributed alongside the licensed work. It is a per-work license with no reach-through effects. ✓ COMPLIANT Full OSD analysis (all 10 criteria): #1 Free Redistribution ✓ No restriction on sale or distribution #2 Source Code ✓ No source code restriction #3 Derived Works ✓ Modification and redistribution permitted #4 Integrity of Author's Source ✓ Attribution preserved; no patch-file clause #5 No Person/Group Discrimination ✓ No such restrictions #6 No Field Discrimination ✓ Transparency is attribution, not restriction #7 Distribution of License ✓ Same rights apply to all recipients #8 Not Product-Specific ✓ Usable by any project; no product mention #9 No Restriction on Other SW ✓ No reach-through provisions #10 Technology-Neutral ✓ No technology-specific terms ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. WHAT GAP DOES THIS LICENSE FILL? Every existing OSI-approved license was designed for human authors. They assume: (a) a human copyright holder exists (b) copyright in the licensed work is valid (c) the "author" is a natural or legal person These assumptions break down for AI-generated code. Three specific problems: PROBLEM 1 — False copyright implication When MIT (or any standard license) is applied to fully autonomous AI-generated code, the line "Copyright (c) [year] [author]" implies human authorship and a valid copyright that may not exist. The US Copyright Office (January 2025) confirmed that a prompt alone does not create copyright. Most jurisdictions require human authorship for copyright to subsist. Applying MIT to such code is, at best, legally meaningless; at worst, actively misleading. PROBLEM 2 — No mechanism for authorship disclosure There is no widely adopted standard for disclosing whether code is fully AI-generated, AI-assisted, or human-authored with AI tooling. This matters for supply-chain security (knowing the provenance of code), regulatory compliance (the EU AI Act requires transparency about AI-generated content), and the integrity of open-source attribution norms. PROBLEM 3 — Undefined status for autonomous agent output AI agents now generate entire codebases with no human creative input — in CI/CD pipelines, automated scaffolding tools, and agentic coding systems. This code has no clear copyright owner. Using Unlicense or CC0 is a common workaround, but neither was designed for this case and neither distinguishes between fully autonomous code and AI-assisted human work. Comparison with the most similar existing licenses: MIT — identical permissive structure, but implies human authorship; no AI-specific provisions; no public domain clause for autonomous code. AI-MIT is a direct extension, not a replacement. Unlicense — public domain dedication, but: (a) makes no distinction between autonomous and AI-assisted code; (b) requires no disclosure of AI origin; (c) has no fallback for jurisdictions where public domain dedication is impossible. CC0 1.0 — similar to Unlicense; designed for creative works, not software; same lack of disclosure requirements. OpenRAIL — AI-focused license, but: (a) designed for ML model artifacts, not generated code; (b) includes use-based behavioral restrictions that prevent OSI approval (fails OSD #6). AI-MIT fills the gap between "pretend it's MIT" and "abandon copyright entirely" by providing a structured, three-mode authorship framework with the minimum additions necessary to be honest about AI origins. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. LEGAL REVIEW The license was drafted with AI assistance (Claude, Anthropic) under human direction — a fact we disclose openly as it is consistent with the license's own Transparency condition. The license has not yet been formally reviewed by a licensed attorney. We are actively seeking legal review, particularly from IP practitioners in the EU, UK, Russia, and Japan, and welcome such review as part of the OSI process. We understand this is a limitation of the current submission and commit to updating the community as reviews are received. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5. EXISTING USERS The license was published on [2026-03-12]. As of submission, the reference repository is the primary user. Currently it used only in one of my project, repo: https://github.com/nik-sharky/searxng-mcp and we are not aware of other projects that have adopted it yet, as it is a new submission. We note that a lack of existing users is inherent to any newly proposed license, and we believe the gap it addresses (described above) represents real demand that will be reflected in adoption once the license has a recognized status. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6. REUSABILITY The license is fully reusable by any licensor. The Authorship Declaration uses bracketed fields (Originator, AI Tool, Year, Repository) that any distributor fills in for their own project. No clause names or refers to a specific licensor, organization, or product. The license achieves the same legal result for all users regardless of who uses it. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7. ADDITIONAL INFORMATION On the Authorship Declaration structure: The Declaration is a required attribution element (like the copyright notice in MIT) that distributors must fill in and preserve. It is not a condition that restricts use — it is a disclosure mechanism. Checking the wrong box would be a misrepresentation, not a license violation per se, analogous to falsifying a copyright notice under MIT. On the "Fully AI-generated" / No Copyright Claim clause: This clause is novel among OSI-submitted licenses. Its purpose is to honestly reflect a legal reality (no human author, therefore possibly no copyright) rather than to impose a restriction. The fallback language ("perpetual, irrevocable, royalty-free license") ensures the clause functions in jurisdictions where public domain dedication is not legally possible (e.g., some EU member states under moral rights doctrine). On meta-context: This license was itself drafted with AI assistance and is disclosed as "AI-assisted" in the reference repository. We believe transparency about this is appropriate and consistent with the license's own values. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The full license text is attached as AI-MIT-License-1.0.txt. Thank you for your consideration. I welcome feedback from the committee and the community. [Nik] [nik.sharky at gmail.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- AI-MIT License Version 1.0, 2025 https://github.com/ai-mit-license/ai-mit-license ------------------------------------------------------------------------ AUTHORSHIP DECLARATION (Distributor must check one and fill in details) [ ] Fully AI-generated -- no human creative input; no copyright claimed [ ] AI-assisted -- human-directed, AI-generated output [ ] Human-authored -- AI used only as a tool (e.g. autocomplete) Originator : [Name, organization, or "AI Agent / "] AI Tool(s) : [e.g. Claude Sonnet 4 (Anthropic), GPT-4o (OpenAI)] Year : [YYYY] Repository : [URL or N/A] ------------------------------------------------------------------------ GRANT OF RIGHTS Permission is hereby granted, free of charge, to any person or system obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions. ------------------------------------------------------------------------ CONDITIONS 1. ATTRIBUTION The above Authorship Declaration, this conditions notice, and the AI-MIT License version tag must be included in all copies or substantial portions of the Software. 2. TRANSPARENCY If the Software is redistributed or used as input for further AI training, the AI origin of the code must not be misrepresented as purely human-authored work. 3. NO COPYRIGHT CLAIM (Fully AI-generated only) When the "Fully AI-generated" box is checked, the Originator makes no copyright claim over the Software. The Software is dedicated to the public domain to the maximum extent permitted by applicable law. Where public domain dedication is not legally possible, the Originator grants a perpetual, irrevocable, royalty-free license to all parties for any purpose. ------------------------------------------------------------------------ DISCLAIMERS THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ORIGINATOR EXPRESSLY DISCLAIMS THAT: (a) the Software is free of third-party intellectual property that may have been embedded through AI training data; (b) the Software meets the requirements of any law, regulation, or framework governing AI-generated outputs (including but not limited to the EU AI Act, US Executive Orders on AI, or sector-specific regulations); (c) the Authorship Declaration above is legally sufficient to establish, transfer, or disclaim rights in any specific jurisdiction -- users are advised to seek independent legal counsel for high-stakes deployments. IN NO EVENT SHALL THE ORIGINATOR BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ------------------------------------------------------------------------ SPDX-License-Identifier: AI-MIT-1.0 From josh.berkus at opensource.org Fri Mar 13 16:35:30 2026 From: josh.berkus at opensource.org (Josh Berkus) Date: Fri, 13 Mar 2026 09:35:30 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: Message-ID: <18108e57-6a6e-4930-814a-d84e30f4b27f@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 From nik.sharky at gmail.com Fri Mar 13 18:54:59 2026 From: nik.sharky at gmail.com (Nik) Date: Fri, 13 Mar 2026 20:54:59 +0200 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: 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 : > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- AI-Attribution License (AIAL) Version 1.0, 2026 https://github.com/ai-mit-license/ai-mit-license SPDX-License-Identifier: AIAL-1.0 ------------------------------------------------------------------------ ABOUT THIS LICENSE This license is a permissive open-source license designed for software projects where some or all files were generated or assisted by artificial intelligence tools. It extends standard permissive licensing with transparent attribution of AI involvement at the file level. ------------------------------------------------------------------------ PART A — PROJECT-LEVEL DECLARATION (fallback default) This section applies to all files in the project that do not carry per-file AI attribution headers (see Part B). If all files carry per-file headers, this section serves as an informational summary only. Project default authorship (check one): [ ] Fully AI-generated -- no human creative input in any file; no copyright claimed for any file [ ] AI-assisted -- human-directed; AI generated some or all content across files [ ] Human-authored -- AI used only as passive tooling (e.g. autocomplete); full human copyright applies [ ] Mixed -- files vary; see per-file headers (Part B) for individual file status Project name : [Name] Originator : [Name, organization, or "AI Agent / "] Year(s) : [YYYY or YYYY-YYYY] Repository : [URL or N/A] ------------------------------------------------------------------------ PART B — PER-FILE AI ATTRIBUTION HEADERS (recommended; takes precedence) For any file where the project-level declaration (Part A) does not accurately describe that file's authorship, the distributor SHOULD add AI attribution tags to the file's comment header alongside standard SPDX tags. Per-file tags take precedence over the project-level declaration for that file. Syntax (place in file comment header alongside SPDX-License-Identifier): SPDX-AI-Authorship: SPDX-AI-Tool: Valid values for SPDX-AI-Authorship: fully-generated The file was produced entirely by an AI tool with no human creative input. No copyright is claimed for this file (see Condition 3 below). ai-assisted A human directed the work; an AI tool generated some or all of the content. Human copyright applies to the extent permitted by applicable law. human-authored A human wrote this file; AI was used only as a passive tool (e.g. syntax highlighting, autocomplete). Standard copyright applies; no AI disclosure required. unknown The AI authorship status of this file is not known (e.g. inherited from a third-party project that did not disclose AI involvement). Use in good faith. SPDX-AI-Tool is REQUIRED when SPDX-AI-Authorship is fully-generated or ai-assisted, and OPTIONAL otherwise. Example file headers: Human-authored file (no AI disclosure needed beyond license ID): ┌─────────────────────────────────────────────────────────────┐ │ # SPDX-FileCopyrightText: 2019 Jane Doe │ │ # SPDX-License-Identifier: AIAL-1.0 │ └─────────────────────────────────────────────────────────────┘ AI-assisted file: ┌─────────────────────────────────────────────────────────────┐ │ # SPDX-FileCopyrightText: 2025 Jane Doe │ │ # SPDX-License-Identifier: AIAL-1.0 │ │ # SPDX-AI-Authorship: ai-assisted │ │ # SPDX-AI-Tool: Claude Sonnet 4 (Anthropic, 2025) │ └─────────────────────────────────────────────────────────────┘ Fully AI-generated file (no human copyright): ┌─────────────────────────────────────────────────────────────┐ │ # SPDX-FileCopyrightText: NONE │ │ # SPDX-License-Identifier: AIAL-1.0 │ │ # SPDX-AI-Authorship: fully-generated │ │ # SPDX-AI-Tool: Claude Sonnet 4 (Anthropic, 2025) │ └─────────────────────────────────────────────────────────────┘ File with unknown AI history (inherited from third-party OSS): ┌─────────────────────────────────────────────────────────────┐ │ # SPDX-FileCopyrightText: 2022 Some Project Contributors │ │ # SPDX-License-Identifier: AIAL-1.0 │ │ # SPDX-AI-Authorship: unknown │ └─────────────────────────────────────────────────────────────┘ File modified by multiple AI tools over time: ┌─────────────────────────────────────────────────────────────┐ │ # SPDX-FileCopyrightText: 2021 Jane Doe │ │ # SPDX-License-Identifier: AIAL-1.0 │ │ # SPDX-AI-Authorship: ai-assisted │ │ # SPDX-AI-Tool: GitHub Copilot (Microsoft, 2022) │ │ # SPDX-AI-Tool: Claude Sonnet 4 (Anthropic, 2025) │ └─────────────────────────────────────────────────────────────┘ ------------------------------------------------------------------------ GRANT OF RIGHTS Permission is hereby granted, free of charge, to any person or system obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions. ------------------------------------------------------------------------ CONDITIONS 1. ATTRIBUTION For each file distributed, either: (a) the per-file AI attribution header (Part B) must be preserved, where present; or (b) where no per-file header is present, the project-level Authorship Declaration (Part A) and this conditions notice must be included in all copies or substantial portions of the Software. The AIAL version tag (SPDX-License-Identifier: AIAL-1.0 or later) must be preserved in all copies. 2. TRANSPARENCY If the Software, or any file within it, is redistributed or used as input for further AI training, the AI origin of any AI-generated or AI-assisted content must not be misrepresented as purely human-authored work. 3. NO COPYRIGHT CLAIM (fully-generated files only) For any file where SPDX-AI-Authorship is "fully-generated" (per-file header) or where the project-level declaration is "Fully AI-generated" and no per-file header is present: The Originator makes no copyright claim over that file. The file is dedicated to the public domain to the maximum extent permitted by applicable law. Where public domain dedication is not legally possible, the Originator grants a perpetual, irrevocable, royalty-free license to all parties for any purpose for that file. ------------------------------------------------------------------------ DISCLAIMERS THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ORIGINATOR EXPRESSLY DISCLAIMS THAT: (a) the Software is free of third-party intellectual property that may have been embedded through AI training data; (b) the Software meets the requirements of any law, regulation, or framework governing AI-generated outputs (including but not limited to the EU AI Act, US Executive Orders on AI, or sector-specific regulations); (c) the AI attribution information provided (per-file or project-level) is legally sufficient to establish, transfer, or disclaim rights in any specific jurisdiction — users are advised to seek independent legal counsel for high-stakes deployments; (d) the SPDX-AI-Authorship and SPDX-AI-Tool tags, as custom extensions not currently part of the official SPDX specification, will be recognized by all SPDX-compliant tooling. IN NO EVENT SHALL THE ORIGINATOR BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ------------------------------------------------------------------------ COMPATIBILITY NOTE This license is structurally compatible with the MIT License. A project that uses AIAL-1.0 grants the same rights as MIT. The additional requirements (AI attribution headers, Transparency condition) are attribution obligations, not restrictions on use or field of endeavor. Files in a project may be licensed under both AIAL-1.0 and another OSI-approved license using a compound SPDX expression: SPDX-License-Identifier: AIAL-1.0 AND Apache-2.0 ------------------------------------------------------------------------ SPDX-License-Identifier: AIAL-1.0 From josh at berkus.org Fri Mar 13 21:34:16 2026 From: josh at berkus.org (Josh Berkus) Date: Fri, 13 Mar 2026 14:34:16 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: <1f2df46a-cc03-4d63-b004-9e06421e2993@berkus.org> On 3/13/26 11:54 AM, Nik wrote: > 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. Great. You might want to wait for a lawyer opinion on this though, since this license does intend to address new legal ground. -- Josh Berkus From shujisado at gmail.com Sat Mar 14 09:45:50 2026 From: shujisado at gmail.com (Shuji Sado) Date: Sat, 14 Mar 2026 18:45:50 +0900 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: 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 : > 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 : > >> 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: From j.gay at ieee.org Sat Mar 14 16:36:34 2026 From: j.gay at ieee.org (Joshua Gay) Date: Sat, 14 Mar 2026 10:36:34 -0600 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: 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 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 : > >> 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 : >> >>> 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: From pfts.offical at gmail.com Sat Mar 14 14:16:33 2026 From: pfts.offical at gmail.com (PTFS) Date: Sat, 14 Mar 2026 16:16:33 +0200 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: <49d4a8f9-1e73-409b-b11c-d88179e536db@chesteklegal.com> References: <49d4a8f9-1e73-409b-b11c-d88179e536db@chesteklegal.com> Message-ID: I just want to note that the author may have used ChatGPT, and ZeroGPT indicates the text is approximately 59.7% AI-generated. That said, using AI doesn’t break any OSI rules. However, it’s worth mentioning because this license could still be challenged under the Open Source Definition (OSD). I’m highlighting this only for context, the AI patterns (shown in yellow in the full text) don’t make it invalid, but they could make reviewers scrutinize it more closely, which may increase the chance of AI-MIT getting rejected, The Full Text i will show it right now : Dear OSI License Review Committee, I am submitting the **AI-MIT License, Version 1.0** for consideration by the Open Source Initiative. ## Summary The AI-MIT License is a permissive open-source license designed to address a genuine gap: existing licenses were written for human authors and handle AI-generated code poorly, creating false implications about authorship and copyright status. The license is deliberately minimal — it preserves the structure and permissiveness of the MIT License while adding three targeted changes for the AI context. ## The problem it solves 1. **False authorship implication.** When `Copyright (c) [year] [author]` is applied to fully AI-generated code, it implies human authorship and copyright that may not legally exist in most jurisdictions. 2. **No standard for disclosure.** There is no widely adopted mechanism for disclosing whether code is AI-generated, AI-assisted, or human-authored. This matters for supply-chain security, regulatory compliance (EU AI Act), and intellectual honesty in open source. 3. **Undefined copyright status.** Fully autonomous AI-generated code (no human creative input) is in a legal grey zone in most jurisdictions. A license that claims copyright over it is at best misleading, at worst invalid. ## What the license does differently from MIT The license adds one structural element (the Authorship Declaration) and three conditions/clauses: **Authorship Declaration** — a required checkbox at the top of the LICENSE file with three modes: - *Fully AI-generated*: no copyright claimed; code dedicated to public domain - *AI-assisted*: human-directed, AI-generated; standard copyright applies - *Human-authored*: AI used as a tool only; identical to MIT posture **Condition 2 — Transparency**: redistribution or use as AI training data must not misrepresent AI origin as human authorship. **Condition 3 — No Copyright Claim**: for fully autonomous code, explicit public domain dedication (with a perpetual irrevocable fallback for jurisdictions where public domain dedication is impossible). **Extended disclaimer**: adds three AI-specific disclaimers about training data provenance, regulatory compliance, and jurisdictional limitations of the authorship declaration. ## OSD compliance analysis 1. **Free Redistribution** ✓ — no restriction on sale or distribution 2. **Source Code** ✓ — no source restriction 3. **Derived Works** ✓ — modification and redistribution permitted 4. **Integrity of the Author's Source Code** ✓ — no patch-file requirement; attribution preserved 5. **No Discrimination Against Persons or Groups** ✓ 6. **No Discrimination Against Fields of Endeavor** ✓ 7. **Distribution of License** ✓ — same rights apply to all recipients 8. **License Must Not Be Specific to a Product** ✓ 9. **License Must Not Restrict Other Software** ✓ 10. **License Must Be Technology-Neutral** ✓ The Transparency condition (Condition 2) requires disclosure of AI origin but does not restrict use in any field — it is an attribution/honesty requirement, not a field-of-endeavor restriction. ## SPDX identifier We are concurrently requesting the SPDX identifier `AI-MIT-1.0` through the SPDX GitHub repository. ## Repository The full license text, README, translations, and supporting materials are available at: https://github.com/ai-mit-license/ai-mit-license ## A note on meta-context This license was initially drafted with AI assistance (Claude, Anthropic) at the direction of a human. We believe this is appropriate and have disclosed it in the repository. The license is itself an example of the category of work it governs. We welcome feedback from the committee and the community at large. Best Regards Bernardo On Thu, Mar 12, 2026 at 7:25 PM Pamela Chestek wrote: > Please review the license submission instructions, > https://opensource.org/licenses/review-process, and provide all the > information that you are asked to provide when you requesting review of a > license. This includes providing a copy as an attachment. Websites change, > so we cannot rely on links to accurately reflect what is being submitted. > > Pam > > Pamela S. Chestek > Chestek Legal > 300 Fayetteville Street > Unit 2492 > Raleigh, NC 27602 > pamela at chesteklegal.com > (919) 800-8033 > www.chesteklegal.com > > On 3/12/2026 4:21 AM, Nik wrote: > > Dear OSI License Review Committee, > > I am submitting the **AI-MIT License, Version 1.0** for consideration by > the Open Source Initiative. > > ## Summary > > The AI-MIT License is a permissive open-source license designed to address > a genuine gap: existing licenses were written for human authors and handle > AI-generated code poorly, creating false implications about authorship and > copyright status. > > The license is deliberately minimal — it preserves the structure and > permissiveness of the MIT License while adding three targeted changes for > the AI context. > > ## The problem it solves > > 1. **False authorship implication.** When `Copyright (c) [year] [author]` > is applied to fully AI-generated code, it implies human authorship and > copyright that may not legally exist in most jurisdictions. > > 2. **No standard for disclosure.** There is no widely adopted mechanism > for disclosing whether code is AI-generated, AI-assisted, or > human-authored. This matters for supply-chain security, regulatory > compliance (EU AI Act), and intellectual honesty in open source. > > 3. **Undefined copyright status.** Fully autonomous AI-generated code (no > human creative input) is in a legal grey zone in most jurisdictions. A > license that claims copyright over it is at best misleading, at worst > invalid. > > ## What the license does differently from MIT > > The license adds one structural element (the Authorship Declaration) and > three conditions/clauses: > > **Authorship Declaration** — a required checkbox at the top of the LICENSE > file with three modes: > - *Fully AI-generated*: no copyright claimed; code dedicated to public > domain > - *AI-assisted*: human-directed, AI-generated; standard copyright applies > - *Human-authored*: AI used as a tool only; identical to MIT posture > > **Condition 2 — Transparency**: redistribution or use as AI training data > must not misrepresent AI origin as human authorship. > > **Condition 3 — No Copyright Claim**: for fully autonomous code, explicit > public domain dedication (with a perpetual irrevocable fallback for > jurisdictions where public domain dedication is impossible). > > **Extended disclaimer**: adds three AI-specific disclaimers about training > data provenance, regulatory compliance, and jurisdictional limitations of > the authorship declaration. > > ## OSD compliance analysis > > 1. **Free Redistribution** ✓ — no restriction on sale or distribution > 2. **Source Code** ✓ — no source restriction > 3. **Derived Works** ✓ — modification and redistribution permitted > 4. **Integrity of the Author's Source Code** ✓ — no patch-file > requirement; attribution preserved > 5. **No Discrimination Against Persons or Groups** ✓ > 6. **No Discrimination Against Fields of Endeavor** ✓ > 7. **Distribution of License** ✓ — same rights apply to all recipients > 8. **License Must Not Be Specific to a Product** ✓ > 9. **License Must Not Restrict Other Software** ✓ > 10. **License Must Be Technology-Neutral** ✓ > > The Transparency condition (Condition 2) requires disclosure of AI origin > but does not restrict use in any field — it is an attribution/honesty > requirement, not a field-of-endeavor restriction. > > ## SPDX identifier > > We are concurrently requesting the SPDX identifier `AI-MIT-1.0` through > the SPDX GitHub repository. > > ## Repository > > The full license text, README, translations, and supporting materials are > available at: > https://github.com/ai-mit-license/ai-mit-license > > ## A note on meta-context > > This license was initially drafted with AI assistance (Claude, Anthropic) > at the direction of a human. We believe this is appropriate and have > disclosed it in the repository. The license is itself an example of the > category of work it governs. > > We welcome feedback from the committee and the community at large. > > Respectfully, > Nik > > _______________________________________________ > 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 listLicense-review at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org > > > _______________________________________________ > 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: From pfts.offical at gmail.com Sat Mar 14 14:18:08 2026 From: pfts.offical at gmail.com (PTFS) Date: Sat, 14 Mar 2026 16:18:08 +0200 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: Message-ID: For some reason, it isnt showing the yellow highlight it was, On Sat, Mar 14, 2026 at 4:16 PM PTFS wrote: > I just want to note that the author may have used ChatGPT, and ZeroGPT > indicates the text is approximately 59.7% AI-generated. That said, using AI > doesn’t break any OSI rules. However, it’s worth mentioning because this > license could still be challenged under the Open Source Definition (OSD). > I’m highlighting this only for context, the AI patterns (shown in yellow in > the full text) don’t make it invalid, but they could make reviewers > scrutinize it more closely, which may increase the chance of AI-MIT getting > rejected, The Full Text i will show it right now : Dear OSI License > Review Committee, > I am submitting the **AI-MIT License, Version 1.0** for consideration by > the Open Source Initiative. ## Summary The AI-MIT License is a permissive > open-source license designed to address a genuine gap: existing licenses > were written for human authors and handle AI-generated code poorly, > creating false implications about authorship and copyright status. The > license is deliberately minimal — it preserves the structure and > permissiveness of the MIT License while adding three targeted changes for > the AI context. ## The problem it solves 1. **False authorship > implication.** When `Copyright (c) [year] [author]` is applied to fully > AI-generated code, it implies human authorship and copyright that may not > legally exist in most jurisdictions. 2. **No standard for disclosure.** > There is no widely adopted mechanism for disclosing whether code is > AI-generated, AI-assisted, or human-authored. This matters for > supply-chain security, regulatory compliance (EU AI Act), and intellectual > honesty in open source. 3. **Undefined copyright status.** Fully > autonomous AI-generated code (no human creative input) is in a legal grey > zone in most jurisdictions. A license that claims copyright over it is at > best misleading, at worst invalid. ## What the license does differently > from MIT The license adds one structural element (the Authorship > Declaration) and three conditions/clauses: **Authorship Declaration** — a > required checkbox at the top of the LICENSE file with three modes: - *Fully > AI-generated*: no copyright claimed; code dedicated to public domain - *AI-assisted*: > human-directed, AI-generated; standard copyright applies - *Human-authored*: > AI used as a tool only; identical to MIT posture **Condition 2 — > Transparency**: redistribution or use as AI training data must not > misrepresent AI origin as human authorship. **Condition 3 — No Copyright > Claim**: for fully autonomous code, explicit public domain dedication (with > a perpetual irrevocable fallback for jurisdictions where public domain > dedication is impossible). **Extended disclaimer**: adds three > AI-specific disclaimers about training data provenance, regulatory > compliance, and jurisdictional limitations of the authorship declaration. > ## OSD compliance analysis 1. **Free Redistribution** ✓ — no restriction on > sale or distribution 2. **Source Code** ✓ — no source restriction 3. > **Derived Works** ✓ — modification and redistribution permitted 4. > **Integrity of the Author's Source Code** ✓ — no patch-file requirement; > attribution preserved 5. **No Discrimination Against Persons or Groups** ✓ > 6. **No Discrimination Against Fields of Endeavor** ✓ 7. **Distribution of > License** ✓ — same rights apply to all recipients 8. **License Must Not Be > Specific to a Product** ✓ 9. **License Must Not Restrict Other Software** ✓ > 10. **License Must Be Technology-Neutral** ✓ The Transparency condition > (Condition 2) requires disclosure of AI origin but does not restrict use in > any field — it is an attribution/honesty requirement, not a > field-of-endeavor restriction. ## SPDX identifier We are concurrently > requesting the SPDX identifier `AI-MIT-1.0` through the SPDX GitHub > repository. ## Repository The full license text, README, translations, and > supporting materials are available at: > https://github.com/ai-mit-license/ai-mit-license ## A note on > meta-context This license was initially drafted with AI assistance (Claude, > Anthropic) at the direction of a human. We believe this is appropriate and > have disclosed it in the repository. The license is itself an example of > the category of work it governs. We welcome feedback from the committee > and the community at large. > Best Regards > Bernardo > > > On Thu, Mar 12, 2026 at 7:25 PM Pamela Chestek > wrote: > >> Please review the license submission instructions, >> https://opensource.org/licenses/review-process, and provide all the >> information that you are asked to provide when you requesting review of a >> license. This includes providing a copy as an attachment. Websites change, >> so we cannot rely on links to accurately reflect what is being submitted. >> >> Pam >> >> Pamela S. Chestek >> Chestek Legal >> 300 Fayetteville Street >> Unit 2492 >> Raleigh, NC 27602 >> pamela at chesteklegal.com >> (919) 800-8033 >> www.chesteklegal.com >> >> On 3/12/2026 4:21 AM, Nik wrote: >> >> Dear OSI License Review Committee, >> >> I am submitting the **AI-MIT License, Version 1.0** for consideration by >> the Open Source Initiative. >> >> ## Summary >> >> The AI-MIT License is a permissive open-source license designed to >> address a genuine gap: existing licenses were written for human authors and >> handle AI-generated code poorly, creating false implications about >> authorship and copyright status. >> >> The license is deliberately minimal — it preserves the structure and >> permissiveness of the MIT License while adding three targeted changes for >> the AI context. >> >> ## The problem it solves >> >> 1. **False authorship implication.** When `Copyright (c) [year] [author]` >> is applied to fully AI-generated code, it implies human authorship and >> copyright that may not legally exist in most jurisdictions. >> >> 2. **No standard for disclosure.** There is no widely adopted mechanism >> for disclosing whether code is AI-generated, AI-assisted, or >> human-authored. This matters for supply-chain security, regulatory >> compliance (EU AI Act), and intellectual honesty in open source. >> >> 3. **Undefined copyright status.** Fully autonomous AI-generated code (no >> human creative input) is in a legal grey zone in most jurisdictions. A >> license that claims copyright over it is at best misleading, at worst >> invalid. >> >> ## What the license does differently from MIT >> >> The license adds one structural element (the Authorship Declaration) and >> three conditions/clauses: >> >> **Authorship Declaration** — a required checkbox at the top of the >> LICENSE file with three modes: >> - *Fully AI-generated*: no copyright claimed; code dedicated to public >> domain >> - *AI-assisted*: human-directed, AI-generated; standard copyright applies >> - *Human-authored*: AI used as a tool only; identical to MIT posture >> >> **Condition 2 — Transparency**: redistribution or use as AI training data >> must not misrepresent AI origin as human authorship. >> >> **Condition 3 — No Copyright Claim**: for fully autonomous code, explicit >> public domain dedication (with a perpetual irrevocable fallback for >> jurisdictions where public domain dedication is impossible). >> >> **Extended disclaimer**: adds three AI-specific disclaimers about >> training data provenance, regulatory compliance, and jurisdictional >> limitations of the authorship declaration. >> >> ## OSD compliance analysis >> >> 1. **Free Redistribution** ✓ — no restriction on sale or distribution >> 2. **Source Code** ✓ — no source restriction >> 3. **Derived Works** ✓ — modification and redistribution permitted >> 4. **Integrity of the Author's Source Code** ✓ — no patch-file >> requirement; attribution preserved >> 5. **No Discrimination Against Persons or Groups** ✓ >> 6. **No Discrimination Against Fields of Endeavor** ✓ >> 7. **Distribution of License** ✓ — same rights apply to all recipients >> 8. **License Must Not Be Specific to a Product** ✓ >> 9. **License Must Not Restrict Other Software** ✓ >> 10. **License Must Be Technology-Neutral** ✓ >> >> The Transparency condition (Condition 2) requires disclosure of AI origin >> but does not restrict use in any field — it is an attribution/honesty >> requirement, not a field-of-endeavor restriction. >> >> ## SPDX identifier >> >> We are concurrently requesting the SPDX identifier `AI-MIT-1.0` through >> the SPDX GitHub repository. >> >> ## Repository >> >> The full license text, README, translations, and supporting materials are >> available at: >> https://github.com/ai-mit-license/ai-mit-license >> >> ## A note on meta-context >> >> This license was initially drafted with AI assistance (Claude, Anthropic) >> at the direction of a human. We believe this is appropriate and have >> disclosed it in the repository. The license is itself an example of the >> category of work it governs. >> >> We welcome feedback from the committee and the community at large. >> >> Respectfully, >> Nik >> >> _______________________________________________ >> 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 listLicense-review at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org >> >> >> _______________________________________________ >> 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: From timofey.zakharchuk.research at gmail.com Sun Mar 15 13:12:39 2026 From: timofey.zakharchuk.research at gmail.com (Timofey Zakharcuk) Date: Sun, 15 Mar 2026 16:12:39 +0300 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= Message-ID: The License states it was made with ai, but it also says that "humans shouldn't be able to copyright claim ai content" As i saw in Vol 149, Issue 6: "A note on meta-context This license was initially drafted with AI assistance (Claude, Anthropic) at the direction of a human. We believe this is appropriate and have disclosed it in the repository. The license is itself an example of the category of work it governs. We welcome feedback from the committee and the community at large." While the License says: "3. NO COPYRIGHT CLAIM (Fully AI-generated only) When the "Fully AI-generated" box is checked, the Originator makes no copyright claim over the Software. The Software is dedicated to the public domain to the maximum extent permitted by applicable law. Where public domain dedication is not legally possible, the Originator grants a perpetual, irrevocable, royalty-free license to all parties for any purpose." AND the Readme of the license on "GitHub" says " *This license was itself written by an AI (Claude, Anthropic) at the direction of a human author. We think that's fitting."* Therefore it contradicts itself and has no legal meaning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at berkus.org Sun Mar 15 21:04:00 2026 From: josh at berkus.org (Josh Berkus) Date: Sun, 15 Mar 2026 14:04:00 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: On 3/14/26 9:36 AM, Joshua Gay via License-review wrote: > 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. File-level attribution is a common approach across many popular open source licenses, including the APL2.0, one of the top three most used licenses in the catalog. If you have a better approach for "distinguishing between modular components of a work", please share it, because it hasn't appeared in any accepted license yet. -- Josh Berkus From j.gay at ieee.org Sun Mar 15 21:27:21 2026 From: j.gay at ieee.org (Joshua Gay) Date: Sun, 15 Mar 2026 15:27:21 -0600 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: Hi Josh, I may not have been clear. I am not objecting to file level notices as a practical approach to documentation. Those are common and useful, and as you said licenses like Apache 2.0 make good use of them. My point is narrower. What I was reacting to was the idea that a file level label could reliably determine something like "this file is fully AI generated and therefore public domain." That moves from documentation into making a legal conclusion about authorship based on the boundary of a file. In otherwords, files are convenient implementation artifacts, but they are not reliable boundaries for authorship. A given module may span multiple files, or a single file may reflect design decisions, prompts, surrounding code context, and integration work that occurred elsewhere in the repository. In that sense the authorship of a portion of code often comes from the development process and the structure of the larger work, not just the literal text inside a particular file. So my concern is less about file level attribution itself and more about using file boundaries as the basis for determining the copyright status of a portion of the work. 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 Sun, Mar 15, 2026, 3:05 PM Josh Berkus wrote: > On 3/14/26 9:36 AM, Joshua Gay via License-review wrote: > > 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. > > File-level attribution is a common approach across many popular open > source licenses, including the APL2.0, one of the top three most used > licenses in the catalog. > > If you have a better approach for "distinguishing between modular > components of a work", please share it, because it hasn't appeared in > any accepted license yet. > > -- > Josh Berkus > > _______________________________________________ > 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: From pamela at chesteklegal.com Sun Mar 15 22:43:20 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Sun, 15 Mar 2026 15:43:20 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: On 3/15/2026 2:27 PM, Joshua Gay via License-review wrote: > What I was reacting to was the idea that a file level label could > reliably determine something like "this file is fully AI generated and > therefore public domain." That moves from documentation into making a > legal conclusion about authorship based on the boundary of a file. In > otherwords, files are convenient implementation artifacts, but they > are not reliable boundaries for authorship. A given module may span > multiple files, or a single file may reflect design decisions, > prompts, surrounding code context, and integration work that occurred > elsewhere in the repository. In that sense the authorship of a portion > of code often comes from the development process and the structure of > the larger work, not just the literal text inside a particular file. That's very true, but it's not a new problem arising with AI, it's a challenge that has existed all along. I don't know any other way to cope with it. As Josh pointed out higher in the thread, even if it's clear on the first submission what the authorship is, that clarity very quickly disappears as the software gets modified. Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com From pamela at chesteklegal.com Sun Mar 15 22:51:46 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Sun, 15 Mar 2026 15:51:46 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: <22063060-bc89-4f06-9ae1-2fb3023a3fcc@chesteklegal.com> On 3/14/2026 9:36 AM, Joshua Gay via License-review wrote: > 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. > > > > When outputs are produced through modern LLM-based workflows it > becomes much harder to characterize the result as lacking human > authorship entirely. > > > > 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. I think that's the reason for this license proposal, it eliminates the ambiguity. It doesn't matter whether the law would characterize the code as copyrightable, it is a contractually adopted and legally enforceable statement about the legal status of the content, "When the 'Fully AI-generated' box is checked, the Originator makes no copyright claim over the Software."  It gives adopters security about their use. Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com From pamela at chesteklegal.com Sun Mar 15 22:57:08 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Sun, 15 Mar 2026 15:57:08 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: <0fdac844-d883-4875-8472-29c6e9cb293e@chesteklegal.com> Hi Nik, 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. Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com On 3/13/2026 11:54 AM, Nik wrote: > 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 : > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pamela at chesteklegal.com Sun Mar 15 23:17:45 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Sun, 15 Mar 2026 16:17:45 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: This response is inadequate and not thoughtful. While the OSI tries to be consistent with and coordinate with the SPDX project, the OSI does not have any control over the SPDX project, so it is not a solution to say that the problem can be fixed with changes to SPDX. Your revised draft then assumes that these tags have been added to SPDX, something we cannot assume in license approval. In my opinion this version of the license must be rejected for this reason. I would also suggest in the future you be more thoughtful about your responses, and make sure they actually are responsive to the points raised and are workable solutions. It doesn't address Josh's point that over time a file, or a project, will have a mixed authorship. Up until now, typically, but not always, changes would be licensed under the same license as the code that is being changed. However, you are presenting a situation where there is likely going to be mixed content in the same file, some AI-generated, some partially, some human - what is your solution to that? Is it your expectation that different people use the same license but check a different box? How should that be noted within a file? How will users know which code is which? If the code isn't /entirely /AI-generated, does it matter that some of it is? If it's not entirely AI-generated, doesn't the user have to assume that someone owns copyright in the code and behave accordingly? Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com On 3/13/2026 11:54 AM, Nik wrote: > 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 : > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pamela at chesteklegal.com Sun Mar 15 23:22:20 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Sun, 15 Mar 2026 16:22:20 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: Message-ID: <7b50c78a-a86a-4dc6-87fd-340e501aa076@chesteklegal.com> I'm not following your point. Are you saying that the license text isn't copyrightable because it was AI generated? Why does that matter to how the license operates? Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com On 3/15/2026 6:12 AM, Timofey Zakharcuk wrote: > The License states it was made with ai, but it also says that "humans > shouldn't be able to copyright claim ai content" > As i saw in Vol 149, Issue 6: > > "A note on > meta-context This license was initially drafted with AI assistance > (Claude, > Anthropic) at the direction of a human. We believe this is appropriate and > have disclosed it in the repository. The license is itself an example of > the category of work it governs. We welcome feedback from the > committee and > the community at large." > > While the License says: > > "3. NO COPYRIGHT CLAIM (Fully AI-generated only) >    When the "Fully AI-generated" box is checked, the Originator >    makes no copyright claim over the Software. The Software is >    dedicated to the public domain to the maximum extent >    permitted by applicable law. Where public domain dedication >    is not legally possible, the Originator grants a perpetual, >    irrevocable, royalty-free license to all parties for any >    purpose." > > AND the Readme of the license on "GitHub" says > " /This license was itself written by an AI (Claude, Anthropic) at the > direction of a human author. We think that's fitting."/ > > Therefore it contradicts itself and has no legal meaning. > > _______________________________________________ > 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: From josh at berkus.org Sun Mar 15 23:55:01 2026 From: josh at berkus.org (Josh Berkus) Date: Sun, 15 Mar 2026 16:55:01 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> Message-ID: <2e6e98c8-dc4f-42d1-bc5d-f80fbfb19a9f@berkus.org> On 3/15/26 3:43 PM, Pamela Chestek wrote: > > That's very true, but it's not a new problem arising with AI, it's a > challenge that has existed all along. I don't know any other way to cope > with it. As Josh pointed out higher in the thread, even if it's clear on > the first submission what the authorship is, that clarity very quickly > disappears as the software gets modified. Yes, that's it. File-level has definite limitations, but it still better than one assertion for the entire project. Like, imagine a project with 300 files and you have a single COPYRIGHT in the base folder that says "Some elements are AI-Assisted and some are Fully AI Generated" So now, if you want to copy a single module from this project, you don't know what copyright applies. Applying that on a per-module/library/function/interface basis would be better, but nobody has found a way to practically do that. -- Josh Berkus From rfontana at redhat.com Mon Mar 16 00:46:42 2026 From: rfontana at redhat.com (Richard Fontana) Date: Sun, 15 Mar 2026 20:46:42 -0400 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: Message-ID: On Sun, Mar 15, 2026 at 9:11 AM PTFS wrote: > > For some reason, it isnt showing the yellow highlight it was, You shouldn't assume that any colors you intended in your original message will survive transmission, given mailing list settings and settings for individual email clients that may strip out HTML and so forth. Maybe try using some typographical convention like brackets or asterisks to enclose what you had intended to show by highlighting. I'm not sure the possibility that any part of this license is AI-generated matters though. Richard > > On Sat, Mar 14, 2026 at 4:16 PM PTFS wrote: >> >> I just want to note that the author may have used ChatGPT, and ZeroGPT indicates the text is approximately 59.7% AI-generated. That said, using AI doesn’t break any OSI rules. However, it’s worth mentioning because this license could still be challenged under the Open Source Definition (OSD). I’m highlighting this only for context, the AI patterns (shown in yellow in the full text) don’t make it invalid, but they could make reviewers scrutinize it more closely, which may increase the chance of AI-MIT getting rejected, The Full Text i will show it right now : Dear OSI License Review Committee, >> I am submitting the **AI-MIT License, Version 1.0** for consideration by the Open Source Initiative. ## Summary The AI-MIT License is a permissive open-source license designed to address a genuine gap: existing licenses were written for human authors and handle AI-generated code poorly, creating false implications about authorship and copyright status. The license is deliberately minimal — it preserves the structure and permissiveness of the MIT License while adding three targeted changes for the AI context. ## The problem it solves 1. **False authorship implication.** When `Copyright (c) [year] [author]` is applied to fully AI-generated code, it implies human authorship and copyright that may not legally exist in most jurisdictions. 2. **No standard for disclosure.** There is no widely adopted mechanism for disclosing whether code is AI-generated, AI-assisted, or human-authored. This matters for supply-chain security, regulatory compliance (EU AI Act), and intellectual honesty in open source. 3. **Undefined copyright status.** Fully autonomous AI-generated code (no human creative input) is in a legal grey zone in most jurisdictions. A license that claims copyright over it is at best misleading, at worst invalid. ## What the license does differently from MIT The license adds one structural element (the Authorship Declaration) and three conditions/clauses: **Authorship Declaration** — a required checkbox at the top of the LICENSE file with three modes: - *Fully AI-generated*: no copyright claimed; code dedicated to public domain - *AI-assisted*: human-directed, AI-generated; standard copyright applies - *Human-authored*: AI used as a tool only; identical to MIT posture **Condition 2 — Transparency**: redistribution or use as AI training data must not misrepresent AI origin as human authorship. **Condition 3 — No Copyright Claim**: for fully autonomous code, explicit public domain dedication (with a perpetual irrevocable fallback for jurisdictions where public domain dedication is impossible). **Extended disclaimer**: adds three AI-specific disclaimers about training data provenance, regulatory compliance, and jurisdictional limitations of the authorship declaration. ## OSD compliance analysis 1. **Free Redistribution** ✓ — no restriction on sale or distribution 2. **Source Code** ✓ — no source restriction 3. **Derived Works** ✓ — modification and redistribution permitted 4. **Integrity of the Author's Source Code** ✓ — no patch-file requirement; attribution preserved 5. **No Discrimination Against Persons or Groups** ✓ 6. **No Discrimination Against Fields of Endeavor** ✓ 7. **Distribution of License** ✓ — same rights apply to all recipients 8. **License Must Not Be Specific to a Product** ✓ 9. **License Must Not Restrict Other Software** ✓ 10. **License Must Be Technology-Neutral** ✓ The Transparency condition (Condition 2) requires disclosure of AI origin but does not restrict use in any field — it is an attribution/honesty requirement, not a field-of-endeavor restriction. ## SPDX identifier We are concurrently requesting the SPDX identifier `AI-MIT-1.0` through the SPDX GitHub repository. ## Repository The full license text, README, translations, and supporting materials are available at: https://github.com/ai-mit-license/ai-mit-license ## A note on meta-context This license was initially drafted with AI assistance (Claude, Anthropic) at the direction of a human. We believe this is appropriate and have disclosed it in the repository. The license is itself an example of the category of work it governs. We welcome feedback from the committee and the community at large. >> Best Regards >> Bernardo >> >> >> On Thu, Mar 12, 2026 at 7:25 PM Pamela Chestek wrote: >>> >>> Please review the license submission instructions, https://opensource.org/licenses/review-process, and provide all the information that you are asked to provide when you requesting review of a license. This includes providing a copy as an attachment. Websites change, so we cannot rely on links to accurately reflect what is being submitted. >>> >>> Pam >>> >>> Pamela S. Chestek >>> Chestek Legal >>> 300 Fayetteville Street >>> Unit 2492 >>> Raleigh, NC 27602 >>> pamela at chesteklegal.com >>> (919) 800-8033 >>> www.chesteklegal.com >>> >>> On 3/12/2026 4:21 AM, Nik wrote: >>> >>> Dear OSI License Review Committee, >>> >>> I am submitting the **AI-MIT License, Version 1.0** for consideration by the Open Source Initiative. >>> >>> ## Summary >>> >>> The AI-MIT License is a permissive open-source license designed to address a genuine gap: existing licenses were written for human authors and handle AI-generated code poorly, creating false implications about authorship and copyright status. >>> >>> The license is deliberately minimal — it preserves the structure and permissiveness of the MIT License while adding three targeted changes for the AI context. >>> >>> ## The problem it solves >>> >>> 1. **False authorship implication.** When `Copyright (c) [year] [author]` is applied to fully AI-generated code, it implies human authorship and copyright that may not legally exist in most jurisdictions. >>> >>> 2. **No standard for disclosure.** There is no widely adopted mechanism for disclosing whether code is AI-generated, AI-assisted, or human-authored. This matters for supply-chain security, regulatory compliance (EU AI Act), and intellectual honesty in open source. >>> >>> 3. **Undefined copyright status.** Fully autonomous AI-generated code (no human creative input) is in a legal grey zone in most jurisdictions. A license that claims copyright over it is at best misleading, at worst invalid. >>> >>> ## What the license does differently from MIT >>> >>> The license adds one structural element (the Authorship Declaration) and three conditions/clauses: >>> >>> **Authorship Declaration** — a required checkbox at the top of the LICENSE file with three modes: >>> - *Fully AI-generated*: no copyright claimed; code dedicated to public domain >>> - *AI-assisted*: human-directed, AI-generated; standard copyright applies >>> - *Human-authored*: AI used as a tool only; identical to MIT posture >>> >>> **Condition 2 — Transparency**: redistribution or use as AI training data must not misrepresent AI origin as human authorship. >>> >>> **Condition 3 — No Copyright Claim**: for fully autonomous code, explicit public domain dedication (with a perpetual irrevocable fallback for jurisdictions where public domain dedication is impossible). >>> >>> **Extended disclaimer**: adds three AI-specific disclaimers about training data provenance, regulatory compliance, and jurisdictional limitations of the authorship declaration. >>> >>> ## OSD compliance analysis >>> >>> 1. **Free Redistribution** ✓ — no restriction on sale or distribution >>> 2. **Source Code** ✓ — no source restriction >>> 3. **Derived Works** ✓ — modification and redistribution permitted >>> 4. **Integrity of the Author's Source Code** ✓ — no patch-file requirement; attribution preserved >>> 5. **No Discrimination Against Persons or Groups** ✓ >>> 6. **No Discrimination Against Fields of Endeavor** ✓ >>> 7. **Distribution of License** ✓ — same rights apply to all recipients >>> 8. **License Must Not Be Specific to a Product** ✓ >>> 9. **License Must Not Restrict Other Software** ✓ >>> 10. **License Must Be Technology-Neutral** ✓ >>> >>> The Transparency condition (Condition 2) requires disclosure of AI origin but does not restrict use in any field — it is an attribution/honesty requirement, not a field-of-endeavor restriction. >>> >>> ## SPDX identifier >>> >>> We are concurrently requesting the SPDX identifier `AI-MIT-1.0` through the SPDX GitHub repository. >>> >>> ## Repository >>> >>> The full license text, README, translations, and supporting materials are available at: >>> https://github.com/ai-mit-license/ai-mit-license >>> >>> ## A note on meta-context >>> >>> This license was initially drafted with AI assistance (Claude, Anthropic) at the direction of a human. We believe this is appropriate and have disclosed it in the repository. The license is itself an example of the category of work it governs. >>> >>> We welcome feedback from the committee and the community at large. >>> >>> Respectfully, >>> Nik >>> >>> _______________________________________________ >>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 From vicenttefelipe097 at gmail.com Tue Mar 17 10:56:25 2026 From: vicenttefelipe097 at gmail.com (Vicentte Felipe) Date: Tue, 17 Mar 2026 07:56:25 -0300 Subject: [License-review] License Review: Modified 0BSD License (Maintenance-Required) Message-ID: Dear OSI License Review Committee, ​I am formally submitting the Modified 0BSD License for review and approval against the Open Source Definition (OSD). ​Following previous feedback regarding trademark concerns, I have renamed and refactored the license. It is now based on the established BSD Zero Clause License (0BSD) framework, but with a specific modification to address developer accountability. ​Submission Details: ​License Name: Modified 0BSD License (Maintenance-Required) ​Version: 1.0 ​Official Repository: https://github.com/Vicenttefelipe097/Modified-0BSD-License ​Rationale: To provide a "Zero-Attribution" permissive license that replaces the standard "AS-IS" disclaimer with a "Duty to Repair." This ensures that users can rely on a commitment to maintenance while enjoying the freedom of a 0BSD-style grant. ​License Text: Modified 0BSD License (Maintenance-Required) Copyright (c) 2026 Vicentte Felipe Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted. THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): Unlike the standard 0BSD license, this software is NOT provided "as-is." The Author(s) and/or Distributor(s) accept an affirmative obligation to: 1. Review and address reported technical defects and bugs. 2. Use best efforts to provide fixes for issues that impair the software’s intended functionality. LIMITATION OF LIABILITY: THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE OBLIGATIONS STATED ABOVE. I believe this modification maintains the spirit of open source while providing a modern framework for professional stewardship. I look forward to the committee’s feedback. ​Best regards, ​Vicentte Felipe Software Developer & Architect https://github.com/Vicenttefelipe097 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.osi-license-review at kevin.km6g.us Tue Mar 17 13:45:43 2026 From: lists.osi-license-review at kevin.km6g.us (Kevin P. Fleming) Date: Tue, 17 Mar 2026 09:45:43 -0400 Subject: [License-review] License Review: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: Message-ID: On Tue, Mar 17, 2026, at 06:56, Vicentte Felipe wrote: > THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): > Unlike the standard 0BSD license, this software is NOT provided "as-is." > The Author(s) and/or Distributor(s) accept an affirmative obligation to: > 1. Review and address reported technical defects and bugs. > 2. Use best efforts to provide fixes for issues that impair the software’s > intended functionality. IANAL, but this obligation appears to be functionally pointless. First, I can't imagine any 'distributor' being willing to take on this obligation, so that means software published using this license would not be included in any Linux distribution or be publishable on a well-known package or container repository (PyPI, DockerHub, crates.io). Second, since this type of license is "accept on use or distribution", and the authors have no idea who is using the software, how could this even be enforced? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mccoy at lexpan.law Tue Mar 17 13:59:09 2026 From: mccoy at lexpan.law (McCoy Smith) Date: Tue, 17 Mar 2026 06:59:09 -0700 Subject: [License-review] License Review: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: Message-ID: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> Vicentte: In order for this license to be considered for approval, you need to answer all the questions set forth in the process for approval, found here: https://opensource.org/licenses/review-process If you want this license to be considered for approval, please follow the process as indicated on OSI's website. On 3/17/2026 3:56 AM, Vicentte Felipe wrote: > Dear OSI License Review Committee, > ​I am formally submitting the Modified 0BSD License for review and > approval against the Open Source Definition (OSD). > ​Following previous feedback regarding trademark concerns, I have > renamed and refactored the license. It is now based on the established > BSD Zero Clause License (0BSD) framework, but with a specific > modification to address developer accountability. > ​Submission Details: > ​License Name: Modified 0BSD License (Maintenance-Required) > ​Version: 1.0 > ​Official Repository: > https://github.com/Vicenttefelipe097/Modified-0BSD-License > ​Rationale: To provide a "Zero-Attribution" permissive license that > replaces the standard "AS-IS" disclaimer with a "Duty to Repair." This > ensures that users can rely on a commitment to maintenance while > enjoying the freedom of a 0BSD-style grant. > ​License Text: > Modified 0BSD License (Maintenance-Required) > Copyright (c) 2026 Vicentte Felipe > > Permission to use, copy, modify, and/or distribute this software for any > purpose with or without fee is hereby granted. > > THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): > Unlike the standard 0BSD license, this software is NOT provided "as-is." > The Author(s) and/or Distributor(s) accept an affirmative obligation to: > 1. Review and address reported technical defects and bugs. > 2. Use best efforts to provide fixes for issues that impair the > software’s >    intended functionality. > > LIMITATION OF LIABILITY: > THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF > USE, > DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR > PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE > OBLIGATIONS STATED ABOVE. > I believe this modification maintains the spirit of open source while > providing a modern framework for professional stewardship. I look > forward to the committee’s feedback. > ​Best regards, > ​Vicentte Felipe Software Developer & Architect > https://github.com/Vicenttefelipe097 > > _______________________________________________ > 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 From vicenttefelipe097 at gmail.com Tue Mar 17 15:24:02 2026 From: vicenttefelipe097 at gmail.com (Vicentte Felipe) Date: Tue, 17 Mar 2026 12:24:02 -0300 Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> Message-ID: Dear License Review Committee, ​Pursuant to the OSI License Review Process, I am providing the formal responses required for the review of the Modified 0BSD License. ​1. Support for the Open Source Definition (OSD): The license complies with all 10 criteria of the OSD. It allows for free redistribution, includes source code, allows for derived works, and does not discriminate against any persons or fields of endeavor. ​2. Unique Benefits: Currently, most permissive licenses (MIT, BSD, 0BSD) include a total disclaimer of warranty ("AS-IS"). This license provides a middle ground for developers who wish to offer a high degree of freedom (Zero Attribution) while legally committing to the quality and maintenance of the code. It provides "Accountable Open Source." ​3. Proliferation Category: This is a Special Purpose License. It is not intended to replace the MIT or 0BSD licenses for all users, but rather to serve projects where the developer wants to provide a "Maintenance Mandate" as a core feature of the software's distribution. ​4. Comparison to Similar Licenses: ​Vs. 0BSD: It is identical in its grant of rights and removal of attribution, but it removes the "AS-IS" clause and replaces it with the "Maintenance Obligation." ​Vs. TAPR Open Hardware License: Like some hardware licenses, it focuses on the "Duty to Repair" or maintain, but adapted for software. ​5. Legal Analysis: The "Maintenance Obligation" is structured as a Condition of the License. If the maintainer or distributor fails to fulfill the duty to repair, the license grant is technically revoked, ensuring that "dead" or "unmaintained" forks cannot claim to be part of the supported ecosystem. ​6. Formal License Text: Modified 0BSD License (Maintenance-Required) Copyright (c) 2026 Vicentte Felipe Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted. THE MAINTENANCE OBLIGATION: Unlike the standard 0BSD license, this software is NOT provided "as-is." The Original Author(s) and/or those who explicitly claim to provide a supported version of this software accept an affirmative obligation to: ​Review and address reported technical defects. LIMITATION OF LIABILITY: THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE OBLIGATIONS STATED ABOVE. El mar, 17 de mar de 2026, 11:00, McCoy Smith escribió: > Vicentte: > > In order for this license to be considered for approval, you need to > answer all the questions set forth in the process for approval, found > here: https://opensource.org/licenses/review-process > > If you want this license to be considered for approval, please follow > the process as indicated on OSI's website. > > On 3/17/2026 3:56 AM, Vicentte Felipe wrote: > > Dear OSI License Review Committee, > > ​I am formally submitting the Modified 0BSD License for review and > > approval against the Open Source Definition (OSD). > > ​Following previous feedback regarding trademark concerns, I have > > renamed and refactored the license. It is now based on the established > > BSD Zero Clause License (0BSD) framework, but with a specific > > modification to address developer accountability. > > ​Submission Details: > > ​License Name: Modified 0BSD License (Maintenance-Required) > > ​Version: 1.0 > > ​Official Repository: > > https://github.com/Vicenttefelipe097/Modified-0BSD-License > > ​Rationale: To provide a "Zero-Attribution" permissive license that > > replaces the standard "AS-IS" disclaimer with a "Duty to Repair." This > > ensures that users can rely on a commitment to maintenance while > > enjoying the freedom of a 0BSD-style grant. > > ​License Text: > > Modified 0BSD License (Maintenance-Required) > > Copyright (c) 2026 Vicentte Felipe > > > > Permission to use, copy, modify, and/or distribute this software for any > > purpose with or without fee is hereby granted. > > > > THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): > > Unlike the standard 0BSD license, this software is NOT provided "as-is." > > The Author(s) and/or Distributor(s) accept an affirmative obligation to: > > 1. Review and address reported technical defects and bugs. > > 2. Use best efforts to provide fixes for issues that impair the > > software’s > > intended functionality. > > > > LIMITATION OF LIABILITY: > > THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR > > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF > > USE, > > DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER > > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR > > PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE > > OBLIGATIONS STATED ABOVE. > > I believe this modification maintains the spirit of open source while > > providing a modern framework for professional stewardship. I look > > forward to the committee’s feedback. > > ​Best regards, > > ​Vicentte Felipe Software Developer & Architect > > https://github.com/Vicenttefelipe097 > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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: From mccoy at lexpan.law Tue Mar 17 15:41:51 2026 From: mccoy at lexpan.law (McCoy Smith) Date: Tue, 17 Mar 2026 08:41:51 -0700 Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> Message-ID: You do not appear to have answered the following questions per the license review guidelines: * Submit a copy of the license as an attachment in simple text format.     This is requested because repositories can change and we need to have a fixed text that all reviewers can review. * Identify what projects are already using the license.     You have not indicated any projects that are using, or are proposing to use, this license. * Provide the identity and contact details of the license steward, if known, and of the submitter. The OSI will try to get in touch with the license steward if the license submitter is not the steward.     If you are the steward, you should identify yourself as such (since the license has your (C) notice on it I assume you are the steward, but you should state so affirmatively). *  Provide any additional information that the submitter believes would be helpful for license review. For example, approval of the license by Debian, the FSF or the Fedora Project would be relevant to the review process.     If no other approvals exist, you should state so.  * If any exist, provide the unique identifier by other projects, like SPDX or ScanCode.     If no identifiers exist, you should state so. *  Describe any legal review the license has been through, including whether it was drafted by a lawyer.     You have listed a "legal analysis" but have not indicated if any lawyer was involved in that analysis or the drafting of the license. In particular, I think there needs to be some description how the affirmative obligation may be binding on the recipient under the terms of this agreement. On 3/17/2026 8:24 AM, Vicentte Felipe wrote: > Dear License Review Committee, > ​Pursuant to the OSI License Review Process, I am providing the formal > responses required for the review of the Modified 0BSD License. > ​1. Support for the Open Source Definition (OSD): > The license complies with all 10 criteria of the OSD. It allows for > free redistribution, includes source code, allows for derived works, > and does not discriminate against any persons or fields of endeavor. > ​2. Unique Benefits: > Currently, most permissive licenses (MIT, BSD, 0BSD) include a total > disclaimer of warranty ("AS-IS"). This license provides a middle > ground for developers who wish to offer a high degree of freedom (Zero > Attribution) while legally committing to the quality and maintenance > of the code. It provides "Accountable Open Source." > ​3. Proliferation Category: > This is a Special Purpose License. It is not intended to replace the > MIT or 0BSD licenses for all users, but rather to serve projects where > the developer wants to provide a "Maintenance Mandate" as a core > feature of the software's distribution. > ​4. Comparison to Similar Licenses: > ​Vs. 0BSD: It is identical in its grant of rights and removal of > attribution, but it removes the "AS-IS" clause and replaces it with > the "Maintenance Obligation." > ​Vs. TAPR Open Hardware License: Like some hardware licenses, it > focuses on the "Duty to Repair" or maintain, but adapted for software. > ​5. Legal Analysis: > The "Maintenance Obligation" is structured as a Condition of the > License. If the maintainer or distributor fails to fulfill the duty to > repair, the license grant is technically revoked, ensuring that "dead" > or "unmaintained" forks cannot claim to be part of the supported > ecosystem. > ​6. Formal License Text: > Modified 0BSD License (Maintenance-Required) > Copyright (c) 2026 Vicentte Felipe > > Permission to use, copy, modify, and/or distribute this software for any > purpose with or without fee is hereby granted. > > THE MAINTENANCE OBLIGATION: > Unlike the standard 0BSD license, this software is NOT provided "as-is." > The Original Author(s) and/or those who explicitly claim to provide a > supported version of this software accept an affirmative obligation to: > ​Review and address reported technical defects. > > LIMITATION OF LIABILITY: > THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF > USE, > DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR > PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE > OBLIGATIONS STATED ABOVE. > > El mar, 17 de mar de 2026, 11:00, McCoy Smith escribió: > > Vicentte: > > In order for this license to be considered for approval, you need to > answer all the questions set forth in the process for approval, found > here: https://opensource.org/licenses/review-process > > If you want this license to be considered for approval, please follow > the process as indicated on OSI's website. > > On 3/17/2026 3:56 AM, Vicentte Felipe wrote: > > Dear OSI License Review Committee, > > ​I am formally submitting the Modified 0BSD License for review and > > approval against the Open Source Definition (OSD). > > ​Following previous feedback regarding trademark concerns, I have > > renamed and refactored the license. It is now based on the > established > > BSD Zero Clause License (0BSD) framework, but with a specific > > modification to address developer accountability. > > ​Submission Details: > > ​License Name: Modified 0BSD License (Maintenance-Required) > > ​Version: 1.0 > > ​Official Repository: > > https://github.com/Vicenttefelipe097/Modified-0BSD-License > > ​Rationale: To provide a "Zero-Attribution" permissive license that > > replaces the standard "AS-IS" disclaimer with a "Duty to > Repair." This > > ensures that users can rely on a commitment to maintenance while > > enjoying the freedom of a 0BSD-style grant. > > ​License Text: > > Modified 0BSD License (Maintenance-Required) > > Copyright (c) 2026 Vicentte Felipe > > > > Permission to use, copy, modify, and/or distribute this software > for any > > purpose with or without fee is hereby granted. > > > > THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): > > Unlike the standard 0BSD license, this software is NOT provided > "as-is." > > The Author(s) and/or Distributor(s) accept an affirmative > obligation to: > > 1. Review and address reported technical defects and bugs. > > 2. Use best efforts to provide fixes for issues that impair the > > software’s > >    intended functionality. > > > > LIMITATION OF LIABILITY: > > THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, > INDIRECT, OR > > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM > LOSS OF > > USE, > > DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR > OTHER > > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR > > PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE > MAINTENANCE > > OBLIGATIONS STATED ABOVE. > > I believe this modification maintains the spirit of open source > while > > providing a modern framework for professional stewardship. I look > > forward to the committee’s feedback. > > ​Best regards, > > ​Vicentte Felipe Software Developer & Architect > > https://github.com/Vicenttefelipe097 > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 > > > _______________________________________________ > 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: From vicenttefelipe097 at gmail.com Tue Mar 17 22:03:02 2026 From: vicenttefelipe097 at gmail.com (Vicentte Felipe) Date: Tue, 17 Mar 2026 19:03:02 -0300 Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> Message-ID: Dear McCoy and the License Review Committee, ​Thank you for your patience as I refine this submission. I am providing the updated project context and the formal declarations requested. ​1. Projects Utilizing the License The license is primarily intended for a specialized framework built on React (by Meta). The goal is to provide a "Zero-Attribution" alternative to the MIT license that ensures long-term maintenance and compatibility for React-based UI components. ​2. Legal Analysis of the Affirmative Obligation Regarding the "Duty to Repair" in a non-attribution context: ​Contractual Condition: The "Maintenance Obligation" is a condition precedent to the license grant. While the user is not required to provide attribution, the Author's right to distribute the software is contingent upon their commitment to the "Duty to Repair." ​Binding Nature: If the maintainer fails to provide "best efforts" to address defects (such as breaking changes in the underlying React framework), they are in breach of the license conditions. ​3. Identity of Steward and Submitter I, Vicentte Felipe, am the submitter and the License Steward. ​Contact: vicenttefelipe097 at gmail.com ​4. External Approvals & Identifiers ​No prior approvals from FSF, Debian, or Fedora exist. ​No SPDX or ScanCode identifiers exist yet. ​5. License Text (Fixed) I have attached the fixed LICENSE.txt to this email for the permanent record. ​Best regards, ​Vicentte Felipe Software Developer & Architect https://github.com/Vicenttefelipe097/Modified-0BSD-License El mar, 17 de mar de 2026, 12:42, McCoy Smith escribió: > You do not appear to have answered the following questions per the license > review guidelines: > > * Submit a copy of the license as an attachment in simple text format. > > This is requested because repositories can change and we need to have > a fixed text that all reviewers can review. > > * Identify what projects are already using the license. > > You have not indicated any projects that are using, or are proposing > to use, this license. > > * Provide the identity and contact details of the license steward, if > known, and of the submitter. The OSI will try to get in touch with the > license steward if the license submitter is not the steward. > > If you are the steward, you should identify yourself as such (since > the license has your (C) notice on it I assume you are the steward, but you > should state so affirmatively). > > * Provide any additional information that the submitter believes would be > helpful for license review. For example, approval of the license by Debian, > the FSF or the Fedora Project would be relevant to the review process. > > If no other approvals exist, you should state so. > > * If any exist, provide the unique identifier by other projects, like > SPDX or ScanCode. > > If no identifiers exist, you should state so. > > * Describe any legal review the license has been through, including > whether it was drafted by a lawyer. > > You have listed a "legal analysis" but have not indicated if any > lawyer was involved in that analysis or the drafting of the license. In > particular, I think there needs to be some description how the affirmative > obligation may be binding on the recipient under the terms of this > agreement. > On 3/17/2026 8:24 AM, Vicentte Felipe wrote: > > Dear License Review Committee, > ​Pursuant to the OSI License Review Process, I am providing the formal > responses required for the review of the Modified 0BSD License. > ​1. Support for the Open Source Definition (OSD): > The license complies with all 10 criteria of the OSD. It allows for free > redistribution, includes source code, allows for derived works, and does > not discriminate against any persons or fields of endeavor. > ​2. Unique Benefits: > Currently, most permissive licenses (MIT, BSD, 0BSD) include a total > disclaimer of warranty ("AS-IS"). This license provides a middle ground for > developers who wish to offer a high degree of freedom (Zero Attribution) > while legally committing to the quality and maintenance of the code. It > provides "Accountable Open Source." > ​3. Proliferation Category: > This is a Special Purpose License. It is not intended to replace the MIT > or 0BSD licenses for all users, but rather to serve projects where the > developer wants to provide a "Maintenance Mandate" as a core feature of the > software's distribution. > ​4. Comparison to Similar Licenses: > ​Vs. 0BSD: It is identical in its grant of rights and removal of > attribution, but it removes the "AS-IS" clause and replaces it with the > "Maintenance Obligation." > ​Vs. TAPR Open Hardware License: Like some hardware licenses, it focuses > on the "Duty to Repair" or maintain, but adapted for software. > ​5. Legal Analysis: > The "Maintenance Obligation" is structured as a Condition of the License. > If the maintainer or distributor fails to fulfill the duty to repair, the > license grant is technically revoked, ensuring that "dead" or > "unmaintained" forks cannot claim to be part of the supported ecosystem. > ​6. Formal License Text: > Modified 0BSD License (Maintenance-Required) > Copyright (c) 2026 Vicentte Felipe > > Permission to use, copy, modify, and/or distribute this software for any > purpose with or without fee is hereby granted. > > THE MAINTENANCE OBLIGATION: > Unlike the standard 0BSD license, this software is NOT provided "as-is." > The Original Author(s) and/or those who explicitly claim to provide a > supported version of this software accept an affirmative obligation to: > ​Review and address reported technical defects. > > LIMITATION OF LIABILITY: > THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF > USE, > DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR > PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE > OBLIGATIONS STATED ABOVE. > > El mar, 17 de mar de 2026, 11:00, McCoy Smith > escribió: > >> Vicentte: >> >> In order for this license to be considered for approval, you need to >> answer all the questions set forth in the process for approval, found >> here: https://opensource.org/licenses/review-process >> >> If you want this license to be considered for approval, please follow >> the process as indicated on OSI's website. >> >> On 3/17/2026 3:56 AM, Vicentte Felipe wrote: >> > Dear OSI License Review Committee, >> > ​I am formally submitting the Modified 0BSD License for review and >> > approval against the Open Source Definition (OSD). >> > ​Following previous feedback regarding trademark concerns, I have >> > renamed and refactored the license. It is now based on the established >> > BSD Zero Clause License (0BSD) framework, but with a specific >> > modification to address developer accountability. >> > ​Submission Details: >> > ​License Name: Modified 0BSD License (Maintenance-Required) >> > ​Version: 1.0 >> > ​Official Repository: >> > https://github.com/Vicenttefelipe097/Modified-0BSD-License >> > ​Rationale: To provide a "Zero-Attribution" permissive license that >> > replaces the standard "AS-IS" disclaimer with a "Duty to Repair." This >> > ensures that users can rely on a commitment to maintenance while >> > enjoying the freedom of a 0BSD-style grant. >> > ​License Text: >> > Modified 0BSD License (Maintenance-Required) >> > Copyright (c) 2026 Vicentte Felipe >> > >> > Permission to use, copy, modify, and/or distribute this software for any >> > purpose with or without fee is hereby granted. >> > >> > THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): >> > Unlike the standard 0BSD license, this software is NOT provided "as-is." >> > The Author(s) and/or Distributor(s) accept an affirmative obligation to: >> > 1. Review and address reported technical defects and bugs. >> > 2. Use best efforts to provide fixes for issues that impair the >> > software’s >> > intended functionality. >> > >> > LIMITATION OF LIABILITY: >> > THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR >> > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF >> > USE, >> > DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER >> > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR >> > PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE >> > OBLIGATIONS STATED ABOVE. >> > I believe this modification maintains the spirit of open source while >> > providing a modern framework for professional stewardship. I look >> > forward to the committee’s feedback. >> > ​Best regards, >> > ​Vicentte Felipe Software Developer & Architect >> > https://github.com/Vicenttefelipe097 >> > >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 listLicense-review at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org > > _______________________________________________ > 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: -------------- next part -------------- Modified 0BSD License (Maintenance-Required) Copyright (c) 2026 Vicentte Felipe Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted. THE MAINTENANCE OBLIGATION: Unlike the standard 0BSD license, this software is NOT provided "as-is." The Original Author(s) and/or those who explicitly claim to provide a supported version of this software accept an affirmative obligation to: ​Review and address reported technical defects. LIMITATION OF LIABILITY: THE AUTHOR(S) SHALL NOT BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. THE REMEDY IS LIMITED TO THE MAINTENANCE OBLIGATIONS STATED ABOVE. From rob at landley.net Tue Mar 17 22:13:04 2026 From: rob at landley.net (Rob Landley) Date: Tue, 17 Mar 2026 17:13:04 -0500 Subject: [License-review] License Review: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: Message-ID: <34e7a1a6-862f-44d0-8e69-71b0c9f1bb58@landley.net> On 3/17/26 05:56, Vicentte Felipe wrote: > Dear OSI License Review Committee, > ​I am formally submitting the Modified 0BSD License for review and approval > against the Open Source Definition (OSD). I created 0BSD in 2013, got it approved by SPDX, walked it through the github choose-a-license approval process, and I am 100% opposed to this. Please call it something else unrelated to 0BSD. (How about 0ISC?) > ​Following previous feedback regarding trademark concerns, Copyrights, trademarks, patents, trade secrets are all DIFFERENT THINGS. They are different areas of law. 0BSD is JUST a copyright license. If you want to license patents, put a patent license alongside it. If you want to mess with trademarks, add a trademark license alongside it. > THE MAINTENANCE OBLIGATION (THE VICENTTE DUTY): > Unlike the standard 0BSD license, this software is NOT provided "as-is." > The Author(s) and/or Distributor(s) accept an affirmative obligation to: > 1. Review and address reported technical defects and bugs. > 2. Use best efforts to provide fixes for issues that impair the software’s > intended functionality. The entire POINT of 0BSD was to be a simple public domain equivalent license that was layman-comprehensible enough for all the developers (from qmail through "the most popular license on github is no license") who were refusing to license their code AT ALL (or trying to do ad-hoc public domain declarations) to maybe get talked into using this thing, while at the same time getting rubber stamped by large corporations who had already accepted 2, 3, and 4 clause BSD licenses and went "oh yeah, another one" and let it in. This is NOT THAT. Please don't muddy the waters. If you want to create a new license, by all means do so. But you clearly have no comprehension of what the POINT of this license was, nor why it gained adoption. > I believe this modification maintains the spirit of open source while No it fucking does not. I can walk away from my open source projects at any time. I can (and do!) ignore patches to make toybox work on windows because I don't want to go there. I do not OWE you fixes for free in perpetuity! Your "duty" is more onerous than the GPL's "virality". And how the HELL do you square the circle of 80% of the original license by weight being a disclaimer that this thing is in ANY WAY fit for purpose (caveat emptor and then some) with "I solemnly swear to use my best efforts to fix any reported bugs for free, forever". (And a bug is anything the reporter thinks it is including new features or a different user interface or just me explaining that they don't know how to use it or we intentionally didn't support that input format and are not going to start now...) Just... no. > providing a modern framework for professional stewardship. I look forward > to the committee’s feedback. Hello no. At the VERY least, please call it something else, unrelated to 0BSD. Rob From josh at berkus.org Tue Mar 17 23:26:17 2026 From: josh at berkus.org (Josh Berkus) Date: Tue, 17 Mar 2026 16:26:17 -0700 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: References: Message-ID: <8f5b4122-0de7-4ef7-a4a4-e75d39ae3ea5@berkus.org> On 3/15/26 5:46 PM, Richard Fontana via License-review wrote: > I'm not sure the possibility that any part of this license is > AI-generated matters though. It matters for claiming copyright over the license itself, but we don't care about that. There is no requirement that the license be copyrightable. -- Josh Berkus From josh at berkus.org Tue Mar 17 23:28:46 2026 From: josh at berkus.org (Josh Berkus) Date: Tue, 17 Mar 2026 16:28:46 -0700 Subject: [License-review] License Review: Modified 0BSD License (Maintenance-Required) In-Reply-To: <34e7a1a6-862f-44d0-8e69-71b0c9f1bb58@landley.net> References: <34e7a1a6-862f-44d0-8e69-71b0c9f1bb58@landley.net> Message-ID: <6409bc26-ab76-4152-8845-72b76ab6c8cf@berkus.org> On 3/17/26 3:13 PM, Rob Landley wrote: > > I created 0BSD in 2013, got it approved by SPDX, walked it through the > github choose-a-license approval process, and I am 100% opposed to this. > > Please call it something else unrelated to 0BSD. (How about 0ISC?) You know I wouldn't let this pass either Rob. ;-) Yeah, it can't be published as "Modified 0BSD License". However, there are more serious problems with the license than the name; it's unlikely to get listed at all. -- Josh Berkus From josh at berkus.org Tue Mar 17 23:37:46 2026 From: josh at berkus.org (Josh Berkus) Date: Tue, 17 Mar 2026 16:37:46 -0700 Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> Message-ID: <87add696-6a73-4aea-aa8c-9e066dbebc68@berkus.org> On 3/17/26 3:03 PM, Vicentte Felipe wrote: > ​Contractual Condition: The "Maintenance Obligation" is a condition > precedent to the license grant. While the user is not required to > provide attribution, the Author's right to distribute the software is > contingent upon their commitment to the "Duty to Repair." > ​Binding Nature: If the maintainer fails to provide "best efforts" to > address defects (such as breaking changes in the underlying React > framework), they are in breach of the license conditions. I don't understand what you're expecting to accomplish with this license. "The Original Author(s) and/or those who explicitly claim to provide a supported version of this software accept an affirmative obligation to: ​Review and address reported technical defects." First, "original author" is meaningless given that you haven't defined it in the license. If distributors are "claiming to provide support", surely addressing technical defects is a matter for the support contract? How would you define, or prove, "claiming to provide support"? Who judges whether defects have been "addressed"? Who defines a "defect"? If your goal is to build a stronger React framework community by pledging to address defect reports yourself, surely there are more effective, and easier, ways to do that than a license? Licenses aren't tools for social engineering. If you're trying to build a commercially and technically successful community, clever license terms aren't going to do that for you. You have to do the actual community-building work. -- Josh Berkus From pamela at chesteklegal.com Wed Mar 18 00:19:31 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Tue, 17 Mar 2026 17:19:31 -0700 Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: <87add696-6a73-4aea-aa8c-9e066dbebc68@berkus.org> References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> <87add696-6a73-4aea-aa8c-9e066dbebc68@berkus.org> Message-ID: IMO this license should be rejected for the reasons that Josh gives. It is nonsensical. Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com On 3/17/2026 4:37 PM, Josh Berkus wrote: > On 3/17/26 3:03 PM, Vicentte Felipe wrote: >> ​Contractual Condition: The "Maintenance Obligation" is a condition >> precedent to the license grant. While the user is not required to >> provide attribution, the Author's right to distribute the software is >> contingent upon their commitment to the "Duty to Repair." >> ​Binding Nature: If the maintainer fails to provide "best efforts" to >> address defects (such as breaking changes in the underlying React >> framework), they are in breach of the license conditions. > > I don't understand what you're expecting to accomplish with this license. > > "The Original Author(s) and/or those who explicitly claim to provide a > supported version of this software accept an affirmative obligation to: > ​Review and address reported technical defects." > > First, "original author" is meaningless given that you haven't defined > it in the license. > > If distributors are "claiming to provide support", surely addressing > technical defects is a matter for the support contract?  How would you > define, or prove, "claiming to provide support"?  Who judges whether > defects have been "addressed"?  Who defines a "defect"? > > If your goal is to build a stronger React framework community by > pledging to address defect reports yourself, surely there are more > effective, and easier, ways to do that than a license? > > Licenses aren't tools for social engineering.  If you're trying to > build a commercially and technically successful community, clever > license terms aren't going to do that for you.  You have to do the > actual community-building work. > From lists.osi-license-review at kevin.km6g.us Wed Mar 18 10:20:23 2026 From: lists.osi-license-review at kevin.km6g.us (Kevin P. Fleming) Date: Wed, 18 Mar 2026 06:20:23 -0400 Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> Message-ID: <028b66cd-7fe9-4a57-8a63-250de5a5345a@app.fastmail.com> On Tue, Mar 17, 2026, at 18:06, Vicentte Felipe wrote: > Binding Nature: If the maintainer fails to provide "best efforts" to address defects (such as breaking changes in the underlying React framework), they are in breach of the license conditions. And... then what? What happens in order to cure this breach? If they don't cure the breach, what happens? Most importantly, the *maintainers* are not subject to the license conditions at all, since they are the copyright holders and can choose to distribute the software under any license they wish. There is literally no recourse provided by this license which would 'force' them to distribute updated versions of the software - the consumers of the software have the same options they have with any other license, which is to stop using the software, or possibly fork it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlo at piana.eu Wed Mar 18 14:10:49 2026 From: carlo at piana.eu (Carlo Piana) Date: Wed, 18 Mar 2026 15:10:49 +0100 (CET) Subject: [License-review] Official Submission: Modified 0BSD License (Maintenance-Required) In-Reply-To: <028b66cd-7fe9-4a57-8a63-250de5a5345a@app.fastmail.com> References: <5a04a8be-d4fb-4463-9a8a-6ea37a48197c@lexpan.law> <028b66cd-7fe9-4a57-8a63-250de5a5345a@app.fastmail.com> Message-ID: <994679175.8900141.1773843049399.JavaMail.zimbra@piana.eu> The obligation appears to be largely unenforceable, vague, and contractually ill-conceived; further details follow. What is most important in my reading is that it imposes a positive obligation to modify the software, even when tied to a purported "supported" status. It remains a positive obligation on which the license is conditioned, and it does not fulfill the requirement of #2 -- the obligation to provide the complete source code when it is not already part of the distribution. In my view, this is not substantially different from requiring a fee or royalty for commercial distribution. Consequently, it appears to conflict with #1, as the fee or royalty is in kind and effectively becomes a maintenance service obligation. Regardless who the original author is (whether the code writer or the first party applying this license to code obtained under another license), adopting this license seems either imprudent or strategically clever. It could be considered imprudent if the obligation applies to them, but potentially strategic if they can avoid the obligation because the copyright holder is positioned to avoid non‑compliance with the condition. Additionally, an obligation typically requires a debtor and a designated entitled party. It is unclear who is entitled -- whether all users, free users, and under what timeframe; whether the entitlement persists indefinitely or only while the "supported status" is claimed; under which SLA; what the consequences of inadequate maintenance are; and whether any liability limitations exist, especially given the potential for significant damages (see further). Regarding a best‑effort commitment, the license language does not explicitly state the terms. This introduces additional complexities that lawyers typically address in software support agreements; such details are difficult to capture in a brief license and may be beyond the author's practical understanding. Finally, the phrase "the remedy is limited to the maintenance obligations stated above" raises questions about which remedy is referenced -- the limitation itself or a tort remedy such as damages. The limitation appears to relate to the use or performance of the software, rather than to the performance of the maintenance obligation. What are the implications of this distinction? I believe this license is not suitable for approval, for several reasons, including those raised by Josh and Pam and its potentially confusing name. I recommend that licenses be examined more thoroughly -- including by a competent lawyer, as the submission instructions recommend -- before we invest our collective professional time -- and associated costs -- into dissecting new licenses. It seems unlikely that an individual without extensive experience could surpass the collective expertise of the many professionals who have crafted hundreds of licenses over the past 25 years, many of which are used by hundreds of thousands of packages. Cheers Carlo, in his personal capacity. From nik.sharky at gmail.com Thu Mar 19 14:26:10 2026 From: nik.sharky at gmail.com (Nik) Date: Thu, 19 Mar 2026 16:26:10 +0200 Subject: [License-review] =?utf-8?q?=5BSUBMISSION=5D_AI-MIT_License_1?= =?utf-8?q?=2E0_=E2=80=94_permissive_license_for_AI-generated_code?= In-Reply-To: <1f2df46a-cc03-4d63-b004-9e06421e2993@berkus.org> References: <18108e57-6a6e-4930-814a-d84e30f4b27f@opensource.org> <1f2df46a-cc03-4d63-b004-9e06421e2993@berkus.org> Message-ID: Thank you — the point was absolutely correct: a proposal like this should be discussed and iterated before entering formal review. With that in mind, please consider this a request to withdraw the current submission from license-review. If there is a more formal or preferred way to do that on this list, please let me know. I will not post further draft revisions in this review thread. My next step will be to summarize the discussion so far, revise the draft more carefully, and continue the concept in a new thread on license-discuss before any future formal submission. Thank you to everyone who took the time to participate and comment. -- Best regards, Nik Babichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Max.Mehl at deutschebahn.com Fri Mar 20 16:13:34 2026 From: Max.Mehl at deutschebahn.com (Max Mehl) Date: Fri, 20 Mar 2026 16:13:34 +0000 Subject: [License-review] Submission: Python-2.0.1 Message-ID: Dear all, Following a discussion on license-discuss@ and a quick coordination with Deb from the Python Software Foundation (in Cc), I would like to propose that Python-2.0.1 be considered an officially approved (legacy) Open Source license. In the same step, I propose to mark Python-2.0 as either Superseded or Voluntarily Retired. In parallel, I propose the same for CNRI-Python-GPL-Compatible, for which I opened a separate thread. I will not repeat all the backstory but refer to the aforementioned discussion and spdx/license-list-XML#2197. In short: Python-2.0.1 is the license that most closely represents the license under which CPython has been published since 2001 (in combination with 0BSD for documentation). In comparison with Python-2.0, which is already OSI approved, the most remarkable difference is an update in the CNRI portion to make it GPL compatible. Attached, you will find the license text for Python-2.0.1 as made available by SPDX, as well as a diff file against Python-2.0 (ignoring formatting and some non-critical boilerplate texts to make things easier for you). Best, Max -- Max Mehl Open Source / Supply Chain Enterprise-Team Chief Technology Office (CTO) DB Systel GmbH / Deutsche Bahn Schedule a meeting: cal.com/mxmehl ________________________________ Pflichtangaben anzeigen N?here Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: https://www.deutschebahn.com/de/konzern/datenschutz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2 -------------------------------------------- 1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using this software ("Python") in source or binary form and its associated documentation. 2. Subject to the terms and conditions of this License Agreement, PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version, provided, however, that PSF's License Agreement and PSF's notice of copyright, i.e., "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Python Software Foundation; All Rights Reserved" are retained in Python alone or in any derivative version prepared by Licensee. 3. In the event Licensee prepares a derivative work that is based on or incorporates Python or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python. 4. PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between PSF and Licensee. This License Agreement does not grant permission to use PSF trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By copying, installing or otherwise using Python, Licensee agrees to be bound by the terms and conditions of this License Agreement. BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0 ------------------------------------------- BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1 1. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization ("Licensee") accessing and otherwise using this software in source or binary form and its associated documentation ("the Software"). 2. Subject to the terms and conditions of this BeOpen Python License Agreement, BeOpen hereby grants Licensee a non-exclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use the Software alone or in any derivative version, provided, however, that the BeOpen Python License is retained in the Software, alone or in any derivative version prepared by Licensee. 3. BeOpen is making the Software available to Licensee on an "AS IS" basis. BEOPEN MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 5. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 6. This License Agreement shall be governed by and interpreted in all respects by the law of the State of California, excluding conflict of law provisions. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between BeOpen and Licensee. This License Agreement does not grant permission to use BeOpen trademarks or trade names in a trademark sense to endorse or promote products or services of Licensee, or any third party. As an exception, the "BeOpen Python" logos available at http://www.pythonlabs.com/logos.html may be used according to the permissions granted on that web page. 7. By copying, installing or otherwise using the software, Licensee agrees to be bound by the terms and conditions of this License Agreement. CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1 --------------------------------------- 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6.1 software in source or binary form and its associated documentation. 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python 1.6.1 alone or in any derivative version, provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright (c) 1995-2001 Corporation for National Research Initiatives; All Rights Reserved" are retained in Python 1.6.1 alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the quotes): "Python 1.6.1 is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement together with Python 1.6.1 may be located on the internet using the following unique, persistent identifier (known as a handle): 1895.22/1013. This Agreement may also be obtained from a proxy server on the internet using the following URL: http://hdl.handle.net/1895.22/1013". 3. In the event Licensee prepares a derivative work that is based on or incorporates Python 1.6.1 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python 1.6.1. 4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by the federal intellectual property law of the United States, including without limitation the federal copyright law, and, to the extent such U.S. federal law does not apply, by the law of the Commonwealth of Virginia, excluding Virginia's conflict of law provisions. Notwithstanding the foregoing, with regard to derivative works based on Python 1.6.1 that incorporate non-separable material that was previously distributed under the GNU General Public License (GPL), the law of the Commonwealth of Virginia shall govern this License Agreement only as to issues arising under or with respect to Paragraphs 4, 5, and 7 of this License Agreement. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. This License Agreement does not grant permission to use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwise using Python 1.6.1, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2 -------------------------------------------------- Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The Netherlands. All rights reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Stichting Mathematisch Centrum or CWI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -------------- next part -------------- A non-text attachment was scrubbed... Name: Python-2.0-Python-2.0.1.diff Type: application/octet-stream Size: 7997 bytes Desc: Python-2.0-Python-2.0.1.diff URL: From Max.Mehl at deutschebahn.com Fri Mar 20 16:13:49 2026 From: Max.Mehl at deutschebahn.com (Max Mehl) Date: Fri, 20 Mar 2026 16:13:49 +0000 Subject: [License-review] Submission: CNRI-Python-GPL-Compatible Message-ID: Dear all, Following a discussion on license-discuss@ and a quick coordination with Deb from the Python Software Foundation (in Cc), I would like to propose that CNRI-Python-GPL-Compatible be considered an officially approved (legacy) Open Source license. In the same step, I propose to mark CNRI-Python as either Superseded or Voluntarily Retired. In parallel, I propose the same for Python-2.0.1, for which I opened a separate thread. I will not repeat all the backstory but refer to the aforementioned discussion and spdx/license-list-XML#2197. In short: CNRI-Python-GPL-Compatible is what most closely represents the CNRI portion of the license under which CPython has been published since 2001 (in combination with 0BSD for documentation). In comparison with CNRI-Python, which is already OSI approved, the most remarkable difference is an update to make it GPL compatible. Attached, you will find the license text for CNRI-Python-GPL-Compatible as made available by SPDX, as well as a diff file against CNRI-Python (ignoring formatting and some non-critical boilerplate texts to make things easier for you). Best, Max -- Max Mehl Open Source / Supply Chain Enterprise-Team Chief Technology Office (CTO) DB Systel GmbH / Deutsche Bahn Schedule a meeting: cal.com/mxmehl ________________________________ Pflichtangaben anzeigen N?here Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: https://www.deutschebahn.com/de/konzern/datenschutz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- CNRI OPEN SOURCE GPL-COMPATIBLE LICENSE AGREEMENT IMPORTANT: PLEASE READ THE FOLLOWING AGREEMENT CAREFULLY. BY CLICKING ON "ACCEPT" WHERE INDICATED BELOW, OR BY COPYING, INSTALLING OR OTHERWISE USING PYTHON 1.6.1 SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6.1 software in source or binary form and its associated documentation. 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python 1.6.1 alone or in any derivative version, provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright © 1995-2001 Corporation for National Research Initiatives; All Rights Reserved" are retained in Python 1.6.1 alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the quotes): "Python 1.6.1 is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement together with Python 1.6.1 may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1013. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1013". 3. In the event Licensee prepares a derivative work that is based on or incorporates Python 1.6.1 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python 1.6.1. 4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by the federal intellectual property law of the United States, including without limitation the federal copyright law, and, to the extent such U.S. federal law does not apply, by the law of the Commonwealth of Virginia, excluding Virginia's conflict of law provisions. Notwithstanding the foregoing, with regard to derivative works based on Python 1.6.1 that incorporate non-separable material that was previously distributed under the GNU General Public License (GPL), the law of the Commonwealth of Virginia shall govern this License Agreement only as to issues arising under or with respect to Paragraphs 4, 5, and 7 of this License Agreement. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. This License Agreement does not grant permission to use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwise using Python 1.6.1, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT -------------- next part -------------- A non-text attachment was scrubbed... Name: CNRI-Python-CNRI-Python-GPL-Compatible.diff Type: application/octet-stream Size: 7150 bytes Desc: CNRI-Python-CNRI-Python-GPL-Compatible.diff URL: From josh at berkus.org Fri Mar 20 16:38:32 2026 From: josh at berkus.org (Josh Berkus) Date: Fri, 20 Mar 2026 09:38:32 -0700 Subject: [License-review] Submission: CNRI-Python-GPL-Compatible In-Reply-To: References: Message-ID: On 3/20/26 9:13 AM, Max Mehl wrote: > Following a discussion on license-discuss@ lists.opensource.org/pipermail/license- > discuss_lists.opensource.org/2026-March/022526.html> and a quick > coordination with Deb from the Python Software Foundation (in Cc), I > would like to propose that CNRI-Python-GPL-Compatible be considered an > officially approved (legacy) Open Source license. In the same step, I > propose to mark CNRI-Python as either Superseded or Voluntarily Retired. The CNRI is written as a clickwrap agreement, rather than as a license. Does this make it problematic to approve? -- Josh Berkus From fontana at sharpeleven.org Fri Mar 20 17:34:27 2026 From: fontana at sharpeleven.org (Richard Fontana) Date: Fri, 20 Mar 2026 13:34:27 -0400 Subject: [License-review] Submission: CNRI-Python-GPL-Compatible In-Reply-To: References: Message-ID: " On Fri, Mar 20, 2026 at 12:39 PM Josh Berkus wrote: > > On 3/20/26 9:13 AM, Max Mehl wrote: > > Following a discussion on license-discuss@ > lists.opensource.org/pipermail/license- > > discuss_lists.opensource.org/2026-March/022526.html> and a quick > > coordination with Deb from the Python Software Foundation (in Cc), I > > would like to propose that CNRI-Python-GPL-Compatible be considered an > > officially approved (legacy) Open Source license. In the same step, I > > propose to mark CNRI-Python as either Superseded or Voluntarily Retired. > > The CNRI is written as a clickwrap agreement, rather than as a license. > Does this make it problematic to approve? The relevant phrasing is: BY CLICKING ON "ACCEPT" WHERE INDICATED BELOW, OR BY COPYING, INSTALLING OR OTHERWISE USING PYTHON 1.6.1 SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. Some other OSI-approved licenses have similar sorts of "usewrap" language. This arguably includes the GPL, though the provision I'm thinking of (GPLv2 section 5) is careful to refer only to "modifying or distributing", and it seems to have gotten reinterpreted by people in the GPL community. A "clickwrap" requirement would violate the OSD, and this was the point of the only amendment to the OSD ever made, OSD 10 ("No provision of the license may be predicated on any individual technology or style of interface"). Richard From fontana at sharpeleven.org Fri Mar 20 17:41:21 2026 From: fontana at sharpeleven.org (Richard Fontana) Date: Fri, 20 Mar 2026 13:41:21 -0400 Subject: [License-review] Submission: CNRI-Python-GPL-Compatible In-Reply-To: References: Message-ID: On Fri, Mar 20, 2026 at 1:34 PM Richard Fontana wrote: > > " > > On Fri, Mar 20, 2026 at 12:39 PM Josh Berkus wrote: > > > > On 3/20/26 9:13 AM, Max Mehl wrote: > > > Following a discussion on license-discuss@ > > lists.opensource.org/pipermail/license- > > > discuss_lists.opensource.org/2026-March/022526.html> and a quick > > > coordination with Deb from the Python Software Foundation (in Cc), I > > > would like to propose that CNRI-Python-GPL-Compatible be considered an > > > officially approved (legacy) Open Source license. In the same step, I > > > propose to mark CNRI-Python as either Superseded or Voluntarily Retired. > > > > The CNRI is written as a clickwrap agreement, rather than as a license. > > Does this make it problematic to approve? > > The relevant phrasing is: > > BY CLICKING ON "ACCEPT" WHERE INDICATED BELOW, OR BY COPYING, > INSTALLING OR OTHERWISE USING PYTHON 1.6.1 SOFTWARE, YOU ARE DEEMED TO > HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. > > Some other OSI-approved licenses have similar sorts of "usewrap" > language. This arguably includes the GPL, though the provision I'm > thinking of (GPLv2 section 5) is careful to refer only to "modifying > or distributing", and it seems to have gotten reinterpreted by people > in the GPL community. > > A "clickwrap" requirement would violate the OSD, and this was the > point of the only amendment to the OSD ever made, OSD 10 ("No > provision of the license may be predicated on any individual > technology or style of interface"). To clarify since I realize I didn't really answer Josh's question, I don't think a "clickwrap or usewrap" clause as we have here violates OSD 10 but I suppose it's debatable. I assume there never was anything to "click" in historical versions of Python and this is just ignorant license lawyer drafting, and I hope that there are no present-day official versions of Python for Windows or whatever where you have to click accept in a GUI installer or something like that. Richard From pamela at chesteklegal.com Fri Mar 20 20:51:48 2026 From: pamela at chesteklegal.com (Pamela Chestek) Date: Fri, 20 Mar 2026 13:51:48 -0700 Subject: [License-review] Submission: CNRI-Python-GPL-Compatible In-Reply-To: References: Message-ID: <0d06201a-cc5e-4e1a-9a1e-bcfb0736f008@chesteklegal.com> On 3/20/2026 10:41 AM, Richard Fontana wrote: > On Fri, Mar 20, 2026 at 1:34 PM Richard Fontana wrote: >> " >> >> On Fri, Mar 20, 2026 at 12:39 PM Josh Berkus wrote: >>> On 3/20/26 9:13 AM, Max Mehl wrote: >>>> Following a discussion on license-discuss@>>> discuss_lists.opensource.org/2026-March/022526.html> and a quick >>>> coordination with Deb from the Python Software Foundation (in Cc), I >>>> would like to propose that CNRI-Python-GPL-Compatible be considered an >>>> officially approved (legacy) Open Source license. In the same step, I >>>> propose to mark CNRI-Python as either Superseded or Voluntarily Retired. >>> The CNRI is written as a clickwrap agreement, rather than as a license. >>> Does this make it problematic to approve? >> The relevant phrasing is: >> >> BY CLICKING ON "ACCEPT" WHERE INDICATED BELOW, OR BY COPYING, >> INSTALLING OR OTHERWISE USING PYTHON 1.6.1 SOFTWARE, YOU ARE DEEMED TO >> HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. >> >> Some other OSI-approved licenses have similar sorts of "usewrap" >> language. This arguably includes the GPL, though the provision I'm >> thinking of (GPLv2 section 5) is careful to refer only to "modifying >> or distributing", and it seems to have gotten reinterpreted by people >> in the GPL community. >> >> A "clickwrap" requirement would violate the OSD, and this was the >> point of the only amendment to the OSD ever made, OSD 10 ("No >> provision of the license may be predicated on any individual >> technology or style of interface"). > To clarify since I realize I didn't really answer Josh's question, I > don't think a "clickwrap or usewrap" clause as we have here violates > OSD 10 but I suppose it's debatable. I assume there never was anything > to "click" in historical versions of Python and this is just ignorant > license lawyer drafting, and I hope that there are no present-day > official versions of Python for Windows or whatever where you have to > click accept in a GUI installer or something like that. > > Richard I would say it doesn't because the clickwrap is in the alternative, "or by copying ...." It doesn't even say that /if/ there is a clickwrap you must assent that way. So, since there is a way to agree to the license, GUI or not, I would say it doesn't violate OSD10. And I appreciate the historical context to OSD10. Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas.hale at nist.gov Tue Mar 31 16:39:52 2026 From: lucas.hale at nist.gov (Hale, Lucas M. (Fed)) Date: Tue, 31 Mar 2026 16:39:52 +0000 Subject: [License-review] Review for the NIST Software License In-Reply-To: References: <1761719293.16850219.1759222662412.JavaMail.zimbra@piana.eu> <2a80e9ec-8a84-4273-9c0a-1c034080106e@chesteklegal.com> Message-ID: Hi all, I'm just checking on the status of the NIST license as I haven't heard anything for over two months. Lucas From: License-review On Behalf Of Hale, Lucas M. (Fed) via License-review Sent: Friday, January 9, 2026 10:06 AM To: License submissions for OSI review Cc: Hale, Lucas M. (Fed) Subject: [EXTERNAL] Re: [License-review] [EXTERNAL] Re: [EXTERNAL] Re: Review for the NIST Software License The license I submitted is for NIST software that is provided as a public service. There should not be anything proprietary in any associated code or repository. I only mentioned the contractor stuff because of the discussion in the original thread. It probably would depend on the specific project, but I could see alternatives such as * Some other (non-open source) license applying to the combined work, or more likely * A clear division between the open and proprietary components where the open part does not contain proprietary tools or data but can interface with such. Lucas From: License-review > On Behalf Of Pamela Chestek Sent: Thursday, January 8, 2026 10:04 PM To: license-review at lists.opensource.org Subject: [EXTERNAL] Re: [License-review] [EXTERNAL] Re: Review for the NIST Software License As I understand it, there wouldn't be any license needed for use in the United States since the software is in the public domain in the US, so the license applies (1) outside of the US and (2) in the US where NIST could claim that the user contractually accepted the limitations on use (the obligation to keep the notice and the waiver of warranty) - but just using the software won't be enough to prove contract, as it does when the agreement is a true copyright license. But I'm generally not concerned with whether a license can be enforced, just that, if it can be enforced, it doesn't have any impermissible restrictions. I'm a little confused by this statement: "Cases where the work is copyright-protected would fall under other licenses." Are you saying that, if there is 3rd party-created software, this license won't be used for it? The document says "NIST-developed software is provided by NIST as a public service." This seems like a possible trap, that is, is it an advisory that there could be software in the bundle that was created by a contractor that isn't included under this license because it isn't "NIST-developed," so it's up to the user to somehow figure that out? It's not great to have it in the license, for that reason. However, it also could be construed as non-operative language, with the next sentences giving clear grants, even if some of the software was created by contractors who have copyright. In light of the fact that this is a legacy government license I'm inclined to overlook its flaws, since it's not trying to impose any unacceptable restrictions. I don't see any reason not to approve it. Pam Pamela S. Chestek Chestek Legal 4641 Post St. Unit 4316 El Dorado Hills, CA 95762 +1 919-800-8033 pamela at chesteklegal www.chesteklegal.com On 1/7/2026 1:35 PM, Hale, Lucas M. (Fed) via License-review wrote: Hi All, I finally managed to get meetings rescheduled after the shutdown and holidays to get answers to your questions. First, the primary questions for submission. 1. Describe what gap not filled by currently existing licenses that the new license will fill. Any open source software created at NIST using federal funding is required to use the NIST software license. Software that originates primarily from NIST-funded work must operate under US government public access policies, which the NIST software license is compliant with. 2. Compare it to and contrast it with the most similar OSI-approved license(s). The NIST license is close to the MIT license in that it defines the copyright scope, usage rights, citation guidelines, and liability disclaimers. It differs in that because it is the result of federally funded work it is not subject to copyright protection in the US to begin with rather than giving the copyright away. 3. Describe any legal review the license has been through, including whether it was drafted by a lawyer. The license was drafted by the NIST Office of Chief Council and has undergone internal review and revisions over the years. As for other discussion and questions from the thread: This license is associated with US government-sponsored work that is performed by government employees or others working at NIST. As stated above and in the license, there is inherently no copyright in the US with the associated work due to the US government public access policies. However, it does specify usage permissions, terms and conditions, and disclaimers to protect against legal liability. As for outside the US, the https://www.usa.gov/government-copyright page has this line: "The U.S. government may assert copyright outside of the United States for U.S. government works." My guess is that this allows for export-control over works to target countries, but I'm not sure if this is currently being done on public access works. Cases where the work is copyright-protected would fall under other licenses. For the "contractors" exceptions, from what I heard it is less of a loophole and more the result of contract negotiations between government organizations and external contractors/subcontractors. The idea is that the external party has or is developing proprietary tools and data that the government wants to use, so complex contracts with special provisions and clauses let the external party retain copyright control while the government has usage rights. But, as stated, that is outside the scope of the license under review. Lucas From: License-review On Behalf Of Hale, Lucas M. (Fed) via License-review Sent: Tuesday, September 30, 2025 11:22 AM To: License submissions for OSI review Cc: Hale, Lucas M. (Fed) Subject: [EXTERNAL] Re: [License-review] Review for the NIST Software License Hi reviewers, I reached out to those in charge of the NIST software policy and will meet with them and our Office of Chief Council to discuss and bring your questions to them. We'll hopefully get answers for moving forward in regards to both sides. Note that since a US Government shutdown is imminent and at this moment likely, progress on the NIST side may take some time and I won't have email access during the down time. Hopefully it won't happen or be too long, but if you need to table/withdraw the review after a time period feel free to do so and we can try again when possible. Lucas From: Carlo Piana > Sent: Tuesday, September 30, 2025 4:58 AM To: License submissions for OSI review > Cc: Hale, Lucas M. (Fed) > Subject: [EXTERNAL] Re: [License-review] Review for the NIST Software License You don't often get email from carlo at piana.eu. Learn why this is important Lucas, if I understand correctly, this should not technically be a license, since the software is not subject to copyright in the USA as far as it has been created by NIST employees. I think that if software is not given protection in the state of first publication is not protected even elsewhere, under the Berne Convention, therefore this is basically a dedication to public domain, whose primary scope is the liability disclaimer(s). However, the "provided that you keep intact this entire notice" is technically (US lawyers please help) a condition, that means this is a license with conditional grant, after all. The other condition-like provision uses the verb "should", which is more of an invite, at face value. I do not see anything that would prevent this text to be approved, maybe in the "non reusable" category. But could NIST give us their position on the above discussion, for the sake of clarity, please? Cheers Carlo (in his personal provisional view and capacity) ________________________________ Da: "Hale, Lucas M. (Fed) via License-review" > A: "license-review at lists.opensource.org" > Cc: "Hale, Lucas M. (Fed)" > Inviato: Lunedì, 29 settembre 2025 22:13:02 Oggetto: [License-review] Review for the NIST Software License Hi OSI reviewers! I would like to submit the National Institute of Standards and Technology (NIST) Software license for review to be included in your list. This is the primary license that NIST staff are expected to use when releasing software. The license complies with the Open Source Definition, including the OSD 3, 5, 6 and 9 criteria. There are numerous projects using the NIST software. For instance, there are 1.3K repositories at https://github.com/usnistgov that should all be using the license. As such, it falls under the legacy category. The NIST license is also listed on the main NIST website https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-data-software-and-technical-series-publications, and has an SPDX listing https://spdx.org/licenses/NIST-Software.html. Under both sites, it is titled "NIST Software License" Thank you for your time and consideration! Sincerely, Lucas Hale _______________________________________________ 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 _______________________________________________ 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: From mccoy at lexpan.law Tue Mar 31 17:37:59 2026 From: mccoy at lexpan.law (McCoy Smith) Date: Tue, 31 Mar 2026 10:37:59 -0700 Subject: [License-review] Review for the NIST Software License In-Reply-To: References: <1761719293.16850219.1759222662412.JavaMail.zimbra@piana.eu> <2a80e9ec-8a84-4273-9c0a-1c034080106e@chesteklegal.com> Message-ID: <28a15ff6-66e6-4ba4-b2e0-8facec18d625@lexpan.law> Lucas: OSI has a two month review and comment period for all licenses. So NIST was in that process until earlier this month. There has been a review at the Board of this license, at the March board meeting, with minutes and results to be published shortly. On 3/31/2026 9:39 AM, Hale, Lucas M. (Fed) via License-review wrote: > > Hi all, > > I’m just checking on the status of the NIST license as I haven’t heard > anything for over two months. > > Lucas > > *From:*License-review > *On Behalf Of *Hale, Lucas M. (Fed) via License-review > *Sent:* Friday, January 9, 2026 10:06 AM > *To:* License submissions for OSI review > > *Cc:* Hale, Lucas M. (Fed) > *Subject:* [EXTERNAL] Re: [License-review] [EXTERNAL] Re: [EXTERNAL] > Re: Review for the NIST Software License > > The license I submitted is for NIST software that is provided as a > public service.  There should not be anything proprietary in any > associated code or repository. > > I only mentioned the contractor stuff because of the discussion in the > original thread.  It probably would depend on the specific project, > but I could see alternatives such as > > * Some other (non-open source) license applying to the combined > work, or more likely > * A clear division between the open and proprietary components where > the open part does not contain proprietary tools or data but can > interface with such. > > Lucas > > *From:*License-review > *On Behalf Of *Pamela Chestek > *Sent:* Thursday, January 8, 2026 10:04 PM > *To:* license-review at lists.opensource.org > *Subject:* [EXTERNAL] Re: [License-review] [EXTERNAL] Re: Review for > the NIST Software License > > As I understand it, there wouldn't be any license needed for use in > the United States since the software is in the public domain in the > US, so the license applies (1) outside of the US and (2) in the US > where NIST could claim that the user contractually accepted the > limitations on use (the obligation to keep the notice and the waiver > of warranty) - but just using the software won't be enough to prove > contract, as it does when the agreement is a true copyright license. > But I'm generally not concerned with whether a license can be > enforced, just that, if it can be enforced, it doesn't have any > impermissible restrictions. > > I'm a little confused by this statement: "Cases where the work is > copyright-protected would fall under other licenses." Are you saying > that, if there is 3rd party-created software, this license won't be > used for it? The document says "NIST-developed software is provided by > NIST as a public service." This seems like a possible trap, that is, > is it an advisory that there could be software in the bundle that was > created by a contractor that isn't included under this license because > it isn't "NIST-developed," so it's up to the user to somehow figure > that out? It's not great to have it in the license, for that reason. > However, it also could be construed as non-operative language, with > the next sentences giving clear grants, even if some of the software > was created by contractors who have copyright. > > In light of the fact that this is a legacy government license I'm > inclined to overlook its flaws, since it's not trying to impose any > unacceptable restrictions. I don't see any reason not to approve it. > > Pam > > Pamela S. Chestek > Chestek Legal > 4641 Post St. > Unit 4316 > El Dorado Hills, CA 95762 > +1 919-800-8033 > pamela at chesteklegal > www.chesteklegal.com > > On 1/7/2026 1:35 PM, Hale, Lucas M. (Fed) via License-review wrote: > > Hi All, > > I finally managed to get meetings rescheduled after the shutdown > and holidays to get answers to your questions. > > First, the primary questions for submission. > > 1. Describe what gap not filled by currently existing licenses > that the new license will fill. > > Any open source software created at NIST using federal funding is > required to use the NIST software license. Software that > originates primarily from NIST-funded work must operate under US > government public access policies, which the NIST software license > is compliant with. > > 2. Compare it to and contrast it with the most similar > OSI-approved license(s). > > The NIST license is close to the MIT license in that it defines > the copyright scope, usage rights, citation guidelines, and > liability disclaimers.  It differs in that because it is the > result of federally funded work it is not subject to copyright > protection in the US to begin with rather than giving the > copyright away. > > 3. Describe any legal review the license has been through, > including whether it was drafted by a lawyer. > > The license was drafted by the NIST Office of Chief Council and > has undergone internal review and revisions over the years. > > As for other discussion and questions from the thread: > > This license is associated with US government-sponsored work that > is performed by government employees or others working at NIST. As > stated above and in the license, there is inherently no copyright > in the US with the associated work due to the US government public > access policies. However, it does specify usage permissions, terms > and conditions, and disclaimers to protect against legal liability. > > As for outside the US, the > https://www.usa.gov/government-copyright page has this line: “The > U.S. government may assert copyright outside of the United States > for U.S. government works.” My guess is that this allows for > export-control over works to target countries, but I’m not sure if > this is currently being done on public access works. > > Cases where the work is copyright-protected would fall under other > licenses.  For the “contractors” exceptions, from what I heard it > is less of a loophole and more the result of contract negotiations > between government organizations and external > contractors/subcontractors. The idea is that the external party > has or is developing proprietary tools and data that the > government wants to use, so complex contracts with special > provisions and clauses let the external party retain copyright > control while the government has usage rights. But, as stated, > that is outside the scope of the license under review. > > Lucas > > *From:*License-review > > *On Behalf Of > *Hale, Lucas M. (Fed) via License-review > *Sent:* Tuesday, September 30, 2025 11:22 AM > *To:* License submissions for OSI review > > > *Cc:* Hale, Lucas M. (Fed) > > *Subject:* [EXTERNAL] Re: [License-review] Review for the NIST > Software License > > Hi reviewers, > > I reached out to those in charge of the NIST software policy and > will meet with them and our Office of Chief Council to discuss and > bring your questions to them. We’ll hopefully get answers for > moving forward in regards to both sides. > > Note that since a US Government shutdown is imminent and at this > moment likely, progress on the NIST side may take some time and I > won’t have email access during the down time. Hopefully it won’t > happen or be too long, but if you need to table/withdraw the > review after a time period feel free to do so and we can try again > when possible. > > Lucas > > *From:*Carlo Piana > *Sent:* Tuesday, September 30, 2025 4:58 AM > *To:* License submissions for OSI review > > *Cc:* Hale, Lucas M. (Fed) > *Subject:* [EXTERNAL] Re: [License-review] Review for the NIST > Software License > > > > > You don't often get email from carlo at piana.eu > . Learn why this is important > > > > > Lucas, > > if I understand correctly, this should not technically be a > license, since the software is not subject to copyright in the USA > as far as it has been created by NIST employees. I think that if > software is not given protection in the state of first publication > is not protected even elsewhere, under the Berne Convention, > therefore this is basically a dedication to public domain, whose > primary scope is the liability disclaimer(s). > > However, the "provided that you keep intact this entire notice" is > technically (US lawyers please help) a condition, that means this > is a license with conditional grant, after all. The other > condition-like provision uses the verb "should", which is more of > an invite,  at face value. > > I do not see anything that would prevent this text to be approved, > maybe in the "non reusable" category. But could NIST give us their > position on the above discussion, for the sake of clarity, please? > > Cheers > > Carlo (in his personal provisional view and capacity) > > ------------------------------------------------------------------------ > > *Da: *"Hale, Lucas M. (Fed) via License-review" > > > *A: *"license-review at lists.opensource.org > " > > > *Cc: *"Hale, Lucas M. (Fed)" > > *Inviato: *Lunedì, 29 settembre 2025 22:13:02 > *Oggetto: *[License-review] Review for the NIST Software License > > Hi OSI reviewers! > > I would like to submit the National Institute of Standards and > Technology (NIST) Software license for review to be included > in your list.  This is the primary license that NIST staff are > expected to use when releasing software. > > The license complies with the Open Source Definition, > including the OSD 3, 5, 6 and 9 criteria. > > There are numerous projects using the NIST software.  For > instance, there are 1.3K repositories at > https://github.com/usnistgov > that should all be using the > license.  As such, it falls under the legacy category. > > The NIST license is also listed on the main NIST website > https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-data-software-and-technical-series-publications > , > and has an SPDX listing > https://spdx.org/licenses/NIST-Software.html > . Under both > sites, it is titled “NIST Software License” > > Thank you for your time and consideration! > > Sincerely, > > Lucas Hale > > > _______________________________________________ > 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 > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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: