#3518 PIC headers are no longer "non-free"?

[Jakub Tilcer]

Maybe I'm just blind, but I didn't find any evidence that the headers are required to be used "only with authentic Microchip products". I didn't find anything in the gputils .inc files, nor in the documentation. Not even in the headers and .inc files of the xc8 compiler. Please correct me if I'm wrong, but it simply seems to me like it once was required to use those files only with MC products, but they changed it.

[Benedikt Freisen]

Various people had already reached the conclusion that such a requirement is likely unenforceable in the context of simple header files.
Maybe Microchip has reached the same conclusion and quietly dropped that requirement. If that can be verified, the "non-free" folder structure becomes unnecessary.

[Jakub Tilcer]

It would be awesome for my project as I would be able to release it as fully opensource.

[Tom Li]

I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?)

So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you to do so, then you can include this file locally without ever using the --use-non-free option in SDCC. Possibly, SDCC can also ship these headers by default and the PIC target would no longer be "non-free".

However, there are still problems.

1. Integrating these headers into SDCC in a backward-compatible manner remains problematic - the SDCC headers are automatically generated from gputils's assembler headers, which themselves are obtained from the Microchip's (now unsupported legacy) MPASM assember, and NOT the XC8 C compiler. So the headers will not be fully identical. Perhaps we can use a separate directory named "xc8/", I can contribute a patch for that!

2. Although the restrictive "only with authentic Microchip products" license no longer covers SDCC, it still covers gputils, which is used by SDCC to produce the final object code from assembly. These headers are actually under a technically more restrictive "all rights reserved" license, so in theory, gputils is not allowed to even redistribute them at all (perhaps the developers of gputils previously asked Microchip and they were told that redistribute by gputils is allowed under the conditions of "only with authentic Microchip products"). A contributor from GNU Guix actually raised the problem here: https://sourceforge.net/p/gputils/bugs/317/ It's still unanswered.

   • So, even if SDCC is freed, which is certainly good, it's not a full solution - it's just moving the problem one layer deeper, into gputils, and the involvement of non-free code/tools is still present - although they not longer affect SDCC compiler or any C source code.
   • Theoretically, for gputils - we can do something similar to what SDCC did before in reverse - automatically generating assembler headers from the XC8 C headers, this way we can get rid of the old proprietary licenses completely in gputils as well. But at the current stage, this work is far-fetched.

For reference, a typical (free) device header in Microchip's XC8 compiler looks like this:

// Version 2.40
// Generated 04/07/2022 GMT

/*
 * Copyright © 2022, Microchip Technology Inc. and its subsidiaries ("Microchip")
 * All rights reserved.
 * 
 * This software is developed by Microchip Technology Inc. and its subsidiaries ("Microchip").
 * 
 * Redistribution and use in source and binary forms, with or without modification, are
 * permitted provided that the following conditions are met:
 * 
 *     1. Redistributions of source code must retain the above copyright notice, this list of
 *        conditions and the following disclaimer.
 * 
 *     2. Redistributions in binary form must reproduce the above copyright notice, this list
 *        of conditions and the following disclaimer in the documentation and/or other
 *        materials provided with the distribution. Publication is not required when
 *        this file is used in an embedded application.
 * 
 *     3. Microchip's name may not be used to endorse or promote products derived from this
 *        software without specific prior written permission.
 * 
 * THIS SOFTWARE IS PROVIDED BY MICROCHIP "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL MICROCHIP BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWSOEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#ifndef _PIC16F1455_INC_
#define _PIC16F1455_INC_

/*
 * Assembly Header file for the Microchip PIC Microcontroller
 * PIC16F1455
 */

[Maarten Brock]

I know practically nothing about the PIC part of SDCC and gputils, but are you saying that the MPASM C header files are converted to ASM include files for gputils and then converted back to C header files for SDCC?

And is there any reason why the new C header files from XC8 are not usable with SDCC?

Further, does SDCC use those (free or not) ASM include files from gputils at all? Or is it only using gpasm and gplink to convert the generated assembly code into a binary?