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

[McCoy Smith]

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>