importing selected (dual license) linux modules

[Thomas Doerfler]

Hi,

in the past few months, Sebastian has extended the RTEMS libbsd
infrastructure so it technically can import/export modules from/to the
Linux kernel tree.

This extension is quite delicate, because in general, the Linux kernel
sources are published under GPLv2, which is definitively incompatible
with the RTEMS license.

But there are some modules, which are dual licensed (GPLv2 or BSD
style), and for those, this extension would be useful. In fact, this
extension has been created to import (and stay in sync with) the DPAA
infrastructure for the FSL/NXP QorIQ device family.

Background (can be skipped):
----------------------------
in the past, Sebastian has created the libbsd infrastructure to import
various SW modules from FreeBSD. This allows us to use FreeBSD code for
networking, USB, WLAN and a broad range of drivers in RTEMS. The
infrastructure allows the RTEMS project to stay in sync with FreeBSD.
This means e.g. that we can harden the WLAN/WPA2 implementation against
the "KRACK" attack as soon as a patch is available for FreeBSD.

Now we have a delicate libbsd extension requirement:

RTEMS contains support for the FSL/NXP "QorIQ" device family, which has
24(!) processors integrated and currently forms the upper end of RTEMS
multicore BSPs. This chip family has a networking subsystem "DPAA" with
complex communication/routing/switching capabilities, including multiple
10GBit ethernet interfaces.

Writing a networking driver for this beast is virtually impossible due
to its complexity. Using/integrating NXPs DPAA framework is the only
feasible way to support these interfaces. The framework is published and
maintained(!) inside the linux kernel code, and it is released under a
dual (GPL or BSDish) license.
----------

Now I see four ways to deal with this linux importer:

A.) We can simply integrate it into RTEMS as an extension to libbsd.
- Technically, it adds a tool to extend the RTEMS code basis.
- But Developers, who are not so familiar with licensing issues might
easily use it to integrate pure GPLv2 code, which would be a big problem
for RTEMS users.

B.) We can reject any code (even dual licensed) that is part of the
Linux kernel.
- This would be inconsistent with other dual licensed modules which are
now also part of RTEMS.
- In the longer term it would also let the QorIQ support become obsolete
(which currently has an important function to prove the superior SMP
efficiency of RTEMS).
- Maybe this decision would even indicate that the RTEMS project is not
capable of keeping track with bleeding edge computing challenges. (I
regard this argument a bit disproportionate, but think about it anyway...)

C.) We can accept selected linux kernel code (which has a proper dual
license) but reject the linux importer mechanism.
- This would allow us to carefully integrate interesting modules and
make licensing problems less probable.
- But this would lead to potential bit rot in these imported modules, a
situation we overcame with the libbsd framework.

D.) We can accept the linux importer and selected linux kernel code, and
provide some monitoring mechanism to avoid misuse of the importer.
- This needs extra effort for the monitoring (manually of automatically)
- OTOH this would give us more flexibility.

-------------------

Any opinions on that? Any hints or ideas how we could solve the
discrepancy between flexibility requirements and legal requirements of
the project?

I would be happy to have this discussed here!

Thomas.


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.