I don't quite agree with that, but I see the point.
I probably communicate the concepts wrong; I'm much better at concrete examples than lawyer talk.
There are actually several ways of writing support headers, not just one. For instance, you may declare all your registers as bit fields, or as bit masks only.
Yes, and while the whole header file is protected by copyright (you cannot redistribute it unless you have a license), you can copy the facts it declares, and not infringe, because those facts are typically not "protectable elements".
I am trying to describe the filtration step in
abstraction-filtration-comparison test, essentially. While the entire test is not endorsed by all courts in Europe, the filtration part basically is. In particular, quoting from the Wikipedia page, the concept of "hardware specifications, interoperability and compatibility requirements, design standards, demands of the market being served, and standard programming techniques" in software being typically not protectable by copyright.
The fair use doctrine in the USA differs a lot from the exceptions to copyrights in Europe, and I'm not familiar with those.
So I don't agree that it's not original work (especially if you're the first author of a given support header), obviously a mere copy of an existing one with just minor changes could not be copyrighted!
No, I wasn't trying to claim that. Me fail English, I believe.
I meant that the declarative facts (macro values, structures, function and variable declarations) are not protected, and that copying/transcribing them into another header file is not copyright infringement, due to the reasons I listed.
Just copying the set of header files as-is is copyright infringement (because you infringe the copyright of the collection); copying a single file depends on why it was copied (if necessary for interoperability with something, it would not be infringing in Europe); and copying the declarative facts to your own header files is not infringing.
I guess the tricky bit is to understand how copyrights apply to works, like nested sets of boxes. Each box as-is is protected by a specific license, but the licenses of its contents can differ; and some contents may not be protectable by copyright at all, if they are obvious/non-creative/etc. enough. Each box needs a sticker describing its license if not compatible with the one it is in (and the outer box license must allow that), and the outermost one needs to list only the minimal set of compatible licenses.
For example, in a simple software project licensed under GPL-3.0, you might have individual files licensed under say CC-0 and modified/three-clause BSD license. These might have a license declaration at the beginning of the file, say
// SPDX-License: CC0-1.0 and
// SPDX-License: BSD-3-Clause, with the license texts in
LICENSE.CC0-1.0 and
LICENSE.BSD-3-Clause in the root directory; or they might not. Because the license compatibility, only the GPL is needed to allow distribution of that project. This is particularly important with multiple-licensed code: those extra licenses do not need to be mentioned, as they are not needed for this project; but it does not invalidate those other licenses. You can pick out a box, and if you find it has or should have a different license sticker on it, you can reuse that particular box with that different license, even if you picked it out of a box that had a different license sticker on it.
If the arrangement of the contents of a box is "original" (in the copyright law sense), then that arrangement is protected by the license chosen by the copyright holder of that arrangement. The definition of "original" is lawyer-speak, and varies a bit in different copyright jurisdictions and copyright domains.
It is important to realize that copyleft licenses, like the GPL, contain language that allows labeling a box with a GPL license only if all the contents are GPL-licensed, or licensed under a compatible license. You cannot stick a box with a proprietary license inside a GPL box; it is not allowed by the license. You also cannot add any kind of limitations or requirements on top of the GPL.
GPL does allow you to include such GPL'd boxes in "compilation" boxes or sets, with other boxes licensed under different licenses, if the boxes are "not linked" together. If you slap a license on such a compilation box, the license only applies to that arrangement, and not to the contained boxes. For example, if you create a DVD with those software packages in it, your copyright extends only to that exact arrangement (plus whatever your own boxes, like artwork you add on top, you might add). If someone takes your DVD, removes your own boxes or changes the arrangement, and distributes the derivative, they are not infringing on your copyrights on the compilation, because they created a new one.
(At this point, however, it is important to note that database stuff has other provisions. If the collection can be/is treated as a database, then different rules apply.)
In the XC16 case, the outermost box is the MPLAB XC16 Compiler. I'm not exactly sure which license it is distributed under, as I haven't run the installer, and cannot see the license described in the release notes. It contains both proprietary and GPL-licensed parts. The license check is not proprietary, it is GPL'd, because it is provided by Microchip in a file that declares itself to be GPL-licensed in a project that declares itself to be GPL-licensed. To see if the user has a license, the code uses a command-line interface, executing a binary at a specific location, whose return value declares the user reference; this is an "interface", and traditionally breaks "derivativeness". That external binary is not GPL'd, but replacing it with another binary that returns a fixed value, or modifying the compiler (under GPL) to never execute any external license checkers, is not prohibited by the GPL license, and does not violate the copyrights related to that external binary.
The
ARM GNU Toolchain provided by Microchip (and the upstream
GNU ARM Embedded Toolchain) provides the compiler (gcc), linker and debugger (binutils-gdb), and the basic C headers and libraries (
newlib), all licensed under GPL.
The
AVR 8-bit Toolchain provides the compiler (gcc), linker and debugger (binutils-gdb), and the basic C headers and libraries (
avr-libc), all licensed under the GPL.
The XC16 sources provide only the toolchain binaries (all licensed under the GPL), and none of the headers and libraries. I was rather surprised by this, as I haven't used PICs or the XC compilers at all, and expected them to be more in line with the ARM and AVR toolchains I'm more familiar with. As I haven't installed the XC16, I do not know what headers and libraries it provides; I only know what the sources provide.
You also said [...]
Me fail English, if you got that impression.
Perhaps the above analogue of wrapping boxes with license paper, and putting and arranging them inside each other, makes more sense?