<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Aug 3, 2026 at 4:51\u202fPM Kevin P. Fleming via License-discuss <<a href="mailto:license-discuss@lists.opensource.org">license-discuss@lists.opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Aug 3, 2026, at 09:00, Stefano Maffulli wrote:<br>
> On 8/2/26 18:21, Shao Kai via License-discuss wrote:<br>
>> 1. Does the non-commercial exemption as defined in the additional<br>
>> permission raise any concerns regarding OSD Section 6 (No<br>
>> Discrimination Against Fields of Endeavor)?<br>
><br>
> Yes, unequivocally. It's stated in <br>
> <a href="https://opensource.org/licenses/common-reasons-for-rejection-of-licenses" rel="noreferrer" target="_blank">https://opensource.org/licenses/common-reasons-for-rejection-of-licenses</a><br>
><br>
> I haven't processed the other questions. <br>
<br>
That was my additional reaction too, but I'm willing to consider that 'additional permissions' may be acceptable on a field-of-endeavor basis where 'fewer permissions' are not, as long as the baseline set of permissions would otherwise be compatible with the OSD.<br></blockquote><div><br></div><div>Giving more permissions to someone is the same as giving less permissions to someone else. The typical use of additional permissions ought to be such that they apply to all users equally.</div><div><br></div><div>Also the specific exception, both wrt the group and the obligation being exempted here, is targeting such fundamental and well understood topics, that I almost assume this is more of a fun legal crossword puzzle than an actually serious proposal. (Because it is clever, I'll admit as much.)</div><div><br></div><div>So, from an OSI point of view, it's kind of well established that treating commercial and non-commercial software differently is not possible for an open source license. There isn't much to add here.</div><div><br></div><div>But perhaps more important in this case is to understand that the proposed additional permission is invalid and ineffective: you cannot use agplv3 as a baseline for this purpose. The key is to understand that the requirement to distribute source code is not some onerous burden you can buy your way out of, rather it is a fundamental right of the *recipient* of the license. In fact, section 7 says exactly this:</div><div><br></div><div><i>" All other non-permissive additional terms are considered "further<br>restrictions" within the meaning of section 10. If the Program as you<br>received it, or any part of it, contains a notice stating that it is<br>governed by this License along with a term that is a further<br>restriction, you may remove that term."</i></div><div><br></div><div>And to be clear, the proposed "additional permission" here is actually a restriction of the rights of the recipient, so it is a "further restriction". Section 10 is about the rights of the recipient, and starts with the right to remove such additional restrictions, which leads to a situation where you have now distributed software using the standard unmodified agplv3 to a recipient which is going to exercise their right to demand from you a copy of the corresponding source.</div><div><br></div><div>So probably shouldn't recommend this idea to anyone who didn't want to publish their source code.</div><div><br></div><div>henrik</div></div></div>