What are the arguments for considering dynamic links not to constitute derivative works?

Question

The status of programs which are dynamically linked with Copyleft licensed binaries (such as a .dll) is contentious. I have created two questions for each side of the debate. The other can be found here.

Unlike the case for considering dynamic links to constitute derivative works, it's been harder to find authorities stating that they do not. But here are some statements saying that there are at least some situations where they do not.

Linus Torvalds wrote:

And don't get me wrong: I do not say that "linking" never creates derived works. I'm just saying that "linking" is just a technical step, and as such is not the answer to whether something is derived or not. Things can be derived works of each other without being linked, and they may not be derived works even if they are linked.

So "linking" basically has very little to do with "derived" per se.

Linking does have one thing that it implies: it's maybe a bit "closer" relationship between the parts than "mkisofs" implies. So there is definitely a higher correlation between "derived work" and "linking", but it's really a correlation, not a causal relationship. For example, if you link two object files together where neither is a "library" with standard interfaces, then the result is most likely a derived work from both. But it wasn't the "act of linking" that caused that to happen, but simply the fact that they were part of a bigger whole, and were meaningless apart from each other.

The University of Washington's School of Law:

The results in this example seem to be the same as above. As long as module C(S) is not considered to be a work derived from G, then it is not within the scope of the GPL. If X can distribute C(S) separately from C(G'), and the combination of C(S) and C(G') is only made by the end-user, X should be free to license C(S) under whatever terms she chooses. And the distribution scheme seems a fraction less “kludgey” than the one employed in example 2, because the step of combination (linking) occurs transparently to the user of a dynamically linked system.
...
In short, the debate over static and dynamic linking simply misses the mark. As we shall see in our next example, using inter-module communication as the basis for a derivative work analysis will lead frequently to counter-intuitive and nonsensical results.

What are the arguments in support of this position?

Answer 1

While the position of the FSF about the interpretation of the GPL is clear, a few people have opposed this position.

Linus' position that is cited in the OP is, that all combined parts must be meaningless without being part of the combination to form a derivate.

Matt Asay compares linking of software to the act of referencing a character, a scene or something similar from a novel in another novel. He claims as with linking no code is copied, it is not derivative.

Lawrence Rosen goes even farther:

The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work.

So, dynamically or even statically linked programs are in this view not always derivates.

But beware, the interpretation if linking is forming a derivative work has not yet (as far as I know) been tested in courts. GPL was topic of quite a few law-suits, but it was never about linking.

Answer 2

This pair of questions (whether dynamic linking creates a derivative or not) is really a false dichotomy.

I think Linus Torvalds is spot on when he says (quoted in the question):

So "linking" basically has very little to do with "derived" per se.

One problem with this false dichotomy it that leads to reasoning that if dynamic linking, does not create a derivative, then something that dynamically links something is not a derivative of that library. I think that pointing out that this is false reasoning is what is implied in last point in the University of Washington's School of Law text quoted by curiousdannii:

On the other hand, if plugins are launched as separate programs, then Fireplug suddenly is not a derivative work, even though this result is counter the common sense result above. Clearly, the mechanism of a given plugin architecture are analytically unhelpful and misleading in answering the derivative work question.

I.e. they are not saying that the hypothetical Firefox-derived program is not a derivative work. IMHO, they're saying that it is, but that it unhelpful to use the "mechanism of a given plugin architecture" to decide whether it is or not.

I think this false dichotomy is not helpful. I sometimes see the following argument presented:

Since X is dynamically linked, and there is no legal precedence that dynamic linking produces a derivative, we can conclude that the composite that makes use of X is not a derivative of X.

I believe this is not a valid argument. That something is dynamically linking is irrelevant to deciding whether it is a derivative of X.

Instead, we must determine how the composite uses X. If the composite can not function without X, then the composite is a derivative of X, no matter what mechanism is used to produce the composite.

There is little case law in this area (and AFAIK, none involving FLOSS licenses), but I think the 9th circuit ruling on Micro Star v. FormGen Inc. comes close. The court found that a CD-ROM with files containing fan-curated levels for a video game did create a derivative work when combined with the original game. While the court agreed that the game manufacturer (FormGen) had licensed its users to create an share such levels, the infringing company (Micro Star) has not been granted such a license. The ruling says:

Nothing indicates that FormGen granted Micro Star any written license at all; nor is there evidence of a nonexclusive oral license. The only written license FormGen conceivably granted was to players who designed their own new levels, but that license contains a significant limitation: Any new levels the players create "must be offered [to others] solely for free".
The parties dispute whether the license is binding, but it doesn't matter. If the license is valid, it clearly prohibits commercial distribution of levels; if it doesn't, FormGen hasn't granted any written licenses at all.

In this case, it is not even a matter of static or dynamic "linking". The user-curated levels are delivered on a CD in the form of files on a format that is understood by the video game. One of the things that makes these files a derivative is that these files are not usable unless they are read of the original game program. It is not the software mechanism used to create the composite that makes this a derivative work, but the fact that derivative work cannot be separated from the original and still function, that decides the outcome.

I should also make it clear that I think Lawrence Rosen of the OSI is wrong when he says:

When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.

I consider Rosen's argument as politicised, and motivated by his personal belief that open source should be about convenience, not about freedom. Rosen, along with collegue Michael Einschlag writes:

The real reason you should care about this issue [i.e. what consitutes a derivative work] is that we want to encourage as much free and open source software to be created without scaring proprietary software users away. If people believe that merely touching your open source software will infect their software with a virus, you will make your software less attractive.
(Source: http://www.rosenlaw.com/lj19.htm)

I agree with Rosen that the exact mechanism you use to make use of the library in you program (static linking, dynamic linking, etc.) does not matter.

However, I disgree with Rosen that "merely use" of said scientific subroutine library in a larger work does not result in a derivative. I think this is a lex ferenda argument. where Rosen wants the law to match OSI's agenda of making the use of free software attractive to commercial companies including permitting such companies to make use of free software in products that does not provide the community with any freedoms.

Such an interpretation of the law is IMHO wrong, and leads to undesirable situations. For instance, let's assume that the "scientific subroutine library" is made available under GPLv3, and some company use it to as part of some sort of proprietary scientific spreadsheet package. Without the functions in the GPLv3 library, the spreadsheet would not be functional. This use of the library would at least violate the intent of the author of the library, no matter how it is technically combined with other software to create the resulting composite work. (If the library author had intended to permit such uses, he/she would have picked a license that allowed incorporaton of the library in a proprietary work, such as LGPLv2.1.)

IMHO it is not the technical architecture of the composite work that is the reason composite should be considered a derivative of the GPLv3 library, but the functional integration of the two - i.e. the fact that without the GPLv3 library, the composite work (the proprietary scientific spreadsheet) would simply not work. This means that if the spreadsheet depends on the GPLv3 library, it is this functional dependency (and not the technical architecture used to combine the two) that gives grounds to say that the spreadsheet is a derivative of the GPLv3 library.

Linking is usually done because the functionality linked-in is required, so it is harder to come up with a counter-example (where something is somehow linked, but there is no functional dependency between the parts). But in a highly contrived example, one can think of a library that would replace the standard library printf with an alternative version that would redact certain words in the program's output. The original program is in no way functional dependent on the redacting version of printf - linking in the alternative library simply changes the behavior of the program. In this case, even if the library is statically linked, the resulting composite is (probably) not a derivative of it.

So to conclude: We should not always conclude that using a dynamically linked library constitutes a derivative work of said library, but the opposite conclusion (that dynamic linking does not constitute a derivative work) is equally false.

Answer 3

The page from the University of Washington's School of Law goes on to say

Typical object oriented programming languages include a standard class hierarchy. This hierarchy provides a framework within which application developers can build their programs. The standard classes typically provide useful classes that represent user interface elements (e.g. windows, buttons, etc.), collection classes (for handling collections of data), and input-output abstractions (e.g. files and networking connections). In many object oriented languages, each class must be a subclass of exactly one superclass. And for this reason, the class hierarchies are rooted by a highly generic, standard class called Object. (The question of the superclass of Object is beyond the scope of this article.) The class Object describes only the most general properties and behaviors. For instance, in Java, the class Object only performs a handful of functions. In Java, every class is a subclass (directly or indirectly) of the Object class. Under the GPL approach, then, every program written in Java is a derived work of Object, because every program written in Java by definition consists of classes that inherit from the Object class.

Such a result certainly sounds extreme. The Object class in Java is extraordinarily generic and bears little relation to many of the classes that inherit from it. To be sure, all Java classes can perform the behaviors defined by Object, precisely because they are subclasses of Object, but this does not necessarily imply that those subclasses should be considered derived works under copyright law. It would be as if an author writes an incredibly generic, one-sentence long "story" along the lines of "There are some characters who do things and stuff happens to them" and then claims that just about every novel that follows is a work derivative of his story. From a naive perspective, almost every story (perhaps with the exception of Waiting for Godot) can be considered derivative of our short story because it borrows or incorporates the same essential plotline. Obviously, though, this is not the result that we obtain under the law. Principally, the reason is that the short story would not be considered copyrightable subject matter, either because it does not meet the minimum creative threshold, or because it is already in the public domain, or because the idea of the story has merged with its expression.

As usual, the answer in this example depends on questions of copyrightability, incorporation, substantial similarity, market demand, and public policy. As a general matter, in the case of inheritance in object oriented systems, a subclass trivially incorporates (and is substantially similar) to its superclass. The analysis should then turn, to a larger degree, on questions of copyrightability of the superclass, market demand, and public policy. For example, if the class B is highly generic (as in Java's Object class), it is unlikely that it would even be considered copyrightable subject matter under the 102(b) bar. On the other hand, if B is highly specialized—as are classes that we find on the fringes or leaves of a class hierarchy—there may be a stronger argument that they contain substantial copyrightable subject matter. This argues, then, for a finding that D is a derivative of B. Even here, though, a market demand analysis might argue against a finding of derivation. Class D will not supplant demand for class B, simply because it makes no sense to deploy D in the absence of B.

I take this to mean that there is a good argument that subclassing through dynamic links can constitute derivative works, but it depends on what is being subclassed: the base Object class is too generic (and perhaps not even copyrightable), but if you subclassed a large class which represented most of the library then it would count as derived. This makes sense to me.

They address function calls in a different place, arguing that they are not derivative:

The third factor focuses on the amount of the original work used in the allegedly infringing work. Here, assuming that modern software engineering principles are followed, the amount of literal copying of code in G' is surely minimal. The relationship between S and G' is just that S makes function calls into G'. Therefore, S makes use just of the function names defined by G', and doesn't actually copy any portions of the G's program text. Finally, the market effect analysis also works in X's favor, because S does not supplant the market for G. In fact, anyone who wishes to use S has to also download a copy of G'.

Finally they give a couple of examples of plugins, concluding that the precise method of linking things is the wrong criteria for determining whether something is derivative or not:

To understand the implications of this method of boundary drawing, consider for a moment the Acrobat Reader plugin for Firefox, and assume that the browser is licensed under the GPL. The plugin offers its own set of user interface buttons and is capable of rendering file formats that are exotic to Firefox. Does this seem like a derivative work of Firefox? Whatever our intuition may tell us, the answer depends - according to the GPL's drafters at least - on the particulars of the Firefox plugin architecture. If the plugin architecture launches plugins and runs them in separate address spaces as separate, running executables, then the GPL does not consider Acrobat Reader a derived work of Firefox. On the other hand, if the plugin is dynamically linked to Firefox, then the GPL urges the opposite characterization. This seems to fly in the face of common sense, which tells us that Acrobat Reader is not a work derived from Firefox.

The following thought experiment demonstrates the absurdity of the GPL approach. Imagine taking the Firefox source code and modifying it in such a way that it is encapsulated in a plugin, called Fireplug. Common sense and the law tell us that Fireplug is a derivative work of Firefox, based simply on the fact that Fireplug incorporates all or most of the Firefox codebase. Now, when we plug Fireplug into Firefox, we essentially have a Firefox browser running within a Firefox browser. And depending on the Firefox plugin architecture, the GPL drives us to incompatible results. If plugins are dynamically linked, Fireplug is a derivative work. This is the right result, but the reasoning is exactly wrong. Fireplug is a derivative work because it incorporates and is substantially similar to Firefox, not because of a decision made by the designer of the Firefox plugin architecture. On the other hand, if plugins are launched as separate programs, then Fireplug suddenly is not a derivative work, even though this result is counter the common sense result above. Clearly, the mechanism of a given plugin architecture are analytically unhelpful and misleading in answering the derivative work question.

Answer 4

In section 0 of the GPLv2 license text the meaning of "derivative work" is clarified inside the definition of "work based on the Program":

This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

So it seems like "derivative work", in this license, is intended to mean "a work containing the Program or a portion of it". When you link dynamically to a library, your program does not contain the library or any portion of it, other than the names of some symbols. Your program may also use some data structures from the library but that might not count as containing a portion of the library.

GPLv3 does not mention the word "derivative".