On Mon, Jul 6, 2015 at 1:00 PM, Isaac Gutekunst <isaac.guteku...@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.guteku...@vecna.com > www.vecna.com > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
