aros and the gpl

Ahh software licensing, a topic I try really hard to avoid. mausle raised a concern with my previous post about ripping code from the Linux kernel for use with AROS:

… you can’t just rip code under GPL license out of the linux kernel tree and link it with AROS code. I know there might be a grey zone with modules already loaded by grub.

Its a comment that needs addressing in more depth than a simple reply will allow, so here we go: my position on GPL code in AROS.

Obvious disclaimer: I’m not a lawyer, and have no access to one. I can make some guesses based on my own reading of licenses and precedent in other software projects. Of course, if the FSF or whoever want to tell me I’m wrong, I’m happy to listen.

First, lets deal with an obvious case. Distribution of GPL’d source code alongside other source code with incompatible licenses is no problem. The GPL only has issues with otherly-licensed software when it comes to linking with them and distributing the result.

And now the gritty bit. The way the GPL places requirements on other software is entirely based on the mechanism by which the pieces of software are combined and interact. The GPL itself is vague on this, but the FSF have a FAQ item in which they acknowledge this grey area and provide their perspective on it:

What constitutes combining two parts into one program? 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.

In many ways this description is tied to Unix-like systems, which makes sense as that is the context in which the GPL was originally developed. Its reasonable that these guidelines are not in the license itself, but since these aspects have never been tested in court all we have to work with is what the original authors were thinking.

In another FAQ item on plugins, we get more relevant detail:

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 the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

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.

So now we need to look at how software running on AROS is combined.

Lets break these descriptions down from an AROS point of view:

• AROS modules are either executable programs, communicating via message ports, or libraries of code which are accessed via a vector table.
• Dynamic linking usually means loading two or modules into memory and then updating pointers within them to arrange for them to directly call into and access each other. AROS modules do not do this; library calls are instead done via function pointers held in a vector table attached to the library, which is fetched via a call to OpenLibrary().
• If modules (usually executable programs) communicate via message ports, then those message ports are accessed from known locations, and data is sent in a format defined in the OS headers.
• For all practical purposes, AROS modules exist within the same address space - we have no memory protection. Messages passed between ports are merely pointers to some area of memory.
• Packet-style filesystems are executable programs, invoked via the equivalent of fork-and-exec.

From this it seems to me that AROS modules that exist standalone (ie loaded from disk) aren’t really linked with the OS core itself, and thus can’t be considered as part of the same program.

There’s a small spanner though when it comes to filesystems: how the filesystem driver is loaded if no filesystem is up and running yet. I think these can be argued around with only one grey area. Lets use a hypothetical GPL ext2 driver as an example.

In the simplest case (license-wise), the AROS boot partition is AFS or something else that is included in the boot image, and you want to have a seperate ext2 partition mounted. The driver would simply be loaded from the AFS partition (say DEVS:ext.handler) and the filesystem mounted that way.

If you wanted to boot from an ext2 partition, then we have two options: including the driver in the boot image, or including it in a seperate module set to be loaded by GRUB.

Background, for the unitiated: GRUB has the ability to load one or more files from any filesystem that it has a driver for and place them in memory somewhere for the kernel to find when it starts. AROS on x86_64 uses this already, with the “core” boot image only including Exec, DOS and a few other absolute necessities and the rest coming from the module set.

These modules are loaded from disk and aren’t included in the main boot image. The kernel has to go to a little extra effort to find and use them, so they clearly aren’t a dynamic link. I’d argue that there’s no grey area: the modules are standalone programs.

As for including the filesystem in the core boot image, that I’ll concede as a grey area. However, one could argue that since there’s still no linking in between the modules included (the kernel searches through memory for the ROMTag structures at the start of each mdoule), the boot image is actually some kind of archive format (perhaps a self-extracting archive) and therefore still not linked. I think I’d lose that argument, and I won’t contest it, but I still find it to be an interesting angle. The point is moot however: as time goes on we’ll find x86, hosted and every other platform port of AROS moving the the x86_64 model with a minimal loader and startup image and then rest of the modules (including filesystems) pulled in from disk, whether that be by GRUB or some other mechanism.

So hopefully I’ve made some kind of argument there. No doubt plenty of people will disagree with me. Good - this is the time to sort this out before I start writing code :P