importing selected (dual license) linux modules

[Chris Johns]

On 27/10/2017 22:07, Sebastian Huber wrote:
> 
> what is now the consensus?
> 
> 1. We keep the Linux submodule and the scripting support private to EB.
> 

I think this is best solution for the project. Transparent source integration
like we have for FreeBSD is the best technical solution however I think we need
to fall back to a more cautious solution for large and complex repos where a
large majority of the code is GPL. We can have FreeBSD as a module in our repo
because the FreeBSD project is doing the auditing and compliance work for us.

I am sure we can develop and maintain the infrastructure on our side to support
private repos that may have the Linux kernel as a submodule. We just need to
teach the maintenance scripts how to look for git submodules and reference them
where needed.

> 2. We rename the "linux" directory into "linux-dual-license" to emphasize that
> this directory contains dual licensed code imported from Linux.

It is not clear to me yet what the best solution is here. My initial concern is
a top level directory called `linux` in a library call `libBSD`, ie a BSD code
base. A drop by visitor reviewing RTEMS may think we include Linux GPL code and
we do not. How valid this concern is is difficult to quantify and it may be
nothing more than me be overly sensitive. As you know Linux is currently the go
to kernel for hardware vendors wanting to have open source drivers and dual
licensing is welcomed because it allows us to use those drivers. This may mean
more imports and more mapping code for the Linux APIs.

My preferred option is to have drivers ported to FreeBSD and merged into the
upstream kernel sources. I encourage we offer this as the preferred path where
possible. I also understand for the drivers just merged the scale and complexity
prohibits that code being converted to FreeBSD and merged into the upstream kernel.

I have suggested `bsps` as a name but it is not a great fit. The reason behind
the name is to say this code is BSP specific. Up to now we have had drivers
coming in from the FreeBSD kernel tree and we have a requirement for transparent
importing not to move the location. Where would we place a driver we write that
is not viable to merge into the upstream FreeBSD sources? The driver would be a
FreeBSD driver but not suitable for the imported kernel tree and it is not
Linux? Do we have 'drivers/linix' etc?

> 3. All commits referencing "linux-dual-license" go to review to devel at rtems.org
> first?

Yes and we should highlight there is new or updated dual license code.

Also adding top level documentation about dual licensed code that explains the
licensing and the code effected would really help. Doing this helps any 3rd
party compliance checks. The doc either covers the code it relates to, the doc
needs updating, or we have a problem.

Chris