Re: Total Reciprocity Public License (TRPL v1.0)
McCoy Smith <[email protected]> Wed, 3 Dec 2025 10:34:05 -0800
| Newsgroups | gmane.comp.licenses.open-source.general |
|---|---|
| Message-ID | <[email protected]> |
I agree with this sentiment. If you're going to claim something is a "use restriction" I think you need to: 1) explain how that is an OSD violation (FWIW the OSD doesn't prohibit "use restrictions" OSDs 5 & 6 prohibit "discrimination" OSD 9 prohibits restrictions "on other software" and OSD 8 prohibits specificity as to specific products); 2) explain which language in the license is problematic, and why. "Functional output" in this license is addressed in 4.1, and I'm not seeing how those requirements are "restrictions" or "discrimination." I do find the definition and obligations around "Deployment" problematic because I believe Freedom Zero is an inherent part of the OSD, although I'm not sure that it's something that flows from the explicit language from the OSD. This license appears to be Freedom Zero violating. [all the above is personal opinions not representative of the OSI board] On 12/3/2025 10:22 AM, Pamela Chestek wrote: > How so? It's easy to say that any limitation is a use restriction - > saying that one has to include a copy of the license discriminates > against those who don't want to. So can you elaborate how this > restriction on output discriminates against a field of endeavor or a > person or group? > > 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 > > Set a meeting with me <https://calendly.com/pamela-chesteklegal/30min> > On 12/3/2025 8:41 AM, Bruce Perens via License-discuss wrote: >> The functional output restrictionn would keep it from being an Open >> Source license. It's pretty clearly a use restriction. >> >> Bruce Perens K6BP >> >> On Wed, Dec 3, 2025, 08:23 Gil Yehuda <[email protected]> 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 <[email protected]> >>> 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 <http://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 <http://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 _______________________________________________ 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