MPLAB X a PIC inhibitor! Alternatives ?

[Karel]

But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.

Of course it is legal.

I agree but it's a little more complicated. If you read back this thread, it appears that some people think that it is perfecly fine
if Microchip hacks the GCC compiler in order to block optimizations but it's not fine when I unblock them by hacking it again.

[NorthGuy]

I just don't think it's a huge difference between this and compiling.

Well, I guess that for most people (at least for me), it is a huge difference.

Have you tried?

So, if you can provide a step by step manual for dummies like me how to download and compile the GCC sourcecode from Microchip, that would be very nice.

I don't need it. But I guess people who did compile it could blog about it or post a video. If you don't see this, it is most likely because there's no demand for such thing.

[cv007]

If you read the license, the payment is mostly for the on-going support.

MCHP would be better off (in my opinion) by just selling 'priority support' (or whatever they currently call it -High Priority Access or something).  Let everyone get the same compiler, whoever wants/needs priority support, they can pay (as they do now). I would assume very little would change for those who currently buy support/extra compiler optimizations. MCHP could then use the resources currently allocated for licensing (dongles, license server, license verification, etc.) to support the actual hardware. Those in charge of XC16/32 could eliminate all the extra code for the various license levels and could work on one single codebase. The Atmel side could do the same thing- add paid support options to their already open/free gcc arm compiler (maybe they already have paid support options, I don't know).

It will be interesting how they merge the Atmel side into what they have- there is no way they are going to make you pay for optimization for their sam/avr parts. If that is true, then the mips side will most likely end up the same eventually. How many companies are left in the MCU chip selling business that also are in the compiler selling business?

[technix]

Thats a good idea.
If you could set up a linux virtualbox machine with the necessary build environment and distribute it that would be much appreciated (and legal of course). Its beyond me 

Just pick someone's ready-made MIPS32 GCC and you are good to go. If you need startup files and linker scripts, extract them from XC32. Or if your machine runs Linux or macOS I may be able to build you one.

[technix]

I just don't think it's a huge difference between this and compiling.

Well, I guess that for most people (at least for me), it is a huge difference.

Have you tried?

So, if you can provide a step by step manual for dummies like me how to download and compile the GCC sourcecode from Microchip, that would be very nice.

I don't need it. But I guess people who did compile it could blog about it or post a video. If you don't see this, it is most likely because there's no demand for such thing.

There are tutorials for building GCC targeting AVR (as part of avr-libc tutorial) or i386 (as part of Linux From Scratch bootstrap process.) I think you can take inspirations from those and build a stock MIPS32 GCC from upstream code.

Just saying, I have used that (fairly outdated) tutorial to build AVR-GCC 7.2 (latest release from upstream) from source for my macOS machine. Not even Microchip is distributing this version. Notice the lack of branding here, with the compiler simple calling itself avr-gcc (GCC) 7.2.0?

Code: [Select]

$ avr-gcc --version
avr-gcc (GCC) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.Here is the output of my ARM Embedded GCC that is branded GCC 6.2.1:

Code: [Select]

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.Or the one from Atmel Studio:

Code: [Select]

avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[technix]

But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.

Of course it is legal.

I agree but it's a little more complicated. If you read back this thread, it appears that some people think that it is perfecly fine
if Microchip hacks the GCC compiler in order to block optimizations but it's not fine when I unblock them by hacking it again.

If Microchip is actively trying to prevent other from modifying XC16 and XC32 to remove the license check, tell FSF and they will be very gladly to sue for you. FSF owns GCC after all, and they have a history of defending GPL. I think Cisco (owns Linksys back then) have better lawyers than Microchip, yet they get successfully sued by FSF for GPL violation.

[technix]

If Microchip really want to make a compiler that they can put in a license check that they can properly defend, while still providing modern functionality, use LLVM as upstream instead of GCC. LLVM can be relicensed as proprietary unlike GCC which is permanently GPL. ARM is already doing this (the ARMCC version 6 is based on LLVM, replacing their own ARMCC version 5 deprecated.) LLVM already have MIPS32 support. Speaking of, LLVM can be used to built modern compiler for 8-bit and 16-bit microcontrollers too, just look at the LLVM-MSP430 and LLVM-AVR branch.

[MT]

But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.

Of course it is legal. It is illegal to forbid hacking GPL licensed software. And it is not really a challenge, because GPL means that you get all the source code and a manual how to compile it (and if you don't, it is illegal again and the FSF will be happy to help you), so you can just modify the source code as you like. But don't forget to publish your modifications or a contact address how to get it, because this is required by GPL.

So i wonder, did Microchip publish their hack to restrict optimization levels? And if so why did they restrict optimization levels to begin with?

[Bruce Abbott]

You missed the point...
This is about modifying/hacking the compiled, GCC compiler,

That too, but mostly it's about cracking proprietary software.

Here's the primary offense:-
 

- compile a new "xclm" binary using the following C code:

int main(void)
{
  return 6;
}

and copy it to /opt/microchip/xc32/v1.42/bin/

- save also the hash of the new binary: sha256sum /opt/microchip/xc32/v1.42/bin/xclm
 
 

Inside the original xclm.exe we find this message:-

  'Reprise License Manager (RLM) v12.0, Copyright (C) 2006-2015, Reprise Software, Inc.'
   
The crack modifies xclm.exe to stop it from actually checking the license, instead faking the return code for a valid license. It also removes Reprise's copyright from the code, an offense in itself.

I am not a lawyer, but I'm betting that Reprise License Manager is not covered by GCC's GPL.

[NorthGuy]

I am not a lawyer, but I'm betting that Reprise License Manager is not covered by GCC's GPL.

On a side note, the license manager which is so easily removed is a fraud in itself. "Reprise Software" scammed Microchip into believing that their licensing model is secure while, as you can see, it is so easily by-passed. There's no intellectual property in this piece of crap. Nothing intellectual at all. On the other hand, scammers usually have the best lawyers ...

[cv007]

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.

[technix]

You missed the point...
This is about modifying/hacking the compiled, GCC compiler,

That too, but mostly it's about cracking proprietary software.

Here's the primary offense:-
 

- compile a new "xclm" binary using the following C code:

int main(void)
{
  return 6;
}

and copy it to /opt/microchip/xc32/v1.42/bin/

- save also the hash of the new binary: sha256sum /opt/microchip/xc32/v1.42/bin/xclm
 
 

Inside the original xclm.exe we find this message:-

  'Reprise License Manager (RLM) v12.0, Copyright (C) 2006-2015, Reprise Software, Inc.'
   
The crack modifies xclm.exe to stop it from actually checking the license, instead faking the return code for a valid license. It also removes Reprise's copyright from the code, an offense in itself.

I am not a lawyer, but I'm betting that Reprise License Manager is not covered by GCC's GPL.

I am not sure if such a modification is GPL-compliant. Maybe we should report this to FSF, and if this "putting a proprietary license check into GPL code" breaks GPL they will happily sue.

[Karel]

Here's the primary offense:-

CV007 is right: https://www.eevblog.com/forum/microcontrollers/mplab-x-a-pic-inhibitor!-alternatives/msg1353555/#msg1353555

There's nothing wrong there.

Hypothetically speaking, I can patch the GCC compiler executable to not look for xclm but for xclm_karel instead.
In that case it's not a problem anymore. No need to replace the xclm. I can do that in five minutes...

[cv007]

This is not that complicated. The source is available, so you can clearly see what they are doing.

Option 1- write 6 lines of shell script that replaces xclm, and inserts the hash of the newly compiled xclm file into three gpl licensed files.
the original xclm is not used or modified, you can delete it- no laws against deleting files
also no laws against creating your own file with the name xclm
the only modifications are to gpl licensed code (3 binary files), which now have the hash value of the new xclm file

Option 2- write 7 lines of shell script that changes the init value of the global variable 'mchp_pic32_license_valid'
in 3 files, change the init value of 'mchp_pic32_license_valid' (.data section)  from -1 (FFFFFFFFFFFFFF) to 6 (0600000000000000)
the xclm file is not used at all since the variable is now initialized to the value 'MCHP_XCLM_VALID_CPP_FULL' (6) (basically, no license check is done)
no need to have an external program (xclm) return a number, but there still needs to be a file named xclm (can be an empty file)
the original xclm is not used or modified, you can delete it

I have tried both ways, both work equally well. I like option 2.

It took me a couple hours to write both scripts (I'm not that bright, so it took a little time to figure out how to do it all from the command line also took some time looking at the gcc source code provided by Microchip). It seems to me that the whole license infrastructure they have is a complete waste of time/resources (excluding XC8 I suppose).

[hans]

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.

[Karel]

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.

It's not the case. The GPL dominates because you can not change the license of (or re-license) GPL'ed software without the permission of all respective copyright holders of that software.

That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Don't get me wrong, there's nothing wrong with writing closed-source proprietary software (I'm not a commy). But when you do, don't whine that you can not use GPL'ed software in your projects.
It has been made very clear that when you distribute modified GPL'ed software, you have to distribute the source as well and allow that other people start to use your modifications in their software (on the same conditions).

Edit:

Also, by distributing GPL'ed software, you have to accept that people can modify ("hack" if you prefer) your software and don't use it as you intended.

[andersm]

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.

The compiler itself is GPL, but eg. the libraries and device database files are not.

[technix]

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.

The compiler itself is GPL, but eg. the libraries and device database files are not.

I am not sure if FSF share this view. They have some pretty rigid requirements about what can be packaged along with GCC in order not to make every single piece of code emitted by the package GPL (due to libgcc usage.)

At least the header files are 3BSDL AFAIK. FSF views 3BSDL as GPL-compatible.

[technix]

Here's the primary offense:-

CV007 is right: https://www.eevblog.com/forum/microcontrollers/mplab-x-a-pic-inhibitor!-alternatives/msg1353555/#msg1353555

There's nothing wrong there.

Hypothetically speaking, I can patch the GCC compiler executable to not look for xclm but for xclm_karel instead.
In that case it's not a problem anymore. No need to replace the xclm. I can do that in five minutes...

Or just patch that entire check out. Or port the patches Microchip made for PIC32 back into stock MIPS32 GCC (so we get C11 and better optimizations.)

[NorthGuy]

That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Or perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.

[Karel]

That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Or perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.

That's fine, I encourage competition. No need to show hate/angriness about the GPL. If you don't like it, don't use it.

[Bruce Abbott]

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.

What does Microchip's 'corporate shenanigans' have to do with updates to GCC for PICs? The compiler is is open-source (not really, but...) so why can't anyone produce a better version if they want? What is stopping the PIC versions from being as up-to-date as others?

This is not that complicated. The source is available, so you can clearly see what they are doing.

The source to xclm is available?

no laws against deleting files
also no laws against creating your own file with the name xclm

You are an actual lawyer versed in IP law? If not then how can you know this is true?

The way I see it, compiling some code and patching it into xclm (which is what happens when you copy it over the existing file) equates to modifying it. Since xclm is proprietary copyrighted software which is not covered by GPL... Now I may be wrong, and it's all perfectly legal. But I still think it's dodgy.

 

[technix]

That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Or perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.

That's fine, I encourage competition. No need to show hate/angriness about the GPL. If you don't like it, don't use it.

Oh the corporates will hate on GPL. In fact they already do.

[Karel]

The way I see it, compiling some code and patching it into xclm (which is what happens when you copy it over the existing file) equates to modifying it.

Here I lost you. If you believe that there's no difference between replacing and modifying, than any further discussion with you is futile.

But for the sake of the discussion, and purely hypothetical, let's assume for a moment that you are right and it is actually "dodgy".
In that case, you don't replace it but you simply patch the compiler by using the alternative methods as described before by others.
Or is that also "dodgy"?

[andersm]

I am not sure if FSF share this view. They have some pretty rigid requirements about what can be packaged along with GCC in order not to make every single piece of code emitted by the package GPL (due to libgcc usage.)

I'm not sure what you're trying to say here. The GPL aggregate clause permits distributing GPL-licensed software with non-GPL software. The GPL also doesn't impose any limits on the license of the libraries it links.

At least the header files are 3BSDL AFAIK. FSF views 3BSDL as GPL-compatible.

Which header files? Some of the library headers installed with XC32 have a BSD-style license, but mostly it's a mishmash of proprietary or no explicitly stated license. The installer places a "compiler license" text file in the root install directory detailing the various components and their licenses.