I was thinking of starting a new open source project that should run on STM32 boards, and I realized that it would need a lot of low level code that accesses many different peripherals. One of the first libraries that comes to mind, and I bet it’s the same for many Cortex-M developers, is ARM CMSIS.
ARM created CMSIS, which stands for Cortex Microcontroller Software Interface Standard, to give a specification on how to develop and distribute the code that accesses the hardware. Products like STM32 offer their own software packages that comply with CMSIS and that provide access to all the registers and functionalities of the chip. ST Microelectronics for example provides the STM32F10x standard peripheral library, and most recently the STM32CubeF1.
CMSIS license
Until recently, CMSIS was distributed with the restriction of an ARM EULA; in particular this agreement contains a clause that licenses the developer to:
(ii) use, copy, modify and sublicence the Source Code (in source or object code form) solely for the purpose of developing, having developed, manufacturing, having manufactured, offering to sell, selling, supplying or otherwise distributing products which comply with the Specification, provided that you preserve all copyright notices included in the Source Code.
This seems to force developers to comply with CMSIS specification when they create a program that uses the CMSIS library. Nowadays the situation changed, because CMSIS source code (not the specification) has been released by ARM under a much less restrictive BSD license. This license allows, for example, to use the CMSIS code in an open source project, with the sole requirement to retain the copyright notice, license conditions and disclaimer on those files. It also allows to use the code in a closed source project, provided that you document the usage and copyright of the CMSIS source code when you distribute the binary. In order to download from ARM the CMSIS package (that contains the source code) you have to register, so one might say that downloading isn’t “free” since you have to “pay” with your credentials and contact information. But the fact that the source code part of the package is under the BSD license means that anyone can legally redistribute that part under the same license, for example it is possible to get it freely from ARM-CMSIS-BSD GitHub repository without registering.
The CMSIS package created by ARM provides access to the Cortex-M functionality of a micro-controller, but any micro-controller has other peripherals and memories inside the chip; for this reason there are chip-specific libraries. STM32 standard peripheral library is distributed (can be downloaded freely) by ST Microelectronics with no license, and in order to obtain a license you have to contact ST. But this code has been superseded by their “Cube” initiative that offers the same (or updated) functionalities in a HAL (Hardware Abstraction Layer) library distributed under a BSD license, following the path that ARM took with CMSIS code.
Under the GNU terminology (backed by the Free Software Foundation) the BSD license is a non-copyleft license because it allows to redistribute the code under stricter restriction, for example by distributing it into a product in binary form you are practically disallowing the user from seeing the source code. It makes sense for ARM and ST to distribute their code under such license because the users of CMSIS code and STM32 libraries are sometimes companies that develop proprietary software products and sell them in binary form together with the hardware, and those companies are the ones who buy chips and create profit for them. On the other hand, the BSD license allows hobbyists, students, and so on, to use the code and the micro-controllers, thus raising the popularity, user base and software ecosystem of the hardware product. The FSF would say, in my interpretation of their philosophy, that such freedom isn’t desirable, and one of the reasons is because it allows to distribute open source code into binary code, and we can’t know (easily) if the original open source code has been modified or if it’s even there. A malicious individual could sell code without giving credit, or could potentially inject vulnerabilities in the devices we own. The FSF would suggest the GPL licenses instead.
libopencm3 license
It’s possible to develop, independently from ARM or ST and their code, a low-level library to access Cortex-M and STM32 peripherals and release it under the GPL license, which forces anyone who develops a program with that code to use GPL when redistributing the program. So this library can only be used in open source projects. This was the intent of libopenstm32 (released under GPL3), intent which was not received completely well: GPL is “viral” and restrictive, in a certain sense, because it forces the developer to keep the code open source, redistribute also its modifications, and use the same license for all the code that links it.
On the basis of the practical effects of these restrictions, the FSF recommends the following:
If developers are already using an established alternative library released under a nonfree license or a lax pushover license, then we recommend using the GNU Lesser General Public License (LGPL).
Which is the case in point because CMSIS and STM32Cube libraries are released under a “lax” license such as the BSD one. Maybe for this reason the libopenstm32 project took a different turn: it was re-branded as libopencm3, with the aim to cover different micro-controllers and not only the STM32, and it was released under the “lesser” LGPL3. The “lesser” GPL licenses are particularly useful for software libraries, and allow the linking of the library into both closed and open source programs, provided that the library and its modifications are released under the LGPL, and also providing something quite peculiar of embedded development that needs some explaining:
The application of LGPL3 license comes quite natural for Linux shared (dynamic) libraries, which are distributed as files separate from the main program. But when we develop for micro-controllers, we (almost always) build a single binary that contains all the libraries, linked statically. The FSF explains in the GPL FAQs the discipline to adopt:
(1) If you statically link against an LGPL’d library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
So if someone would use an LGPL3 library into its own closed source program, they must provide also a way for the user to redo the linking part. This might sometimes be a hassle (provide object archive, linker script and linker command; strip debug symbols; be aware of the toolchain) but it seems doable in common cases.
To conclude, a Cortex-M developer has currently many options if they want to use an existing low-level library to access peripherals. There are the CMSIS and STM32Cube libraries, which are released under BSD license so they can be used in any project and modified at will, and those modifications can end up closed in a binary and not shared back to the open source community. Then there’s the libopencm3 library, which is shared under the LGPL3 and so it could be used in any project, the modifications must be shared back if they are distributed, and the linking should be made possible even when used for closed source programs. They are both valid options, I hope this post will allow developers to make a more informed decision.
I am currently trying libopencm3, which seems quite rich and evolved to support many micro-controllers; I’m going to write something about it soon.
Posts
Freedom Embedded 
April 19th, 2015 → 11:24
[…] A few days ago I talked about libopencm3, an open source library to access Cortex-M functionalities and peripherals of many micro-controllers, especially STM32 variants. I wanted to use this library to develop on a Nucleo board that I have in my hand, specifically the Nucleo-F103RB, which mounts an STM32F103RB. […]