copyright creative-commons gpl copyright-transfer
Does utilizing &quot;copyleft&quot; programs like git and gcc imply that the output has to be under the same license?
<p><a href="https://opensource.org/licenses/GPL-2.0" rel="nofollow noreferrer">GPL v2.0</a> states the following as git's license:</p>

<blockquote>
  <p>b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.</p>
</blockquote>

<p>According to <a href="https://law.stackexchange.com/questions/41982/does-cc-sa-share-alike-force-me-to-provide-a-free-version-of-the-derivative">this</a>, any sort of "copyleft" license will stay with "derived" works. </p>

<p>Does this apply in the case of utilizing "copyleft" software output within closed-source/non-"free as in freedom" project? </p>

<p>My understanding is that here "derived from the program" means "created by modifying the source code of the program" and not "created by running the program". Certainly that is the way all users that I have heard of treat the matter. Note that a commercial program, such as a word processor, will be fully protected by copyright, but the maker does not claim to have any rights over documents written using it.</p>

<p>"Derived" here seems pretty clearly to mean "derivative work" in the sense in which that term is used in copyright law.  In copyright law "derived work" is a term of art with a definition specific to that field.  </p>

<p>@DavidSiegel is right, but I'd like to add:</p>
<ul>
<li><p>The whole copyleft issue hinges basically on the question whether the &quot;utilizing&quot; tightly integrates that copyleft code/program/library (with the exception of system libraries). If the project links or intimately integrates the copyleft program/library/code (think: it cannot work without that) then copyleft would kick in.</p>
</li>
<li><p>This is not the case with using a GPLed tool processes (a part of) your project and which is not further required for using the product of this processing. The <a href="https://www.gnu.org/licenses/gpl-faq.html" rel="nofollow noreferrer">GPL FAQ</a> actually answers the very question on <code>gcc</code>:</p>
</li>
</ul>
<p><a href="https://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF" rel="nofollow noreferrer">Can I use GPL-covered editors such as GNU Emacs to develop nonfree programs? Can I use GPL-covered tools such as GCC to compile them? </a></p>
<blockquote>
<p>Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.</p>
<p>[... snip: there's more there on the more complicated case of tools that copy parts of their own GPLed code into the product ...]</p>
</blockquote>
<p>There are other ways of &quot;utilizing&quot; non-free software, also covered in those FAQ, e.g.:</p>
<p><a href="https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL" rel="nofollow noreferrer">If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?</a></p>
<blockquote>
<p>When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.</p>
<p>However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.</p>
<p>Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.</p>
<p>A consequence is that if you choose to use GPLed Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.</p>
</blockquote>
