[License-review] Submission of Orivex Syscall Note License (OSN-1.0) for OSI Approval - Revised Submission (Kartik Pawar)

Tue Oct 28 11:47:02 UTC 2025

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>