<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Dec 3, 2025 at 1:58\u202fPM Pamela Chestek <<a href="mailto:pamela.chestek@opensource.org">pamela.chestek@opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p><br>
</p>
<div>On 12/3/2025 11:40 AM, Bruce Perens via
License-discuss wrote:<br>
</div>
<p>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. </p></div></blockquote><div>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 <i>contrive</i> 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.</div><div><br></div><div>In contrast, use of a library is a straightforward combination of works, and would not require the terms in question about functional production.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>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</p></div></blockquote><div>The author, like most programmers worldwide and many who approach license-discuss,</div><div><br></div><div>* Is unaware of the functional vs. expressive dichotomy and thus believes that copyright has equal force over the entire text of their program.</div><div>* And believes the court has infinite jurisdiction, for example over sovereign powers.</div><div>* Believes the court will compel most anything at all in the name of curing an infringement.</div><div><br></div><div>> 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."</div><div><br></div><div>He didn't define compatible, and we have a spectrum of such definitions - consider FSF's declaration that GPL2 and Apache 2 are incompatible.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>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.</p></div></blockquote><div>But this is not a derivative work issue. It's simply an issue of a work processed by another work.</div><div><br></div><div> Thanks</div><div><br></div><div> Bruce</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p><br></p></blockquote></div></div>