Hi Antonio, My first reaction is, it is an oversight on ARM side. After considering the fact that ARM has been licensing codes for a long time already, may be there are issues surrounding intellectual property that ARM wants to protect, or it contains parts they license that cannot be GPL-v2. But then, it was licensed under Apache-2.0 which makes this very much less likely.
It's always possible that this issue of GPLv2 was never considered by ARM, particularly since Apache-2.0 is compatible with GPLv3. I believe ARM sees software as an enabler to sell hardware and will therefore be very accommodating to software developers. I think the easiest way is to get into contact with the ARM, explain to them the situation and ask for dual-licensing and see what they think. I think it is necessary to confirm they will not dual licensing GPL-v2 that before you and the OpenOCD team decide on the next move and put in any effort on this front. Email the CMSIS-5 maintainer, they can put you in touch with the relevant people. If I ask, they will probably ignore me, but Antonio, Paul or any OpenOCD developer is another question altogether. I am sure you thought of this as well. Care to share why you did not propose this route as a possible solution? Or may be you did? I don't see getting OpenOCD to compile two ways, i.e. GPL-v2 with linux fragment and U-Boot and GPL-v3 with FLM, as something to pursue. It is difficult to explain and enforce in configure, and downstream developers might just mix the incompatible code up and end up infringing copyrights unwittingly. End users will also be confused on why they can do this in one copy of OpenOCD, but not the other. Furthermore, all users of code analysis tools for copyright management such as Protex must put in extra effort in the tools to manage this, and it will (rightly) get licensing compliance team antenna up and sniffing around. However, if everything else is not possible, and FLM is important to a non-insignificant number of users _and_ they can live with the restrictions of GPL-v3, then it will be a reluctant may be. In this case, may be consider a fork instead of a v3 branch to manage the licensing issue. Many thanks and best regards Cinly -----Original Message----- From: Antonio Borneo <borneo.anto...@gmail.com> Sent: Sunday, April 24, 2022 6:28 AM To: OpenOCD <OpenOCD-devel@lists.sourceforge.net> Subject: ARM CMSIS-Pack Flash Programming A user on IRC mentioned the availability of FLM files for flash programming, provided by chip vendors. He asked if OpenOCD can support them. I've never heard of them so ... quick check ... https://arm-software.github.io/CMSIS_5/Pack/html/flashAlgorithm.html https://github.com/ARM-software/CMSIS_5/tree/develop/Device/_Template_Flash https://github.com/pyocd/FlashAlgo I have found a few FLM files inside Segger JLink applications. https://www.segger.com/downloads/jlink/JLink_Linux_x86_64.tgz ARM defined the struct and the function prototypes API to be exported by a position independent ELF, renamed as .FLM. The debugger loads the ELF in target memory, exchanges data through target memory, calls the API. It could be interesting to add FLM support to OpenOCD because we could easily reuse what chip vendors distribute. The problem is the Apache-2.0 license of the include file https://github.com/ARM-software/CMSIS_5/blob/develop/Device/_Template_Flash/FlashOS.h or the same split in two files https://github.com/pyocd/FlashAlgo/blob/main/source/FlashOS.h https://github.com/pyocd/FlashAlgo/blob/main/source/FlashPrg.h Apache-2.0 is not compatible with GPLv2 (only with GPLv3) https://www.apache.org/licenses/GPL-compatibility.html We had some talk about switching OpenOCD to GPLv3, but this will prevent us from including code fragments from Linux and U-Boot. No way. Plus we have to drop what we have already included! Linux only accepts Apache-2.0 code that has been dual licensed https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/dual/Apache-2.0 like this one, that by the way is still in "staging" and could even be dropped atter a while https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/wfx/hif_api_mib.h If you have different info, please let me know. Having some firmware .FLM in Apache-2.0 or other incompatible license is not a problem as long as the firmware is not linked inside OpenOCD binary but distributed as an independent file. The issue is that we need the include file to describe, inside OpenOCD, how to read the struct and how to format the arguments of the API. Or probably not !!! For the API we need to set the target registers accordingly to the ABI then call the function by setting the target's program counter PC. The function prototype is implicit in the way we set the registers, but we don't need to include the Apache-2.0 file .h in OpenOCD! For the struct, we need to load it from the ELF/FLM. But to handle host and target endianess we cannot simply read() the struct from target ELF in a host struct defined in the Apache-2.0 file .h. We should read from ELF an array, parse it to extract the struct fields, adapt the endianess and put them in a completely different struct or in a set of local variables. Maybe this could be the way to go! Feedback? Antonio
