Licenses for servers in a microkernel design

[rod]

If I have a microkernel that offloads most tasks to servers running in user mode, could that servers be licensed independently?

I mean, e.g., could I use code from the Linux kernel for the ext2 server that translates partitions to filesystems, modify it, state modifications and license the resulting code in my project under GLP2 (as the Linux kernel is licensed), and, e.g., grab some other code for some other server with some other license and modify it for adapting to the InterProcess Communication mechanism of my kernel and then store also in my project with its respective license?

Also, would it be the same if a server runs in privileged mode (ring<3)?

[dozniak]

If I have a microkernel that offloads most tasks to servers running in user mode, could that servers be licensed independently?

Yes, they are not part of the kernel and not linked with the kernel.

Depending on your implementation they could be libraries or full processes. If they are libraries things are more complicated (see GPL vs LGPL), but if they are standalone processes they can be licensed completely independently.

It doesn't matter in which privilege level they run.

[Boris]

Hi,
You will have to license your modifications in GPL.
Double check for AGPL which is viral not at binary links but at API links.
The main exemple i have in head is ghostscript, which is AGPL but which requires you to pur AGPL any code that uses it even using remote APIS like cups

[simeonz]

If I have a microkernel that offloads most tasks to servers running in user mode, could that servers be licensed independently?

This is a thorny question. You need to seek professional legal help if you decide to distribute. Still, although GPL is a very broadly worded license, and also I am not a lawyer, the answer I think is ultimately no, you should not.

To my understanding, the one key notion in the license is that of derivative work. Inter-process communication or anything technical like that are not important factors. Derivative work means that the value and/or function of your software rests to some extent on another piece of software. In contrast, if it provides some well defined service without resting on GPL code, it is not derived and thus free to choose another license. Functionally independent (my term here) does not imply that it never interacts with GPL software in any way, but rather that it does not do so as primary means to provide its function and that the service provided is well defined separately. For example, creating a VM offering is ok, even though the user may opt to host a GPL OS inside it. Creating a VM specifically for a GPL OS, e.g. based on some hypervisor interface specification, may be dangerous, but could be ok too. It is a grey area, because such VM depends on the GPL software's existence to be functional, but in operation it does not evoke GPL support as such, at least not to provide the advertised service to the user. If your software is not functionally independent or purposefully derives its core value from GPL software, you have to license it GPL.

A legal exception to this is conformance. If your product rests on a software ecosystem implemented in GPL and conforms to interface specification particular to that execution environment, then it is not required to license as GPL. To my understanding, this does not need to be expressed in the wording of the license. It applies as a general legal principle. A license cannot limit conformance. However, it is still not advisable to distribute software in compilations that include the ecosystem in a bundle, because it might be construed as profiting (monetarily or otherwise) on the value of the GPL software, not on the added value of your own product.

Another grey area is a product that makes certain features available through pluggable modules, whose license can be either non-GPL or GPL. In other words, software whose core rests heavily on supporting functionality in unspecified license, but which is deliberately engineered in a manner that enables it to derive distinctive benefits by aggregating particular pre-existing GPL solutions underneath it. This opens up a can of worms, where bridges/shims and other mediating means delineate the software core and the supporting components in expressly abstract manner, such that the necessary functions may be provided independently. One way to secure some legal credibility is to implement at least one version of the pluggable module in non-GPL, even if that version has stripped bare bones value in it. Also, the manner of distribution and the build environment become relevant. Optimally, the user should be the one to acquire and build the GPL components, even if aided by some automating process that is shipped with the core product. Very grey area, morally dubious, and legally dangerous. But this is probably technically closest to your idea as it stands right now. Sometimes this is done in reverse, by making the core a pluggable module and the communication mechanism open-source, etc.

In a nutshell, my view is that GPL (and licenses in general) are rants with legal consequences. You can't hope to interpret them, but to evaluate the risks, and to back off in time. In your case, I wouldn't take the odds.

[rod]

If I have a microkernel that offloads most tasks to servers running in user mode, could that servers be licensed independently?

This is a thorny question. You need to seek professional legal help if you decide to distribute. Still, although GPL is a very broadly worded license, and also I am not a lawyer, the answer I think is ultimately no, you should not.

(...)

In a nutshell, my view is that GPL (and licenses in general) are rants with legal consequences. You can't hope to interpret them, but to evaluate the risks, and to back off in time. In your case, I wouldn't take the odds.

Licenses seem a scary thing. Contradictory opinions arise. I've found this link:

https://en.wikipedia.org/wiki/License_c ... ined_works

--------
For combined works with "strong copyleft" modules, a stronger isolation is required. This can be achieved by separating the programs by an own process and allowing communication only via binary ABIs or other indirect means.[6] Examples are Android's kernel space-to-user space separation via Bionic, or Linux distros which have proprietary binary blobs included despite having a strong copyleft kernel.[4][11]
--------

Which maybe would mean that Inter Process Communication could be sufficient to isolate, e.g., a MIT kernel and some GPL (and with other licenses) drivers/servers in their own processes and address spaces.
But I can't be sure. Maybe I will have to leave aside GPL code and use only permisively licensed code in my project, if any.

[simeonz]

or Linux distros which have proprietary binary blobs included despite having a strong copyleft kernel.

There are indeed companies like Nvidia and Amd with their kernel shims. The reason why this is tentatively tolerated for the time being is because it serves the user base. Second, officially endorsed solutions like FUSE do the same thing for file systems. And finally, and most importantly, the essence of those drivers is not derivative, but rather conforming. Nvidia and Amd are merely taking precautions against idiosyncratic legal eventualities, but they are not really breaching GPL in spirit. Even so, they get a lot of backlash for this. (Whether or not the existence of proprietary drivers is good for the stability of the Linux kernel is another topic, but it has nothing to do with GPL.)

In my opinion, you cannot benefit from this example. Deriving specific functionality from software and then merely using IPC for isolation is still failure to comply with the GPL conditions. In practice, such violations exist and are tolerated, especially when there is no monetary incentive or no major impact, but I am being pedantic to be on the safe side.

A more defensible solution might be to have compatibility layer for linux modules. That is, to provide the API and host linux kernel blobs in system processes, patching the blob code at load time as needed. Then you can provide a self sufficient bare bones OS and a procedure for migrating drivers. I understand that this is overkill, but thought I should mention it.

[rod]

So another option would be to license my project under the GPL, and then I could include almost any code?
How would I integrate the code from other sources? Would I have to put a license header for imported files that didn't have it? And what happens if I modify them?

[dozniak]

So another option would be to license my project under the GPL, and then I could include almost any code?
How would I integrate the code from other sources? Would I have to put a license header for imported files that didn't have it? And what happens if I modify them?

Once again, I believe you missed my first reply.

In the case of microkernel design with standalone servers it does not matter what the license of some of the servers is. They are independent entities and can be licensed completely independently.

[rod]

So another option would be to license my project under the GPL, and then I could include almost any code?
How would I integrate the code from other sources? Would I have to put a license header for imported files that didn't have it? And what happens if I modify them?

Once again, I believe you missed my first reply.

In the case of microkernel design with standalone servers it does not matter what the license of some of the servers is. They are independent entities and can be licensed completely independently.

Ok, thanks. It sounds reasonable.
As different people say different things, I didn't know whom to observe.

[dozniak]

So another option would be to license my project under the GPL, and then I could include almost any code?
How would I integrate the code from other sources? Would I have to put a license header for imported files that didn't have it? And what happens if I modify them?

Once again, I believe you missed my first reply.

In the case of microkernel design with standalone servers it does not matter what the license of some of the servers is. They are independent entities and can be licensed completely independently.

Ok, thanks. It sounds reasonable.
As different people say different things, I didn't know whom to observe.

You may have some servers under GPL, some under MIT, some commercially-licensed and they should work fine as long as they are not _linked_ together into a single blob. As long as they are separate processes that communicate through well defined interfaces you should be good to go.

Take a look at this quick license summary site - https://tldrlegal.com/license/gnu-gener ... license-v2 it could help to see the limits of different licenses (i linked GPLv2 as an example).