<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>In my opinion, speaking personally, this license really needs to
go through a legal review before submission/resubmission. Here are
a few reasons:</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/25/2025 12:08 AM, Righteousness
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE0NYFG5QXWP31re0R=CHgjhJTRwspto7+oxyrQZ7K3vA4o5JQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">karuman2013@gmail.com</a></div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
</body>
</html>