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@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
