[License-discuss] Total Reciprocity Public License (TRPL v1.0)

Wed Dec 3 16:47:49 UTC 2025

Thank You Gil for feedback.You identified a critical logical loop (the
'Postman problem') that would have made compliance impossible.

Maybe adding this address your poins:
1. Adding a 'System Library/Standard Tool' exception: To ensure generic
tools (OS, Browsers, API clients) are not infected, targeting only specific
functional wrappers.

2. Tightening 'Intimate Communication': Removing 'not limited to' and
defining specific dependency types to reduce legal ambiguity.

3. Clarifying Deployment: Explicitly exempting personal/study use, focusing
'Deployment' on organizational/commercial utility.

My goal is 'Stronger than AGPL,' not 'Impossible to Run.' Your feedback
helps bridge that gap.

Regards,
Jay

On Wed, Dec 3, 2025, 9:52 PM Gil Yehuda <tenorgil at gmail.com> wrote:

> Jay,
> If you intend to ask for critique, there’s quite a bit — from nitpicking
> details to fundamental flaws. I’ll list some of the apparent ones below as
> I read the license text.
> If you intend to suggest this as a new open source license that would meet
> the OSD, I don’t think this will do.
>
> As I read the license:
>
>    - Preamble: Licenses are documents that grant rights under conditions.
>    This text suggests that the license can guarantee freedom, indeed “radical”
>    freedom (I’m 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’s better expressed in a manifesto, not a legal document.
>    - “Intimate Communication” is one of my favorite terms found in
>    software licenses since it makes people think we’re also dabbling in
>    marriage counseling. My constructive comment here is that when licenses say
>    “This includes, but is not limited to” 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 — and
>    that’s 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.
>    - “Content Output” is defined with two terms “human consumption or
>    data storage” — 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...
>    - “Deployment” is defined with a curious inclusion of the term
>    “internally or externally” which I assume means in the context of a
>    corporation (not of “human consumption” in the above clause — right?!) If
>    so, then “internally” 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 “deployment’ subject to copyright protection. I do not
>    believe that would hold up in the current interpretation of copyright laws.
>    - “Consequently” (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 — this
>    license declares that the proprietary software becomes part of a "Combined
>    Work” 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’s say I license the proprietary edition of
>    Postman and use it to make an API call to software under TRPL 1.0 —
>    internally (to my corporation, not in my body). I now have to acquire and
>    release Postman’s proprietary source code under the TRPL 1.0 license? How
>    would I go about doing that? Since there’s no definition of “release” 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 — 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.
>
>
> I’m 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’s copyrights, this license would make it nearly
> impossible to do so. I’d always have to limit my use of this software to
> ensure I don’t inadvertently infringe other people’s rights.
>
> 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 — 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.
>
> Gil
>
>
>
> On Dec 3, 2025, at 12:59 AM, Jay Patel <jaypatel.ani at gmail.com> wrote:
>
> I am reaching out to community to collect feedback on the proposed license.
>
> Here is text of License:
>
> https://github.com/trplfoundation/trpl-license/blob/main/LICENSE
>
> Thanks,
>
> Jay
>
> _______________________________________________
> 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
> License-discuss at lists.opensource.org
>
> 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
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20251203/cdfb88fc/attachment-0001.htm>