<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><p>Hi,</p><p>Thanks to Carlo-san for the thorough review. I broadly agree with his analysis. I'd like to add three narrower points that I don't think were explicitly covered, plus one suggestion about an existing pattern that may meet the author's stated goal without a new license.</p><p><strong>1) Sublicensing inconsistency</strong></p><p>§2.2 appears to grant an open-ended right to "sublicense," while §4.6 conditions sublicensing on passing through the original terms; the definitions also fold "sublicense" into "Distribution." This creates ambiguity about whether downstreams rely on the original license or a new downstream license.</p><p><strong>2) Fixed attribution phrase in §4.3</strong></p><p>Mandating the exact sentence ("This distribution includes Orivex syscall interfaces (OSN-1.0) ...") to be displayed "prominently" is heavier than common NOTICE/attribution practice and reduces reusability for non-Orivex projects.</p><p><strong>3) Making an SPDX identifier part of the redistribution requirement (§4.1)</strong></p><p>SPDX tags are excellent metadata, but they are managed outside the license and may not exist for a new text. Making their inclusion a legal condition of redistribution can fail for reasons unrelated to copyright compliance.</p><p><strong>Existing solution for the stated goal</strong></p><p>If the aim is simply to clarify that user-space programs using kernel UAPI/ABI via syscalls are <strong>not</strong> derivative works of the kernel, there is an established SPDX exception used for this purpose: <strong>Linux-syscall-note</strong> (paired with GPL-2.0-only). Reusing that pattern--or documenting the clarification in project docs while using a standard license (e.g., Apache-2.0 or MIT/BSD)--would avoid introducing a new license and improve portability and adoption.</p><p>Best,</p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2025\u5e7410\u670821\u65e5(\u706b) 22:22 Carlo Piana via License-review <<a href="mailto:license-review@lists.opensource.org">license-review@lists.opensource.org</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><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div>Hi, </div><div><br></div><div>thank you for the submission. I take that the .md file is just the gist of the license, but it is not useful to the approval process. </div><div><br></div><div>I firstly note a potential ambiguity on who is the Licensor. It can be either of:</div><div><br></div><div>- everybody who holds any copyright the software</div><div>- who holds the copyright in the original </div><div><br></div><div>The second seems the case, as you elected to define also contributor (as the Apache 2.0 does), which is an interesting election WRT patent license, but in other cases it creates an unacceptable, in my view, discrimination between Licensor and Contributor, for instance in 11. Termination and with a lesser problem in 12. Export Control. This alone discriminates different classes of copyright holders and I consider it potentially against #5.</div><div><br></div><div>Also I am strongly in disfavor not only of any choice of law (only marginally problematic here), but also with any jurisdiction clause. We had this discussion a number of times here.</div><div><br></div><div>On the positive side, I note Section 6 that you took pains at not creating a condition there. Good. Also the patent grant seems correct (again, Apache-style).</div><div><br></div><div>Section 7. creates text that makes difficult to port. It would be nice if submitters already decided to use placeholders instead of their name, or, better, to avoid placing the original licensor in a more favorable position than others, who might become even more prominent licensors.</div><div><br></div><div>Section 9 seems a good example of how you can protect the interest of Contributors, Apache style. I hoped you had done the same elsewhere (see above). </div><div><br></div><div>Also Section 10. although I am not sure I would accept it if I were a contributor and probably I would advise clients against it. The Apache license, which has a similar provision, makes it only as a consequence of the decision to provide a warranty, which makes more sense. This however does not seem to be against OSD, per se, but I urge you to reconsider this, it would create friction and I am not even sure it would hold water in many jurisdictions.</div><div><br></div><div>Also Section 14 is problematic, as it is not clear what the matter hereof is. Suppose licensing software is a part of a contract agreement? </div><div><br></div><div>As the copyright grant in Section 2, what language exactly enables the licensor to distribute dervative works at all? The license only extends to "prepare" and "reproduce", but the right to distribute is only granted in the software, in the source or binary form.</div><div><br></div><div>Please avoid, by all means "open-source". The correct spelling is Open Source. <a href="https://opensource.org/blog/is-" target="_blank">https://opensource.org/blog/is-</a><span id="m_1166572478853767782DWT1181">open-source</span>-ever-hyphenated</div><div><br></div><div>The definition of "Software" is also problematic. It only applies to Software as defined, and what if anyone would use it for different purposes? Why have not you defined software in Section 1 "Definition", leaving the preamble as a a non-normative part of the license?</div><div><br></div><div>So, all in all there is some good faith effort and some quite apparent flaws, on a very cursory reading of the license. I think fixing them (there might be others that I have not spotted) would be relatively easy, but at this version I would find it hard to approve it, even as a special purpose license.</div><div><br></div><div>Cheers</div><div><br></div><div>Carlo </div><div>in his personal capacity</div><div><br></div><hr id="m_1166572478853767782zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>Da: </b>"Righteousness" <<a href="mailto:karuman2013@gmail.com" target="_blank">karuman2013@gmail.com</a>><br><b>A: </b>"<a href="mailto:license-review@lists.opensource.org" target="_blank">license-review@lists.opensource.org</a>" <<a href="mailto:license-review@lists.opensource.org" target="_blank">license-review@lists.opensource.org</a>><br><b>Inviato: </b>Lunedė, 20 ottobre 2025 15:09:03<br><b>Oggetto: </b>[License-review] Submission of Orivex Syscall Note License (OSN-1.0) for OSI Approval<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr">Dear Open Source Initiative License Review Committee,<br><br>I am submitting the Orivex Syscall Note License (OSN-1.0) for your consideration for OSI approval.<br><br>Background:<br>Orivex is an operating system currently under active development. OSN-1.0 is a permissive license specifically designed for Orivex\u2019s kernel-facing components, including kernel headers, syscall interface definitions, reference ABI documentation, and related API files. This license is intended to enable Orivex to be released as open source in the future.<br><br>Why a New License is Necessary:<br>Existing OSI-approved licenses, such as MIT, BSD, or Apache 2.0, provide general-purpose permissive licensing but do not explicitly address kernel- and syscall-level artifacts. OSN-1.0 fills this gap by:<br>- Preserving attribution and provenance specifically for kernel interfaces and ABI contracts.<br>- Providing guidance for ABI and syscall interface compatibility without imposing legal obligations.<br>- Explicitly separating trademark rights from copyright and patent grants.<br>- Clarifying contributor patent grants and termination conditions related to patent litigation.<br><br>Comparison to Similar OSI Licenses:<br>- MIT/BSD: Similar in permissiveness and simplicity, but do not provide guidance on syscall/ABI traceability or contributor patent grant clarity.<br>- Apache 2.0: Includes patent grants and some attribution requirements, but is heavier and not tailored for kernel-facing artifacts or syscall-specific documentation.<br>OSN-1.0 balances permissiveness, clarity, and lightweight design, while providing explicit protections and guidance for kernel interface development.<br><br>Open Source Definition Compliance:<br>OSN-1.0 has been designed to satisfy all ten criteria of the Open Source Definition (OSD), including:<br>- Free redistribution<br>- Availability of source code<br>- Permission to create derivative works<br>- No discrimination against persons, groups, or fields of endeavor<br>- Technology-neutral terms<br>- Clear redistribution and license grant requirements<br><br>Additional Information:<br>- Copyright (c) 2025 Kartik<br>- SPDX Identifier: Orivex-syscall-note<br>- Governing Law: India<br><br>I believe OSN-1.0 provides a clear, permissive license suitable for projects requiring kernel- or syscall-level interfaces while remaining fully OSD-compliant. I would be happy to provide any additional information, clarifications, or documentation needed to facilitate your review.<br><br>Thank you for your time and consideration.<br><br>Best regards,<br>Kartik<br><a href="mailto:karuman2013@gmail.com" target="_blank">karuman2013@gmail.com</a><br></div>
<br>_______________________________________________<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" 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" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br></blockquote></div></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>