RTEMS STM32 BSP Development

[Isaac Gutekunst]

Hi RTEMS Developers,

As mentioned in my previous email to rtems-users, we are looking to 
develop a BSP family for use with the STM32 family of processors. There 
is a lot of similarity among the silicon itself, and the Cube software 
distribution provides a common API.

We are hoping to leverage this to make a BSP (or BSP family) to allow 
seamless migration between all processors in the family. We believe the 
easiest way to get there (and support most if not all STM32 processors) 
is to use the HAL provided by ST. Our BSP would be based on the work of 
Sebastian Huber and Embedded Brains, with some parts added and replaced 
to use the more generic STM32Cube HAL.

The STM32Cube code is MISRA-C 2004 compliant, clean, mature, and well 
documented. However, we are not 100% sure about the acceptability of 
including it in RTEMS. We would really like to contribute this BSP back, 
so we want to get the licencing concerns out of the way ASAP.

Here are our concerns:

The STM32Cube zip download file contains a Release_Notes.html

This page contains the text:

Licensed under MCD-ST Liberty SW License Agreement V2, (the "License"); 
You may not use this package except in compliance with the License. You 
may obtain a copy of the License at:

        http://www.st.com/software_license_agreement_liberty_v2

Unless required by applicable law or agreed to in writing, software 
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 
See the License for the specific language governing permissions and 
limitations under the License.


However, the components we want appear to be BSD licenced. These are
CMSIS
STM32F4xx_HAL_Driver.

The Licence and Release Notes in these sub-directories indicates that 
the components are BSD licenced (with an exception for a subset of CMSIS 
that's not BSD licenced).

However, we are concerned that the top level licence "pollutes" the 
nested licences. In order to overcome that concern, we would prefer to 
see the BSD licenced code available as a separate download. However, 
since the download is obtainable without accepting an EULA, it might be OK.


The specific paragraph in the MCD-ST Liberty SW License Agreement that 
concerns us the most is:

"Licensed Software: means the enclosed SOFTWARE/FIRMWARE, EXAMPLES,
PROJECT TEMPLATE and all the related documentation and design tools 
licensed and delivered in the form of object and/or source code as the 
case maybe. "


When taken in conjunction with

"Unless otherwise explicitly stated in this Agreement, You may not sell, 
assign, sublicense, lease, rent or otherwise distribute the Licensed 
Software for commercial purposes, in whole or in part..."

Is concerning for RTEMS, because it may pollute the sub-licenced code. I 
feel the top level licence is overridden by the nested licences, and it 
was not STs intention to limit the use of the HAL code. I do believe 
they are protecting their rights with regards to the Middleware. The 
STM32_Audio code for example contains a nested duplication of the top 
level MCD-ST licence.


What do you all think about these licencing concerns? Can some of these 
files) be accepted into the RTEMS tree?

I want to focus on the licensing concerns first, and when these are 
resolved, move onto other issues such as style, technical 
considerations, and the fun stuff: BSP architecture and development!

-- 
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.gutekunst at vecna.com
www.vecna.com