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

[Bruce Perens]

On Wed, Dec 3, 2025 at 1:58 PM Pamela Chestek <pamela.chestek at opensource.org>
wrote:

>
> On 12/3/2025 11:40 AM, Bruce Perens via License-discuss wrote:
>
> 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.
>
My point is about the functional vs. expressive nature of code generated by
the compiler.  That code is purely functional, small fragments intended to
execute a very well-defined function at the command of source code defining
the function. The code generated would be a translation of the input and
under the same copyright and terms as the input. The compiler author could
*contrive* for the compiler to embed more significant portions of itself in
the program in order to induce a tort, but such deliberate contrivances are
meat for expert testimony, IMO unlikely to sway a court, and could perhaps
backfire on the compiler author as assisting, encouraging, or securing the
tort, etc.

In contrast, use of a library is a straightforward combination of works,
and would not require the terms in question about functional production.

> 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
>
The author, like most programmers worldwide and many who approach
license-discuss,

* Is unaware of the functional vs. expressive dichotomy and thus believes
that copyright has equal force over the entire text of their program.
* And believes the court has infinite jurisdiction, for example over
sovereign powers.
* Believes the court will compel most anything at all in the name of curing
an infringement.

> 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."

He didn't define compatible, and we have a spectrum of such definitions -
consider FSF's declaration that GPL2 and Apache 2 are incompatible.

> 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.
>
But this is not a derivative work issue. It's simply an issue of a work
processed by another work.

    Thanks

    Bruce

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20251203/f1669b84/attachment.htm>