[License-discuss] Total Reciprocity Public License (TRPL v1.0)
Pamela Chestek
pamela.chestek at opensource.org
Wed Dec 3 21:56:24 UTC 2025
On 12/3/2025 11:40 AM, Bruce Perens via License-discuss wrote:
> OK, I dismissed the license quickly, which might leave the submitter
> in the dark. Thus:
>
> The term in question is the following:
>
> /4.1 Functional Output
> If the Program is used to generate Functional Output (e.g., a compiler
> generating binaries, a transpiler generating code, or an ML trainer
> generating Model Weights), that output is considered a derivative work
> of the Program.
> * You must license such Functional Output under this License or a
> compatible Free Software license.
> * You cannot claim exclusive proprietary rights over Functional Output
> generated by the Program./
> /
> /
> First, exclusive of the OSD, consider that for the purpose of
> enforcement this is primarily a copyright license. How would you
> assert in court that a violation of the above terms infringes
> the copyright of a compiler under those terms? The code generated by
> the compiler is entirely functional, and not itself copyrightable
> under 17 USC 102(b). Note that the license itself acknowledges that
> this is "functional". The code is a straightforward translation of the
> input to instructions that perform the exact action specified by the
> input, with perhaps trivial modification for the purpose of
> optimization. The effect of translating a program as found in CAI v.
> Altai applies, with the addition that this is a machine translation
> not expressing any creativity in the translation. A separate work is
> not created, the output still bears the copyright of the original
> work, no significant copyrightable component of the original work
> persists in the created executable.
It is not an accurate statement that "code generated by the compiler is
entirely functional, and not itself copyrightable under 17 USC 102(b)."
The Copyright Office considers source code and executable code to be two
different manifestations of the same work, a "computer program"
(Copyright Compendium § 721.5), and a computer program surely is
copyrightable. Just because it's in executable form (having been
compiled) doesn't mean it's not protected by copyright.
But that seems orthogonal to your point. Your hypo seems to be that the
compiler is under this license ("infringes the copyright of the
compiler") and the question is about the relationship of the output to
the compiler. You dismiss the possibility that some copyrightable
portions of the compiler end up in the compiled code, but I understand
that it is possible - libraries, for example. So it's at least
theoretically possible that the output could be a derivative work of the
compiler, and if so, this is a quasi-copyleft requirement (more about
that in a moment), which is acceptable for an open source license.
Now let's assume that the compiled work is not a derivative work of the
compiler. Where a work isn't actually a derivative work of the compiler,
but the license says it is, we have a significant interpretation problem
with the scope of the license. Has the license author acted as their own
lexicographer and redefined "derivative work" for the purpose of their
license, or are we to adhere to the definitive under U.S. Copyright Law,
perhaps even extraterritorially? Certainly an interpretation problem for
the license, but arguably not inconsistent with the OSD.
>
> Second, if we ignore the enforceability issues of the license for the
> purpose of analyzing the intent of its terms, the use restriction here
> is that the program can not be used to process any input intended to
> be under another license than that of the program itself. This
> obviously precludes the use of the program to produce not only
> proprietary software, but Open Source under any license other than its
> own.
I quibble with "under any license other than its own" because the
requirement is that the Output be licensed "under this License or a
compatible Free Software license." So there are other license options,
which include the availability of permissive licenses (why I called this
license quasi-copyleft). If the Output can be under a permissive
license, the Output can be used for proprietary software. So this
license doesn't discriminate based on fields of endeavor, i.e.,
commercialization.
Also, copyleft has long been accepted as complying with the OSD. So,
even if this license required any derivative work to be under this
license only, it would not be a reason it's not an open source license.
Certainly the GPLs make commercialization more challenging, but they
don't prevent it altogether, either expressly or by operation.
So the only OSD problem I see is those situations where the Output
cannot be considered a derivative work of the origin work, which I would
consider a violation of OSD9 - but maybe not even then, at least not by
the letter of OSD9, if the Output isn't software per se. But enforcing
copyleft for true derivative works is not a problem.
I want to be clear that I haven't reviewed the license in any depth, and
Jay's comments all seem quite sound as reasons why it's not yet suitable
for submission, I'm just reacting to this issue.
Pam
Pamela S. Chestek
Chestek Legal
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com
>
> This doesn't mean the license would be a bad idea, if it had legal
> solidity presently lacking. Only that the community developed around
> it should be called something other than Open Source.
>
> Thanks
>
> Bruce
>
> On Wed, Dec 3, 2025 at 10:35 AM McCoy Smith <mccoy at lexpan.law> wrote:
>
> 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
>> pamela at chesteklegal.com
>> www.chesteklegal.com <http://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 <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
>>>> <http://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 <http://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 anopensource.org <http://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 anopensource.org <http://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 <http://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
>
>
>
> --
> Bruce Perens K6BP
>
> _______________________________________________
> 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
--
Pamela S. Chestek
Former Board Member
Open Source Initiative
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20251203/934e6380/attachment-0001.htm>
More information about the License-discuss
mailing list