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

[Shuji Sado]

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>