22

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
    Commented Apr 18, 2023 at 8:29

4 Answers 4

Reset to default
15

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
  • 5
    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
    Commented Nov 26, 2019 at 20:32
5

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
    Commented 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
    Commented 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
    Commented 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
    Commented 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
    Commented Dec 1, 2021 at 0:26
1

The act of loading a program which dynamically links a library would generally produce an generally-ephemeral work derived from that library. If one were to take a memory snapshoot of the running program, that would generally be a derivative work of the library; if the library were received under a GPL license, someone distributing the memory image would likely be required to distribute everything that went into producing it, along with anything the licenses for that material would be required to distribute with it.

The GPL, however, expressly authorizes the production of derivative works that are not distributed. The fact that loading a program in a context where it can dynamically load a GPL library would create a derived work in memory does not imply that the program on disk (excluding the library) would be a derivative of the GPL work, since no copyrightable aspect of the GPL code would be employed in the production of the program on disk (again, excluding the library).

It's unclear whether and in what cases a cryptographic hash may be considered a derived work of something else. If a closed-source program would refuse to run with any library whose cryptographic hash didn't match what would be generated when using unmodified GPL source with a particular compiler, the presence of the hash check within the closed-source program might be viewed as making it a derivative work of the GPL source, but a document with the closed-source program which merely stated what the hash should be would probably not create any issue (even if the document itself were viewed as a derivative work, any source-distribution requirements associated with it could be satisfied by bundling the source code for the GPL library and the program used to compute the hash).

Improve this answer
0

When it comes to GPLv3, it is explicitly defined in the license text, as seen in the bolded part of the quoted text below.

From Section 0 of GPLv3:

“The Program” refers to any copyrightable work licensed under this License. .....

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.

And from Section 1 of GPLv3:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

It may have been better for it to say 'The “Corresponding Source” for a covered work in object code form ...' i.e. to add "covered".

Improve this answer
1
  • Simply asserting it isn't the same as making an argument... Hence this question, cause not all of us are convinced by what GNU say.
    – curiousdannii
    Commented Sep 12 at 9:08

Your Answer

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

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