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"?

  • MPL defines "Larger Work" specifically in the first definition section, and then has a later section dedicated to the topic.
    – Brandin
    Jul 26 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
    Jul 26 at 12:38
  • 2
    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
    Jul 26 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
    Jul 27 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
    Jul 28 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.