Re: For Discussion: GNU Affero General Public License v3.0 with NonCommercial Exception

Dear Shao Kai,

I agree with Andrew's take on it, which is that in operation it is 
effectively two licenses. It is the AGPL with an additional, 
conceptually acceptable, permission, which is to be relieved of the 
obligation to provide source code for some uses. But anyone downstream 
can remove the additional permission, and it then becomes a standard 
AGPL. I don't think the fact that it discriminates in favor of a group 
in some situations means it no longer meets the OSD -- the GPL licenses 
themselves have different compliance obligations for noncommercial uses, 
in the AGPLv3 in Section 6(c).

I say it's conceptually acceptable, but a limitation tied to 
commerciality is very difficult to define and even more difficult when 
you're trying to add it to an existing license. Your terms introduce 
ambiguity because you have contradicted some of the terms of the 
AGPL. The AGPL says in Section 2 "This License explicitly affirms your 
unlimited permission to run the unmodified Program." However, you may be 
taking away some of that unlimited permission with your definition of 
"Non-Commercial Purposes" where you define it as "(b) internal 
deployment or service delivery by a legally registered 
non-profit organization, educational institution, or government agency, 
provided that such use is in furtherance of the organization's 
charitable, educational, or public-service mission as defined in its 
governing documents." Internal deployment of AGPL-licensed materials has 
no compliance obligations for anyone, commercial or non-commercial, but 
you've said it's only allowed for a "legally registered 
non-profit organization, educational institution, or government agency" 
(consistent with their non-profit mission). Should I interpret this to 
mean that a commercial company using it internally will have to provide 
the source code, even though that's not required under the AGPL?

Similarly, "Commercial Purposes" prohibit "providing the Software or any 
Derivative Work thereof as a backend component of a fee-based online 
service (including but not limited to SaaS, PaaS, API services, or 
backend engines) to third parties." A "backend" component may simply be 
running the unmodified Program, which the AGPL allows without any source 
code obligation, but your addition seems to say it will have a source 
code obligation. The section on "Commercial Purposes" is also 
problematic in another way -- I assume it's meant to be clarification of 
what is NOT Non-Commercial Purposes, but it would be better to call it 
that, rather than introducing a new defined term that is not used 
as-such in the document. You've set up two separate buckets that will 
have a gap between them, creating ambiguity.

You also prohibit " providing fee-based technical support, consulting, 
implementation, customization, or training services that involve 
modification, copying, or distribution of the Software or any Derivative 
Work, unless such services do not involve any modification, copying, or 
distribution of the Software." It would not be an infringement of 
copyright for someone to get paid to provide consulting, implementation, 
customization or training (since the AGPL allows all of those 
activities) and it's an unresolved question, discussed at length with 
respect to the SSPL, whether trying to extend rights arising from 
copyright to non-copyright areas is appropriate for open source 
licenses. The AGPL, which only has the source code obligation for 
modified code, is an example of trying to avoid overreach, so it's 
interesting that of all licenses you've added this to the AGPL.

In your section 4 "Attribution Obligation" you require a "valid URL 
pointing to the original source code repository of the Software." This 
doesn't jump out at me as an OSD problem (although it is a practical 
problem, 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2026-July/006117.html), 
but it looks to me like an AGPL problem because a url is not an 
Additional Permission that you can add under Section 7.

So conceptually you are probably ok under the OSD (except for the 
undecided question about overextension), but there are other traps you 
also have to also look out for.

Pam

Pamela S. Chestek
Chestek Legal
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
[email protected]
www.chesteklegal.com


On 8/3/2026 12:23 PM, Andrew Katz wrote:
> IMV an additional permission, even if NC limited, does not prevent the licence from being open source.
>
> A quick thought experiment: code is dual licensed under GPL and CC-BY-NC. Is it open source? Yes, clearly, because a recipient can use it (etc) under GPL. The addition of another optional licence cannot act as an additional restriction under the GPL. Of course if the code is modified and redistributed under the NC licence, that is not open source, but there’s no contradiction there.
>
> This proposal is essentially for a dual licence under an open source licence and another restrictive licence.
>
> Best
>
> Andrew
>
>
>
> Andrew Katz
> +44 7970 835001
> I'm emailing from my smartphone, so please excuse terseness!
>
>
>> On 3 Aug 2026, at 14:51, Kevin P. Fleming via License-discuss <[email protected]> wrote:
>>
>> On Mon, Aug 3, 2026, at 09:00, Stefano Maffulli wrote:
>>>> On 8/2/26 18:21, Shao Kai via License-discuss wrote:
>>>>    1. Does the non-commercial exemption as defined in the additional
>>>>       permission raise any concerns regarding OSD Section 6 (No
>>>>       Discrimination Against Fields of Endeavor)?
>>> Yes, unequivocally. It's stated in
>>> https://opensource.org/licenses/common-reasons-for-rejection-of-licenses
>>>
>>> I haven't processed the other questions.
>> 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.
>>
>> _______________________________________________
>> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.
>>
>> License-discuss mailing list
>> [email protected]
>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.
>
> License-discuss mailing list
> [email protected]
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org

_______________________________________________
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.

License-discuss mailing list
[email protected]
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org