<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Great, let\u2019s talk about that goal: \u201cStronger than AGPL\u201d<div><br></div><div>I believe AGPL failed to meet its original intent. I understand the motivation on the part of the FSF folks to close the \u201cloophole" that SaaS created given that software isn\u2019t distributed in cardboard boxes with disks inside them. But when you look at much of the AGPL-licensed software (I have not done the research to know if this is the majority, or just the majority of the kinds of software I come across in my work), AGPL isn\u2019t being used as much to promote the four software freedoms, it\u2019s often used to leverage corporate users into a commercial licensing deal. Moreover, that mechanism was not as effective as the vendors wished for, which is why many opted for different licenses (Commons Clause, BSL, SSPL, etc.) that are not open source nor to they strictly promote Free Software principles. Rather they help promote the outcomes those companies wished for: to gain many users with minimal marketing, get paying customers where there\u2019s opportunity, and ward off competitors. But they appear close enough to being open source for many to be confused at the marketing, or not to care as much about the OSD as the folks here tend to.</div><div><br></div><div>Note: I\u2019m aware that Software Freedom is not fundamentally at odds with commercial outcomes. But they are different enough to realize that what is happening with dual license deals is not exactly what was intended to happen. I\u2019m also not condemning people from their desire to make money. I\u2019m trying to convey a neutral observation comparing stated intent with empirical outcomes and noting the shift. Meaning this: If I would have wanted AGPL to succeed at its original goal, I would be disappointed in the outcome of how it is used by many.</div><div><br></div><div><div>So, if "Stronger than AGPL" means to create a license so unsafe to use that corporate users would prefer the commercial alternative, then this license could be improved to meet that goal \u2014 but why? We already have license that appear to promote freedom but are more effective at encouraging commercial outcomes. I\u2019m glad for those who chose BSL, SSPL, etc. as they were clear about their intent. They don\u2019t "believe in open source," they believe in it when it aligns with their financial outcomes. I respect the honesty in that position. I do not see this license as giving them something they need or don\u2019t already have.</div><div><br></div><div>If, however, \u201cStronger than AGPL\u201d means to promote the principles of Software Freedom (per FSF) more than AGPL does, I\u2019d pause and introspect why AGPL didn\u2019t meet the goal (if you agree with me that it didn\u2019t). Then you can see if your license is really focused on fixing that part of the problem. If not, it may fail for the same reasons AGPL did.</div></div><div><br></div><div>Now, if you believe that AGPL succeeded, then this license faces a different set of problems. You may want to start with the AGPL definitions instead of creating newer ones that are inconsistent with AGPL.</div><div><br></div><div>Gil</div><div><br></div><div><br></div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Dec 3, 2025, at 11:47\u202fAM, Jay Patel <jaypatel.ani@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="auto"><div><div>Thank You Gil for feedback.You identified a critical logical loop (the 'Postman problem') that would have made compliance impossible.</div><div dir="auto"><br></div><div dir="auto">Maybe adding this address your poins:</div><div dir="auto">1. Adding a 'System Library/Standard Tool' exception: To ensure generic tools (OS, Browsers, API clients) are not infected, targeting only specific functional wrappers.</div><div dir="auto"><br></div><div dir="auto">2. Tightening 'Intimate Communication': Removing 'not limited to' and defining specific dependency types to reduce legal ambiguity.</div><div dir="auto"><br></div><div dir="auto">3. Clarifying Deployment: Explicitly exempting personal/study use, focusing 'Deployment' on organizational/commercial utility.</div><div dir="auto"><br></div><div dir="auto">My goal is 'Stronger than AGPL,' not 'Impossible to Run.' Your feedback helps bridge that gap.</div><div dir="auto"><br></div>Regards,</div><div dir="auto">Jay<br><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Dec 3, 2025, 9:52\u202fPM Gil Yehuda <<a href="mailto:tenorgil@gmail.com">tenorgil@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space"><div style="line-break:after-white-space">Jay, <div>If you intend to ask for critique, there\u2019s quite a bit \u2014 from nitpicking details to fundamental flaws. I\u2019ll list some of the apparent ones below as I read the license text.</div><div>If you intend to suggest this as a new open source license that would meet the OSD, I don\u2019t think this will do.</div><div><br></div><div>As I read the license:</div><div><ul><li>Preamble: Licenses are documents that grant rights under conditions. This text suggests that the license can guarantee freedom, indeed \u201cradical\u201d freedom (I\u2019m not sure of the difference) in software architecture (not just code?). Licenses should articulate the rights they grant and the conditions under which those rights are granted. Preambles are great to convey intent which helps when trying to interpret ambiguity; but they also reveal cases where the intent is to express a wish for how things ought to be in the world. That\u2019s better expressed in a manifesto, not a legal document.</li><li>\u201cIntimate Communication\u201d is one of my favorite terms found in software licenses since it makes people think we\u2019re also dabbling in marriage counseling. My constructive comment here is that when licenses say \u201cThis includes, but is not limited to\u201d that automatically creates a speed bump where a reader (and their lawyer) have to imagine if this includes something surprisingly not intended. It creates a very broad scope \u2014 and that\u2019s going to warn me to stay away from using code under this license because I might intent to comply only to learn that the scope was even broader than assumed.</li><li>\u201cContent Output\u201d is defined with two terms \u201chuman consumption or data storage\u201d \u2014 I understand the first to exclude non-human uses and the second to exclude the use of data that is not stored. I note this because of the next phrase...</li><li>\u201cDeployment\u201d is defined with a curious inclusion of the term \u201cinternally or externally\u201d which I assume means in the context of a corporation (not of \u201chuman consumption\u201d in the above clause \u2014 right?!) If so, then \u201cinternally\u201d suggests that if I deploy my application onto my work computer for use by my work colleagues, then the copyright license considers this to be \u201cdeployment\u2019 subject to copyright protection. I do not believe that would hold up in the current interpretation of copyright laws. </li><li>\u201cConsequently\u201d (line 40) is where this becomes quite challenging. If I create a system with code licensed under TRPL 1.0 that shares data with any proprietary software to achieve a unified functional goal \u2014 this license declares that the proprietary software becomes part of a "Combined Work\u201d that I must release its source code under the terms of this license. But what if that proprietary software is not mine to release? I might not even have the source code? Let\u2019s say I license the proprietary edition of Postman and use it to make an API call to software under TRPL 1.0 \u2014 internally (to my corporation, not in my body). I now have to acquire and release Postman\u2019s proprietary source code under the TRPL 1.0 license? How would I go about doing that? Since there\u2019s no definition of \u201crelease\u201d here, can I assume that if I deploy internally, then I can release internally too? You see that would not help promote your intent. This section of the license seems to convey how you wish software would work \u2014 but it does not clarify how I, a potential user of software licensed under this license, needs to do to make the world work that way. </li></ul><div><br></div><div>I\u2019m concerned there is little practical use of this license since any software licensed this way, no matter how appealing that software may be, is automatically going to pose a threat to the rest of my software. Given that software is subject to copyright, and that as a user of software, I seek to honor other people\u2019s copyrights, this license would make it nearly impossible to do so. I\u2019d always have to limit my use of this software to ensure I don\u2019t inadvertently infringe other people\u2019s rights.</div></div><div><br></div><div>Rather than a license, maybe we can collectively imagine what the past 40-50 years of technology would have been like had there been no copyright on source code. I imagine it would be different \u2014 better in some ways, worse in others. This license appears to invoke that imagination. But since source code is subject to copyright laws, I think the licenses should do their best to work within that context, granting rights that the grantor wishes to grant, and imposing conditions that the users of the software wish to, and can, comply with. This text falls short on the second part, at least for me. </div><div><br></div><div>Gil</div><div><br></div><div><br id="m_7648066646094320510lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Dec 3, 2025, at 12:59\u202fAM, Jay Patel <<a href="mailto:jaypatel.ani@gmail.com" target="_blank" rel="noreferrer">jaypatel.ani@gmail.com</a>> wrote:</div><br><div><div dir="auto">I am reaching out to community to collect feedback on the proposed license.<div dir="auto"><br></div><div dir="auto">Here is text of License:</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/trplfoundation/trpl-license/blob/main/LICENSE" target="_blank" rel="noreferrer">https://github.com/trplfoundation/trpl-license/blob/main/LICENSE</a></div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Jay</div><div dir="auto"><br></div></div>
_______________________________________________<br>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 <a href="http://opensource.org/" target="_blank" rel="noreferrer">opensource.org</a> email address.<br><br>License-discuss mailing list<br><a href="mailto:License-discuss@lists.opensource.org" target="_blank" rel="noreferrer">License-discuss@lists.opensource.org</a><br><a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" target="_blank" rel="noreferrer">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br></div></blockquote></div><br></div></div></div>_______________________________________________<br>
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 <a href="http://opensource.org/" rel="noreferrer noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank" rel="noreferrer">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_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. Official statements by the Open Source Initiative will be sent from an opensource.org email address.<br><br>License-discuss mailing list<br>License-discuss@lists.opensource.org<br>http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org<br></div></blockquote></div><br></div></body></html>