RTEMS STM32 BSP Development

[Gedare Bloom]

On Mon, Jul 6, 2015 at 1:00 PM, Isaac Gutekunst
<isaac.gutekunst at vecna.com> wrote:
> 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?
>
It would be best to get a statement from the vendor that the licenses
within individual files over-ride the MCD-ST one.

I agree with your assessment in general. For example, if I download a
GPL3 package containing some files with only a permissive license
(e.g. BSD), I can pull out those files for re-use with the BSD
licensing. So, if the source code is downloadable without having to
agree to an EULA, I suspect the BSD license applies to these files,
rather than the MCD-ST one. But that is just my lay understanding.

Gedare

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