3

I am planning to include a program covered by the GNU General Public License and a GPL-incompatible program in a collective work designed for a machine that executes programs from a cartridge containing an execute-in-place parallel ROM and an MMU. The MMU divides the memory into pages and makes only one visible to the CPU at once. One or more programs can be stored in a page. The only anticipated interaction among programs is that one can launch another: the launcher launches the program that the user chooses, and then each program launches the launcher when the user chooses to quit. My intuition is that the spirit of the GPL would treat each page as a separate "executable file". Am I right?

When a page is switched in, the CPU cannot see code or data in other pages without writing a page number to the MMU's control port. One program launches another by writing the page number and then jumping to the program's entry point, which produces semantics analogous to exec() in a POSIX system. I plan to structure the aggregate such that programs with incompatible licenses never share a page.

The GPL FAQ claims that the GPL allows distribution of on the same medium:

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.

This appears to allow inclusion of, say, both GIMP and non-free programs on the same CD.

However the GPL FAQ also states:

If the modules are included in the same executable file, they are definitely combined in one program.

Answers to Distributing an operating system DVD bundling proprietary and GNU-GPL software? imply that a DVD image is not an "executable file" in this sense, even if one can boot a virtual machine from it. But would a ROM cartridge containing independent programs in separate banks be an "executable file"? If so, where is the line drawn? Is it between a block memory (such as DVD or SD) and an XIP memory (such as parallel flash)? Is it use of a documented file-system-like data structure in order to allow executables to be extracted and replaced?

Improve this question
4
  • 1
    How do the different programs interact?
    – Martijn
    Nov 25, 2015 at 18:08
  • @Martijn Only by jumping to another program's entry point. The launcher launches other programs, and other programs launch the launcher when the user chooses to quit. In my view it's semantically the equivalent of exec(), but my concern is how GPL defines "the same executable file".
    – Damian Yerrick
    Nov 25, 2015 at 18:28
  • You could argue that you've created an unusual filesystem in the ROM cartridge, and therefore each program is a separate file. This would be an even better argument if there was a way to extract the individual program files again. (IANAL;TINLA)
    – user253751
    Jun 24, 2020 at 10:58
  • @user253751 It turns out I had in fact anticipated extraction of the program in each bank of ROM.
    – Damian Yerrick
    Jul 7, 2020 at 11:33

1 Answer 1

Reset to default
3

I'm not aware of any case law on this specific issue, but I don't think any court would find this to be a single program. The section of the FAQ you cited reads (abbridged, emphasis mine):

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 [...].

Where's the line between two separate programs, and one program with two parts? [...] 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).

[...] 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. [...]

The means of communication is the important part of when the FSF considers it a single program, and the single executable file description only seems to be a helper for file-system based operating systems.

Since you describe the means of communication between the different parts are a launcher that launches different programs that have no further internal communication, and run entirely separately, they should not be interpreted as a single program.

I don't think a either a memory page or a ROM can be considered a file at all in the context of "single executable file" as meant in the FAQ.

Improve this answer

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.