<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I agree with everything McCoy says, and have some additional
comments.</p>
<p>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?<br>
<br>
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.</p>
<p>As Carlo already pointed out, you have two different types of
participants, Contributors and Licensor. The Contributor is <i>also</i> 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.</p>
<p>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.</p>
<p>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. </p>
<p>Pam</p>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
pamela@chesteklegal<br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 10/26/2025 8:17 AM, McCoy Smith
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:200e4928-2f67-4a1e-b627-6c5b1c44b603@lexpan.law">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 moz-txt-link-freetext"
href="mailto:License-review@lists.opensource.org"
moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org"
moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<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>