STM32 Demo Code Carries Extra (hidden?) Copyrights

Recently I started a repository that houses a template which may be used to compile STM32F0 projects with a GCC toolchain. There are two code packages from STM that I used when putting this together, the firmware for the Discovery board itself, and the Standard Peripheral Library for the chip family. I read the license agreements in the root of both packages and I think they’re quite fair. Basically the agreement is you can use them for any purposes as long as the code is only being used on STM hardware. Fair enough.

You can image I was quite upset so see a comment from a reader stating that I have a copyright violation with one of the files in the repo. It seems the linker script that is given as an example for Atollic’s TrueSTUDIO has it’s own extremely strict copyright:

** (c)Copyright Atollic AB.
** You may use this file as-is or modify it according to the needs of your
** project. Distribution of this file (unmodified or modified) is not
** permitted. Atollic AB permit registered Atollic TrueSTUDIO(R) users the
** rights to distribute the assembled, compiled & linked contents of this
** file as part of an application binary file, provided that it is built
** using the Atollic TrueSTUDIO(R) toolchain.

First off, I’m in violation just for posting the file in a repository. But read a bit deeper. Any code that is compiled with this using a GCC toolchain also breaks the copyright unless it’s Atollic’s toolchain.

My beef here is that STM is distributing this. Why? Why put something so restrictive into a software library with such an otherwise reasonable license? Surely there are many engineers at STM capable of writing a linker script that they could release under their own license which would work with TrueSTUDIO. And, it would have the added benefit of allowing other GCC-based toolchains a convenient (and legal) method of linking code.

So I’ve completely removed the file from the repository. If you were one of the ten people watching it on github, this had the unintended consequence of dumping your watch request. In the mean time I’m trying to learn how to write my own linker. This guide regarding Cortex-M3 linkers has been a great help. If you have the skills to contribute a working linker script, please issue a pull request or raise an issue over at github.

31 thoughts on “STM32 Demo Code Carries Extra (hidden?) Copyrights

  1. ST probably provides linker files for each of their parts. If I were you I would look around wherever you found the peripheral driver library. Also look at any examples that came with the driver library…each of them will have a linker command file. FYI Linker files are pretty standard, so the ST ones should work with pretty much any linker (although it might need some tweaking).

    Linker command files are somewhat daunting to those who have never messed with them, but they are even easier to tweak than code once you understand how they work.

  2. I maintain some similar “skeleton” projects for microcontrollers..

    To be honest there aren’t too many ways to write a linker script for a micro.. it’s not like the memory map moves around. I really doubt the license in that file could be enforced. I would do the following if you’re really worried about:

    — Study the bad license linker file and write down the memory sections etc you need. These are public knowledge and should be in the datasheets anyhow so it’s not “stealing”.

    — Using the ld manual and the tricks cribbed from the existing linker script write your own.

    Or just do like everyone else does (including demo board vendors!) and just remove the license notice, clean up the formatting, remove any unneeded junk, and rewrite the comments.

    Also… you really don’t want to write your own linker. That’s a lot harder than a linker script. :p

    1. Think that is bad, check out Invensense and their IMU code for the MPU-6000/9000 series. They give you an NDA for code that only works for one hardware they don’t even stock, and don’t tell you that the chip needs that code and hardware to work at all like intended.

  3. I dealt with this on stm32f4 few days ago. I use Attolic startup script (assembly) with linker script from NuttX RTOS.

    Btw. I have a functioning STM32F4 GCC template for a long time now + modified TNKernel RTOS with FPU registers saving in dispatcher. (Actually I’m using it for my dumb brushed quad project.) I can post it somewhere if somebody is interrested.

  4. Luckily there’s a loophole:
    The code as-is is copyrighted, but the methods used can only be patented. Replace all the variables, then change the order, maybe throw in some obfuscation for good measure. The result is identical function, but no violations of copyright. It is entirely unethical to some, but so is releasing that bogus code in the first place.

    This is a method that skirts between the lines of copyright and patents, and the fact that code can fall in the cracks. I cannot claim the full legal validity of the method though, so I would consult with counsel before trying.

      1. Not that code, all code has the same issue. You can copyright non-functional features (design, actual words, etc) or patent functional ones (algorithms, etc), but most software is never patented.

        That license oddly leaves out a lot of needed restrictions, and therefore is only enforceable as a copyright violation (not breach of contract). If they ever did try to sue, their lawyer would talk them out of it, the judge would talk them out of it, and eventually, the case would be thrown out on the grounds that it’s an equivalently functioning work, not a copy.

  5. That shows how much they care about you coding for their boards. Then think, if they are incompetent like this on the tool chain, what should you expect of the hardware, firmware blob, over time? I wouldn’t expect nice things…

    Stm is the worst experience this hobbyist ever had.

  6. At least for the STM32F4 Discovery board there were link and project files for other IDEs than Atollic’s. Atollic TrueStudio adds the same disclaimer to includes and source files it creates when starting a new project. One of the main reasons I’m going to take a closer look at CooCox – which as an added bonus seems to support a whole array of ARM CPUs from many manufacturers.

    1. I already wanted to ask the question “Wouldn’t using CooCox solve that issue?!”

      I use it and I like it a lot. I could write my first STM32 Code within 40mins – including the download, thanks to all the well implemented examples and those “funcion lists”. CooCox on the other side is only available for windows (which i dislike as well), but its a start…

    2. I started with attolic, it was the only free env. I found with only the restrictions other that you had to mention it was build with attolic, but then they forced an update now with code size restrictions and I read the extreme license on the few attolic files. So I went for codesourcery and eclipse was simple to setup compared to the extreme hassle of getting the right driver installed for an st-link

  7. ChibiOS ( is an excellent GPL-licensed RTOS for the STM32 that includes from-scratch startup code and linker scripts for several compilers, including GCC.

    Its development is heavily targeted towards STM32, and so it has terrific peripheral drivers integrated into the OS (synchronous threaded UART I/O, for example) and it’s very performant on all the STM32 families. Yet, it’s well abstracted from the architectures it runs on, so you run into relatively few arcane embedded issues.

    I’ve been using and contributing to the OS for my own projects, and ChibiOS + STM32F2/F4 is now definitely my go-to µC solution these days.

  8. I’ve been “playing” a bit with CodeSourcery / Eclipse / Atollic, and am amazed at the time it took me to get a simple template going! I never thought it would be so hard!
    It could be nice if an foss Eclipse project wizard existed along the lines of the one in Atollic to get things going….

  9. The only thing relevant in those linker scripts is the memory map, it is not copyrighted. There are many dummy scripts in gcc’s directory ( using the ‘.x’ extension ) just browse it’s alongside with crt’s objects.

    Basicaly a LD linker script is no challenge for a developper, but you have to read LD’s info page first ( on linux ). Furthemore those provided by Attolic are just bullshit ! They lack many sections filled by the compiler( ex: ‘sdata’ section ). LD is part of the Tool Chain, as GCC do, so one have to learn how to use it too. ST guys are lamers !!

    Also, if it’s not a good idea to rewrite a linker, an elf loader would be great, but It may use a lot of RAM.

    PS. If you are using C++, you’ll have to add ‘.ctors’, ‘.dtors’ as well as ‘.gcc_except_table’ sections.

  10. Because of those licensing issues inside the ST libraries uwe_ and I started libopenstm32 project a while ago. By now it got renamed to libopencm3 as it got support for other Cortex-M3 microcontrollers. (by now the project name became again a bit of a misnomer as support for Cortex-m0 and m3 chips got added too, but we don’t want to change the name again. :) )

    Check it out at and

    And visit us on freenode in #libopencm3 channel. :D

    Cheers Esden

    1. Sweet!

      I picked up a few of the NXP chips a couple of years ago but due to the lack of linker scripts with permissive licenses, time to try and work it out myself and lack of SWD support in any chip burning software I could find for linux I ended up just using AVR chips, avr-gcc and paying the extra for the ICs.

      I’ll give the arm chips another go next time I come up with a microcontroller project.

  11. “Basically the agreement is you can use them for any purposes as long as the code is only being used on STM hardware. Fair enough.”

    That isn’t fair enough in my opinion. You can’t build open source software (as defined by OSI) out of code with that restriction. CMSIS and all other significant sample code I’ve seen from every ARM vendor has similar or worse restrictions. If you want to make open source hardware or software, you must look elsewhere or start from scratch.

    Lately I’ve been working on adding LPC43xx support to libopencm3. It’s a lot of work, but hopefully it will enable plenty of future open source projects.

  12. The copyright for the TrueStudio Linker script for the STM32L-Discovery is a little different, but still limited to using their tools. (stm32_flash.ld)

    (c)Copyright Atollic AB.
    ** You may use this file as-is or modify it according to the needs of your
    ** project. This file may only be built (assembled or compiled and linked)
    ** using the Atollic TrueSTUDIO(R) product. The use of this file together
    ** with other tools than Atollic TrueSTUDIO(R) is not permitted.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.