Does the acceptance of a software licence constitute a contract? Can such a contract be closed without using said software?
<p>This question revolves around the (unresolved) question in the open source community, whether "dynamic linking" against a GPL-licensed library requires your software to be GPL-licensed, as well. I will first give some background on the GPL / copyleft, and then some technical background. Third, I give a concrete example of a program in which the problem arises. Finally, I try to formulate the actual question. Feel free to skip the first two or three sections.</p>

<p>Since jurisdiction often matters: I live in Germany, but would also be interested in how this plays out in US law.</p>

<h2>GPL / Copyleft</h2>

<p>One populare software license is the GPL ("General Public License"). The GPL is a copyleft licence, i.e., it contains the passage that any software "based on" the GPL-licensed software must also be GPL-licensed. There seems to be an agreement that this can be reformulated to "any derivative work" (although the term "derivative" does not appear in the license itself). One major open question is when exactly software A is "based on" software B (or a "derivative" of software B). </p>

<h2>Technical Background: Dynamic Linking</h2>

<p>Almost all programs we use are not written 'in one piece', but rather pull in many reusable pieces of software, so-called libraries. The way these libraries are 'pulled in' is often termed <em>linking</em>. There are two fundamentally different ways of linking: Static and dynamic linking. In static linking, the software library as a whole is copied into the program during translation from source code to an executable program. The software library is thus physically part of the binary program you distribute.</p>

<p>In dynamic linking, the binary programm instead contains a reference to the library. Think of it as a marker in the program that says "at this point in the program, execute function <code>xyz</code> from library <code>abc</code>". When you run the program, your operating system looks up library <code>abc</code>, loads it into memory, and when the main program reaches the marker, program execution jumps to the program code of function <code>xyz</code> in library <code>abc</code>.</p>

<h2>A simple, yet complete example</h2>

<p>This example constitutes a complete Python program that could be distributed as written (with a few omissions) here. Say I have a file <code>the_program.py</code> containing:</p>



<pre><code>from the_library import some_function

some_function()
</code></pre>

<p>This is a complete, runnable python program that does nothing but execute the function <code>some_function</code> from some hypothetic python library <code>the_library</code>. If I send you this (plain text) file via e-mail and you have python and <code>the_library</code> on your computer, you can run it.</p>

<p>Of course, python programs are usually not distributed via e-mail but rather via some central repository (mainly "PyPi"). To do that, I create a second file called <code>setup.py</code>, roughly containing:</p>

<pre><code>setup(
  name="my_program",
  install_requires="the_library"
)
</code></pre>

<p>I would then upload these two files (and nothing else) to such a repository. If you wanted to install my program, you would (in some automatic fashion via a packet manager) download the two files, and the <code>setup.py</code> file tells your packet manager that it also needs to download and install <code>the_library</code> for my program to work.</p>

<p><a href="https://opensource.stackexchange.com/questions/1187/what-are-the-arguments-for-considering-dynamic-links-to-constitute-derivative-wo">The Free Software Foundation (who created the GPL) and many open source advocates now argue</a> that I need to license my two files above under the GPL (assuming that <code>the_library</code> is a GPL-licensed library), since it is a "derivative" of <code>the_library</code>. </p>

<p>Note that at no point do I myself distribute any part of <code>the_library</code>. All I (resp. my code) does is include a pointer that says "you need <code>the_library</code> to run this". To spin this further: I could have written my program without ever downloading or seeing any part of <code>the_library</code> myself. That I can do that is obvious: I was able to write above code without the hypothetical library <code>the_library</code> even existing, and of course I could also upload this code to a package repository.</p>

<h1>The Question</h1>

<p>In my understanding, a software license constitutes a contract between the person providing the software and the person accepting the license to download/use the software. However, since I can build my software without ever interacting with (i.e., downloading, installing, using, …) the GPL-licensed library myself, how can I have accepted a contract with the authors of the library? If such a contract has not been closed, how can I be bound by it to license my software in any way?</p>

<h2>"But that does never really happen!"</h2>

<p>One might argue that in practice, I will never be able to write a software that dynamically links to some library without actually using that library myself to test my program, figure out how the library works, etc. Thus, in practice, I will always have accepted the license of the library while installing it.</p>

<p>However, because of this peculiarity of GPL-licensed libraries, there are replacements for some of them being developed. People try to create other (less restrictively licensed) libraries with the same interface and the same functionality, which can act as a drop-in replacement.</p>

<p>I might now develop my software with such a replacement, but still offer the user of the software the possibility to install the "original" instead of the replacement. Maybe the original is faster, or safer, or just ships with more operating systems. Thus, the case "I never interacted with the GPL-licensed code, but they still require me to abide by their terms" does in fact arise in practice.</p>

<p>In the USA, the GPL license is a license, not a contract. It allows you to do certain things that would be copyright infringement if you did them without a license, as long as you follow the license terms. You cannot be sued for breach of contract, but for copyright infringement.</p>
<p>In Germany, the GPL license is considered a contract. The US argument that a one sided contract without considerations is invalid doesn’t apply in Germany, so this is fine. It’s a strange contract because one side doesn’t require any evidence that you agreed to the contract. If a case about GPL licensed software went to court, the judge could ask you “did you accept the license” and the answer would determine whether you are accused of copyright infringement or breach of contract.</p>
<p>In the USA, you don’t “accept” the GPL license. It just tells you what things you are allowed to do under which condition, beyond what copyright law allows you to do anyway. You can be sued for copyright infringement, and the questions then are: did you do something not within the rights you have due to copyright law? If no, you are not guilty. Did the GPL license give you permission? If not, guilty. Did you follow the conditions of the GPL license? Yes, not guilty. No, guilty.</p>
<p>Due to comments: In the USA, &quot;accepting the license&quot; is like &quot;accepting a present&quot;, it doesn't give you any obligations to do something. But you can get into a situation where you have the choice between following the terms in the license and committing copyright infringement. Now Microsoft might have three lines of GPL licensed code in Word. They have the choice between publishing all of Word with a GPL license, or paying say $10,000 for copyright infringement - you can guess what they will do. If I used a huge GPL licensed library in my hobby project, I'd publish my hobby project under the GPL license to avoid getting prosecuted. I assume your company is somewhere in between.</p>

<p>There is some confusion evident in the question, which I will attempt to clear up, before moving on to an actual answer.</p>
<p><a href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html" rel="nofollow noreferrer">Version 2 of the GPL</a> does not refer to linking at all, except in a section titled &quot;How to Apply These Terms to Your New Programs&quot; - which appears <em>after</em> a very prominent &quot;END OF TERMS AND CONDITIONS&quot; header. So version 2 of the GPL does not explicitly impose any conditions on any kind of linking whatsoever.</p>
<p><a href="https://www.gnu.org/licenses/gpl-3.0.en.html" rel="nofollow noreferrer">Version 3 of the GPL</a> does refer to linking a couple of times, but the first reference to linking is in the definition of &quot;Corresponding Source&quot; and the second relates to AGPL compatibility (the third is, like in the GPLv2, not part of the license). If you are not already under the obligation to provide Corresponding Source, then GPLv3 does not explicitly say that linking creates this obligation.</p>
<p>Instead, GPLv2 and GPLv3 both say (more or less) that <em>distributing a derivative work</em> is what creates the obligation to provide source code (under the same license). It is fairly uncontroversial that static linking is this sort of distribution, because you are including a verbatim copy of the original library (in compiled form). So what you are really asking is this: <strong>Does my dynamically-linked application form a derivative work of the library to which it is linked?</strong></p>
<p>This is a difficult question, and it's not one which the license could have answered by itself. Every jurisdiction in the world has its own concept of what exactly counts as a &quot;derivative work,&quot; so it's unlikely that there is a single, universally-correct answer. To make matters worse, software has only been around for a handful of decades at this point. The law is poorly-developed and the issue has been rarely litigated. In short, nobody really knows the answer to this question.</p>
<p>Nevertheless, here are summaries of the pro and con arguments:</p>
<ul>
<li><strong>Pro:</strong> Developers who make intimate, elaborate use of a library, exchange complex data structures with it, and generally integrate it into their core application logic, cannot then claim that the application and the library are wholly independent works. The application would not work without the library, and in some cases it may derive a substantial amount of its market value from the library's capabilities. Moreover, the application incorporates the library's invariants and interfaces, even if only into the negative space of the application's function calls to the library. The application's overall structure and design is closely influenced by the structure and design of the library, and this sort of close creative influence is exactly what the derivative work right is supposed to protect.</li>
<li><strong>Con:</strong> APIs are not, or should not be, copyrightable (at least, that is <a href="https://www.fsf.org/news/fsf-statement-on-jurys-partial-verdict-in-oracle-v-google" rel="nofollow noreferrer">the stance of the FSF</a>, and they wrote the GPL in the first place). Even if APIs are copyrightable, their use is likely to be fair (under US law, see <em>Oracle v. Google</em>). The primary common element between the library and the application is an API. Other libraries could be written to the same API, and you could replace one with the other, and still have a functional application at the end of the day. Moreover, some libraries, like GNU Readline, could easily be replaced with an extremely trivial (but less useful) implementation. You could ship this implementation together with the application, and it's hard to see how that would violate copyright or the GPL (even if the user replaced your trivial implementation with the real GNU Readline after the fact - that replacement is not an act of distribution and is not prohibited by the GPL). So why should it become copyright infringement merely because you omit this trivial implementation and allow the operating system to automatically load GNU Readline instead?</li>
</ul>
<p>To some extent, these arguments are talking past one another. The &quot;pro&quot; argument assumes a library which is deeply and fundamentally integrated into the application, while the &quot;con&quot; side focuses more on incidental or secondary use of a library. It is possible that either argument might succeed under different circumstances. And of course, this all depends heavily on the specific copyright laws of individual jurisdictions.</p>
<p>Finally, we can dispense with the &quot;contract or license?&quot; question altogether, because both versions of the GPL explicitly say that they only restrict activities that would otherwise require a copyright license. If you do something which copyright law would have otherwise allowed, then you have not violated the GPL, so the GPL's status as a contract cannot create liability where none would otherwise have existed. If you do something which violates the GPL, then you necessarily violate the licensor's copyright, regardless of whether the GPL is &quot;valid&quot; or not. This might still affect the remedies that the court is willing or able to order, depending on the vagaries of copyright vs. contract law in your specific jurisdiction, but it would not affect whether or not you are liable for a GPL violation in the first place.</p>
<p><strong>TL;DR:</strong> You don't have to accept the GPL, because it only prohibits you from doing things which copyright law would otherwise prohibit anyway. Regardless of whether the GPL applies to you or not, you are prohibited from doing those things without a copyright license (which might be the GPL, or another license altogether). Whether or not dynamic linking is &quot;one of those things&quot; which you are prohibited from doing is very much an open question.</p>

licensing open-source-software gpl