Hi Cinly, the reason I started this thread was not to complain about Apache-2.0, but only to dump my thoughts in case someone wants to add FLM support to OpenOCD and get scared or blocked by the license issue. I'm not working on the flashing code, so I don't plan to go further on this. At least not soon.
Apache-2.0 and BSD-like licenses are welcome by the tool vendors that want to integrate that code in their proprietary SW tools. At the same time Apache-2.0 can be integrated in GPL-v3, so good for non-proprietary code too. I believe this is the rationale behind ARM's decision for Apache-2.0. Yes, we can ask ARM to release these files under dual license "Apache-2.0 OR GPLv2", but at this point even if ARM accepts, it would not be a game changer: - the FLM blobs from chip vendors will be under their own whatever license and, if incompatible with GPLv2, we will never link these inside OpenOCD (independently from ARM decision); - the code in OpenOCD to load and use the FLM blobs can be easily written without ARM include files (no license issue). The only advantage could be to have in OpenOCD contrib/ folder some GPLv2 helper compatible with FLM API and to link them in OpenOCD. But the most interesting benefit of FLM is supporting the external chip vendor's blob. In contrib/ we can still have Apache-2.0 or GPLv3 helpers and put the resulting FLM binary in a separate folder for all the FLM. The project https://github.com/pyocd/FlashAlgo is interesting because it could become the recipient, outside of OpenOCD, for all these FLM helpers in source code. Maybe even chip vendors could join it. FlashAlgo could be packaged by Linux distro and, once installed, you get all the FLM files in /usr/share/FlashAlgo/. OpenOCD could search there. Either OpenOCD could install some FLM in the same folder above, or we directly add the FLM code to the FlashAlgo project. And FlashAlgo looks used by other tools too, so more contributors than in the OpenOCD community alone! Regards, Antonio On Mon, Apr 25, 2022 at 3:13 AM Ooi, Cinly <cinly....@intel.com> wrote: > > 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 >
