<div dir="ltr"><div dir="ltr">Hi,<br><br>Thanks for posting the revision. It looks like you addressed the previously noted issues; I don\u2019t see an obvious OSD conflict in the current text.<br>I have two small clarifications to reduce ambiguity:<br><br>§2.4: The intent seems to be pass-through rather than sublicensing. To make that unmistakable, I suggest adding the words "under this License".<br>§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. <br><br>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.<br><br></div><div>Best,</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2025/10/25 21:30 Righteousness <<a href="mailto:karuman2013@gmail.com">karuman2013@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear License Review Committee,<div><br></div><div>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.</div><div><br></div><div><font size="4"><b>Who authored & legal review</b></font></div><div><ul><li><b>Author: </b>Kartik Pawar (Orivex Project Lead)</li><li><b>Legal review: </b>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.</li></ul><div><font size="4"><b>What gap OSN-1.0 fills (short statement)</b></font></div><div>OSN-1.0 fills a narrow interoperability gap not directly covered by common permissive licenses: it provides a clear, normative treatment of <b>syscall/ABI boundary files </b>(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 <b>avoiding the creation of derivative-work obligations for callers across the syscall boundary</b>. 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.
</div><div><br></div><div><font size="4"><b>Comparison with Apache-2.0 (short)</b></font></div><div><ul><li><b>Form & grants: </b>OSN borrows familiar structure and grant language (copyright + patent) similar to Apache-2.0.</li><li><b>Key differences: </b>OSN introduces a <b>normative definition of "Syscall Boundary" </b>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.
</li></ul><div><font size="4"><b>Responses to McCoy's specific points</b></font></div></div></div><div><ol><li><b>Contribution section / CLA ambiguity: </b>Fixed by making the automatic contribution license (Section 5.2) effective on submission and explicitly stating that a CLA (if offered) <b>may not reduce downstream recipient rights </b>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.</li><li><b>Section 5.4 / unnecessary statements removed: </b>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.
</li><li><b>"Should" vs "Must" language in redistribution: </b>Where
preservation of provenance/notice is required for license integrity, advisory \u201cshould\u201d language was changed to <b>"must" </b>(Sections 4.1-4.3, 4.4 for binaries). Traceability encouragement (e.g., SYSCALL-CHANGES.md) is explicitly non-normative and advisory only.
</li><li><b>Syscall boundary definition: </b>Added an explicit, normative definition of <b>"Syscall Boundary" </b>in the Definitions section to anchor what files the license targets.</li><li><b>Indemnity clause: </b>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.
</li><li><b>Termination & multiple Licensors: </b>Clarified that only the Licensor whose rights are affected may initiate termination as to their portion of the Software.</li><li><b>Non-normative material reduced: </b>
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\u201313) is normative.</li><li><b>SPDX identifier & formatting: </b>SPDX identifier normalized to <font face="monospace">Orivex-syscall-note-1.0 </font><font face="arial, sans-serif">and author name updated to <b>Kartik Pawar</b>.</font></li></ol><div><font face="arial, sans-serif" size="4"><b>What I'm submitting now</b></font></div></div><div><ul><li><span style="font-family:arial,sans-serif">The </span><b style="font-family:arial,sans-serif">revised OSN-1.0 </b><span style="font-family:arial,sans-serif">license text is attached for your convenience.</span></li></ul>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. </div><div><br></div><div>Sincerely,</div><div><b>Kartik Pawar</b></div><div>Orivex Project Lead</div><div><a href="mailto:karuman2013@gmail.com" target="_blank">karuman2013@gmail.com</a></div><div><b></b></div></div>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Shuji Sado</div><div>Chairman, Open Source Group Japan<br><a href="https://opensource.jp/" target="_blank">https://opensource.jp/</a><br>English blog: <a href="https://shujisado.org/" target="_blank">https://shujisado.org/</a></div><div>Japanese blog: <a href="https://shujisado.com/" target="_blank">https://shujisado.com/</a></div><div><br></div></div></div></div>