Hello Jookia,
The AGPLv3 also talks about use of the software over a network service, and I imagine with the focus on IPC and proxying it might be better to clarify this usage too as a combined work. Unless all this doesn't apply to IPC?
Admittedly, I don't completely understand the question. Neither AGPLv3 nor our linking exception mention IPC. The use of IPC is unrelated to licensing.
Let me still try to comment on it: If a custom component uses Genode's IPC mechanism, it is naturally linked against Genode's base libraries and uses Genode's API headers (otherwise, it could not invoke the IPC in the first place). Consequently, when distributing the binary of such a component to a user or providing the component's functionality as a web service to a user, the AGPLv3 requires one to also provide the source code of Genode and the custom source code. Thanks to our exception clause, the latter does not need to be licensed under AGPLv3 (the custom code is not "infected" by the Genode's license). Any "approved" open-source license is fine.
With Genode becoming AGPLv3, we face the question of how to integrate 3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode component. To address this concern, Genode-specific glue code that is needed to integrate the 3rd-party code with the Genode API ("system library") will have a license that is compatible with both the license of the 3rd-party code and Genode's AGPLv3 as such glue code is a derivative of both Genode and the incorporated code, e.g., the MIT license. In line with the wording of the exception clause above, when distributing binaries of such components, the licenses of both Genode and the incorporated 3rd-party code must be respected.
This sounds a bit sketch. Could you elaborate more on how this works?
First, let me point you to the excellent FAQ at gnu.org:
https://www.gnu.org/licenses/gpl-faq.html
I will try to explain the situation with own words and examples. In the following, assume that we want to combine a GPLv2 driver into a Genode component. We also can - for this discussion - regard AGPLv3 as the same as GPLv3.
"Combining" can have different forms that must be distinguished:
* Both licenses (GPLv2 and GPLv3) are known to be mutually incompatible with each other. This means, one is not allowed to copy GPLv2 code snippets into an GPLv3-licensed source code or vice versa. This practice would ultimately "re-license" the code snippet. This is a no-go.
* In practice, 3rd-party code is most often used as an "independent module". For example, when combining a Linux device driver with Genode, the Linux device driver is definitely not a derivate from Genode. Vice versa, Genode is clearly not a derivate of the Linux device driver. Both were developed independent from each other.
In the latter situation, both parts can in principle be combined. But as the resulting binary contains both the Linux driver code and Genode, the licensing terms of both licenses apply. That means, when distributing a binary, one has to provide all the source code that is needed to reproduce the binary from source. This includes the Genode source code and the source code of the Linux driver. In addition, the GPLv3 also requires one to provide the user with the ability to actually use the reproduced binary (look for "tivoization"). In short, it is possible to combine independent modules as long as the license of each individual module is respected.
In practice, when combining such independent modules, some form of glue code is needed to interface both parts. This glue code is typically quite simple, as small as possible, and - in contrast to the glued-together parts - not of great general value. It is ultimately "tainted" by the interfaces of both modules. Hence, the question of license "compatibility" (the first point above) enters the picture.
To go out of the way of possible compatibility concerns, it is a good practice to use a liberal license for such glue code whenever possible. However, this ultimately is a case-by-case decision. For example, consider the Linux device-driver example above. If it is infeasible to craft the glue code without copying some functions and data structures from the Linux kernel code into the glue code, the glue code will naturally inherit Linux' GPLv2 license. But in another situation where clean interfaces exist and the glue code is written completely from scratch, it is reasonable to use a liberal license for the glue code rather than a strict copyleft license like GPLv3. This allows other (non-GPLv3) projects to reuse parts of the glue code, and it avoids any friction when contributing generally useful parts of the glue code to the upstream project.
Could I help to dissolve the "sketchiness" you observed?
Cheers Norman