From carlo at piana.eu  Wed Oct  1 06:04:17 2025
From: carlo at piana.eu (Carlo Piana)
Date: Wed, 1 Oct 2025 08:04:17 +0200 (CEST)
Subject: [License-review] Review for the NIST Software License
In-Reply-To: <d8272cb3-bcfd-4640-bc7a-8c0e5d1e28c0@landley.net>
References: 
 <SA1PR09MB8846781A441569456E2ED050EC1BA@SA1PR09MB8846.namprd09.prod.outlook.com>
 <1761719293.16850219.1759222662412.JavaMail.zimbra@piana.eu>
 <f406a013-4332-486f-841a-84412b1fe33a@lexpan.law>
 <d8272cb3-bcfd-4640-bc7a-8c0e5d1e28c0@landley.net>
Message-ID: <2057666380.17409061.1759298657683.JavaMail.zimbra@piana.eu>



----- Messaggio originale -----
> Da: "Rob Landley" <rob at landley.net>
> A: "license-review at lists.opensource.org" <license-review at lists.opensource.org>
> Inviato: Martedì, 30 settembre 2025 21:36:45
> Oggetto: Re: [License-review] Review for the NIST Software License

[...]

> 
> The trick they use is to hire contractors, who are not technically
> "employees" of the government and thus get copyrights to the works they
> create, and then have those contractors (or subcontractors, whatever the
> shell game is this week) assign their copyrights to the government as
> part of the contract.
> 

However insane this is, it makes some sense. I assumed it being work for hire it would follow the same rule, and I was obviously wrong.

On the Berne Convention, I could be wrong as well, but it being a copyright union, it should work ubiquitously in the same way, at least on the generalities (obtain the right, not obtain the right). But we are (I am) digressing.

Thank you for the clarification.

Carlo



> Rob
> 
> _______________________________________________
> 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
> https://eu-west-1.protection.sophos.com?d=opensource.org&u=aHR0cDovL2xpc3RzLm9wZW5zb3VyY2Uub3JnL21haWxtYW4vbGlzdGluZm8vbGljZW5zZS1yZXZpZXdfbGlzdHMub3BlbnNvdXJjZS5vcmc=&i=NjhjNzIxMTA1NWQ1ZjI0MWQ5M2FlMmQ1&t=RkhzTit2MkhPcFZVeStQemp3YUIxZlNSRjJlc3V5bFR2NjdzTk5SS1VRUT0=&h=0e8c0490df2b48c8b5c6cacb71b5d26f&s=AVNPUEhUT0NFTkNSWVBUSVYUz-thzf5vzA36NQu-S1uCFXRfKLlpNelcCIhxHTYetdwsTswl63sVa2ILmbtWtRI

From shujisado at gmail.com  Wed Oct  1 11:48:24 2025
From: shujisado at gmail.com (Shuji Sado)
Date: Wed, 1 Oct 2025 20:48:24 +0900
Subject: [License-review] Review for the NIST Software License
In-Reply-To: 
 <SA1PR09MB8846781A441569456E2ED050EC1BA@SA1PR09MB8846.namprd09.prod.outlook.com>
References: 
 <SA1PR09MB8846781A441569456E2ED050EC1BA@SA1PR09MB8846.namprd09.prod.outlook.com>
Message-ID: 
 <CAAvo7O6cAr0sX=QwT+oPJnQ-7ojxSbxzKk58dBY6f7peXNvW1w@mail.gmail.com>

Hi,

Whether the NIST Software License operates as a copyright license depends
on two points:
(1) national treatment for foreign works (Berne art. 5(2)); and
(2) whether the jurisdiction does NOT apply the rule of the shorter term
down to the U.S. “term of 0 years” for U.S. Government employee works.

Where the shorter-term rule is applied, NIST employee-authored code can end
up with no copyright term; where it is not applied, the work may enjoy a
normal term abroad.
The former includes the EU/UK/Japan; the latter includes
Australia/Switzerland/China.

Separately, contractor-authored code assigned to the U.S. Government is a
different category and may be protected.
In any case, recognizing the NIST Software License under the OSD seems
plausible, but it would help if NIST clearly distinguished
employee-authored from contractor-authored code across its repositories.


2025/9/30 17:23 Hale, Lucas M. (Fed) via License-review <
license-review at lists.opensource.org>:

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


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

From josh at berkus.org  Fri Oct 10 20:30:38 2025
From: josh at berkus.org (Josh Berkus)
Date: Fri, 10 Oct 2025 21:30:38 +0100
Subject: [License-review] [2nd Resubmission] ModelGo Attribution License,
 Version 2.0
In-Reply-To: <7F574427-EF5D-4A8F-911A-D1162A2218A2@gmail.com>
References: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
 <ef8ea4fc-7a96-4639-8701-75e96ad47d56@berkus.org>
 <A34D9DA1-D2E4-424B-81A2-9B4110DF216C@gmail.com>
 <5925bcd6-9dc6-47a6-ab3c-c07958ff3e04@opensource.org>
 <7F574427-EF5D-4A8F-911A-D1162A2218A2@gmail.com>
Message-ID: <29330d4d-23d6-4fa1-bfa1-c3f15fb3257d@berkus.org>

On 9/25/25 04:35, Moming Duan wrote:
> Hi, I just wanted to check in on the status of the ModelGo License 
> review. Thanks.

Sorry, we're still discussing.  We should have updates for you in the 
next week.  Thanks for your patience!

-- 
Josh Berkus

From karuman2013 at gmail.com  Mon Oct 20 13:09:03 2025
From: karuman2013 at gmail.com (Righteousness)
Date: Mon, 20 Oct 2025 18:39:03 +0530
Subject: [License-review] Submission of Orivex Syscall Note License (OSN-1.0)
 for OSI Approval
Message-ID: 
 <CAE0NYFH31bsTaf_Mv1qcz7jqHwPPfy7NMaw_TzxRTC9WLQWYOw@mail.gmail.com>

Dear Open Source Initiative License Review Committee,

I am submitting the Orivex Syscall Note License (OSN-1.0) for your
consideration for OSI approval.

Background:
Orivex is an operating system currently under active development. OSN-1.0
is a permissive license specifically designed for Orivex’s kernel-facing
components, including kernel headers, syscall interface definitions,
reference ABI documentation, and related API files. This license is
intended to enable Orivex to be released as open source in the future.

Why a New License is Necessary:
Existing OSI-approved licenses, such as MIT, BSD, or Apache 2.0, provide
general-purpose permissive licensing but do not explicitly address kernel-
and syscall-level artifacts. OSN-1.0 fills this gap by:
- Preserving attribution and provenance specifically for kernel interfaces
and ABI contracts.
- Providing guidance for ABI and syscall interface compatibility without
imposing legal obligations.
- Explicitly separating trademark rights from copyright and patent grants.
- Clarifying contributor patent grants and termination conditions related
to patent litigation.

Comparison to Similar OSI Licenses:
- MIT/BSD: Similar in permissiveness and simplicity, but do not provide
guidance on syscall/ABI traceability or contributor patent grant clarity.
- Apache 2.0: Includes patent grants and some attribution requirements, but
is heavier and not tailored for kernel-facing artifacts or syscall-specific
documentation.
OSN-1.0 balances permissiveness, clarity, and lightweight design, while
providing explicit protections and guidance for kernel interface
development.

Open Source Definition Compliance:
OSN-1.0 has been designed to satisfy all ten criteria of the Open Source
Definition (OSD), including:
- Free redistribution
- Availability of source code
- Permission to create derivative works
- No discrimination against persons, groups, or fields of endeavor
- Technology-neutral terms
- Clear redistribution and license grant requirements

Additional Information:
- Copyright (c) 2025 Kartik
- SPDX Identifier: Orivex-syscall-note
- Governing Law: India

I believe OSN-1.0 provides a clear, permissive license suitable for
projects requiring kernel- or syscall-level interfaces while remaining
fully OSD-compliant. I would be happy to provide any additional
information, clarifications, or documentation needed to facilitate your
review.

Thank you for your time and consideration.

Best regards,
Kartik
karuman2013 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251020/989c9f94/attachment-0001.htm>
-------------- next part --------------
SPDX-License-Identifier: Orivex-syscall-note
ORIVEX SYSCALL NOTE LICENSE (OSN-1.0)

Copyright (c) 2025 Kartik

Preamble
--------
The Orivex Syscall Note License (OSN-1.0) is a permissive open-source license tailored for
kernel-facing artifacts such as kernel headers, syscall interface definitions, reference ABI
documentation, and related API files (collectively, the "Software").  OSN-1.0 seeks to:
  (a) provide broad, unencumbered rights to use, modify, and redistribute the Software;
  (b) preserve attribution and provenance of kernel interface definitions and ABI contracts;
  (c) encourage upstream compatibility and traceability of changes to syscall interfaces;
  (d) protect Orivex trademarks and identity by separating trademark rights from copyright
      and patent grants; and
  (e) clarify contributor patent grants and termination on patent litigation.

1. Definitions
--------------
In this License:
  1.1 "You" (or "Your") means any individual or legal entity exercising Rights under this
      License.
  1.2 "Licensor" means the copyright holder(s) identified at the top of this document or
      any entity that subsequently holds copyright in the Software and distributes it under
      OSN-1.0.
  1.3 "Contributor" means any individual or legal entity that submits Contributions to the
      Software.
  1.4 "Contribution" means any original work of authorship, including modifications and
      additions, submitted to the Software and intentionally contributed by You to the
      Licensor for inclusion in the Software.
  1.5 "Derivative Work" has the meaning given by applicable law, and includes works that
      incorporate or are based upon the Software.
  1.6 "Distribution" means any transfer, conveyance, sale, sublicense, lease, or public
      offering of the Software or derivative works thereof, in source or binary/object form.
  1.7 "Notice File" means a file named SYSCALL-LICENSE.md or NOTICE, or other similarly
      prominent file, used to communicate attribution, license terms, or other required
      notices to recipients of the Software.
  1.8 "Binary Form" means object code or any form other than readable source code.
  1.9 "Source Form" means the preferred form for making modifications, including but not
      limited to original source code, documentation source, and build scripts.

2. Grant of Copyright License
-----------------------------
Subject to the terms and conditions of this License, the Licensor hereby grants You a
worldwide, royalty-free, non-exclusive, perpetual, irrevocable copyright license to:
  2.1 Reproduce and prepare Derivative Works of the Software;
  2.2 Distribute, sublicense, and publicly display the Software in Source Form and Binary Form;
  2.3 Perform and otherwise use the Software for any purpose, including commercial use;
  2.4 Permit third parties to exercise any of the foregoing rights.

3. Patent License
-----------------
  3.1 Patent Grant by Licensor. Subject to the terms of this License, the Licensor grants
      You a worldwide, royalty-free, non-exclusive, perpetual patent license under
      Licensor-owned patents to make, use, sell, offer to sell, import, and otherwise
      distribute the Software, but only to the extent such patent claims are necessarily
      infringed by the Software as delivered by the Licensor.
  3.2 Patent Grant by Contributor. By making a Contribution, each Contributor hereby grants
      You a worldwide, royalty-free, non-exclusive, perpetual patent license under any
      patent claims that are necessarily infringed by their Contribution alone or by the
      Contribution when combined with the Software submitted to the Licensor.
  3.3 Termination for Patent Litigation. If You (or any entity controlled by You) institutes
      or causes to be instituted any patent litigation (including a cross-claim or counterclaim)
      against any party alleging that the Software or a Contribution infringes a patent,
      then any patent licenses granted to You under Sections 3.1 or 3.2 for the Software
      shall terminate as to the party to whom such license was granted.

4. Redistribution: Source and Binary Requirements
------------------------------------------------
Redistributions of the Software, in Source or Binary Form, must meet the following:
  4.1 License Copy. Redistributions must include a complete, unmodified copy of this
      OSN-1.0 License text or a machine-readable reference to it (for Binary Form),
      and the SPDX identifier where feasible.
  4.2 Copyright and Notices. Redistributions must retain, in all source files and in any
      distributed NOTICE or SYSCALL-LICENSE.md file, all copyright, patent, and attribution
      notices that appear in the Software.
  4.3 Prominent Attribution Note. Redistributions must include in a prominent location (for
      example a top-level README, NOTICE, or SYSCALL-LICENSE.md) the statement:
        "This distribution includes Orivex syscall interfaces (OSN-1.0). See SYSCALL-LICENSE.md
         or NOTICE for details."
  4.4 SYSCALL-CHANGES.md. If You modify files covered by the Software, You must include a
      SYSCALL-CHANGES.md documenting the nature of changes (short summary, author, and date)
      and distribute it alongside the modified files. This requirement is for provenance and
      traceability and does not otherwise limit Your rights to modify or distribute.
  4.5 Binary Form. For Binary Form redistributions, You must reproduce the information
      required by Sections 4.1–4.4 in a NOTICE or equivalent documentation distributed with
      the Binary (e.g., in a top-level directory, installer, or package metadata).
  4.6 Sublicensing. You may grant sublicenses to downstream recipients, provided sublicenses
      preserve the requirements of this License with respect to the portions of the Software
      covered by OSN-1.0.

5. Contribution Policy and Developer Agreement
----------------------------------------------
  5.1 By submitting a Contribution to the Software, You represent that You have the right to
      grant the rights described in this License and that Your Contribution does not violate
      any third-party rights.
  5.2 Each Contributor grants the Licensor and recipients of the Software the licenses
      described in Sections 2 and 3 for their Contribution.
  5.3 Optionally, the Licensor may provide a Contributor License Agreement (CLA) or Developer
      Agreement for signature; signing such an agreement is not mandatory to contribute but
      may be required by the project for administrative or corporate compliance reasons.
  5.4 The Licensor may, at its discretion, refuse to accept contributions that are encumbered
      by third-party license terms incompatible with OSN-1.0.

6. Compatibility and Stability Guidance
---------------------------------------
  6.1 Compatibility Encouragement. The Licensor strongly encourages contributors and downstream
      redistributors to preserve ABI and syscall interface compatibility where possible.
  6.2 Deprecation and Breaking Changes. Where a change breaks compatibility, the party making
      the change should document the change, provide an upstream notice, and, where reasonably
      practicable, offer a deprecation period sufficient to allow downstream projects to adapt.
  6.3 Not a License Obligation. The guidance in this Section 6 is non-binding and intended
      to encourage cooperative development; it does not create legal obligations beyond those
      expressly stated in other sections of this License.

7. Trademarks, Name & Logos
---------------------------
  7.1 No Trademark Grant. This License does not grant permission to use trade names, trademarks,
      service marks, logos, or product names of the Licensor, except as required solely to
      identify the origin of the Software in notices as required by Section 4.3.
  7.2 Referencing the Orivex Name. You may refer to the Software as "Orivex syscall interfaces"
      for identification and compatibility descriptions, provided such references do not imply
      endorsement by the Orivex project or use of Orivex trademarks beyond the limited attribution
      permitted by Section 4.3.
  7.3 Separate Trademark Policies. The Licensor may publish separate trademark usage guidelines;
      compliance with such guidelines is required to make use of Orivex trademarks beyond the
      attribution described above.

8. Disclaimer of Warranty
-------------------------
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU.

9. Limitation of Liability
--------------------------
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL THE LICENSOR OR ANY
CONTRIBUTOR BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, PUNITIVE, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION), HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE), ARISING IN ANY WAY OUT OF THE USE OF THE SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

10. Indemnity
-------------
Unless otherwise agreed in a separate written agreement, You agree (to the extent permitted
by applicable law) to indemnify, defend and hold harmless the Licensor and its Contributors
from and against any claim, liability, loss, damage, or expense (including reasonable legal
fees) arising out of Your modification, distribution, or use of the Software, or any violation
of this License by You.

11. Termination
---------------
  11.1 Automatic Termination. Your rights under this License will terminate automatically if You
       fail to comply with any of its terms and fail to cure such non-compliance within thirty
       (30) days of receiving written notice from the Licensor; provided that termination of Your
       rights will not terminate rights that have already been granted by You to third parties
       if those third parties received the Software lawfully and in compliance with this License.
  11.2 Effect of Termination. Upon termination, You must cease all distribution of the Software
       that relies on rights under this License, except that You may continue to use and distribute
       any portions of the Software that were received under a separate license or prior lawful grant.
  11.3 Survival. Provisions that by their nature survive termination shall survive, including
       Sections 3 (Patent License, to the extent it survived by applicable law), 8 (Disclaimer
       of Warranty), 9 (Limitation of Liability), 10 (Indemnity), 11 (Termination), 12 (Severability),
       and 13 (Governing Law & Dispute Resolution).

12. Export Controls & Applicable Law
-----------------------------------
  12.1 Export Compliance. You are solely responsible for complying with all applicable export
       and import laws and regulations. The Licensor makes no representation that the Software
       may be exported or used under any particular jurisdiction.
  12.2 Governing Law & Jurisdiction. This License shall be governed by and construed in accordance
       with the laws of India without regard to its conflict of law principles. Any disputes arising
       out of or relating to this License shall be subject to the exclusive jurisdiction of the
       courts located in New Delhi, India.

13. Severability
---------------
If any provision of this License is held to be invalid, illegal, or unenforceable under
applicable law, such provision shall be reformed only to the extent necessary to make it valid,
legal, and enforceable, and the remaining provisions shall remain in full force and effect.

14. Interpretation & Entire Agreement
-------------------------------------
This License constitutes the entire agreement between the parties with respect to the subject
matter hereof and supersedes any prior or contemporaneous agreements, understandings, or
arrangements. Headings are for convenience only and shall not affect interpretation.

15. How to Apply This License
-----------------------------
To apply this license to your work, attach the following copyright and license header to each
source file or include it in a top-level license file; keep the SPDX identifier if possible.

Suggested source-file header:
  /*
  <OPTIONAL MESSAGE>
  Copyright (C) <YEAR> <COPYRIGHT HOLDER>

  <PROJECT NAME> is distributed under the Orivex Syscall Note License (OSN),
  version <VERSION> or any later version at your option.

  The software is provided as-is, without any guarantees or warranties of any kind.
  See SYSCALL-LICENSE.md or NOTICE for the full license terms.
*/


16. Recommended Top-Level Files
-------------------------------
It is recommended that distributions include the following top-level files:
  16.1 SYSCALL-LICENSE.md  -- Full license text or a pointer to this OSN-1.0 text.
  16.2 NOTICE or README    -- Attribution statement required by Section 4.3.
  16.3 SYSCALL-CHANGES.md  -- Record of notable modifications to syscall/ABI files.
  16.4 CONTRIBUTORS (optional) -- List of significant contributors and their affiliations.

Appendix A — Suggested NOTICE / SYSCALL-LICENSE.md Template
------------------------------------------------------------
This distribution contains Orivex syscall interfaces licensed under the Orivex Syscall Note
License (OSN-1.0). See the file SYSCALL-LICENSE.md for the full license text.

Copyright (c) 2025 Kartik

This NOTICE file lists notices and attributions required by OSN-1.0:
  - "Orivex syscall interfaces (OSN-1.0) — see SYSCALL-LICENSE.md"
  - Any additional notices retained from upstream sources.

Appendix B — Suggested SYSCALL-CHANGES.md Template
--------------------------------------------------
File: <relative-path-to-file>
Author: <name / organization>
Date: <YYYY-MM-DD>
Summary:
  - <Short description of changes; e.g., "Added new socket syscall number", "Renamed struct foo to bar">
Impact:
  - <Backward-compatibility impact (none / deprecation / breaking)>

Final Notes
-----------
  * This license is intended to be permissive and broadly compatible with open-source ecosystems,
    while providing clear attribution and contributor patent protections.
  * This document is a legal instrument. You may wish to have counsel review this text before
    formal adoption for a major project or before making formal submissions to standards bodies
    or the Open Source Initiative.
  * If you want, I can:
     - produce a one-page "license summary" for your README,
     - prepare an OSI submission cover letter draft explaining how OSN-1.0 differs from MIT/BSD/Apache,
     - or generate ready-to-drop SYSCALL-LICENSE.md, NOTICE, and SYSCALL-CHANGES.md files.

END OF LICENSE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SYSCALL-LICENSE.md
Type: application/octet-stream
Size: 1653 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251020/989c9f94/attachment-0001.a>

From carlo at piana.eu  Tue Oct 21 13:21:17 2025
From: carlo at piana.eu (Carlo Piana)
Date: Tue, 21 Oct 2025 15:21:17 +0200 (CEST)
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval
In-Reply-To: 
 <CAE0NYFH31bsTaf_Mv1qcz7jqHwPPfy7NMaw_TzxRTC9WLQWYOw@mail.gmail.com>
References: 
 <CAE0NYFH31bsTaf_Mv1qcz7jqHwPPfy7NMaw_TzxRTC9WLQWYOw@mail.gmail.com>
Message-ID: <1760796185.26429334.1761052877264.JavaMail.zimbra@piana.eu>

Hi, 

thank you for the submission. I take that the .md file is just the gist of the license, but it is not useful to the approval process. 

I firstly note a potential ambiguity on who is the Licensor. It can be either of: 

- everybody who holds any copyright the software 
- who holds the copyright in the original 

The second seems the case, as you elected to define also contributor (as the Apache 2.0 does), which is an interesting election WRT patent license, but in other cases it creates an unacceptable, in my view, discrimination between Licensor and Contributor, for instance in 11. Termination and with a lesser problem in 12. Export Control. This alone discriminates different classes of copyright holders and I consider it potentially against #5. 

Also I am strongly in disfavor not only of any choice of law (only marginally problematic here), but also with any jurisdiction clause. We had this discussion a number of times here. 

On the positive side, I note Section 6 that you took pains at not creating a condition there. Good. Also the patent grant seems correct (again, Apache-style). 

Section 7. creates text that makes difficult to port. It would be nice if submitters already decided to use placeholders instead of their name, or, better, to avoid placing the original licensor in a more favorable position than others, who might become even more prominent licensors. 

Section 9 seems a good example of how you can protect the interest of Contributors, Apache style. I hoped you had done the same elsewhere (see above). 

Also Section 10. although I am not sure I would accept it if I were a contributor and probably I would advise clients against it. The Apache license, which has a similar provision, makes it only as a consequence of the decision to provide a warranty, which makes more sense. This however does not seem to be against OSD, per se, but I urge you to reconsider this, it would create friction and I am not even sure it would hold water in many jurisdictions. 

Also Section 14 is problematic, as it is not clear what the matter hereof is. Suppose licensing software is a part of a contract agreement? 

As the copyright grant in Section 2, what language exactly enables the licensor to distribute dervative works at all? The license only extends to "prepare" and "reproduce", but the right to distribute is only granted in the software, in the source or binary form. 

Please avoid, by all means "open-source". The correct spelling is Open Source. https://opensource.org/blog/is- open-source -ever-hyphenated 

The definition of "Software" is also problematic. It only applies to Software as defined, and what if anyone would use it for different purposes? Why have not you defined software in Section 1 "Definition", leaving the preamble as a a non-normative part of the license? 

So, all in all there is some good faith effort and some quite apparent flaws, on a very cursory reading of the license. I think fixing them (there might be others that I have not spotted) would be relatively easy, but at this version I would find it hard to approve it, even as a special purpose license. 

Cheers 

Carlo 
in his personal capacity 

> Da: "Righteousness" <karuman2013 at gmail.com>
> A: "license-review at lists.opensource.org" <license-review at lists.opensource.org>
> Inviato: Lunedì, 20 ottobre 2025 15:09:03
> Oggetto: [License-review] Submission of Orivex Syscall Note License (OSN-1.0)
> for OSI Approval

> Dear Open Source Initiative License Review Committee,

> I am submitting the Orivex Syscall Note License (OSN-1.0) for your consideration
> for OSI approval.

> Background:
> Orivex is an operating system currently under active development. OSN-1.0 is a
> permissive license specifically designed for Orivex’s kernel-facing components,
> including kernel headers, syscall interface definitions, reference ABI
> documentation, and related API files. This license is intended to enable Orivex
> to be released as open source in the future.

> Why a New License is Necessary:
> Existing OSI-approved licenses, such as MIT, BSD, or Apache 2.0, provide
> general-purpose permissive licensing but do not explicitly address kernel- and
> syscall-level artifacts. OSN-1.0 fills this gap by:
> - Preserving attribution and provenance specifically for kernel interfaces and
> ABI contracts.
> - Providing guidance for ABI and syscall interface compatibility without
> imposing legal obligations.
> - Explicitly separating trademark rights from copyright and patent grants.
> - Clarifying contributor patent grants and termination conditions related to
> patent litigation.

> Comparison to Similar OSI Licenses:
> - MIT/BSD: Similar in permissiveness and simplicity, but do not provide guidance
> on syscall/ABI traceability or contributor patent grant clarity.
> - Apache 2.0: Includes patent grants and some attribution requirements, but is
> heavier and not tailored for kernel-facing artifacts or syscall-specific
> documentation.
> OSN-1.0 balances permissiveness, clarity, and lightweight design, while
> providing explicit protections and guidance for kernel interface development.

> Open Source Definition Compliance:
> OSN-1.0 has been designed to satisfy all ten criteria of the Open Source
> Definition (OSD), including:
> - Free redistribution
> - Availability of source code
> - Permission to create derivative works
> - No discrimination against persons, groups, or fields of endeavor
> - Technology-neutral terms
> - Clear redistribution and license grant requirements

> Additional Information:
> - Copyright (c) 2025 Kartik
> - SPDX Identifier: Orivex-syscall-note
> - Governing Law: India

> I believe OSN-1.0 provides a clear, permissive license suitable for projects
> requiring kernel- or syscall-level interfaces while remaining fully
> OSD-compliant. I would be happy to provide any additional information,
> clarifications, or documentation needed to facilitate your review.

> Thank you for your time and consideration.

> Best regards,
> Kartik
> [ mailto:karuman2013 at gmail.com | karuman2013 at gmail.com ]

> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily
> those of the Open Source Initiative. Communication from the Open Source
> Initiative will be sent from an opensource.org email address.

> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251021/1d81ca3d/attachment.htm>

From shujisado at gmail.com  Tue Oct 21 14:12:08 2025
From: shujisado at gmail.com (Shuji Sado)
Date: Tue, 21 Oct 2025 23:12:08 +0900
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval
In-Reply-To: <1760796185.26429334.1761052877264.JavaMail.zimbra@piana.eu>
References: 
 <CAE0NYFH31bsTaf_Mv1qcz7jqHwPPfy7NMaw_TzxRTC9WLQWYOw@mail.gmail.com>
 <1760796185.26429334.1761052877264.JavaMail.zimbra@piana.eu>
Message-ID: 
 <CAAvo7O47-ivGkeHnsCaszE+g+r+A7-SxDU82AduJSJX7GRRzFg@mail.gmail.com>

Hi,

Thanks to Carlo-san for the thorough review. I broadly agree with his
analysis. I'd like to add three narrower points that I don't think were
explicitly covered, plus one suggestion about an existing pattern that may
meet the author's stated goal without a new license.

*1) Sublicensing inconsistency*

§2.2 appears to grant an open-ended right to "sublicense," while §4.6
conditions sublicensing on passing through the original terms; the
definitions also fold "sublicense" into "Distribution." This creates
ambiguity about whether downstreams rely on the original license or a new
downstream license.

*2) Fixed attribution phrase in §4.3*

Mandating the exact sentence ("This distribution includes Orivex syscall
interfaces (OSN-1.0) ...") to be displayed "prominently" is heavier than
common NOTICE/attribution practice and reduces reusability for non-Orivex
projects.

*3) Making an SPDX identifier part of the redistribution requirement (§4.1)*

SPDX tags are excellent metadata, but they are managed outside the license
and may not exist for a new text. Making their inclusion a legal condition
of redistribution can fail for reasons unrelated to copyright compliance.

*Existing solution for the stated goal*

If the aim is simply to clarify that user-space programs using kernel
UAPI/ABI via syscalls are *not* derivative works of the kernel, there is an
established SPDX exception used for this purpose: *Linux-syscall-note*
(paired with GPL-2.0-only). Reusing that pattern--or documenting the
clarification in project docs while using a standard license (e.g.,
Apache-2.0 or MIT/BSD)--would avoid introducing a new license and improve
portability and adoption.

Best,

2025年10月21日(火) 22:22 Carlo Piana via License-review <
license-review at lists.opensource.org>:

> Hi,
>
> thank you for the submission. I take that the .md file is just the gist of
> the license, but it is not useful to the approval process.
>
> I firstly note a potential ambiguity on who is the Licensor.  It can be
> either of:
>
> - everybody who holds any copyright  the software
> - who holds the copyright in the original
>
> The second seems the case, as you elected to define also contributor (as
> the Apache 2.0 does), which is an interesting election WRT patent license,
> but in other cases it creates an unacceptable, in my view, discrimination
> between Licensor and Contributor, for instance in 11. Termination and with
> a lesser problem in 12. Export Control. This alone discriminates different
> classes of copyright holders and I consider it potentially against #5.
>
> Also I am strongly in disfavor not only of any choice of law (only
> marginally problematic here), but also with any jurisdiction clause.  We
> had this discussion a number of times here.
>
> On the positive side, I note Section 6 that you took pains at not creating
> a condition there. Good. Also the patent grant seems correct (again,
> Apache-style).
>
> Section 7. creates text that makes difficult to port. It would be nice if
> submitters already decided to use placeholders instead of their name, or,
> better, to avoid placing the original licensor in a more favorable position
> than others, who might become even more prominent licensors.
>
> Section 9 seems a good example of how you can protect the interest of
> Contributors, Apache style. I hoped you had done the same elsewhere (see
> above).
>
> Also Section 10. although I am not sure I would accept it if I were a
> contributor and probably I would advise clients against it. The Apache
> license, which has a similar provision, makes it only as a consequence of
> the decision to provide a warranty, which makes more sense. This however
> does not seem to be against OSD, per se, but I urge you to reconsider this,
> it would create friction and I am not even sure it would hold water in many
> jurisdictions.
>
> Also Section 14 is problematic, as it is not clear what the matter hereof
> is. Suppose licensing software is a part of a contract agreement?
>
> As the copyright grant in Section 2, what language exactly enables the
> licensor to distribute dervative works at all? The license only extends to
> "prepare" and "reproduce", but the right to distribute is only granted in
> the software, in the source or binary form.
>
> Please avoid, by all means "open-source". The correct spelling is Open
> Source. https://opensource.org/blog/is-open-source-ever-hyphenated
>
> The definition of "Software" is also problematic. It only applies to
> Software as defined, and what if anyone would use it for different
> purposes? Why have not you defined software in Section 1 "Definition",
> leaving the preamble as a a non-normative part of the license?
>
> So, all in all there is some good faith effort and some quite apparent
> flaws, on a very cursory reading of the license.  I think fixing them
> (there might be others that I have not spotted) would be relatively easy,
> but at this version I would find it hard to approve it, even as a special
> purpose license.
>
> Cheers
>
> Carlo
> in his personal capacity
>
> ------------------------------
>
> *Da: *"Righteousness" <karuman2013 at gmail.com>
> *A: *"license-review at lists.opensource.org" <
> license-review at lists.opensource.org>
> *Inviato: *Lunedì, 20 ottobre 2025 15:09:03
> *Oggetto: *[License-review] Submission of Orivex Syscall Note License
> (OSN-1.0) for OSI Approval
>
> Dear Open Source Initiative License Review Committee,
>
> I am submitting the Orivex Syscall Note License (OSN-1.0) for your
> consideration for OSI approval.
>
> Background:
> Orivex is an operating system currently under active development. OSN-1.0
> is a permissive license specifically designed for Orivex’s kernel-facing
> components, including kernel headers, syscall interface definitions,
> reference ABI documentation, and related API files. This license is
> intended to enable Orivex to be released as open source in the future.
>
> Why a New License is Necessary:
> Existing OSI-approved licenses, such as MIT, BSD, or Apache 2.0, provide
> general-purpose permissive licensing but do not explicitly address kernel-
> and syscall-level artifacts. OSN-1.0 fills this gap by:
> - Preserving attribution and provenance specifically for kernel interfaces
> and ABI contracts.
> - Providing guidance for ABI and syscall interface compatibility without
> imposing legal obligations.
> - Explicitly separating trademark rights from copyright and patent grants.
> - Clarifying contributor patent grants and termination conditions related
> to patent litigation.
>
> Comparison to Similar OSI Licenses:
> - MIT/BSD: Similar in permissiveness and simplicity, but do not provide
> guidance on syscall/ABI traceability or contributor patent grant clarity.
> - Apache 2.0: Includes patent grants and some attribution requirements,
> but is heavier and not tailored for kernel-facing artifacts or
> syscall-specific documentation.
> OSN-1.0 balances permissiveness, clarity, and lightweight design, while
> providing explicit protections and guidance for kernel interface
> development.
>
> Open Source Definition Compliance:
> OSN-1.0 has been designed to satisfy all ten criteria of the Open Source
> Definition (OSD), including:
> - Free redistribution
> - Availability of source code
> - Permission to create derivative works
> - No discrimination against persons, groups, or fields of endeavor
> - Technology-neutral terms
> - Clear redistribution and license grant requirements
>
> Additional Information:
> - Copyright (c) 2025 Kartik
> - SPDX Identifier: Orivex-syscall-note
> - Governing Law: India
>
> I believe OSN-1.0 provides a clear, permissive license suitable for
> projects requiring kernel- or syscall-level interfaces while remaining
> fully OSD-compliant. I would be happy to provide any additional
> information, clarifications, or documentation needed to facilitate your
> review.
>
> Thank you for your time and consideration.
>
> Best regards,
> Kartik
> karuman2013 at gmail.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
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not
> necessarily those of the Open Source Initiative. Communication from the
> Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>


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

From wrarich at pppl.gov  Tue Oct 21 13:55:45 2025
From: wrarich at pppl.gov (Will Rarich)
Date: Tue, 21 Oct 2025 09:55:45 -0400
Subject: [License-review] OSI License Submission - PPPL BSD-3
In-Reply-To: 
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
Message-ID: 
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>

Hi,

I wanted to follow up on this discussion from earlier this year regarding a
genericization of the BSD-3-LBNL entry on the OSI site into one that can be
adapted to any DOE National Laboratory. We would like to have an OSI link
to refer to this preferred license, particularly within the metadata of
open source software listed in DOE CODE
<https://www.osti.gov/doecode/biblio/12565>. A "BSD-3-DOE" would be more
appropriate than the version naming LBNL.

Please let me know if there's any other information PPPL can provide to
justify this request.

Best,

Will Rarich
Technology Transfer Specialist
wrarich at pppl.gov
Mobile: (908)-285-7143
Visit us at https://innovation.pppl.gov/
*Princeton Plasma Physics Laboratory* is a U.S. Department of Energy
National Laboratory managed by Princeton University.
[image: PPPL]


On Mon, Jul 21, 2025 at 1:00 PM Will Rarich <wrarich at pppl.gov> wrote:

> Carlo,
>
> Thank you for your comments. Apologies for any confusion around the
> "claiming copyright" concept we mentioned in the request, it is just
> required in our government reporting obligations that we cite a published
> OSS license.
>
> Josh's suggestion to genericize the language in the BSD-LBNL on the OSI
> site is probably the ideal solution for us and other DOE labs. We only
> submitted this request because citing that version could be confusing,
> since it contains the specific name of the Lab.
>
> Best,
>
> Will Rarich
> Technology Transfer Specialist
> wrarich at pppl.gov
> Mobile: (908)-285-7143
> Visit us at https://innovation.pppl.gov/
> *Princeton Plasma Physics Laboratory* is a U.S. Department of Energy
> National Laboratory managed by Princeton University.
> [image: PPPL]
>
>
> On Fri, Jul 18, 2025 at 9:36 AM Carlo Piana <carlo at piana.eu> wrote:
>
>> Will,
>>
>> thank you for your submission.
>>
>> If I understand correctly, the main reason for creating a new license and
>> submit it as an approved license is to permit attribution of copyright? I
>> am rather opposed to have this kind of licenses approved, since the BSD
>> license has a placeholder and any name slotted in is by definition approved
>> and this one, if I understand it correctly, does not bring any difference
>> but the name, so it's the same license.
>>
>> Despite it not being necessarily an issue of proliferation, giving it a
>> different name when it's actually the same license, creates unnecessary
>> friction, clogs the namespace and creates a lot of issues in automated
>> license compatibility resolution, especially if it's given a separate SPDX
>> identifier.
>>
>> Besides, it is not the license the right place to claim copyright. In
>> source code there are standards like SPDX and REUSE and that one is the
>> (machine readable) way. In object code there are numerous ways too.
>>
>> Have you considered the above?
>>
>> Thank you very much.
>>
>> Carlo
>>
>>
>> ------------------------------
>>
>> *Da: *"Will Rarich via License-review" <
>> license-review at lists.opensource.org>
>> *A: *"license-review at lists.opensource.org" <
>> license-review at lists.opensource.org>
>> *Cc: *"Will Rarich" <wrarich at pppl.gov>
>> *Inviato: *Mercoledì, 9 luglio 2025 18:25:54
>> *Oggetto: *[License-review] OSI License Submission - PPPL BSD-3
>>
>> Hello,
>>
>> I work in the tech transfer office at the Princeton Plasma Physics Lab
>> (PPPL), a DOE National Laboratory, and I have recently taken up a
>> stewardship role over the lab's software portfolio. I am in the process of
>> ensuring we are compliant with our contractual obligations to the DOE in
>> how we obtain permission to copyright software, so there are a number of
>> "legacy" codes at the lab being open sourced in addition to anything newly
>> authored by our developers. My colleague Chris Wright has prepared a
>> preferred license for this process, a variant of Lawrence Berkeley National
>> Lab's BSD-3 license (https://opensource.org/license/bsd-3-clause-lbnl)
>> with PPPL's name substituted. We would like to have our license officially
>> approved by OSI to encourage its use when our developers decide to open
>> source through our office.
>>
>> As it pertains to this review process, this license would be considered
>> "new" as it has been in use for only a few months.
>>
>> The attached PPPL BSD-3 License complies with the Open Source Definition,
>> including clauses 3, 5, 6, and 9.
>>
>> Anarrima (https://github.com/PrincetonUniversity/anarrima) has been made
>> publicly available with the PPPL BSD-3 License, and several other
>> PPPL-developed codes will be imminently open sourced with it.
>>
>> The license steward is PPPL's Strategic Engagement and Applications
>> Development office (SEAD at pppl.gov).
>>
>> The license name is Princeton Plasma Physics Lab BSD Variant License with
>> the identifier BSD-3-Clause-PPPL.
>>
>> The gap filled by this additional license is PPPL's ability to assert
>> copyright on software authored by its staff and affiliates. When DOE-funded
>> software announcements are made in accordance with our government contract
>> at https://www.osti.gov/doecode/ the announcement requires the name
>> and/or link to the OSS License. Having the PPPL version of the
>> BSD-3-Clause-PPPL published on opensource.org will reduce confusion by
>> enabling links to the correct document.
>>
>> It is most similar to LBNL's BSD-3 license (
>> https://opensource.org/license/bsd-3-clause-lbnl) with PPPL's name
>> substituted throughout.
>>
>> The license has not been through legal review.
>>
>> I am happy to address any further questions or comments regarding this
>> license.
>>
>> Best,
>>
>> Will Rarich
>> Technology Transfer Specialist
>> wrarich at pppl.gov
>> Mobile: (908)-285-7143
>> Visit us at https://innovation.pppl.gov/
>> *Princeton Plasma Physics Laboratory* is a U.S. Department of Energy
>> National Laboratory managed by Princeton University.
>> [image: PPPL]
>>
>> _______________________________________________
>> The opinions expressed in this email are those of the sender and not
>> necessarily those of the Open Source Initiative. Communication from the
>> Open Source Initiative will be sent from an opensource.org email address.
>>
>> License-review mailing list
>> License-review at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251021/3638994d/attachment.htm>

From rfontana at redhat.com  Wed Oct 22 13:35:07 2025
From: rfontana at redhat.com (Richard Fontana)
Date: Wed, 22 Oct 2025 09:35:07 -0400
Subject: [License-review] OSI License Submission - PPPL BSD-3
In-Reply-To: 
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
Message-ID: 
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>

If I understand correctly, the objection is actually to use of an SPDX
identifier that refers to `LBNL`. I would say you should raise this with
the SPDX legal team  and that this is not an OSI issue. (cc'ing Jilayne
Lovejoy who's on the SPDX legal team)

I suppose OSI could rename "Lawrence Berkeley National Labs BSD Variant
License" to something more generic but I don't think that would guarantee
that SPDX would follow suit with its corresponding identifier.

But it seems somewhat akin to a project complaining about using
`Apache-2.0` or `GPL-2.0-or-later` because the project is not affiliated
with the Apache Software Foundation or the GNU project, respectively. It's
an arguably charming feature of open source that licenses often have names
with historical associations that refer to particular licensors -- indeed
this is of course also true of "BSD". Especially on the SPDX identifier
side, or in cases where an SPDX identifier is assigned before a license
gets OSI-approved (possibly relevant to `BSD-3-Clause-LBNL`?), the problem
is that sometimes the SPDX identifier has what I'd argue is the "wrong"
historical association, in the sense that the license in question
originated with some earlier licensor/author/copyright holder, though I
don't know if that's relevant in this case.

Richard


On Wed, Oct 22, 2025 at 8:14 AM Will Rarich via License-review <
license-review at lists.opensource.org> wrote:

> Hi,
>
> I wanted to follow up on this discussion from earlier this year regarding
> a genericization of the BSD-3-LBNL entry on the OSI site into one that can
> be adapted to any DOE National Laboratory. We would like to have an OSI
> link to refer to this preferred license, particularly within the metadata
> of open source software listed in DOE CODE
> <https://www.osti.gov/doecode/biblio/12565>. A "BSD-3-DOE" would be more
> appropriate than the version naming LBNL.
>
> Please let me know if there's any other information PPPL can provide to
> justify this request.
>
> Best,
>
> Will Rarich
> Technology Transfer Specialist
> wrarich at pppl.gov
> Mobile: (908)-285-7143
> Visit us at https://innovation.pppl.gov/
> *Princeton Plasma Physics Laboratory* is a U.S. Department of Energy
> National Laboratory managed by Princeton University.
> [image: PPPL]
>
>
> On Mon, Jul 21, 2025 at 1:00 PM Will Rarich <wrarich at pppl.gov> wrote:
>
>> Carlo,
>>
>> Thank you for your comments. Apologies for any confusion around the
>> "claiming copyright" concept we mentioned in the request, it is just
>> required in our government reporting obligations that we cite a published
>> OSS license.
>>
>> Josh's suggestion to genericize the language in the BSD-LBNL on the OSI
>> site is probably the ideal solution for us and other DOE labs. We only
>> submitted this request because citing that version could be confusing,
>> since it contains the specific name of the Lab.
>>
>> Best,
>>
>> Will Rarich
>> Technology Transfer Specialist
>> wrarich at pppl.gov
>> Mobile: (908)-285-7143
>> Visit us at https://innovation.pppl.gov/
>> *Princeton Plasma Physics Laboratory* is a U.S. Department of Energy
>> National Laboratory managed by Princeton University.
>> [image: PPPL]
>>
>>
>> On Fri, Jul 18, 2025 at 9:36 AM Carlo Piana <carlo at piana.eu> wrote:
>>
>>> Will,
>>>
>>> thank you for your submission.
>>>
>>> If I understand correctly, the main reason for creating a new license
>>> and submit it as an approved license is to permit attribution of copyright?
>>> I am rather opposed to have this kind of licenses approved, since the BSD
>>> license has a placeholder and any name slotted in is by definition approved
>>> and this one, if I understand it correctly, does not bring any difference
>>> but the name, so it's the same license.
>>>
>>> Despite it not being necessarily an issue of proliferation, giving it a
>>> different name when it's actually the same license, creates unnecessary
>>> friction, clogs the namespace and creates a lot of issues in automated
>>> license compatibility resolution, especially if it's given a separate SPDX
>>> identifier.
>>>
>>> Besides, it is not the license the right place to claim copyright. In
>>> source code there are standards like SPDX and REUSE and that one is the
>>> (machine readable) way. In object code there are numerous ways too.
>>>
>>> Have you considered the above?
>>>
>>> Thank you very much.
>>>
>>> Carlo
>>>
>>>
>>> ------------------------------
>>>
>>> *Da: *"Will Rarich via License-review" <
>>> license-review at lists.opensource.org>
>>> *A: *"license-review at lists.opensource.org" <
>>> license-review at lists.opensource.org>
>>> *Cc: *"Will Rarich" <wrarich at pppl.gov>
>>> *Inviato: *Mercoledì, 9 luglio 2025 18:25:54
>>> *Oggetto: *[License-review] OSI License Submission - PPPL BSD-3
>>>
>>> Hello,
>>>
>>> I work in the tech transfer office at the Princeton Plasma Physics Lab
>>> (PPPL), a DOE National Laboratory, and I have recently taken up a
>>> stewardship role over the lab's software portfolio. I am in the process of
>>> ensuring we are compliant with our contractual obligations to the DOE in
>>> how we obtain permission to copyright software, so there are a number of
>>> "legacy" codes at the lab being open sourced in addition to anything newly
>>> authored by our developers. My colleague Chris Wright has prepared a
>>> preferred license for this process, a variant of Lawrence Berkeley National
>>> Lab's BSD-3 license (https://opensource.org/license/bsd-3-clause-lbnl)
>>> with PPPL's name substituted. We would like to have our license officially
>>> approved by OSI to encourage its use when our developers decide to open
>>> source through our office.
>>>
>>> As it pertains to this review process, this license would be considered
>>> "new" as it has been in use for only a few months.
>>>
>>> The attached PPPL BSD-3 License complies with the Open Source
>>> Definition, including clauses 3, 5, 6, and 9.
>>>
>>> Anarrima (https://github.com/PrincetonUniversity/anarrima) has been
>>> made publicly available with the PPPL BSD-3 License, and several other
>>> PPPL-developed codes will be imminently open sourced with it.
>>>
>>> The license steward is PPPL's Strategic Engagement and Applications
>>> Development office (SEAD at pppl.gov).
>>>
>>> The license name is Princeton Plasma Physics Lab BSD Variant License
>>> with the identifier BSD-3-Clause-PPPL.
>>>
>>> The gap filled by this additional license is PPPL's ability to assert
>>> copyright on software authored by its staff and affiliates. When DOE-funded
>>> software announcements are made in accordance with our government contract
>>> at https://www.osti.gov/doecode/ the announcement requires the name
>>> and/or link to the OSS License. Having the PPPL version of the
>>> BSD-3-Clause-PPPL published on opensource.org will reduce confusion by
>>> enabling links to the correct document.
>>>
>>> It is most similar to LBNL's BSD-3 license (
>>> https://opensource.org/license/bsd-3-clause-lbnl) with PPPL's name
>>> substituted throughout.
>>>
>>> The license has not been through legal review.
>>>
>>> I am happy to address any further questions or comments regarding this
>>> license.
>>>
>>> Best,
>>>
>>> Will Rarich
>>> Technology Transfer Specialist
>>> wrarich at pppl.gov
>>> Mobile: (908)-285-7143
>>> Visit us at https://innovation.pppl.gov/
>>> *Princeton Plasma Physics Laboratory* is a U.S. Department of Energy
>>> National Laboratory managed by Princeton University.
>>> [image: PPPL]
>>>
>>> _______________________________________________
>>> 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: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251022/d880e50f/attachment-0001.htm>

From mccoy at lexpan.law  Wed Oct 22 15:50:52 2025
From: mccoy at lexpan.law (McCoy Smith)
Date: Wed, 22 Oct 2025 08:50:52 -0700
Subject: [License-review] OSI License Submission - PPPL BSD-3
In-Reply-To: 
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
Message-ID: <93302564-8af5-462d-983e-b8751b826fa1@lexpan.law>

I don't think OSI is proposing to rename this license (the PPPL one; the 
LBNL one is already approved under its current and historical name). I 
think the idea here is that PPPL doesn't need a separate approval or 
entry (by OSI) as it is really just LBNL with a different author name. 
And thus would fall within the existing approval of LBNL if OSI were to 
adopt the "replaceable language" schema of SPDX (which I think it should).

GIven that LBNL is already approved under that name (and has an SPDX 
identifier under that name) I don't think anyone ought to be renaming it 
(even if it is just in metadata).


On 10/22/2025 6:35 AM, Richard Fontana via License-review wrote:
> If I understand correctly, the objection is actually to use of an SPDX 
> identifier that refers to `LBNL`. I would say you should raise this 
> with the SPDX legal team  and that this is not an OSI issue. (cc'ing 
> Jilayne Lovejoy who's on the SPDX legal team)
>
> I suppose OSI could rename "Lawrence Berkeley National Labs BSD 
> Variant License" to something more generic but I don't think that 
> would guarantee that SPDX would follow suit with its corresponding 
> identifier.
>
> But it seems somewhat akin to a project complaining about using 
> `Apache-2.0` or `GPL-2.0-or-later` because the project is not 
> affiliated with the Apache Software Foundation or the GNU project, 
> respectively. It's an arguably charming feature of open source that 
> licenses often have names with historical associations that refer to 
> particular licensors -- indeed this is of course also true of "BSD". 
> Especially on the SPDX identifier side, or in cases where an SPDX 
> identifier is assigned before a license gets OSI-approved (possibly 
> relevant to `BSD-3-Clause-LBNL`?), the problem is that sometimes the 
> SPDX identifier has what I'd argue is the "wrong" historical 
> association, in the sense that the license in question originated with 
> some earlier licensor/author/copyright holder, though I don't know if 
> that's relevant in this case.
>
> Richard
>
>
> On Wed, Oct 22, 2025 at 8:14 AM Will Rarich via License-review 
> <license-review at lists.opensource.org> wrote:
>
>     Hi,
>
>     I wanted to follow up on this discussion from earlier this year
>     regarding a genericization of the BSD-3-LBNL entry on the OSI site
>     into one that can be adapted to any DOE National Laboratory. We
>     would like to have an OSI link to refer to this preferred license,
>     particularly within the metadata of open source software listed in
>     DOE CODE <https://www.osti.gov/doecode/biblio/12565>. A
>     "BSD-3-DOE" would be more appropriate than the version naming LBNL.
>
>     Please let me know if there's any other information PPPL can
>     provide to justify this request.
>
>     Best,
>
>     Will Rarich
>     Technology Transfer Specialist
>     wrarich at pppl.gov
>     Mobile: (908)-285-7143
>     Visit us at https://innovation.pppl.gov/
>     *Princeton Plasma Physics Laboratory* is a U.S. Department of
>     Energy National Laboratory managed by Princeton University.
>     PPPL
>
>
>     On Mon, Jul 21, 2025 at 1:00 PM Will Rarich <wrarich at pppl.gov> wrote:
>
>         Carlo,
>
>         Thank you for your comments. Apologies for any confusion
>         around the "claiming copyright" concept we mentioned in the
>         request, it is just required in our government reporting
>         obligations that we cite a published OSS license.
>
>         Josh's suggestion to genericize the language in the BSD-LBNL
>         on the OSI site is probably the ideal solution for us and
>         other DOE labs. We only submitted this request because citing
>         that version could be confusing, since it contains the
>         specific name of the Lab.
>
>         Best,
>
>         Will Rarich
>         Technology Transfer Specialist
>         wrarich at pppl.gov
>         Mobile: (908)-285-7143
>         Visit us at https://innovation.pppl.gov/
>         *Princeton Plasma Physics Laboratory* is a U.S. Department of
>         Energy National Laboratory managed by Princeton University.
>         PPPL
>
>
>         On Fri, Jul 18, 2025 at 9:36 AM Carlo Piana <carlo at piana.eu>
>         wrote:
>
>             Will,
>
>             thank you for your submission.
>
>             If I understand correctly, the main reason for creating a
>             new license and submit it as an approved license is to
>             permit attribution of copyright? I am rather opposed to
>             have this kind of licenses approved, since the BSD license
>             has a placeholder and any name slotted in is by definition
>             approved and this one, if I understand it correctly, does
>             not bring any difference but the name, so it's the same
>             license.
>
>             Despite it not being necessarily an issue of
>             proliferation, giving it a different name when it's
>             actually the same license, creates unnecessary friction,
>             clogs the namespace and creates a lot of issues in
>             automated license compatibility resolution, especially if
>             it's given a separate SPDX identifier.
>
>             Besides, it is not the license the right place to claim
>             copyright. In source code there are standards like SPDX
>             and REUSE and that one is the (machine readable) way. In
>             object code there are numerous ways too.
>
>             Have you considered the above?
>
>             Thank you very much.
>
>             Carlo
>
>
>             ------------------------------------------------------------------------
>
>                 *Da: *"Will Rarich via License-review"
>                 <license-review at lists.opensource.org>
>                 *A: *"license-review at lists.opensource.org"
>                 <license-review at lists.opensource.org>
>                 *Cc: *"Will Rarich" <wrarich at pppl.gov>
>                 *Inviato: *Mercoledì, 9 luglio 2025 18:25:54
>                 *Oggetto: *[License-review] OSI License Submission -
>                 PPPL BSD-3
>
>                 Hello,
>
>                 I work in the tech transfer office at the Princeton
>                 Plasma Physics Lab (PPPL), a DOE National Laboratory,
>                 and I have recently taken up a stewardship role over
>                 the lab's software portfolio. I am in the process of
>                 ensuring we are compliant with our contractual
>                 obligations to the DOE in how we obtain permission to
>                 copyright software, so there are a number of "legacy"
>                 codes at the lab being open sourced in addition to
>                 anything newly authored by our developers. My
>                 colleague Chris Wright has prepared a preferred
>                 license for this process, a variant of Lawrence
>                 Berkeley National Lab's BSD-3 license
>                 (https://opensource.org/license/bsd-3-clause-lbnl)
>                 with PPPL's name substituted. We would like to have
>                 our license officially approved by OSI to encourage
>                 its use when our developers decide to open source
>                 through our office.
>
>                 As it pertains to this review process, this license
>                 would be considered "new" as it has been in use for
>                 only a few months.
>
>                 The attached PPPL BSD-3 License complies with the Open
>                 Source Definition, including clauses 3, 5, 6, and 9.
>
>                 Anarrima
>                 (https://github.com/PrincetonUniversity/anarrima) has
>                 been made publicly available with the PPPL BSD-3
>                 License, and several other PPPL-developed codes will
>                 be imminently open sourced with it.
>
>                 The license steward is PPPL's Strategic Engagement and
>                 Applications Development office (SEAD at pppl.gov).
>
>                 The license name is Princeton Plasma Physics Lab BSD
>                 Variant License with the identifier BSD-3-Clause-PPPL.
>
>                 The gap filled by this additional license is
>                 PPPL's ability to assert copyright on software
>                 authored by its staff and affiliates. When DOE-funded
>                 software announcements are made in accordance with our
>                 government contract at https://www.osti.gov/doecode/
>                 the announcement requires the name and/or link to the
>                 OSS License. Having the PPPL version of the
>                 BSD-3-Clause-PPPL published on opensource.org
>                 <http://opensource.org> will reduce confusion by
>                 enabling links to the correct document.
>
>                 It is most similar to LBNL's BSD-3
>                 license (https://opensource.org/license/bsd-3-clause-lbnl)
>                 with PPPL's name substituted throughout.
>
>                 The license has not been through legal review.
>
>                 I am happy to address any further questions or
>                 comments regarding this license.
>
>                 Best,
>
>                 Will Rarich
>                 Technology Transfer Specialist
>                 wrarich at pppl.gov
>                 Mobile: (908)-285-7143
>                 Visit us at https://innovation.pppl.gov/
>                 *Princeton Plasma Physics Laboratory* is a U.S.
>                 Department of Energy National Laboratory managed by
>                 Princeton University.
>                 PPPL
>
>                 _______________________________________________
>                 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
>                 <http://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 <http://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: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251022/5357ecb5/attachment-0001.htm>

From josh.berkus at opensource.org  Wed Oct 22 16:13:12 2025
From: josh.berkus at opensource.org (Josh Berkus)
Date: Wed, 22 Oct 2025 09:13:12 -0700
Subject: [License-review] OSI License Submission - PPPL BSD-3
In-Reply-To: 
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
Message-ID: <c9343a2f-ae3a-43d7-9090-472baa053f4a@opensource.org>

On 10/22/25 6:35 AM, Richard Fontana via License-review wrote:
> If I understand correctly, the objection is actually to use of an SPDX 
> identifier that refers to `LBNL`. I would say you should raise this with 
> the SPDX legal team  and that this is not an OSI issue. (cc'ing Jilayne 
> Lovejoy who's on the SPDX legal team)

If SPDX does want to rename/dual-name, of course, we'll adjust our 
catalog to suit.

-- 
-- Josh Berkus
OSI Board Member

From josh at berkus.org  Wed Oct 22 18:28:55 2025
From: josh at berkus.org (Josh Berkus)
Date: Wed, 22 Oct 2025 11:28:55 -0700
Subject: [License-review] OSI License Submission - PPPL BSD-3
In-Reply-To: <93302564-8af5-462d-983e-b8751b826fa1@lexpan.law>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
 <93302564-8af5-462d-983e-b8751b826fa1@lexpan.law>
Message-ID: <c8575e64-e5ea-4035-96de-652eacf3ac4c@berkus.org>

On 10/22/25 8:50 AM, McCoy Smith wrote:
> I don't think OSI is proposing to rename this license (the PPPL one; the 
> LBNL one is already approved under its current and historical name). I 
> think the idea here is that PPPL doesn't need a separate approval or 
> entry (by OSI) as it is really just LBNL with a different author name. 
> And thus would fall within the existing approval of LBNL if OSI were to 
> adopt the "replaceable language" schema of SPDX (which I think it should).

We have done the thing before where in the preface to the license on our 
page we list other names the license is known by.  We could do that 
here, with an "Also known as BSD-3-PPPL or BSD-3-DOE".

-- 
Josh Berkus

From josh.berkus at opensource.org  Wed Oct 22 21:22:20 2025
From: josh.berkus at opensource.org (Josh Berkus)
Date: Wed, 22 Oct 2025 14:22:20 -0700
Subject: [License-review] [External] Re:  OSI License Submission - PPPL
 BSD-3
In-Reply-To: 
 <CAJXV7V6XYygWLJ0D=V1Hb0Z=eW1LCLdhcc+E2SaBg4M_NRGrTA@mail.gmail.com>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
 <c9343a2f-ae3a-43d7-9090-472baa053f4a@opensource.org>
 <CAJXV7V6XYygWLJ0D=V1Hb0Z=eW1LCLdhcc+E2SaBg4M_NRGrTA@mail.gmail.com>
Message-ID: <e0117a36-e44a-44fa-8c3e-a3b6c99ec49f@opensource.org>

On 10/22/25 9:21 AM, Chris Wright wrote:
> Thanks for discussing this with us. I don't actually mind the name 
> remaining BSD-LBNL, I agree with Richard that sometimes the historical 
> aspect is actually a fun nomenclature to maintain. My reason for 
> opening this discussion was instead that the text of the license itself 
> contains "Lawrence Berkeley National Lab" in several places, which needs 
> to be generalized to <COPYRIGHT HOLDER> or something like that. And if 
> LBNL wants to keep their version with their name specifically included, 
> then maybe we need a different name for the generic version. I can talk 
> to LBNL if that is helpful also.

That genericization update is happening soon, the Board just voted to 
authorize it.

-- 
-- Josh Berkus
OSI Board Member

From pamela at chesteklegal.com  Thu Oct 23 07:04:59 2025
From: pamela at chesteklegal.com (Pamela Chestek)
Date: Thu, 23 Oct 2025 00:04:59 -0700
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval
In-Reply-To: 
 <CAAvo7O47-ivGkeHnsCaszE+g+r+A7-SxDU82AduJSJX7GRRzFg@mail.gmail.com>
References: 
 <CAE0NYFH31bsTaf_Mv1qcz7jqHwPPfy7NMaw_TzxRTC9WLQWYOw@mail.gmail.com>
 <1760796185.26429334.1761052877264.JavaMail.zimbra@piana.eu>
 <CAAvo7O47-ivGkeHnsCaszE+g+r+A7-SxDU82AduJSJX7GRRzFg@mail.gmail.com>
Message-ID: <10d4c837-815a-4d1f-961d-c416f1618702@chesteklegal.com>

I agree with all the prior commenters statements and would like to add 
my thoughts.

My primary concern is Section 6, which I recognize is the rationale for 
creating a new license. However, it is expressly not binding. In my 
view, it therefore has no business being in the document. There is a 
legal principle (at least in the US) that every word in a written 
agreement is there for a reason. Including terms that aren't binding 
therefore opens the door to misinterpretation and misconstruction of the 
license because a court may struggle to figure out what the heck it's 
meant to do with this section. The place to express this sort of desire, 
and in fact make it meaningful, is in your contribution policy. You can 
reject a contribution if it does not preserve ABI and syscall interface 
compatibility, so you can at least protect the blessed version of the 
program. And, as you've conceded in the license, if downstream modifiers 
don't do so, there's nothing you can do about it anyway. So I believe 
this section can only create confusion and difficulty in its legal 
interpretation and the problem is better dealt with elsewhere.

Section 3.1 is a grant of a patent license "only to the extent such 
patent claims are necessarily infringed by the Software */as delivered 
by/* the Licensor." This can be read to say that only those who receive 
the software directly from the patent holder are granted the patent 
license. Sublicensees, or someone who receives the code from a mirror 
site, would not have the patent license. That's not acceptable in an 
open source license. I assume the problem you are trying to solve is to 
avoid granting a license to later-modified software, but this word 
choice isn't likely to be interpreted that way. As an example, the 
Apache license uses the phrase "where such license applies only to those 
patent claims licensable by such Contributor" to solve the problem.

To Shuji-san's comment that there are two sublicense provisions, 2.2 and 
4.6, I would add that there is another confusing spot, 2.4, which says 
that a license is granted to "permit third parties to exercise any of 
the foregoing rights." Isn't that a sublicense? What else might it mean? 
Also, I believe nowadays sublicenses are generally disfavored in open 
source licenses and the better practice is that everyone is a direct 
licensee, as modeled by the way it's handled in the GPL licenses. So I 
would just take out the concept of sublicensing altogether.

Is it your intention to create a copyleft license? In section 5.2 you 
state "Each Contributor Grants the Licensor and recipients of the 
Software the licenses described in Sections 2 and 3 for their 
Contribution." You also state in 1.2 that the "Licensor" means ... any 
entity that subsequently holds copyright in the Software and distributes 
it under OSN-1.0." The combination of these sections suggests that you 
mean to have all Contributor's must use this license, that is, that it's 
a copyleft license. If that is your intention, it needs to be said more 
clearly. If it's not your intention, then the language needs to be 
cleaned up to avoid the implication. Also, why mention only sections 2 
and 3, why not require adoption of all the terms of the agreement? 
Referring only to sections 2 and 3 means that the contributor could 
argue they did not agree to other parts of the license, such as allowing 
a cure period for termination.

Section 7.3, when you say "compliance with such [external trademark] 
guidelines is required to make use of Orivex trademarks beyond the 
attribution described above," creates the possibility that there are 
additional terms not contained in the license. The OSI won't approve 
licenses that have unknown terms external to the license because it's 
possible for those terms to impose additional requirements that are 
inconsistent with the OSD. For example, the trademark guidelines could 
prohibit a lawful use of the trademark in exchange for a requirement 
that does not comply with the OSD, like "commercial distributions must 
remove all use of the Orivex trademark in the source code," resulting in 
a violation of OSD6.

Section 5.4 is unnecessary. I've never seen it argued that a project 
must accept contributions, so saying that you don't have to in some, or 
any, circumstance doesn't add anything.

For the above reasons I am not in favor of approving this license.

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 10/21/2025 7:12 AM, Shuji Sado wrote:
>
> Hi,
>
> Thanks to Carlo-san for the thorough review. I broadly agree with his 
> analysis. I'd like to add three narrower points that I don't think 
> were explicitly covered, plus one suggestion about an existing pattern 
> that may meet the author's stated goal without a new license.
>
> *1) Sublicensing inconsistency*
>
> §2.2 appears to grant an open-ended right to "sublicense," while §4.6 
> conditions sublicensing on passing through the original terms; the 
> definitions also fold "sublicense" into "Distribution." This creates 
> ambiguity about whether downstreams rely on the original license or a 
> new downstream license.
>
> *2) Fixed attribution phrase in §4.3*
>
> Mandating the exact sentence ("This distribution includes Orivex 
> syscall interfaces (OSN-1.0) ...") to be displayed "prominently" is 
> heavier than common NOTICE/attribution practice and reduces 
> reusability for non-Orivex projects.
>
> *3) Making an SPDX identifier part of the redistribution requirement 
> (§4.1)*
>
> SPDX tags are excellent metadata, but they are managed outside the 
> license and may not exist for a new text. Making their inclusion a 
> legal condition of redistribution can fail for reasons unrelated to 
> copyright compliance.
>
> *Existing solution for the stated goal*
>
> If the aim is simply to clarify that user-space programs using kernel 
> UAPI/ABI via syscalls are *not* derivative works of the kernel, there 
> is an established SPDX exception used for this purpose: 
> *Linux-syscall-note* (paired with GPL-2.0-only). Reusing that 
> pattern--or documenting the clarification in project docs while using 
> a standard license (e.g., Apache-2.0 or MIT/BSD)--would avoid 
> introducing a new license and improve portability and adoption.
>
> Best,
>
>
> 2025年10月21日(火) 22:22 Carlo Piana via License-review 
> <license-review at lists.opensource.org>:
>
>     Hi,
>
>     thank you for the submission. I take that the .md file is just the
>     gist of the license, but it is not useful to the approval process.
>
>     I firstly note a potential ambiguity on who is the Licensor.  It
>     can be either of:
>
>     - everybody who holds any copyright  the software
>     - who holds the copyright in the original
>
>     The second seems the case, as you elected to define also
>     contributor (as the Apache 2.0 does), which is an interesting
>     election WRT patent license, but in other cases it creates an
>     unacceptable, in my view, discrimination between Licensor and
>     Contributor, for instance in 11. Termination and with a lesser
>     problem in 12. Export Control. This alone discriminates different
>     classes of copyright holders and I consider it potentially against #5.
>
>     Also I am strongly in disfavor not only of any choice of law (only
>     marginally problematic here), but also with any jurisdiction
>     clause.  We had this discussion a number of times here.
>
>     On the positive side, I note Section 6 that you took pains at not
>     creating a condition there. Good. Also the patent grant seems
>     correct (again, Apache-style).
>
>     Section 7. creates text that makes difficult to port. It would be
>     nice if submitters already decided to use placeholders instead of
>     their name, or, better, to avoid placing the original licensor in
>     a more favorable position than others, who might become even more
>     prominent licensors.
>
>     Section 9 seems a good example of how you can protect the interest
>     of Contributors, Apache style. I hoped you had done the same
>     elsewhere (see above).
>
>     Also Section 10. although I am not sure I would accept it if I
>     were a contributor and probably I would advise clients against it.
>     The Apache license, which has a similar provision, makes it only
>     as a consequence of the decision to provide a warranty, which
>     makes more sense. This however does not seem to be against OSD,
>     per se, but I urge you to reconsider this, it would create
>     friction and I am not even sure it would hold water in many
>     jurisdictions.
>
>     Also Section 14 is problematic, as it is not clear what the matter
>     hereof is. Suppose licensing software is a part of a contract
>     agreement?
>
>     As the copyright grant in Section 2, what language exactly enables
>     the licensor to distribute dervative works at all? The license
>     only extends to "prepare" and "reproduce", but the right to
>     distribute is only granted in the software, in the source or
>     binary form.
>
>     Please avoid, by all means "open-source". The correct spelling is
>     Open Source.
>     https://opensource.org/blog/is-open-source-ever-hyphenated
>
>     The definition of "Software" is also problematic. It only applies
>     to Software as defined, and what if anyone would use it for
>     different purposes? Why have not you defined software in Section 1
>     "Definition", leaving the preamble as a a non-normative part of
>     the license?
>
>     So, all in all there is some good faith effort and some quite
>     apparent flaws, on a very cursory reading of the license.  I think
>     fixing them (there might be others that I have not spotted) would
>     be relatively easy, but at this version I would find it hard to
>     approve it, even as a special purpose license.
>
>     Cheers
>
>     Carlo
>     in his personal capacity
>
>     ------------------------------------------------------------------------
>
>         *Da: *"Righteousness" <karuman2013 at gmail.com>
>         *A: *"license-review at lists.opensource.org"
>         <license-review at lists.opensource.org>
>         *Inviato: *Lunedì, 20 ottobre 2025 15:09:03
>         *Oggetto: *[License-review] Submission of Orivex Syscall Note
>         License (OSN-1.0) for OSI Approval
>
>         Dear Open Source Initiative License Review Committee,
>
>         I am submitting the Orivex Syscall Note License (OSN-1.0) for
>         your consideration for OSI approval.
>
>         Background:
>         Orivex is an operating system currently under active
>         development. OSN-1.0 is a permissive license specifically
>         designed for Orivex’s kernel-facing components, including
>         kernel headers, syscall interface definitions, reference ABI
>         documentation, and related API files. This license is intended
>         to enable Orivex to be released as open source in the future.
>
>         Why a New License is Necessary:
>         Existing OSI-approved licenses, such as MIT, BSD, or Apache
>         2.0, provide general-purpose permissive licensing but do not
>         explicitly address kernel- and syscall-level artifacts.
>         OSN-1.0 fills this gap by:
>         - Preserving attribution and provenance specifically for
>         kernel interfaces and ABI contracts.
>         - Providing guidance for ABI and syscall interface
>         compatibility without imposing legal obligations.
>         - Explicitly separating trademark rights from copyright and
>         patent grants.
>         - Clarifying contributor patent grants and termination
>         conditions related to patent litigation.
>
>         Comparison to Similar OSI Licenses:
>         - MIT/BSD: Similar in permissiveness and simplicity, but do
>         not provide guidance on syscall/ABI traceability or
>         contributor patent grant clarity.
>         - Apache 2.0: Includes patent grants and some attribution
>         requirements, but is heavier and not tailored for
>         kernel-facing artifacts or syscall-specific documentation.
>         OSN-1.0 balances permissiveness, clarity, and lightweight
>         design, while providing explicit protections and guidance for
>         kernel interface development.
>
>         Open Source Definition Compliance:
>         OSN-1.0 has been designed to satisfy all ten criteria of the
>         Open Source Definition (OSD), including:
>         - Free redistribution
>         - Availability of source code
>         - Permission to create derivative works
>         - No discrimination against persons, groups, or fields of endeavor
>         - Technology-neutral terms
>         - Clear redistribution and license grant requirements
>
>         Additional Information:
>         - Copyright (c) 2025 Kartik
>         - SPDX Identifier: Orivex-syscall-note
>         - Governing Law: India
>
>         I believe OSN-1.0 provides a clear, permissive license
>         suitable for projects requiring kernel- or syscall-level
>         interfaces while remaining fully OSD-compliant. I would be
>         happy to provide any additional information, clarifications,
>         or documentation needed to facilitate your review.
>
>         Thank you for your time and consideration.
>
>         Best regards,
>         Kartik
>         karuman2013 at gmail.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 <http://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 <http://opensource.org> email address.
>
>     License-review mailing list
>     License-review at lists.opensource.org
>     http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
>
> -- 
> Shuji Sado
> Chairman, Open Source Group Japan
> https://opensource.jp/
> English blog: https://shujisado.org/
> Japanese blog: https://shujisado.com/
>
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251023/c74c6ac0/attachment-0001.htm>

From mccoy at lexpan.law  Thu Oct 23 14:28:36 2025
From: mccoy at lexpan.law (McCoy Smith)
Date: Thu, 23 Oct 2025 07:28:36 -0700
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval
In-Reply-To: <10d4c837-815a-4d1f-961d-c416f1618702@chesteklegal.com>
References: 
 <CAE0NYFH31bsTaf_Mv1qcz7jqHwPPfy7NMaw_TzxRTC9WLQWYOw@mail.gmail.com>
 <1760796185.26429334.1761052877264.JavaMail.zimbra@piana.eu>
 <CAAvo7O47-ivGkeHnsCaszE+g+r+A7-SxDU82AduJSJX7GRRzFg@mail.gmail.com>
 <10d4c837-815a-4d1f-961d-c416f1618702@chesteklegal.com>
Message-ID: <2a83c057-9765-4e7f-9d7a-3a9de57bff9d@lexpan.law>

On 10/23/2025 12:04 AM, Pamela Chestek wrote:
>
> Section 5.4 is unnecessary. I've never seen it argued that a project 
> must accept contributions, so saying that you don't have to in some, 
> or any, circumstance doesn't add anything.
>
The whole contribution section really doesn't make sense.

Section 5.2 says "Each Contributor grants the Licensor and recipients of 
the Software the licenses described in Sections 2 and 3 for their 
Contribution." But Section 5.3 says "Optionally, the Licensor may 
provide a Contributor License Agreement (CLA) or Developer Agreement for 
signature; signing such an agreement is not mandatory to contribute 
but may be required by the project for administrative or corporate 
compliance reasons."

What happens if the terms of the 5.3 contribution agreement are 
narrower, or broader, than the automatic contribution terms in 5.2? 
Which terms govern the contribution? Also, if the CLA of 5.3 is not 
mandatory to contribute, what's the point in addressing it in this license?


Also, the requirements for approval are that you:

  * Describe what gap not filled by currently existing licenses that the
    new license will fill.
  * Compare it to and contrast it with the most similar OSI-approved
    license(s).
  * Describe any legal review the license has been through, including
    whether it was drafted by a lawyer.


I'm not sure any of these have been done (there certainly isn't any 
discussion of legal review); there is a mention of this license being 
somewhat based on Apache-2.0 or perhaps MIT or perhaps both and it seems 
to borrow some of the text of those licenses, but it's not clear to me 
what gap this license fills over that license (other than the various 
non-mandatory portions already commented upon) and how it differs and 
contrasts with that license. I tried to do a redline compare of OSN vs 
Apache 2.0 and didn't see a whole lot that was reproduced.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251023/c1356609/attachment.htm>

From sainslie at lbl.gov  Thu Oct 23 18:39:22 2025
From: sainslie at lbl.gov (sainslie at lbl.gov)
Date: Thu, 23 Oct 2025 11:39:22 -0700
Subject: [License-review] [External] Re:  OSI License Submission - PPPL
 BSD-3
In-Reply-To: 
 <CAJXV7V4Q28EiE-svnC0BGuzCL3wvxZ-8e97_gnU6pNPotjaV5g@mail.gmail.com>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
 <c9343a2f-ae3a-43d7-9090-472baa053f4a@opensource.org>
 <CAJXV7V6XYygWLJ0D=V1Hb0Z=eW1LCLdhcc+E2SaBg4M_NRGrTA@mail.gmail.com>
 <e0117a36-e44a-44fa-8c3e-a3b6c99ec49f@opensource.org>
 <CAJXV7V4Q28EiE-svnC0BGuzCL3wvxZ-8e97_gnU6pNPotjaV5g@mail.gmail.com>
Message-ID: <009901dc444c$5a603510$0f209f30$@lbl.gov>

Hi. Not a problem. Was in use a few years before my time at LBNL (2015) and was used by LBNL first. If it becomes more generic regarding the copyright of the entity using it that’s fine by me. It would be nice if it could still be called the LBNL BSD as it is a variant BSD first used and created by LBNL.

 

Sebastian

 

From: Chris Wright <cwright at pppl.gov> 
Sent: Thursday, October 23, 2025 11:13 AM
To: Josh Berkus <josh.berkus at opensource.org>; Sebastian Ainslie <sainslie at lbl.gov>
Cc: License submissions for OSI review <license-review at lists.opensource.org>; Richard Fontana <rfontana at redhat.com>; Will Rarich <wrarich at pppl.gov>; J Lovejoy <opensource at jilayne.com>
Subject: Re: [External] Re: [License-review] OSI License Submission - PPPL BSD-3

 

Excellent thank you Josh!

 

I am copying Sebastian at LBNL for his awareness since the BSD-LBNL is his license. 

 

Long story short Sebastian, we wanted a BSD-PPPL to copy yours, and that turned into (rightly so) a discussion on a genericized BSD-LBNL instead of a new copy with PPPL substituted throughout, and that turned into just genericizing the existing listing on opensource.org <http://opensource.org> . Hopefully that doesn't cause you any problems. 

 

Best,

Chris

Chris Wright

Team Lead, Strategic Engagement and Applications Development

Head of Technology Transfer

Office: Room LSB134(609)-243-2425

Mobile: (865)-696-6949

Book a Meeting: https://calendly.com/cw20

Visit us at  <https://innovation.pppl.gov/> https://innovation.pppl.gov/

Princeton Plasma Physics Laboratory is a U.S. Department of Energy National Laboratory managed by Princeton University.



 

 

On Wed, Oct 22, 2025 at 5:22 PM Josh Berkus <josh.berkus at opensource.org <mailto:josh.berkus at opensource.org> > wrote:

On 10/22/25 9:21 AM, Chris Wright wrote:
> Thanks for discussing this with us. I don't actually mind the name 
> remaining BSD-LBNL, I agree with Richard that sometimes the historical 
> aspect is actually a fun nomenclature to maintain. My reason for 
> opening this discussion was instead that the text of the license itself 
> contains "Lawrence Berkeley National Lab" in several places, which needs 
> to be generalized to <COPYRIGHT HOLDER> or something like that. And if 
> LBNL wants to keep their version with their name specifically included, 
> then maybe we need a different name for the generic version. I can talk 
> to LBNL if that is helpful also.

That genericization update is happening soon, the Board just voted to 
authorize it.

-- 
-- Josh Berkus
OSI Board Member

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251023/e6ca105f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251023/e6ca105f/attachment.jpg>

From josh.berkus at opensource.org  Thu Oct 23 18:47:57 2025
From: josh.berkus at opensource.org (Josh Berkus)
Date: Thu, 23 Oct 2025 11:47:57 -0700
Subject: [License-review] [External] Re:  OSI License Submission - PPPL
 BSD-3
In-Reply-To: <009901dc444c$5a603510$0f209f30$@lbl.gov>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
 <c9343a2f-ae3a-43d7-9090-472baa053f4a@opensource.org>
 <CAJXV7V6XYygWLJ0D=V1Hb0Z=eW1LCLdhcc+E2SaBg4M_NRGrTA@mail.gmail.com>
 <e0117a36-e44a-44fa-8c3e-a3b6c99ec49f@opensource.org>
 <CAJXV7V4Q28EiE-svnC0BGuzCL3wvxZ-8e97_gnU6pNPotjaV5g@mail.gmail.com>
 <009901dc444c$5a603510$0f209f30$@lbl.gov>
Message-ID: <dabfd062-a2b6-4eb8-9aad-947a609e8f89@opensource.org>

On 10/23/25 11:39 AM, sainslie at lbl.gov wrote:
> Hi. Not a problem. Was in use a few years before my time at LBNL (2015) 
> and was used by LBNL first. If it becomes more generic regarding the 
> copyright of the entity using it that’s fine by me. It would be nice if 
> it could still be called the LBNL BSD as it is a variant BSD first used 
> and created by LBNL.
> 

It's OSI practice to NOT rename licenses unless the original license 
steward requests it.  That's not being proposed.

-- 
-- Josh Berkus
OSI Board Member

From sainslie at lbl.gov  Thu Oct 23 19:49:35 2025
From: sainslie at lbl.gov (sainslie at lbl.gov)
Date: Thu, 23 Oct 2025 12:49:35 -0700
Subject: [License-review] [External] Re:  OSI License Submission - PPPL
 BSD-3
In-Reply-To: <dabfd062-a2b6-4eb8-9aad-947a609e8f89@opensource.org>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
 <c9343a2f-ae3a-43d7-9090-472baa053f4a@opensource.org>
 <CAJXV7V6XYygWLJ0D=V1Hb0Z=eW1LCLdhcc+E2SaBg4M_NRGrTA@mail.gmail.com>
 <e0117a36-e44a-44fa-8c3e-a3b6c99ec49f@opensource.org>
 <CAJXV7V4Q28EiE-svnC0BGuzCL3wvxZ-8e97_gnU6pNPotjaV5g@mail.gmail.com>
 <009901dc444c$5a603510$0f209f30$@lbl.gov>
 <dabfd062-a2b6-4eb8-9aad-947a609e8f89@opensource.org>
Message-ID: <011b01dc4456$29519180$7bf4b480$@lbl.gov>

Ok. Let's leave the name as is then.

Thank you.

Sebastian


​Sebastian Ainslie
Commercialization Manager
Intellectual Property Office
Lawrence Berkeley National Laboratory





4154244741


sainslie at lbl.gov


ipo.lbl.gov













-----Original Message-----
From: Josh Berkus <josh.berkus at opensource.org> 
Sent: Thursday, October 23, 2025 11:48 AM
To: sainslie at lbl.gov; 'Chris Wright' <cwright at pppl.gov>
Cc: 'License submissions for OSI review' <license-review at lists.opensource.org>; 'Richard Fontana' <rfontana at redhat.com>; 'Will Rarich' <wrarich at pppl.gov>; 'J Lovejoy' <opensource at jilayne.com>
Subject: Re: [External] Re: [License-review] OSI License Submission - PPPL BSD-3

On 10/23/25 11:39 AM, sainslie at lbl.gov wrote:
> Hi. Not a problem. Was in use a few years before my time at LBNL 
> (2015) and was used by LBNL first. If it becomes more generic 
> regarding the copyright of the entity using it that’s fine by me. It 
> would be nice if it could still be called the LBNL BSD as it is a 
> variant BSD first used and created by LBNL.
> 

It's OSI practice to NOT rename licenses unless the original license steward requests it.  That's not being proposed.

--
-- Josh Berkus
OSI Board Member


From opensource at jilayne.com  Fri Oct 24 04:17:46 2025
From: opensource at jilayne.com (J Lovejoy)
Date: Thu, 23 Oct 2025 22:17:46 -0600
Subject: [License-review] [External] Re:  OSI License Submission - PPPL
 BSD-3
In-Reply-To: <009901dc444c$5a603510$0f209f30$@lbl.gov>
References: 
 <CAKvc+FxAs9a_y2-sCuc+TERh5P2rijPzf_YD2-AEPfi6nscb9g@mail.gmail.com>
 <993260815.340135.1752845804986.JavaMail.zimbra@piana.eu>
 <CAKvc+FxuOLoaupmRorBP7JOsu17e3uGCV9K7Gfu5W_XL1T_AZg@mail.gmail.com>
 <CAKvc+Fyd5acrd64ojAbs_TmKvQeYuG+cP6jKp95etJPMpFoY4A@mail.gmail.com>
 <CAC1cPGyk12c9_oiAm0+nqR+TNYNfXhY11wuD22kBe_GN7z0amw@mail.gmail.com>
 <c9343a2f-ae3a-43d7-9090-472baa053f4a@opensource.org>
 <CAJXV7V6XYygWLJ0D=V1Hb0Z=eW1LCLdhcc+E2SaBg4M_NRGrTA@mail.gmail.com>
 <e0117a36-e44a-44fa-8c3e-a3b6c99ec49f@opensource.org>
 <CAJXV7V4Q28EiE-svnC0BGuzCL3wvxZ-8e97_gnU6pNPotjaV5g@mail.gmail.com>
 <009901dc444c$5a603510$0f209f30$@lbl.gov>
Message-ID: <c3ebb093-d78a-457f-a5e2-9cf35b04d194@jilayne.com>

Hi all,

To clarify from the SPDX side a bit: I assume we are talking about this 
license: https://spdx.org/licenses/BSD-3-Clause-LBNL.html

This was added to the SPDX License List as of version 1.20 (so a very, 
very long time ago, and likely as part of the initial alignment with 
licenses found in Fedoras "good" list at that time - figured you'd 
appreciate that detail, Richard!)

SPDX has always made it a goal to avoid changes to license ids, unless 
there are extenuating circumstances - which it does not sound like there 
are here.

As for the "tempatizing" - under SPDX Matching Guidelines (see 
https://github.com/spdx/license-list-XML/blob/main/DOCS/license-matching-guidelines-and-templates.md 
) the copyright notice at the top is... a copyright notice, thus not 
considered part of the license. We also have the concept of 
"replaceable" text to accommodate things like names in certain clauses, 
which do not make any substantive legal difference. You can see this 
instantiated in the xml markup of the license here 
https://github.com/spdx/license-list-XML/blob/main/src/BSD-3-Clause-LBNL.xml 
and noted by colored text on the website page.

If I understand the thread correctly - SPDX has already done what is 
being asked here insofar as allowing "matches".

Relatedly, I just happen to chat with McCoy about OSI adopting SPDX's 
matching guidelines, which would be a fanstastic step forward. As I said 
to McCoy, I would highly recommend the OSI reach out to SPDX-legal (via 
mailing list or contact myself and Steve Winslow directly) in order to 
have a more thorough discussion of areas of collaboration and to ensure 
a successful adoption of whatever makes sense for the OSI to leverage 
b/c... no point in reinventing the wheel!

Cheers,
Jilayne

On 10/23/25 11:39 AM, sainslie at lbl.gov wrote:
>
> Hi. Not a problem. Was in use a few years before my time at LBNL 
> (2015) and was used by LBNL first. If it becomes more generic 
> regarding the copyright of the entity using it that’s fine by me. It 
> would be nice if it could still be called the LBNL BSD as it is a 
> variant BSD first used and created by LBNL.
>
> Sebastian
>
> *From:*Chris Wright <cwright at pppl.gov>
> *Sent:* Thursday, October 23, 2025 11:13 AM
> *To:* Josh Berkus <josh.berkus at opensource.org>; Sebastian Ainslie 
> <sainslie at lbl.gov>
> *Cc:* License submissions for OSI review 
> <license-review at lists.opensource.org>; Richard Fontana 
> <rfontana at redhat.com>; Will Rarich <wrarich at pppl.gov>; J Lovejoy 
> <opensource at jilayne.com>
> *Subject:* Re: [External] Re: [License-review] OSI License Submission 
> - PPPL BSD-3
>
> Excellent thank you Josh!
>
> I am copying Sebastian at LBNL for his awareness since the BSD-LBNL is 
> his license.
>
> Long story short Sebastian, we wanted a BSD-PPPL to copy yours, and 
> that turned into (rightly so) a discussion on a genericized BSD-LBNL 
> instead of a new copy with PPPL substituted throughout, and that 
> turned into just genericizing the existing listing on opensource.org 
> <http://opensource.org>. Hopefully that doesn't cause you any problems.
>
> Best,
>
> Chris
>
> Chris Wright
>
> Team Lead, Strategic Engagement and Applications Development
>
> Head of Technology Transfer
>
> Office: Room LSB134(609)-243-2425
>
> Mobile: (865)-696-6949
>
> Book a Meeting: https://calendly.com/cw20
>
> Visit us at https://innovation.pppl.gov/ <https://innovation.pppl.gov/>
>
> *Princeton Plasma Physics Laboratory* is a U.S. Department of Energy 
> National Laboratory managed by Princeton University.
>
> Image removed by sender. PPPL
>
> On Wed, Oct 22, 2025 at 5:22 PM Josh Berkus 
> <josh.berkus at opensource.org> wrote:
>
>     On 10/22/25 9:21 AM, Chris Wright wrote:
>     > Thanks for discussing this with us. I don't actually mind the name
>     > remaining BSD-LBNL, I agree with Richard that sometimes the
>     historical
>     > aspect is actually a fun nomenclature to maintain. My reason for
>     > opening this discussion was instead that the text of the license
>     itself
>     > contains "Lawrence Berkeley National Lab" in several places,
>     which needs
>     > to be generalized to <COPYRIGHT HOLDER> or something like that.
>     And if
>     > LBNL wants to keep their version with their name specifically
>     included,
>     > then maybe we need a different name for the generic version. I
>     can talk
>     > to LBNL if that is helpful also.
>
>     That genericization update is happening soon, the Board just voted to
>     authorize it.
>
>     -- 
>     -- Josh Berkus
>     OSI Board Member
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251023/a7f1292b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251023/a7f1292b/attachment.jpg>

From karuman2013 at gmail.com  Sat Oct 25 07:08:51 2025
From: karuman2013 at gmail.com (Righteousness)
Date: Sat, 25 Oct 2025 12:38:51 +0530
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI
 Approval - Revised Submission (Kartik Pawar)
Message-ID: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>

Dear License Review Committee,

Thank you for the helpful feedback on our initial OSN-1.0 submission, and
particularly to McCoy Smith for the detailed comments. I have revised the
license to address the issues raised (clarified contributor/CLA
interaction, tightened redistribution language, defined the syscall
boundary, softened indemnity, and moved non-normative guidance to a single,
explicitly-labeled advisory section). Below is a concise summary of the
changes and explanations requested by the committee.

*Who authored & legal review*

   - *Author: *Kartik Pawar (Orivex Project Lead)
   - *Legal review: *The text was drafted by the project team (Kartik
   Pawar) and has undergone internal peer review by Orivex contributors. It
   has not yet been through external counsel. We are prepared to obtain and
   provide an independent legal review if the committee recommends it.

*What gap OSN-1.0 fills (short statement)*
OSN-1.0 fills a narrow interoperability gap not directly covered by common
permissive licenses: it provides a clear, normative treatment of *syscall/ABI
boundary files *(headers, syscall numbers, ABI-structure layouts, formal
ABI docs) so those files may be licensed in a way that preserves
attribution and patent grants while *avoiding the creation of
derivative-work obligations for callers across the syscall boundary*. In
short: OSN clarifies how syscall/ABI interface artifacts can be reused by
both open-source and proprietary userland implementations without producing
unintended downstream copyleft consequences.

*Comparison with Apache-2.0 (short)*

   - *Form & grants: *OSN borrows familiar structure and grant language
   (copyright + patent) similar to Apache-2.0.
   - *Key differences: *OSN introduces a *normative definition of "Syscall
   Boundary" *and places explicit, enforceable conditions for syscall/ABI
   interface redistributions (attribution, notice pointers). OSN also
   clarifies the relationship between automatic contribution licensing and
   optional CLAs so that a CLA cannot reduce downstream rights already granted
   under the license. Unlike Apache, OSN is scoped to syscall/ABI interface
   files and their reuse semantics at kernel/userland boundaries.

*Responses to McCoy's specific points*

   1. *Contribution section / CLA ambiguity: *Fixed by making the automatic
   contribution license (Section 5.2) effective on submission and explicitly
   stating that a CLA (if offered) *may not reduce downstream recipient
   rights *for Contributions already licensed under Section 5.2. If a
   Contributor later explicitly states a Contribution is governed solely by a
   CLA, that fact will control only as to that later Contribution. This
   resolves precedence and ambiguity concerns.
   2. *Section 5.4 / unnecessary statements removed: *Any redundant or
   advisory text implying projects must accept contributions was removed.
   Contribution process guidance is governance material and explicitly
   separated from the operative license terms.
   3. *"Should" vs "Must" language in redistribution: *Where preservation
   of provenance/notice is required for license integrity, advisory “should”
   language was changed to *"must" *(Sections 4.1-4.3, 4.4 for binaries).
   Traceability encouragement (e.g., SYSCALL-CHANGES.md) is explicitly
   non-normative and advisory only.
   4. *Syscall boundary definition: *Added an explicit, normative
   definition of *"Syscall Boundary" *in the Definitions section to anchor
   what files the license targets.
   5. *Indemnity clause: *Softened to state that contributors/users are
   responsible for claims arising from their own modifications or
   distributions, and removed any broad affirmative indemnity obligations for
   Licensors. Any additional indemnity must be in a separate written
   agreement.
   6. *Termination & multiple Licensors: *Clarified that only the Licensor
   whose rights are affected may initiate termination as to their portion of
   the Software.
   7. *Non-normative material reduced: * All prior explanatory/templating
   content was removed or consolidated into a single, explicitly-labelled
   non-normative suggestion section (Section 14). The operative license
   (Sections 1–13) is normative.
   8. *SPDX identifier & formatting: *SPDX identifier normalized to
Orivex-syscall-note-1.0
   and author name updated to *Kartik Pawar*.

*What I'm submitting now*

   - The *revised OSN-1.0 *license text is attached for your convenience.

Thank you for your time and guidance. Please let me know if the committee
would prefer the redline as an attachment or if any additional edits would
make review easier.

Sincerely,
*Kartik Pawar*
Orivex Project Lead
karuman2013 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251025/a2ad007e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Orivex-syscall-note
Type: application/octet-stream
Size: 10971 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251025/a2ad007e/attachment.a>

From shujisado at gmail.com  Sun Oct 26 13:43:24 2025
From: shujisado at gmail.com (Shuji Sado)
Date: Sun, 26 Oct 2025 22:43:24 +0900
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)
In-Reply-To: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
References: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
Message-ID: 
 <CAAvo7O7P=kre6Fr2jPTSZKOEBe9agL3GpinbkVjm_guqS1NSeQ@mail.gmail.com>

Hi,

Thanks for posting the revision. It looks like you addressed the previously
noted issues; I don’t see an obvious OSD conflict in the current text.
I have two small clarifications to reduce ambiguity:

§2.4: The intent seems to be pass-through rather than sublicensing. To make
that unmistakable, I suggest adding the words "under this License".
§4.1: The sentence "Binary distributions must include such pointer in a
Notice File" can be read to require a pointer even when the full text is
already included.

Bigger-picture point: if the primary goal is to clarify non-derivativeness
at the syscall/UAPI boundary for Linux, the long-standing pattern
GPL-2.0-only WITH Linux-syscall-note already achieves that. Although your
text is not Linux-specific, it does appear tailored to Linux practice, and
I would expect very low likelihood of upstream acceptance in the Linux
kernel for a new standalone license. Unless you are targeting non-Linux
kernels or hypervisor/userland ABIs and can show concrete adopters there,
the practical value proposition may be questioned.

Best,

2025/10/25 21:30 Righteousness <karuman2013 at gmail.com>:

> Dear License Review Committee,
>
> Thank you for the helpful feedback on our initial OSN-1.0 submission, and
> particularly to McCoy Smith for the detailed comments. I have revised the
> license to address the issues raised (clarified contributor/CLA
> interaction, tightened redistribution language, defined the syscall
> boundary, softened indemnity, and moved non-normative guidance to a single,
> explicitly-labeled advisory section). Below is a concise summary of the
> changes and explanations requested by the committee.
>
> *Who authored & legal review*
>
>    - *Author: *Kartik Pawar (Orivex Project Lead)
>    - *Legal review: *The text was drafted by the project team (Kartik
>    Pawar) and has undergone internal peer review by Orivex contributors. It
>    has not yet been through external counsel. We are prepared to obtain and
>    provide an independent legal review if the committee recommends it.
>
> *What gap OSN-1.0 fills (short statement)*
> OSN-1.0 fills a narrow interoperability gap not directly covered by common
> permissive licenses: it provides a clear, normative treatment of *syscall/ABI
> boundary files *(headers, syscall numbers, ABI-structure layouts, formal
> ABI docs) so those files may be licensed in a way that preserves
> attribution and patent grants while *avoiding the creation of
> derivative-work obligations for callers across the syscall boundary*. In
> short: OSN clarifies how syscall/ABI interface artifacts can be reused by
> both open-source and proprietary userland implementations without producing
> unintended downstream copyleft consequences.
>
> *Comparison with Apache-2.0 (short)*
>
>    - *Form & grants: *OSN borrows familiar structure and grant language
>    (copyright + patent) similar to Apache-2.0.
>    - *Key differences: *OSN introduces a *normative definition of
>    "Syscall Boundary" *and places explicit, enforceable conditions for
>    syscall/ABI interface redistributions (attribution, notice pointers). OSN
>    also clarifies the relationship between automatic contribution licensing
>    and optional CLAs so that a CLA cannot reduce downstream rights already
>    granted under the license. Unlike Apache, OSN is scoped to syscall/ABI
>    interface files and their reuse semantics at kernel/userland boundaries.
>
> *Responses to McCoy's specific points*
>
>    1. *Contribution section / CLA ambiguity: *Fixed by making the
>    automatic contribution license (Section 5.2) effective on submission and
>    explicitly stating that a CLA (if offered) *may not reduce downstream
>    recipient rights *for Contributions already licensed under Section
>    5.2. If a Contributor later explicitly states a Contribution is governed
>    solely by a CLA, that fact will control only as to that later Contribution.
>    This resolves precedence and ambiguity concerns.
>    2. *Section 5.4 / unnecessary statements removed: *Any redundant or
>    advisory text implying projects must accept contributions was removed.
>    Contribution process guidance is governance material and explicitly
>    separated from the operative license terms.
>    3. *"Should" vs "Must" language in redistribution: *Where preservation
>    of provenance/notice is required for license integrity, advisory “should”
>    language was changed to *"must" *(Sections 4.1-4.3, 4.4 for binaries).
>    Traceability encouragement (e.g., SYSCALL-CHANGES.md) is explicitly
>    non-normative and advisory only.
>    4. *Syscall boundary definition: *Added an explicit, normative
>    definition of *"Syscall Boundary" *in the Definitions section to
>    anchor what files the license targets.
>    5. *Indemnity clause: *Softened to state that contributors/users are
>    responsible for claims arising from their own modifications or
>    distributions, and removed any broad affirmative indemnity obligations for
>    Licensors. Any additional indemnity must be in a separate written
>    agreement.
>    6. *Termination & multiple Licensors: *Clarified that only the
>    Licensor whose rights are affected may initiate termination as to their
>    portion of the Software.
>    7. *Non-normative material reduced: * All prior explanatory/templating
>    content was removed or consolidated into a single, explicitly-labelled
>    non-normative suggestion section (Section 14). The operative license
>    (Sections 1–13) is normative.
>    8. *SPDX identifier & formatting: *SPDX identifier normalized to Orivex-syscall-note-1.0
>    and author name updated to *Kartik Pawar*.
>
> *What I'm submitting now*
>
>    - The *revised OSN-1.0 *license text is attached for your convenience.
>
> Thank you for your time and guidance. Please let me know if the committee
> would prefer the redline as an attachment or if any additional edits would
> make review easier.
>
> Sincerely,
> *Kartik Pawar*
> Orivex Project Lead
> karuman2013 at gmail.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
>


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

From mccoy at lexpan.law  Sun Oct 26 15:17:17 2025
From: mccoy at lexpan.law (McCoy Smith)
Date: Sun, 26 Oct 2025 08:17:17 -0700
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)
In-Reply-To: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
References: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
Message-ID: <200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law>

In my opinion, speaking personally, this license really needs to go 
through a legal review before submission/resubmission. Here are a few 
reasons:

1. The preamble includes a defined term ("Software") that is used within 
the text of the grants. Given that preambles can be construed as not 
part of the license, I think this is a significant drafting flaw that 
can render the subsequent grants ambiguous.

2. The defined terms include at least one term ("Syscall Boundary") 
which is used nowhere in the rights and obligations of the license; at 
best, it is used recursively (and not as a defined term) in the 
definition itself or in the preamble definition above (also, not as a 
defined term).

3. The term "Software" as used throughout the license to define the 
rights and obligations, appears to be limited to "kernel-facing 
artifacts such as kernel headers, syscall interface definitions, formal 
ABI documentation, and related API/ABI files." That means any other 
software to which this license is attached is not licensed at all. So 
this license winds up being quasi-open source depending upon whether the 
software to which it is attached fits fully, partially, or not at all 
within the defined term "Software." I don't think OSI should be 
approving a license as being open source when it can be used in a way 
that closes off (or more accurately, does not license at all) some or 
all of the software to which it is attached. The fact that the steward 
might only wish to use it for software falling within that definition 
doesn't mean that others might not, and thus you wind up having an OSI 
approved license that doesn't grant all (or any) rights to the software 
it is used with. I also am not sure to what extent a Derivative Work of 
Software which doesn't fit into the definition of "Software" as 
specified above is or is not licensed under a grant of this scope. I 
think it could be argued either way, thus rendering the license grants 
potentially ambiguous.

4. I don't see what the point is of having a license like this that is 
restricted to a specific class of software. If you want to attach this 
license to interfaces, syscalls, and the like, you could just as easily 
release those components with an MIT or Apache license attached, as the 
licensed "Software" (or "Work" in Apache) and get essentially the same 
result. If, for whatever reason you don't like the attribution 
requirements of MIT or Apache and prefer the attribution requirements in 
Sec 4, then just write a standard open source grant (like either of 
those licenses, or others) with this new attribution requirement.

5. At least the Limitation of Liability clause (8) and the Indemnity 
clause (9) are in conflict. The limitation of liability clause disclaims 
all liability to the licensor or any contributor, but the indemnity 
clause appears to attempt to impose back some amount of liability at 
least on Contributors. It also says it is an indemnity clause, but then 
says "create any affirmative obligation for the Licensor or any 
Contributor to indemnify any party." I'm not sure what exactly the 
obligations are in the "Indemnity" clause because of that, and the 
clause also appears to be discriminatory, since it imposes the 
obligation only on the licensee and not the licensor (because it applies 
to "You" -- the licensee, and not the Licensor).

6. The survival of Sec 3, but not Sec 2 (or for that matter, Sec 5) upon 
termination doesn't make a whole lot of sense to me and I'd like to 
understand why this license structures survival in that way.

In summary, this license still has a lot of fairly fundamental 
philosophical and drafting issues that really need addressing before it 
is in any shape for approval.


On 10/25/2025 12:08 AM, Righteousness wrote:
> Dear License Review Committee,
>
> Thank you for the helpful feedback on our initial OSN-1.0 submission, 
> and particularly to McCoy Smith for the detailed comments. I have 
> revised the license to address the issues raised (clarified 
> contributor/CLA interaction, tightened redistribution language, 
> defined the syscall boundary, softened indemnity, and moved 
> non-normative guidance to a single, explicitly-labeled advisory 
> section). Below is a concise summary of the changes and explanations 
> requested by the committee.
>
> *Who authored & legal review*
>
>   * *Author: *Kartik Pawar (Orivex Project Lead)
>   * *Legal review: *The text was drafted by the project team (Kartik
>     Pawar) and has undergone internal peer review by Orivex
>     contributors. It has not yet been through external counsel. We are
>     prepared to obtain and provide an independent legal review if the
>     committee recommends it.
>
> *What gap OSN-1.0 fills (short statement)*
> OSN-1.0 fills a narrow interoperability gap not directly covered by 
> common permissive licenses: it provides a clear, normative treatment 
> of *syscall/ABI boundary files *(headers, syscall numbers, 
> ABI-structure layouts, formal ABI docs) so those files may be licensed 
> in a way that preserves attribution and patent grants while *avoiding 
> the creation of derivative-work obligations for callers across the 
> syscall boundary*. In short: OSN clarifies how syscall/ABI interface 
> artifacts can be reused by both open-source and proprietary userland 
> implementations without producing unintended downstream copyleft 
> consequences.
>
> *Comparison with Apache-2.0 (short)*
>
>   * *Form & grants: *OSN borrows familiar structure and grant language
>     (copyright + patent) similar to Apache-2.0.
>   * *Key differences: *OSN introduces a *normative definition of
>     "Syscall Boundary" *and places explicit, enforceable conditions
>     for syscall/ABI interface redistributions (attribution, notice
>     pointers). OSN also clarifies the relationship between automatic
>     contribution licensing and optional CLAs so that a CLA cannot
>     reduce downstream rights already granted under the license. Unlike
>     Apache, OSN is scoped to syscall/ABI interface files and their
>     reuse semantics at kernel/userland boundaries.
>
> *Responses to McCoy's specific points*
>
>  1. *Contribution section / CLA ambiguity: *Fixed by making the
>     automatic contribution license (Section 5.2) effective on
>     submission and explicitly stating that a CLA (if offered) *may not
>     reduce downstream recipient rights *for Contributions already
>     licensed under Section 5.2. If a Contributor later explicitly
>     states a Contribution is governed solely by a CLA, that fact will
>     control only as to that later Contribution. This resolves
>     precedence and ambiguity concerns.
>  2. *Section 5.4 / unnecessary statements removed: *Any redundant or
>     advisory text implying projects must accept contributions was
>     removed. Contribution process guidance is governance material and
>     explicitly separated from the operative license terms.
>  3. *"Should" vs "Must" language in redistribution: *Where
>     preservation of provenance/notice is required for license
>     integrity, advisory “should” language was changed to *"must"
>     *(Sections 4.1-4.3, 4.4 for binaries). Traceability encouragement
>     (e.g., SYSCALL-CHANGES.md) is explicitly non-normative and
>     advisory only.
>  4. *Syscall boundary definition: *Added an explicit, normative
>     definition of *"Syscall Boundary" *in the Definitions section to
>     anchor what files the license targets.
>  5. *Indemnity clause: *Softened to state that contributors/users are
>     responsible for claims arising from their own modifications or
>     distributions, and removed any broad affirmative indemnity
>     obligations for Licensors. Any additional indemnity must be in a
>     separate written agreement.
>  6. *Termination & multiple Licensors: *Clarified that only the
>     Licensor whose rights are affected may initiate termination as to
>     their portion of the Software.
>  7. *Non-normative material reduced: * All prior
>     explanatory/templating content was removed or consolidated into a
>     single, explicitly-labelled non-normative suggestion section
>     (Section 14). The operative license (Sections 1–13) is normative.
>  8. *SPDX identifier & formatting: *SPDX identifier normalized to
>     Orivex-syscall-note-1.0 and author name updated to *Kartik Pawar*.
>
> *What I'm submitting now*
>
>   * The *revised OSN-1.0 *license text is attached for your convenience.
>
> Thank you for your time and guidance. Please let me know if the 
> committee would prefer the redline as an attachment or if any 
> additional edits would make review easier.
>
> Sincerely,
> *Kartik Pawar*
> Orivex Project Lead
> karuman2013 at gmail.com
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251026/17e6077c/attachment-0001.htm>

From pamela at chesteklegal.com  Sun Oct 26 20:38:12 2025
From: pamela at chesteklegal.com (Pamela Chestek)
Date: Sun, 26 Oct 2025 13:38:12 -0700
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)
In-Reply-To: <200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law>
References: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
 <200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law>
Message-ID: <f5cf1c39-94eb-4a12-b100-a2f035e951b7@chesteklegal.com>

I agree with everything McCoy says, and have some additional comments.

First, the license submission guidelines also ask for the "Identify what 
projects are already using the license," which you haven't provided. Is 
this license in use? If not, who is your intended user?

To be clear on the SPDX identifier, the OSI does not issue SPDX 
identifiers, that is done by the SPDX project. You would have to ask for 
their approval separately.

As Carlo already pointed out, you have two different types of 
participants, Contributors and Licensor. The Contributor is /also/ a 
Licensor, but it's convoluted how you get there (it's not part of the 
definition but is in Section 5.2). The result of treating them 
differently is that the scope of the patent license is different for 
each - the Licensor grants a license to "Derivative Works to the extent 
such patent claims would necessarily be infringed by ... Derivative 
Works that include the Licensor's Contribution(s)," but the Contributor 
grants the license only to "any patent claims that would necessarily be 
infringed by their Contribution alone or by their Contribution when 
combined with the Software submitted to the Licensor." The Contributor 
isn't granting a license to Derivative Works? Why not? But aren't they 
also a Licensor, as stated in Section 5.2? And what happens when a 
Licensor then later becomes a Contributor, which license  grant applies? 
The lack of necessary scope in the Contributor patent grant, in my 
opinion, makes this a non-free license.

You have many sections that are unnecessary, circular, or redundant. For 
example, 4.4 is redundant and/or recursive to 4.1. Generally one need 
not comment on separate agreements (Sections 5.3, 6, 9, 10.2). I don't 
understand why the copyright grant is broken up into four sections - 
just because it was done that way in a license written a decade ago (if 
that was your model) doesn't mean that it's a good drafting practice 
today. So there are many small problems with this license in addition to 
the big ones previously identified.

I agree with McCoy that this license needs the input of a licensing 
professional before the OSI reviews it again. In my opinion, fixing all 
the problems with this license is not a task that a layperson can 
competently do without professional assistance. I suggest that the 
submitter withdraw it from review and reconsider, first, whether this 
license is necessary at all, and, if you do still want to proceed, 
getting the assistance of a lawyer knowledgeable about drafting licenses 
and at least familiar with open source licenses.

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 10/26/2025 8:17 AM, McCoy Smith wrote:
>
> In my opinion, speaking personally, this license really needs to go 
> through a legal review before submission/resubmission. Here are a few 
> reasons:
>
> 1. The preamble includes a defined term ("Software") that is used 
> within the text of the grants. Given that preambles can be construed 
> as not part of the license, I think this is a significant drafting 
> flaw that can render the subsequent grants ambiguous.
>
> 2. The defined terms include at least one term ("Syscall Boundary") 
> which is used nowhere in the rights and obligations of the license; at 
> best, it is used recursively (and not as a defined term) in the 
> definition itself or in the preamble definition above (also, not as a 
> defined term).
>
> 3. The term "Software" as used throughout the license to define the 
> rights and obligations, appears to be limited to "kernel-facing 
> artifacts such as kernel headers, syscall interface definitions, 
> formal ABI documentation, and related API/ABI files." That means any 
> other software to which this license is attached is not licensed at 
> all. So this license winds up being quasi-open source depending upon 
> whether the software to which it is attached fits fully, partially, or 
> not at all within the defined term "Software." I don't think OSI 
> should be approving a license as being open source when it can be used 
> in a way that closes off (or more accurately, does not license at all) 
> some or all of the software to which it is attached. The fact that the 
> steward might only wish to use it for software falling within that 
> definition doesn't mean that others might not, and thus you wind up 
> having an OSI approved license that doesn't grant all (or any) rights 
> to the software it is used with. I also am not sure to what extent a 
> Derivative Work of Software which doesn't fit into the definition of 
> "Software" as specified above is or is not licensed under a grant of 
> this scope. I think it could be argued either way, thus rendering the 
> license grants potentially ambiguous.
>
> 4. I don't see what the point is of having a license like this that is 
> restricted to a specific class of software. If you want to attach this 
> license to interfaces, syscalls, and the like, you could just as 
> easily release those components with an MIT or Apache license 
> attached, as the licensed "Software" (or "Work" in Apache) and get 
> essentially the same result. If, for whatever reason you don't like 
> the attribution requirements of MIT or Apache and prefer the 
> attribution requirements in Sec 4, then just write a standard open 
> source grant (like either of those licenses, or others) with this new 
> attribution requirement.
>
> 5. At least the Limitation of Liability clause (8) and the Indemnity 
> clause (9) are in conflict. The limitation of liability clause 
> disclaims all liability to the licensor or any contributor, but the 
> indemnity clause appears to attempt to impose back some amount of 
> liability at least on Contributors. It also says it is an indemnity 
> clause, but then says "create any affirmative obligation for the 
> Licensor or any Contributor to indemnify any party." I'm not sure what 
> exactly the obligations are in the "Indemnity" clause because of that, 
> and the clause also appears to be discriminatory, since it imposes the 
> obligation only on the licensee and not the licensor (because it 
> applies to "You" -- the licensee, and not the Licensor).
>
> 6. The survival of Sec 3, but not Sec 2 (or for that matter, Sec 5) 
> upon termination doesn't make a whole lot of sense to me and I'd like 
> to understand why this license structures survival in that way.
>
> In summary, this license still has a lot of fairly fundamental 
> philosophical and drafting issues that really need addressing before 
> it is in any shape for approval.
>
>
> On 10/25/2025 12:08 AM, Righteousness wrote:
>> Dear License Review Committee,
>>
>> Thank you for the helpful feedback on our initial OSN-1.0 submission, 
>> and particularly to McCoy Smith for the detailed comments. I have 
>> revised the license to address the issues raised (clarified 
>> contributor/CLA interaction, tightened redistribution language, 
>> defined the syscall boundary, softened indemnity, and moved 
>> non-normative guidance to a single, explicitly-labeled advisory 
>> section). Below is a concise summary of the changes and explanations 
>> requested by the committee.
>>
>> *Who authored & legal review*
>>
>>   * *Author: *Kartik Pawar (Orivex Project Lead)
>>   * *Legal review: *The text was drafted by the project team (Kartik
>>     Pawar) and has undergone internal peer review by Orivex
>>     contributors. It has not yet been through external counsel. We
>>     are prepared to obtain and provide an independent legal review if
>>     the committee recommends it.
>>
>> *What gap OSN-1.0 fills (short statement)*
>> OSN-1.0 fills a narrow interoperability gap not directly covered by 
>> common permissive licenses: it provides a clear, normative treatment 
>> of *syscall/ABI boundary files *(headers, syscall numbers, 
>> ABI-structure layouts, formal ABI docs) so those files may be 
>> licensed in a way that preserves attribution and patent grants while 
>> *avoiding the creation of derivative-work obligations for callers 
>> across the syscall boundary*. In short: OSN clarifies how syscall/ABI 
>> interface artifacts can be reused by both open-source and proprietary 
>> userland implementations without producing unintended downstream 
>> copyleft consequences.
>>
>> *Comparison with Apache-2.0 (short)*
>>
>>   * *Form & grants: *OSN borrows familiar structure and grant
>>     language (copyright + patent) similar to Apache-2.0.
>>   * *Key differences: *OSN introduces a *normative definition of
>>     "Syscall Boundary" *and places explicit, enforceable conditions
>>     for syscall/ABI interface redistributions (attribution, notice
>>     pointers). OSN also clarifies the relationship between automatic
>>     contribution licensing and optional CLAs so that a CLA cannot
>>     reduce downstream rights already granted under the license.
>>     Unlike Apache, OSN is scoped to syscall/ABI interface files and
>>     their reuse semantics at kernel/userland boundaries.
>>
>> *Responses to McCoy's specific points*
>>
>>  1. *Contribution section / CLA ambiguity: *Fixed by making the
>>     automatic contribution license (Section 5.2) effective on
>>     submission and explicitly stating that a CLA (if offered) *may
>>     not reduce downstream recipient rights *for Contributions already
>>     licensed under Section 5.2. If a Contributor later explicitly
>>     states a Contribution is governed solely by a CLA, that fact will
>>     control only as to that later Contribution. This resolves
>>     precedence and ambiguity concerns.
>>  2. *Section 5.4 / unnecessary statements removed: *Any redundant or
>>     advisory text implying projects must accept contributions was
>>     removed. Contribution process guidance is governance material and
>>     explicitly separated from the operative license terms.
>>  3. *"Should" vs "Must" language in redistribution: *Where
>>     preservation of provenance/notice is required for license
>>     integrity, advisory “should” language was changed to *"must"
>>     *(Sections 4.1-4.3, 4.4 for binaries). Traceability encouragement
>>     (e.g., SYSCALL-CHANGES.md) is explicitly non-normative and
>>     advisory only.
>>  4. *Syscall boundary definition: *Added an explicit, normative
>>     definition of *"Syscall Boundary" *in the Definitions section to
>>     anchor what files the license targets.
>>  5. *Indemnity clause: *Softened to state that contributors/users are
>>     responsible for claims arising from their own modifications or
>>     distributions, and removed any broad affirmative indemnity
>>     obligations for Licensors. Any additional indemnity must be in a
>>     separate written agreement.
>>  6. *Termination & multiple Licensors: *Clarified that only the
>>     Licensor whose rights are affected may initiate termination as to
>>     their portion of the Software.
>>  7. *Non-normative material reduced: * All prior
>>     explanatory/templating content was removed or consolidated into a
>>     single, explicitly-labelled non-normative suggestion section
>>     (Section 14). The operative license (Sections 1–13) is normative.
>>  8. *SPDX identifier & formatting: *SPDX identifier normalized to
>>     Orivex-syscall-note-1.0 and author name updated to *Kartik Pawar*.
>>
>> *What I'm submitting now*
>>
>>   * The *revised OSN-1.0 *license text is attached for your convenience.
>>
>> Thank you for your time and guidance. Please let me know if the 
>> committee would prefer the redline as an attachment or if any 
>> additional edits would make review easier.
>>
>> Sincerely,
>> *Kartik Pawar*
>> Orivex Project Lead
>> karuman2013 at gmail.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
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251026/7db8b246/attachment-0001.htm>

From duanmoming at gmail.com  Mon Oct 27 02:39:52 2025
From: duanmoming at gmail.com (Moming Duan)
Date: Mon, 27 Oct 2025 10:39:52 +0800
Subject: [License-review] [2nd Resubmission] ModelGo Attribution License,
 Version 2.0
In-Reply-To: <29330d4d-23d6-4fa1-bfa1-c3f15fb3257d@berkus.org>
References: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
 <ef8ea4fc-7a96-4639-8701-75e96ad47d56@berkus.org>
 <A34D9DA1-D2E4-424B-81A2-9B4110DF216C@gmail.com>
 <5925bcd6-9dc6-47a6-ab3c-c07958ff3e04@opensource.org>
 <7F574427-EF5D-4A8F-911A-D1162A2218A2@gmail.com>
 <29330d4d-23d6-4fa1-bfa1-c3f15fb3257d@berkus.org>
Message-ID: <58A7D39F-5990-4AB4-82BC-122EF6361FFE@gmail.com>

Dear OSI Community,


I’m still waiting for the decision and feedback on this round of review. Please let me know if there’s any update. Thanks.


Best,
Moming

> On Oct 11, 2025, at 04:30, Josh Berkus <josh at berkus.org> wrote:
> 
> On 9/25/25 04:35, Moming Duan wrote:
>> Hi, I just wanted to check in on the status of the ModelGo License review. Thanks.
> 
> Sorry, we're still discussing.  We should have updates for you in the next week.  Thanks for your patience!
> 
> -- 
> Josh Berkus


From rob at landley.net  Mon Oct 27 20:22:54 2025
From: rob at landley.net (Rob Landley)
Date: Mon, 27 Oct 2025 15:22:54 -0500
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)
In-Reply-To: <200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law>
References: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
 <200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law>
Message-ID: <ad7eed76-46fb-4a36-813a-fc7794b50c21@landley.net>

On 10/26/25 10:17, McCoy Smith wrote:
> 4. I don't see what the point is of having a license like this that is 
> restricted to a specific class of software. If you want to attach this 
> license to interfaces, syscalls, and the like, you could just as easily 
> release those components with an MIT or Apache license attached, as the 
> licensed "Software" (or "Work" in Apache) and get essentially the same 
> result. If, for whatever reason you don't like the attribution 
> requirements of MIT or Apache and prefer the attribution requirements in 
> Sec 4, then just write a standard open source grant (like either of 
> those licenses, or others) with this new attribution requirement.

Or use a "public domain equivalent" license like 0BSD which doesn't have 
an attribution requirement. (It's in the github choose-a-license 
pulldown menu for new repositories.)

https://en.wikipedia.org/wiki/Public-domain-equivalent_license

Rob

From carlo at piana.eu  Tue Oct 28 11:47:02 2025
From: carlo at piana.eu (Carlo Piana)
Date: Tue, 28 Oct 2025 12:47:02 +0100 (CET)
Subject: [License-review] Submission of Orivex Syscall Note License
 (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)
In-Reply-To: <f5cf1c39-94eb-4a12-b100-a2f035e951b7@chesteklegal.com>
References: 
 <CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com>
 <200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law>
 <f5cf1c39-94eb-4a12-b100-a2f035e951b7@chesteklegal.com>
Message-ID: <1971472865.29840455.1761652022629.JavaMail.zimbra@piana.eu>

I agree with McCoy and Pam. 

Apparent that there is a lot of legal work to do. 

Perhaps resubmitting after a legal review would be a good idea. Taking into consideration the valuable contributions of others who reviewed and commented on the license, as well as my earlier reaction, could also be beneficial. In the meantime, I suggest that withdrawing the application might be wise. 

All the best, 

Carlo 
as individual commenter, not as member of OSI's licensing committee. 

> Da: "Pamela Chestek" <pamela at chesteklegal.com>
> A: "license-review at lists.opensource.org" <license-review at lists.opensource.org>
> Inviato: Domenica, 26 ottobre 2025 21:38:12
> Oggetto: Re: [License-review] Submission of Orivex Syscall Note License
> (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)

> I agree with everything McCoy says, and have some additional comments.

> First, the license submission guidelines also ask for the "Identify what
> projects are already using the license," which you haven't provided. Is this
> license in use? If not, who is your intended user?

> To be clear on the SPDX identifier, the OSI does not issue SPDX identifiers,
> that is done by the SPDX project. You would have to ask for their approval
> separately.

> As Carlo already pointed out, you have two different types of participants,
> Contributors and Licensor. The Contributor is also a Licensor, but it's
> convoluted how you get there (it's not part of the definition but is in Section
> 5.2). The result of treating them differently is that the scope of the patent
> license is different for each - the Licensor grants a license to "Derivative
> Works to the extent such patent claims would necessarily be infringed by ...
> Derivative Works that include the Licensor's Contribution(s)," but the
> Contributor grants the license only to "any patent claims that would
> necessarily be infringed by their Contribution alone or by their Contribution
> when combined with the Software submitted to the Licensor." The Contributor
> isn't granting a license to Derivative Works? Why not? But aren't they also a
> Licensor, as stated in Section 5.2? And what happens when a Licensor then later
> becomes a Contributor, which license grant applies? The lack of necessary scope
> in the Contributor patent grant, in my opinion, makes this a non-free license.

> You have many sections that are unnecessary, circular, or redundant. For
> example, 4.4 is redundant and/or recursive to 4.1. Generally one need not
> comment on separate agreements (Sections 5.3, 6, 9, 10.2). I don't understand
> why the copyright grant is broken up into four sections - just because it was
> done that way in a license written a decade ago (if that was your model)
> doesn't mean that it's a good drafting practice today. So there are many small
> problems with this license in addition to the big ones previously identified.

> I agree with McCoy that this license needs the input of a licensing professional
> before the OSI reviews it again. In my opinion, fixing all the problems with
> this license is not a task that a layperson can competently do without
> professional assistance. I suggest that the submitter withdraw it from review
> and reconsider, first, whether this license is necessary at all, and, if you do
> still want to proceed, getting the assistance of a lawyer knowledgeable about
> drafting licenses and at least familiar with open source licenses.

> Pam
> Pamela S. Chestek
> Chestek Legal
> 4641 Post St.
> Unit 4316
> El Dorado Hills, CA 95762
> +1 919-800-8033
> pamela at chesteklegal
> [ http://www.chesteklegal.com/ | www.chesteklegal.com ]

> On 10/26/2025 8:17 AM, McCoy Smith wrote:

>> In my opinion, speaking personally, this license really needs to go through a
>> legal review before submission/resubmission. Here are a few reasons:

>> 1. The preamble includes a defined term ("Software") that is used within the
>> text of the grants. Given that preambles can be construed as not part of the
>> license, I think this is a significant drafting flaw that can render the
>> subsequent grants ambiguous.

>> 2. The defined terms include at least one term ("Syscall Boundary") which is
>> used nowhere in the rights and obligations of the license; at best, it is used
>> recursively (and not as a defined term) in the definition itself or in the
>> preamble definition above (also, not as a defined term).

>> 3. The term "Software" as used throughout the license to define the rights and
>> obligations, appears to be limited to "kernel-facing artifacts such as kernel
>> headers, syscall interface definitions, formal ABI documentation, and related
>> API/ABI files." That means any other software to which this license is attached
>> is not licensed at all. So this license winds up being quasi-open source
>> depending upon whether the software to which it is attached fits fully,
>> partially, or not at all within the defined term "Software." I don't think OSI
>> should be approving a license as being open source when it can be used in a way
>> that closes off (or more accurately, does not license at all) some or all of
>> the software to which it is attached. The fact that the steward might only wish
>> to use it for software falling within that definition doesn't mean that others
>> might not, and thus you wind up having an OSI approved license that doesn't
>> grant all (or any) rights to the software it is used with. I also am not sure
>> to what extent a Derivative Work of Software which doesn't fit into the
>> definition of "Software" as specified above is or is not licensed under a grant
>> of this scope. I think it could be argued either way, thus rendering the
>> license grants potentially ambiguous.

>> 4. I don't see what the point is of having a license like this that is
>> restricted to a specific class of software. If you want to attach this license
>> to interfaces, syscalls, and the like, you could just as easily release those
>> components with an MIT or Apache license attached, as the licensed "Software"
>> (or "Work" in Apache) and get essentially the same result. If, for whatever
>> reason you don't like the attribution requirements of MIT or Apache and prefer
>> the attribution requirements in Sec 4, then just write a standard open source
>> grant (like either of those licenses, or others) with this new attribution
>> requirement.

>> 5. At least the Limitation of Liability clause (8) and the Indemnity clause (9)
>> are in conflict. The limitation of liability clause disclaims all liability to
>> the licensor or any contributor, but the indemnity clause appears to attempt to
>> impose back some amount of liability at least on Contributors. It also says it
>> is an indemnity clause, but then says "create any affirmative obligation for
>> the Licensor or any Contributor to indemnify any party." I'm not sure what
>> exactly the obligations are in the "Indemnity" clause because of that, and the
>> clause also appears to be discriminatory, since it imposes the obligation only
>> on the licensee and not the licensor (because it applies to "You" -- the
>> licensee, and not the Licensor).

>> 6. The survival of Sec 3, but not Sec 2 (or for that matter, Sec 5) upon
>> termination doesn't make a whole lot of sense to me and I'd like to understand
>> why this license structures survival in that way.

>> In summary, this license still has a lot of fairly fundamental philosophical and
>> drafting issues that really need addressing before it is in any shape for
>> approval.

>> On 10/25/2025 12:08 AM, Righteousness wrote:

>>> Dear License Review Committee,

>>> Thank you for the helpful feedback on our initial OSN-1.0 submission, and
>>> particularly to McCoy Smith for the detailed comments. I have revised the
>>> license to address the issues raised (clarified contributor/CLA interaction,
>>> tightened redistribution language, defined the syscall boundary, softened
>>> indemnity, and moved non-normative guidance to a single, explicitly-labeled
>>> advisory section). Below is a concise summary of the changes and explanations
>>> requested by the committee.

>>> Who authored & legal review

>>>     * Author: Kartik Pawar (Orivex Project Lead)
>>>    * Legal review: The text was drafted by the project team (Kartik Pawar) and has
>>>    undergone internal peer review by Orivex contributors. It has not yet been
>>>    through external counsel. We are prepared to obtain and provide an independent
>>>     legal review if the committee recommends it.
>>> What gap OSN-1.0 fills (short statement)
>>> OSN-1.0 fills a narrow interoperability gap not directly covered by common
>>> permissive licenses: it provides a clear, normative treatment of syscall/ABI
>>> boundary files (headers, syscall numbers, ABI-structure layouts, formal ABI
>>> docs) so those files may be licensed in a way that preserves attribution and
>>> patent grants while avoiding the creation of derivative-work obligations for
>>> callers across the syscall boundary . In short: OSN clarifies how syscall/ABI
>>> interface artifacts can be reused by both open-source and proprietary userland
>>> implementations without producing unintended downstream copyleft consequences.

>>> Comparison with Apache-2.0 (short)

>>>    * Form & grants: OSN borrows familiar structure and grant language (copyright +
>>>     patent) similar to Apache-2.0.
>>>    * Key differences: OSN introduces a normative definition of "Syscall Boundary"
>>>    and places explicit, enforceable conditions for syscall/ABI interface
>>>    redistributions (attribution, notice pointers). OSN also clarifies the
>>>    relationship between automatic contribution licensing and optional CLAs so that
>>>    a CLA cannot reduce downstream rights already granted under the license. Unlike
>>>    Apache, OSN is scoped to syscall/ABI interface files and their reuse semantics
>>>     at kernel/userland boundaries.
>>> Responses to McCoy's specific points

>>>    1. Contribution section / CLA ambiguity: Fixed by making the automatic
>>>    contribution license (Section 5.2) effective on submission and explicitly
>>>    stating that a CLA (if offered) may not reduce downstream recipient rights for
>>>    Contributions already licensed under Section 5.2. If a Contributor later
>>>    explicitly states a Contribution is governed solely by a CLA, that fact will
>>>    control only as to that later Contribution. This resolves precedence and
>>>     ambiguity concerns.
>>>    2. Section 5.4 / unnecessary statements removed: Any redundant or advisory text
>>>    implying projects must accept contributions was removed. Contribution process
>>>    guidance is governance material and explicitly separated from the operative
>>>     license terms.
>>>    3. "Should" vs "Must" language in redistribution: Where preservation of
>>>    provenance/notice is required for license integrity, advisory “should” language
>>>    was changed to "must" (Sections 4.1-4.3, 4.4 for binaries). Traceability
>>>    encouragement (e.g., SYSCALL-CHANGES.md) is explicitly non-normative and
>>>     advisory only.
>>>    4. Syscall boundary definition: Added an explicit, normative definition of
>>>    "Syscall Boundary" in the Definitions section to anchor what files the license
>>>     targets.
>>>    5. Indemnity clause: Softened to state that contributors/users are responsible
>>>    for claims arising from their own modifications or distributions, and removed
>>>    any broad affirmative indemnity obligations for Licensors. Any additional
>>>     indemnity must be in a separate written agreement.
>>>    6. Termination & multiple Licensors: Clarified that only the Licensor whose
>>>    rights are affected may initiate termination as to their portion of the
>>>     Software.
>>>    7. Non-normative material reduced: All prior explanatory/templating content was
>>>    removed or consolidated into a single, explicitly-labelled non-normative
>>>    suggestion section (Section 14). The operative license (Sections 1–13) is
>>>     normative.
>>>    8. SPDX identifier & formatting: SPDX identifier normalized to
>>>     Orivex-syscall-note-1.0 and author name updated to Kartik Pawar .
>>> What I'm submitting now

>>>     * The revised OSN-1.0 license text is attached for your convenience.

>>> Thank you for your time and guidance. Please let me know if the committee would
>>> prefer the redline as an attachment or if any additional edits would make
>>> review easier.

>>> Sincerely,
>>> Kartik Pawar
>>> Orivex Project Lead
>>> [ mailto:karuman2013 at gmail.com | karuman2013 at gmail.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 [ mailto:License-review at lists.opensource.org |
>>> License-review at lists.opensource.org ] [
>>> http://lists.opensource.org/mailman/listinfo/license-review_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 [ mailto:License-review at lists.opensource.org |
>> License-review at lists.opensource.org ] [
>> http://lists.opensource.org/mailman/listinfo/license-review_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: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251028/40f714ec/attachment-0001.htm>

From carlo at piana.eu  Tue Oct 28 17:22:00 2025
From: carlo at piana.eu (Carlo Piana)
Date: Tue, 28 Oct 2025 18:22:00 +0100 (CET)
Subject: [License-review] [2nd Resubmission] ModelGo Attribution
 License, Version 2.0
In-Reply-To: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
References: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
Message-ID: <409991840.30100324.1761672120604.JavaMail.zimbra@piana.eu>

Moming, 

while reviewing the modifications to decide on the approval (actually it should be better to withdraw and resubmit at the end of the discussion) I noticed that the modifications only applied to the MG-by and not to the Open Source version. 

Comparing the two texts, moreover I see that here the liability disclaimer says "to the maximum extent permissible under applicable law, the Licensed Materials are provided on an “as is" and “as available” basis without any representation, warranty, *condition* or term of any kind (whether express, implied, statutory or otherwise)... 

"condition, or term" does not appear in the other license and I think it does not make sense adding it at all, since the license has terms and conditions. 

At least, however, I think you should port the improvements of the Attribution license to the Open Source one, I really don't see why, while sharing like 95% of the provisions, this has not been done to the identical ones here: the rationale applies equally. 

I also object using "Source Code Form" for "preferred form for making modifications, since most evidently the definition includes way more than source code and it is not good practice to define something with a name which is misleading. 

I am still dubious that you can include the Output in the Derivative definition and that a license can purport to control it. This shall undergo more discussion, here and elsewhere, as it is a central point upon which I tried to make an impression every time I discussed porting Open Source concepts to the world of AI. 

At present, I am not inclined to approve the ModelGo Open Source license, while for the Attribution, after the changes at least, I don't see major problems. 

For the "zero", I think the title is misleading, because it has no "zero" conditions, and I have not made a final opinion yet. 

Best, 

Carlo 

> Da: "Moming Duan" <duanmoming at gmail.com>
> A: "license-review at lists.opensource.org" <license-review at lists.opensource.org>
> Inviato: Mercoledì, 18 giugno 2025 11:31:21
> Oggetto: [License-review] [2nd Resubmission] ModelGo Attribution License,
> Version 2.0

> Dear OSI Community,

> Following our previous discussions in May, I have made further revisions to the
> ModelGo Attribution License (MG-BY-2.0). I am submitting this updated version
> for OSI review via this email. The license text is attached.

> —————— Major Updates to Previous Submission

> * Removes restrictions on model output.
> * Revises the termination clause to provide for automatic termination.
> * Adds more explicit granting of rights in Section 2.1.
> * Narrows the definition of “Derivative Materials” by including the phrase: “in
> order to replicate, approximate, or otherwise achieve functional behavior that
> is similar to the Model.”
> * Removes “Derivative Materials” in Section 5: “Nothing in this License permits
> You to modify this License as applied to the Licensed Materials.”
> * Fixes typos and formatting issues.

> —————— License Introduction

> License Name : ModelGo Attribution License
> Version : 2.0
> Short Identifier: MG-BY-2.0
> Copyleft: No
> Legacy or New : New License
> Drafted By Lawyer : Yes, Rajah & Tann Singapore LLP
> Approved or Used by Projects : No

> License URL : [ https://ids.nus.edu.sg/modelgo-mg-by.html |
> https://ids.nus.edu.sg/modelgo-mg-by.html ]
> Introduction and Video : [ https://www.modelgo.li/ | https://www.modelgo.li/ ]

> Overview :

> ModelGo Attribution License Version 2.0 (MG-BY-2.0) is a new license designed
> for publishing models (typically neural networks like Llama2, DeepSeek). It is
> one of the variants in the ModelGo License family. MG-BY-2.0 is the a
> permissive license in the ModelGo family, requiring that the original license
> and attribution be provided when distributing the original Licensed Materials
> or Derivative Materials ( Licensed Materials and Derivative Materials are
> defined in Clause 1). A statement of modification is required, if applicable.
> (Red content represents the differences from MG0-2.0 license)

> Complies with OSD:

> OSD 3 Derived Works — MG-BY-2.0 Clause 2.1 (a) grants copyright and patent
> rights to create derivatives.
> OSD 5 and OSD 6 — No discrimination clause is included in MG-BY-2.0.
> OSD 9 License Must Not Restrict Other Software — No such restriction is included
> in MG-BY-2.0.

> The Gap to Fill:
> Model sharing is very common on the web, with over 1.4 million models currently
> listed on Hugging Face ( [ https://huggingface.co/models |
> https://huggingface.co/models ] ). However, most of these models are not
> properly licensed. When publishing their models, developers typically choose
> from three main options (as seen in the model license tags on the Hugging Face
> website):

>     * OSS licenses, e.g., Apache-2.0, MIT
>    * Open responsible AI licenses (OpenRAILs), e.g., CreativeML-OpenRAIL-M,
>     OpenRAIL++
>     * Proprietary Licenses, e.g., Llama2, Llama3

> However, not all licenses are well-suited for model publishing.

> Why not use OSS licenses?
> Traditional OSS licenses lack clear definitions regarding machine learning
> concepts, such as Models, Output, and Derivatives created through knowledge
> transfer. This ambiguity can result in certain ML activities (e.g.,
> Distillation, Mix-of-Expert) being beyond the control of the model owner.

> Why not use OpenRAILs?
> Recently, Responsible AI Licenses ( [ https://www.licenses.ai/ |
> https://www.licenses.ai/ ] ) have been widely advocated to govern AI
> technologies, aiming to restrict unlawful and unethical uses of models. While I
> acknowledge the growing need for such governance, these copyleft-style
> restrictions do not comply with the OSD and may cause incompatibility with
> licenses like GPL-3.0. Another concern is that these behavioral restrictions
> may proliferate within the AI model ecosystem, increasing the risk of license
> breaches.

> Why not use Llama2 or Llama3 Licenses?
> These licenses are proprietary licenses that are not reusable. Furthermore, they
> include exclusive terms such as "You will not use the Llama Materials or any
> output or results of the Llama Materials to improve any other large language
> model" and copyleft-style behavioral restrictions.

> In fact, the dilemma in current model publishing is the lack of a
> general-purpose license for model developers. Additionally, since no single
> license meets diverse model publishing needs, some developers resort to using
> CC licenses with different elements. However, CC licenses are ill-suited for
> this purpose as they do not grant patent rights. This motivated the drafting of
> ModelGo License family, which provides different licensing elements similar to
> CC but specifically designed for model publishing.

> Comparison with Existing OSI-Approved Licenses:
> Since I could not find an OSI-approved model license, I can only compare
> MG-BY-2.0 with one similar OSS license — Apache-2.0

> * MG-BY-2.0 defines licensed materials and derivative works differently from
> Apache-2.0, tailoring them to models.
> * MG-BY-2.0 can govern the remote access (e.g., chatbot) scenario.

> If further comparisons or supporting evidence are needed to strengthen my
> claims, please let me know. I am more than willing to engage in further
> discussions with the OSI community about this license and contribute to
> promoting standardized model publishing. 🤗

> Best,
> Moming

> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily
> those of the Open Source Initiative. Communication from the Open Source
> Initiative will be sent from an opensource.org email address.

> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251028/39a5f612/attachment.htm>

From duanmoming at gmail.com  Thu Oct 30 04:40:51 2025
From: duanmoming at gmail.com (Moming Duan)
Date: Thu, 30 Oct 2025 12:40:51 +0800
Subject: [License-review] [2nd Resubmission] ModelGo Attribution License,
 Version 2.0
In-Reply-To: <409991840.30100324.1761672120604.JavaMail.zimbra@piana.eu>
References: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
 <409991840.30100324.1761672120604.JavaMail.zimbra@piana.eu>
Message-ID: <C1E61DAF-18A0-4A2F-AC0B-23549E6C40B7@gmail.com>

Hi Carlo,

Thanks for your review.

> while reviewing the modifications to decide on the approval (actually it should be better to withdraw and resubmit at the end of the discussion) I noticed that the modifications only applied to the MG-by and not to the Open Source version.
> 
> Comparing the two texts, moreover I see that here the liability disclaimer says "to the maximum extent permissible under applicable law, the Licensed Materials are provided on an “as is" and “as available” basis without any representation, warranty, *condition* or term of any kind (whether express, implied, statutory or otherwise)... 
> 
> "condition, or term" does not appear in the other license and I think it does not make sense adding it at all, since the license has terms and conditions.  
> 
> At least, however, I think you should port the improvements of the Attribution license to the Open Source one, I really don't see why, while sharing like 95% of the provisions,  this has not been done to the identical ones here: the rationale applies equally.

It seems you’re comparing the 2nd resubmission of MG-BY with the (1st) resubmission of MG-BY-OS (which was renamed to MG-BY-SA in the 2nd resubmission). For clarification, the 2nd resubmission of the MG license text is in the email with the subject:

[2nd Resubmission] ModelGo Zero License, Version 2.0
[2nd Resubmission] ModelGo Attribution-ShareAlike License, Version 2.0


> I also object using "Source Code Form" for "preferred form for making modifications, since most evidently the definition includes way more than source code and it is not good practice to define something with a name which is misleading.

This definition refers to GPL-3.0, which states:

The "source code" for a work means the preferred form of the work  for making modifications to it.

I am also not sure that MG-BY-SA can meet the approval requirements. And as Pam previously mentioned, there remains a question of whether copyleft can effectively function in the context of ML models. I look forward to OSI’s decision and hope to engage in a deeper discussion on this topic in the future.

> 
> I am still dubious that you can include the Output in the Derivative definition and that a license can purport to control it. This shall undergo more discussion, here and elsewhere, as it is a central point upon which I tried to make an impression every time I discussed porting Open Source concepts to the world of AI.
> 
> For the "zero", I think the title is misleading, because it has no "zero" conditions, and I have not made a final opinion yet.

Please refer to the 2nd resubmission version of MG, where I have already removed all the conditions as suggested by McCoy Smith. Thanks.


Best,
Moming

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/1a2d873d/attachment.htm>

From carlo at piana.eu  Thu Oct 30 09:06:59 2025
From: carlo at piana.eu (Carlo Piana)
Date: Thu, 30 Oct 2025 10:06:59 +0100 (CET)
Subject: [License-review] [2nd Resubmission] ModelGo Attribution
 License, Version 2.0
In-Reply-To: <C1E61DAF-18A0-4A2F-AC0B-23549E6C40B7@gmail.com>
References: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
 <409991840.30100324.1761672120604.JavaMail.zimbra@piana.eu>
 <C1E61DAF-18A0-4A2F-AC0B-23549E6C40B7@gmail.com>
Message-ID: <269697692.31269127.1761815219719.JavaMail.zimbra@piana.eu>

> Da: "Moming Duan" <duanmoming at gmail.com>
> A: "License submissions for OSI review" <license-review at lists.opensource.org>,
> "Carlo Piana" <carlo at piana.eu>
> Inviato: Giovedì, 30 ottobre 2025 5:40:51
> Oggetto: Re: [License-review] [2nd Resubmission] ModelGo Attribution License,
> Version 2.0

> Hi Carlo,
> Thanks for your review.

>> while reviewing the modifications to decide on the approval (actually it should
>> be better to withdraw and resubmit at the end of the discussion) I noticed that
>> the modifications only applied to the MG-by and not to the Open Source version.

>> Comparing the two texts, moreover I see that here the liability disclaimer says
>> "to the maximum extent permissible under applicable law, the Licensed Materials
>> are provided on an “as is" and “as available” basis without any representation,
>> warranty, *condition* or term of any kind (whether express, implied, statutory
>> or otherwise)...

>> "condition, or term" does not appear in the other license and I think it does
>> not make sense adding it at all, since the license has terms and conditions.

>> At least, however, I think you should port the improvements of the Attribution
>> license to the Open Source one, I really don't see why, while sharing like 95%
>> of the provisions, this has not been done to the identical ones here: the
>> rationale applies equally.

> It seems you’re comparing the 2nd resubmission of MG-BY with the (1st)
> resubmission of MG-BY-OS (which was renamed to MG-BY-SA in the 2nd
> resubmission). For clarification, the 2nd resubmission of the MG license text
> is in the email with the subject:

> [2nd Resubmission] ModelGo Zero License, Version 2.0
> [2nd Resubmission] ModelGo Attribution-ShareAlike License, Version 2.0

It's very likely a mistake on our side, sorry. 

>> I also object using "Source Code Form" for "preferred form for making
>> modifications, since most evidently the definition includes way more than
>> source code and it is not good practice to define something with a name which
>> is misleading.

> This definition refers to GPL-3.0, which states:

> The "source code" for a work means the preferred form of the work for making
> modifications to it.

I know, this is the same definition we used. The objection is not on the definition, it's on calling this stuff "source code", because it's not code and probably not even source. 

> I am also not sure that MG-BY-SA can meet the approval requirements. And as Pam
> previously mentioned, there remains a question of whether copyleft can
> effectively function in the context of ML models. I look forward to OSI’s
> decision and hope to engage in a deeper discussion on this topic in the future.

That's a shared concern, yes. 

>> I am still dubious that you can include the Output in the Derivative definition
>> and that a license can purport to control it. This shall undergo more
>> discussion, here and elsewhere, as it is a central point upon which I tried to
>> make an impression every time I discussed porting Open Source concepts to the
>> world of AI.

>> For the "zero", I think the title is misleading, because it has no "zero"
>> conditions, and I have not made a final opinion yet.

> Please refer to the 2nd resubmission version of MG, where I have already removed
> all the conditions as suggested by McCoy Smith. Thanks.

Then we have a problem with tracking down the re-submission, because apparently I am not the only one confused by that. 

Could you please provide us with a full set of the final, revised licenses, as well as a word-diff comparing them to the originals? That would be a huge help and save us from further embarrassment of looking in the wrong place. Thank you. 

Carlo 

> Best,
> Moming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/ff9f532e/attachment.htm>

From duanmoming at gmail.com  Thu Oct 30 13:41:16 2025
From: duanmoming at gmail.com (Moming Duan)
Date: Thu, 30 Oct 2025 21:41:16 +0800
Subject: [License-review] [2nd Resubmission] ModelGo Attribution License,
 Version 2.0
In-Reply-To: <269697692.31269127.1761815219719.JavaMail.zimbra@piana.eu>
References: <883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com>
 <409991840.30100324.1761672120604.JavaMail.zimbra@piana.eu>
 <C1E61DAF-18A0-4A2F-AC0B-23549E6C40B7@gmail.com>
 <269697692.31269127.1761815219719.JavaMail.zimbra@piana.eu>
Message-ID: <E38E16FE-01A0-4084-B9F3-9DE1D6C42EC3@gmail.com>

Hi Carlo,


I also thought it would be helpful to provide the full set in this thread, but I was concerned about causing additional versioning confusion, so I didn’t include them in my previous response~
I’ve now placed the final versions of the license text files below (please ignore the license texts shared in other threads).

These final versions are mostly consistent with the 2nd resubmission, except for the following updates:

I updated the copyright years of all three licenses from 2024 to 2025 to ensure everything is up to date. 
In this email, I revised MG-BY-SA-2.0 by replacing “Source Code Form” with “Preferred Adaptable Form.”


I agree that “Source Code Form” in the SA could be misleading, so I replaced it with “Preferred Adaptable Form.” However, this term may still require further discussion. For example, someone might argue that providing only API access could also be considered “adaptable,” since users can improve outputs via prompts for their specific use cases. Ultimately, the core question remains how copyleft concept can effectively enforce in the context of ML models. 
As for the other two, I think MG0 and MG-BY are already in good shape after the continued rounds of review and iteration, and I wonder if we might be close to reaching consensus on them.

For convenience, I’ve also attached the license texts from the (1st) resubmission (in 1stR.zip) and provide the word-diff views between the 1st and 2nd resubmissions using Diffchecker links below. More discussion about these modifications can be found in the (1st) resubmission thread.

MG0: https://www.diffchecker.com/N95uZiD1/
MG-BY: https://www.diffchecker.com/GfjVnw3u/
MG-BY-SA: https://www.diffchecker.com/NvVxWuAl/


Best,
Moming





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/525a8a18/attachment-0005.htm>
-------------- next part --------------
ModelGo Attribution License
Version 2.0, May 2025

By exercising the rights granted in Section 2.1, You acknowledge and agree that You have 
read, understood, and agree to be bound by the terms and conditions of this License. If You 
do not agree to any terms and/or conditions of this License, then the Licensor grants You no 
rights under this License.

1.	DEFINITIONS

"Complementary Materials" means the source code and scripts used to define, run, load, 
benchmark and/or evaluate the Model, and prepare data for the purpose of training, pretraining, 
fine-tuning and/or evaluation of the Model, and any tutorials, operating manuals, user guides 
and/or documentation that guide users in using, operating, implementing and/or customising 
the Model.

"Derivative Materials" means all improvements, modifications or derivative works to the 
Licensed Material or any part thereof, which are created or developed by You (either by 
Yourself or jointly with other third parties), including any derivative model developed by 
transferring patterns of weights, parameters, activations and/or Output from the Model, such as 
through distillation methods or synthetic data generation techniques, in order to replicate, 
approximate, or otherwise achieve functional behavior that is similar to the Model.

"Distribution" (or "Distribute") means any transmission, publication, public performance, 
sharing, or other methods of making the Licensed Materials, Derivative Materials and/or Output 
available to a third party, including providing the Licensed Materials or any part thereof as a 
hosted service or remotely accessible service, such as API-based access or web access.

"Licensor" means the rights owner that is granting the License.

"Licensed Materials" means the Model and Complementary Materials that are Distributed by 
the Licensor under this License. The Licensed Materials do not include any datasets used for 
pretraining, training, adapting, or evaluating the Model, which may or may not be made 
available under a separate license.

"Model" means the machine-learning constructs and/or assemblies licensed by the Licensor 
under this License, including any checkpoints, learned weights, parameters (including optimizer 
states) and the model architecture.

"Output" means any information, data, and/or content, including but not limited to images, text, 
text effects, audio files, and/or video files, generated through operation of the Model, or through 
operation of any new model developed by transferring patterns from the Model.

"You" (or "Your") means you, or any other person or entity you are entering into this license on 
behalf of, provided you have the legal authority to bind such person or entity.

2.	LICENSE RIGHTS

2.1	Grant of Rights

(a)	Subject to the conditions in Section 2.2 of this License, the Licensor hereby grants to 
You a non-exclusive, sublicensable, irrevocable, royalty-free, worldwide license under 
the relevant copyrights, patent rights, database rights, and any other intellectual property 
rights to:

(i)	make, have made, use, reproduce, sell, offer to sell, import and Distribute the 
Licensed Materials;

(ii)	use the Licensed Materials to create Derivative Materials; and

(iii)	make, have made, use, reproduce, sell, offer to sell, import and Distribute 
Derivative Materials.

2.2	Conditions

(a)	If You Distribute any of the Licensed Materials or Derivative Materials, You shall:

(i)	provide a copy of this License with the Licensed Material or Derivative Materials;

(ii)	in the case of Distributing Derivative Materials, provide as part of the Distribution, 
prominent notices stating that You have modified the Licensed Materials and the 
relevant date of such modification;

(iii)	retain as part of the Distribution any existing copyright notice, attribution notice, 
and/or any notice identifying the authors of the Licensed Materials and any 
Derivative Materials.

2.3	Reservation of Rights

You shall not refer to the Licensor or use the Licensor's trademarks, trade names, and service 
marks, for any publicity, advertising or marketing purposes, without the Licensor's prior written 
consent.

3.	DISCLAIMER

To the maximum extent permissible under applicable law, the Licensed Materials are provided 
on an "as is" and "as available" basis without any representation or warranty of any kind 
(whether express, implied, statutory or otherwise), including of merchantability, satisfactory 
quality, fitness for a particular purpose, title, accuracy, correctness, absence of error, reliability, 
timeliness, non-infringement of or compliance with any laws, regulations and/or third-party 
rights, all of which are expressly disclaimed by the Licensor.

4.	LIMITATION OF LIABILITY

To the maximum extent permissible under applicable law, the Licensor shall not be liable for 
any claims, damages, or any other liabilities, in any way arising out of or in connection with the 
Licensed Materials, Derivative Materials, and/or Output, whether on an action or claim in 
contract, tort (including negligence), breach of statutory duty or otherwise, even if the Licensor 
has been advised of the possibility of such damages.

5.	TERMINATION

This License shall terminate immediately if You breach any material term and/or condition of 
this License, or if You initiate any legal action against the Licensor alleging that the Licensed 
Materials and/or Derivative Materials infringe any patent worldwide. Sections 3, 4 and 6 shall 
survive the termination of this License.

6.	MODIFICATION OF THIS LICENSE

This License is Copyright © 2025 National University of Singapore. Permission is granted to 
copy, distribute, or communicate this License without modification. Nothing in this License 
permits You to modify this License as applied to the Licensed Materials. However, You may 
modify the text of this License and copy, distribute or communicate Your modified version and 
apply it to other original works of authorship, provided that You do not use the name "ModelGo" 
for your version of the license and furnish a readable notice describing Your modifications to 
this License.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/525a8a18/attachment-0006.htm>
-------------- next part --------------
ModelGo Zero License
Version 2.0, May 2025

By exercising the rights granted in Section 2.1, You acknowledge that You have read and 
understood this License, including the Disclaimer in Section 3.

1.	DEFINITIONS

"Complementary Materials" means the source code and scripts used to define, run, load, 
benchmark and/or evaluate the Model, and prepare data for the purpose of training, pretraining, 
fine-tuning and/or evaluation of the Model, and any tutorials, operating manuals, user guides 
and/or documentation that guide users in using, operating, implementing and/or customising 
the Model.

"Derivative Materials" means all improvements, modifications or derivative works to the 
Licensed Material or any part thereof, which are created or developed by You (either by 
Yourself or jointly with other third parties), including any derivative model developed by 
transferring patterns of weights, parameters, activations and/or Output from the Model, such as 
through distillation methods or synthetic data generation techniques, in order to replicate, 
approximate, or otherwise achieve functional behavior that is similar to the Model.

"Distribution" (or "Distribute") means any transmission, publication, public performance, 
sharing, or other methods of making the Licensed Materials, Derivative Materials and/or Output 
available to a third party, including providing the Licensed Materials or any part thereof as a 
hosted service or remotely accessible service, such as API-based access or web access.

"Licensor" means the rights owner that is granting the License.

"Licensed Materials" means the Model and Complementary Materials that are Distributed by 
the Licensor under this License. The Licensed Materials do not include any datasets used for 
pretraining, training, adapting, or evaluating the Model, which may or may not be made 
available under a separate license.

"Model" means the machine-learning constructs and/or assemblies licensed by the Licensor 
under this License, including any checkpoints, learned weights, parameters (including optimizer 
states) and the model architecture.

"Output" means any information, data, and/or content, including but not limited to images, text, 
text effects, audio files, and/or video files, generated through operation of the Model, or through 
operation of any new model developed by transferring patterns from the Model.

"You" (or "Your") means you, or any other person or entity you are entering into this license on 
behalf of, provided you have the legal authority to bind such person or entity.

2.	LICENSE RIGHTS

2.1	Grant of Rights

(a)	The Licensor hereby grants to You a non-exclusive, sublicensable, irrevocable, royalty-
free, worldwide license under the relevant copyrights, patent rights, database rights, and 
any other intellectual property rights to:

(i)	make, have made, use, reproduce, sell, offer to sell, import and Distribute the 
Licensed Materials;

(ii)	use the Licensed Materials to create Derivative Materials; and

(iii)	make, have made, use, reproduce, sell, offer to sell, import and Distribute 
Derivative Materials.

2.2	Reservation of Rights

You shall not refer to the Licensor or use the Licensor's trademarks, trade names, and service 
marks, for any publicity, advertising or marketing purposes, without the Licensor's prior written 
consent.

3.	DISCLAIMER

To the maximum extent permissible under applicable law, the Licensed Materials are provided 
on an "as is" and "as available" basis without any representation or warranty of any kind 
(whether express, implied, statutory or otherwise), including of merchantability, satisfactory 
quality, fitness for a particular purpose, title, accuracy, correctness, absence of error, reliability, 
timeliness, non-infringement of or compliance with any laws, regulations and/or third-party 
rights, all of which are expressly disclaimed by the Licensor.

4.	LIMITATION OF LIABILITY

To the maximum extent permissible under applicable law, the Licensor shall not be liable for 
any claims, damages, or any other liabilities, in any way arising out of or in connection with the 
Licensed Materials, Derivative Materials, and/or Output, whether on an action or claim in 
contract, tort (including negligence), breach of statutory duty or otherwise, even if the Licensor 
has been advised of the possibility of such damages.

5.	MODIFICATION OF THIS LICENSE

This License is Copyright © 2025 National University of Singapore. Permission is granted to 
copy, distribute, or communicate this License without modification. Nothing in this License 
permits You to modify this License as applied to the Licensed Materials. However, You may 
modify the text of this License and copy, distribute or communicate Your modified version and 
apply it to other original works of authorship, provided that You do not use the name "ModelGo" 
for your version of the license and furnish a readable notice describing Your modifications to 
this License.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/525a8a18/attachment-0007.htm>
-------------- next part --------------
ModelGo Attribution-ShareAlike License
Version 2.0, May 2025

By exercising the rights granted in Section 2.1, You acknowledge and agree that You have 
read, understood, and agree to be bound by the terms and conditions of this License. If You 
do not agree to any terms and/or conditions of this License, then the Licensor grants You no 
rights under this License.

1.	DEFINITIONS

"Complementary Materials" means the source code and scripts used to define, run, load, 
benchmark and/or evaluate the Model, and prepare data for the purpose of training, pretraining, 
fine-tuning and/or evaluation of the Model, and any tutorials, operating manuals, user guides 
and/or documentation that guide users in using, operating, implementing and/or customising 
the Model.

"Derivative Materials" means all improvements, modifications or derivative works to the 
Licensed Material or any part thereof, which are created or developed by You (either by 
Yourself or jointly with other third parties), including any derivative model developed by 
transferring patterns of weights, parameters, activations and/or Output from the Model, such as 
through distillation methods or synthetic data generation techniques, in order to replicate, 
approximate, or otherwise achieve functional behavior that is similar to the Model.

"Distribution" (or "Distribute") means any transmission, publication, public performance, 
sharing, or other methods of making the Licensed Materials, Derivative Materials and/or Output 
available to a third party, including providing the Licensed Materials or any part thereof as a 
hosted service or remotely accessible service, such as API-based access or web access.

"Licensor" means the rights owner that is granting the License.

"Licensed Materials" means the Model and Complementary Materials that are Distributed by 
the Licensor under this License. The Licensed Materials do not include any datasets used for 
pretraining, training, adapting, or evaluating the Model, which may or may not be made 
available under a separate license.

"Model" means the machine-learning constructs and/or assemblies licensed by the Licensor 
under this License, including any checkpoints, learned weights, parameters (including optimizer 
states) and the model architecture.

"Output" means any information, data, and/or content, including but not limited to images, text, 
text effects, audio files, and/or video files, generated through operation of the Model, or through 
operation of any new model developed by transferring patterns from the Model.

"You" (or "Your") means you, or any other person or entity you are entering into this license on 
behalf of, provided you have the legal authority to bind such person or entity.

2.	LICENSE RIGHTS

2.1	Grant of Rights

(a)	Subject to the conditions in Section 2.2 of this License, the Licensor hereby grants to 
You a non-exclusive, non-sublicensable, irrevocable, royalty-free, worldwide license 
under the relevant copyrights, patent rights, database rights, and any other intellectual 
property rights to:

(i)	make, have made, use, reproduce, sell, offer to sell, import and Distribute the 
Licensed Materials;

(ii)	use the Licensed Materials to create Derivative Materials; and

(iii)	make, have made, use, reproduce, sell, offer to sell, import and Distribute 
Derivative Materials.

2.2	Conditions

(a)	If You Distribute any of the Licensed Materials or Derivative Materials, You shall:

(i)	provide a copy of this License with the Licensed Material or Derivative Materials;

(ii)	in the case of Distributing Derivative Materials, provide as part of the Distribution, 
prominent notices stating that You have modified the Licensed Materials and the 
relevant date of such modification;

(iii)	retain as part of the Distribution any existing copyright notice, attribution notice, 
and/or any notice identifying the authors of the Licensed Materials and any 
Derivative Materials;

(iv)	provide a copy of all such Distributed Licensed Materials and Distributed 
Derivative Materials in Preferred Adaptable Form to the recipient of the Distributed 
Licensed Materials or Distributed Derivative Materials. For the purposes of this 
clause, "Preferred Adaptable Form" means the preferred form for making 
modifications to and reproducing the Licensed Materials and/or Derivative 
Materials;

(v)	license Derivative Materials under this License.

2.3	Reservation of Rights

You shall not refer to the Licensor or use the Licensor's trademarks, trade names, and service 
marks, for any publicity, advertising or marketing purposes, without the Licensor's prior written 
consent.

3.	DISCLAIMER

To the maximum extent permissible under applicable law, the Licensed Materials are provided 
on an "as is" and "as available" basis without any representation or warranty of any kind 
(whether express, implied, statutory or otherwise), including of merchantability, satisfactory 
quality, fitness for a particular purpose, title, accuracy, correctness, absence of error, reliability, 
timeliness, non-infringement of or compliance with any laws, regulations and/or third-party 
rights, all of which are expressly disclaimed by the Licensor.

4.	LIMITATION OF LIABILITY

To the maximum extent permissible under applicable law, the Licensor shall not be liable for 
any claims, damages, or any other liabilities, in any way arising out of or in connection with the 
Licensed Materials, Derivative Materials, and/or Output, whether on an action or claim in 
contract, tort (including negligence), breach of statutory duty or otherwise, even if the Licensor 
has been advised of the possibility of such damages.

5.	TERMINATION

This License shall terminate immediately if You breach any material term and/or condition of 
this License, or if You initiate any legal action against the Licensor alleging that the Licensed 
Materials and/or Derivative Materials infringe any patent worldwide. Sections 3, 4 and 6 shall 
survive the termination of this License.

6.	MODIFICATION OF THIS LICENSE

This License is Copyright © 2025 National University of Singapore. Permission is granted to 
copy, distribute, or communicate this License without modification. Nothing in this License 
permits You to modify this License as applied to the Licensed Materials. However, You may 
modify the text of this License and copy, distribute or communicate Your modified version and 
apply it to other original works of authorship, provided that You do not use the name "ModelGo" 
for your version of the license and furnish a readable notice describing Your modifications to 
this License.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/525a8a18/attachment-0008.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1stR.zip
Type: application/zip
Size: 9219 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/525a8a18/attachment-0001.zip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251030/525a8a18/attachment-0009.htm>