Updating Genode's license to AGPLv3 + open-source linking clause

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth