7

When talking about "mere aggregation" vs "larger work", i.e. if a work under license X should be considered a separate program or a part of the larger work, GNU GPL license and its FAQ section go deep defining the difference:

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.

This basically means that if semantic of the communication between, say, backend software and a frontend software is intimate enough (see an example here) they may be considered as one larger work, and distribution of the frontend part would mean the distribution of the whole.

I've found nothing related to "mere aggregation" vs "larger work" in other copyleft licenses and their FAQs.

So I wonder if the principle described in GPL FAQ is something related to GPL-family of licenses only or it may be considered universal and can be applied to, say, MPL too?

Could it be that a privately run backend service containing Mozilla Public License dependency is considered distributed ("conveyed") to users if the frontend part is distributed and semantics of the communication between the backend and the frontend falls under "intimate enough"?

Improve this question
5
  • MPL defines "Larger Work" specifically in the first definition section, and then has a later section dedicated to the topic.
    – Brandin
    Commented Jul 26, 2021 at 9:02
  • Can you please elaborate? MPL defines "larger work" as "a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software". To me, not an English native speaker, "combine" isn't quite specific, as it doesn't specify relations between MPLed files and other separate files. Meanwhile GPL is precise about what's "modify" and "aggregation", i.e. what's a derivative work, a work based on GPL work.
    – vrs
    Commented Jul 26, 2021 at 12:38
  • 3
    I don't have time to perform a robust survey at the moment, but the core of the issue is that the GPL is a strong copyleft license: it imposes its requirements as wide as they will go, under copyright law, so the critical question is: just how far does the law allow? The MPL is a weak copyleft license that limits its copyleft requirements to only the specific files that contain MPL-licensed code, which is much less than the law would allow. Therefore the question of aggregation is relevant to strong copyleft licenses and usually not relevant to weak copyleft licenses.
    – apsillers ♦
    Commented Jul 26, 2021 at 15:14
  • @apsillers I suspect that this what MPL 2.0 FAQ's Q12 is also trying to say: MPL is concerned about MPLed files being modified, while GPL is about all the software based on the GPL
    – vrs
    Commented Jul 27, 2021 at 8:04
  • 1
    Note that this distinction would have to be made by a court of law in some case before it to be able to say if the FSF's intent/interpretation holds water. But AFAIK this hasn't happened. It looks generally correct to my non-lawyer eyes, but that doesn't mean squat.
    – vonbrand
    Commented Jul 28, 2021 at 2:32

2 Answers 2

Reset to default
3

The principle is universal, in the sense that any licence that tries to place restrictions on how you can use what copyright law defines as a derivative work will be limited by how copyright law defines derivative work, and the reach of such licences will therefore be co-extensive. The FSF FAQ admits that it uses the legal boundary when it writes "This is a legal question, which ultimately judges will decide".

In practice, such universality is of less import because most major free licences don't define their reach as the full extent of derivative works according to copyright law. Most go less far: the permissive licences are pretty laissez-faire about what you can do with derivatives, while the MPL's approach is often described as per-file copyright (as s1.10.b taken with s1.4 excludes new files, containing only newly-written code, from being "Covered Software". Some go even further, such as the SSPL, which attempts to extend its reach to your backup software and your NAGIOS box (s13).

So the concept is universal, but the GPL family are the only major family of licences (that I know of) that use it.

Improve this answer
1

No, you cannot assume that the definitions and examples that have been published in relation to GPL are universal and also applicable to other licenses. If that was the case then you would see respective wording on the webpage of these other licenses.

The answer to Q11 in the MPL 2.0 FAQ is pretty clear is pretty clear about your second question. The answer is: "No"

Improve this answer

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.