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.
LoadLibrary
(explicit linking) to load the dll you are making a derivative work of the library and the LGPL section 6 triggers (requiring you to release all object files).