18

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.

The FSF believes that dynamic links almost always constitute derivative works. The GNP GPL FAQ states explains their position:

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work?

No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

What is the difference between an “aggregate” and other kinds of “modified versions”?

An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

From the last question I gather that the ultimate factor on whether they consider a 'link' to be derivative is whether the link means that the programmes share a memory address space. Pipes and sockets are fine, but no .dll or .so files. (Personally this seems like an odd criteria to me. It's my understanding that .dlls which directly access each other's memory are rather uncommon.)

What are the arguments in support of this position?

Improve this question
1
  • This question makes the false claim that the FSF contends that dynamic linking creates derivative works. That is not the FSF's position. And you'll notice that the excerpt that supposedly shows that this is the FSF's position does not contain the word "derivative" anywhere in it. A "derivative work" is a very specific legal term that is completely different from a "combined work".
    – David Schwartz
    Apr 18 at 8:29

2 Answers 2

Reset to default
11

Well, it basically boils down to what is understood as a derivate.

A program that dynamically links a library is a derivate in this point of view, because it as a whole delivers the product function to the user. If you remove the library it stops working. A similar situation with plugins that are dynamically loaded and linked - without the original program they aren't working. So the working program/plugin is a derivative work, as for it's completeness is the linked part needed. Without it it's incomplete.

Many open source authors accept this point of view. There are many reasons for it. First of all, it is the interpretation of the FSF, the authors of the license. So many simply accept that interpretations, as this was the intent. Similarly it is out of respect for the developers of software under the GPL. As these authors chose the GPL, they may have been considered this usage, so out of respect many don't challenge this claim, as it is clear what the developers wished who released their software under the terms of the GPL.

One major example of a supporter of this interpretation of the GPL is Debian. As the cdrtools-author Jörg Schilling switched the license of parts of the code to the CDDL, Debian claimed this a violation of the GPL and started the fork cdrkit. A similar case happened with KDE, which used the library Qt which was back at that point not GPL-licensed. Debian saw that as a violation of the GPL and removed KDE from the distribution. In both cases there would be no violation if linking wouldn't create a derivative work, so Debian clearly seems to be the opinion it does so.

But, as far as I know at least, there was no law-suit so far that tested that assumption. The GPL was used in law-suits, but never about the linking problem

Improve this answer
1
  • 3
    If one has two blobs of bits that were compiled and built independently, and a program which loads them into memory in a fashion that allows them to interact usefully, the act of running that latter program may create an ephemeral derivative work of both programs, but unless one produces and distributes a memory dump of the system, that derivative work would never be distributed.
    – supercat
    Nov 26, 2019 at 20:32
4

Related: CeCILL is a license developed to be a GPL equivalent, compatible with GPL and French law.

CeCILL is the first license defining the principles of use and dissemination of Free Software in conformance with French law, following the principles of the GNU GPL.

The interesting moment is how they are defining "contributions":

Module: means a set of sources files including their documentation that enables supplementary functions or services in addition to those offered by the Software.

Internal Module: means any or all Module, connected to the Software so that they both execute in the same address space.

External Module: means any or all Modules, not derived from the Software, so that this Module and the Software run in separate address spaces, with one calling the other when they are run.

Contribution: means any or all modifications, corrections, translations, adaptations and/or new functions integrated into the Software by any or all Contributors, as well as any or all Internal Modules.

[...]

5.3.2 DISTRIBUTION OF MODIFIED SOFTWARE

When the Licensee makes a Contribution to the Software, the terms and conditions for the distribution of the resulting Modified Software become subject to all the provisions of this Agreement.

In other words, when CeCILL authors were adapting GPL for the French law, their choice was to explicitly state that if some code is running in the same address space, it is considered to be a contribution and creates modified software, which should be distributed under compatible license.

Improve this answer
5
  • But why should being run in the same address space matter? What's the relevance of address spaces to whether something is derived from something else?
    – curiousdannii
    Jul 7, 2020 at 12:53
  • AFAIK, GPL authors wanted any linking to a GPL library to be treated as derived work (see GPL FAQ). But the license text doesn't use words like "linking" explicitly. And many people think that static linking creates a derived work, but shared linking doesn't (because the result doesn't "contain" original work). I don't know if it's true, but it's a common opinion, contradicting the original authors' intentions. So, in my understanding, CeCILL is an attempt to fix this and explicitly state that any linking creates a derived work. They do it by introducing a formal address space terminology.
    – gavv
    Jul 7, 2020 at 15:26
  • 2
    So the end goal of the license is just to say, in formal language: if you're using our library in any way (no matter of linking type), your code should be open-source. This fits with the original goals of RMS, AFAIK.
    – gavv
    Jul 7, 2020 at 15:29
  • Thanks, that makes sense from the FSF's ideological perspective, though it doesn't seem very legally rigorous.
    – curiousdannii
    Jul 7, 2020 at 15:30
  • If a blob of bits is designed to be loaded together with a compiled piece of open-source software, but does not contain any copyrightable material from that open-source software, the authors of the open-source software have zero legal authority over how that blob of bits is distributed. Unless the open-source license restricts the production of derivative works even if they are not distributed I see no basis for prohibiting dynamic linking with code that doesn't contain any copyrightable open-source material.
    – supercat
    Dec 1, 2021 at 0:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.