Here's the primary offense:
There is nothing wrong there. The original xclm is not modified at all, and not even used.
Unless I'm missing something, they are simply creating their own program that has the same name- xclm - which returns an exit code. Then a hash is computed on the new xclm program which is inserted into a gpl binary. Unless there is something wrong with deleting proprietary files, I don't see what offense may be occurring.
Well, it could be that the XC16/XC32 as a "complete package" is
not GPL, and that modifications to the "package" (i.e. how parts of GPL and non-GPL parts interact) is not allowed.
Then again, if GPL dominates then I suppose this is not the case.
----
Nevertheless, I think the underlying problem is support by the manufacturer. AVR & ARM (and to some degree MSP430) have very accessible GCC compilers that are not proprietary products. This means they are easily installed by 1 command with a package managers on virtually any system.
The platform specific modifications are taken upstream, so one can build AVR and ARM compilers (haven't tried/used MSP430 though) for the latest GCC 7.2.0. Look at the
Arch software repositories (or Fedora for that matter..), the cutting edge stuff is out there if you absolutely need it.
The cutting edge stuff have primarily front-end updates (new C++ features, some of which are nice for embedded).
But there are also some very relevant backend tunings as well. A few weeks ago, we were doing a little coding challenge to implement some math operations as fast as possible on an AVR. I was surprised to see that the code (with some inline assembly for custom integer types) could be
2x faster on GCC7.2.0 compared to GCC4.9.2 (standard Arduino branch). The compiler was much better in handling register pressure for some iterative parts of the code, leading to far less memory loads, thus a much higher level of optimization.
I tried to use
XC16 C++ a little back. It does work.. somewhat, if you can miss the stdc++ library... (there is an embedded oriented SSTL version, admittedly haven't tried using that for XC16 yet though).
And then.. I found out that XC16 is still using GCC base version 4.5.1. That version is more than
7 years old (released 2010). This version has
few C++11 features integrated, but many nice features are not available.
I have never tried modifying the GCC code base, but something tells me that "building a newer GCC version if you want" is a major undertaking due to regressions. And I don't think you could blame the GCC maintainers for that; they cannot babysit code that is not in their repository. Though luck if a 3rd party has to fix all the regressions.
As a user looking for a good long-term embedded platform, I think the pay-to-unlock compiler optimizations is not even the biggest issue. You can either pay 1k$ or get your hands dirty. Stagnation in the compiler development is a much bigger issue for me.
As far as I am aware, Microchip has always ignored C++ requests for XC16 and other compiler complaints on their forums. Ever since it's introduction in I think 2012(?) XC32 C++ version is now a "free offering!", like as if they have gone above themselves to provide this to their customers.
I think in 2015, XC32 1.40 upgraded to GCC 4.8.3, which was somewhat recent version back then. However by now also already 3 years old.. The cynic in me thinks that perhaps we would have never 'gotten' this upgrade if it wasn't for Microchip working on embedded Linux support for their larger PIC32MZ parts.
I'm not holding my hopes up for a change in this paradigm anytime soon. I think if MCHP wants to get their compiler quality up to par with ARM and AVR, they will need to drop this corporate shenanigans.