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

Sun Oct 26 20:38:12 UTC 2025

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>