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