Re: Total Reciprocity Public License (TRPL v1.0)

On Wed, Dec 3, 2025 at 1:58 PM Pamela Chestek <[email protected]>
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

>
>

_______________________________________________
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