4 ms·

"Microchip’s compilers are based on the open source GCC compiler, but they keep some special sauce locked up." How is this possibly not a GPL violation? Unless

by lutorm 15y ago

"Microchip’s compilers are based on the open source GCC compiler, but they keep some special sauce locked up." How is this possibly not a GPL violation? Unless they are running their compilers as a service, they must be redistributing the GCC GPL code, in which case it seems they must license their "secret sauce" under the GPL as well.

marshray 15y ago
It sounded like the compiler was properly GPL but the libc was closed source.
- tesseract 15y ago
  Or peripheral driver code which runs on the Microchip device (and may interact with libc, but not necessarily, and not that it matters from a licensing perspective since there are plenty of non-GPL libc's).
- deleted 15y ago
  [deleted]
reemrevnivek 15y ago
This has been the subject of many heated discussions in the embedded world. For a start, see http://www.embeddedrelated.com/usenet/embedded/show/91196-1.php http://www.embeddedrelated.com/usenet/embedded/show/91196-1.... and http://www.microchip.com/forums/tm.aspx?m=292995 http://www.microchip.com/forums/tm.aspx?m=292995 for a start. There are code size limitations (your binary must be no larger than 16 kB, some of these devices have 128 kB of Flash), there are optimization restrictions (you can't use -O3 or -Os, and some -f flags are disabled), and the libc is closed-source. These are the things that bug most people. The OP here is pointing out issues with closed-source peripheral stacks. That's a whole different issue.
pnathan 15y ago
As an aside here, what you can do is have your GPL code load a non-GPL DLL. I've seen that before. (Very frustrating when you're trying to understand how the custom GDB works).
- caf 15y ago
  If you distribute the GPL code and that non-GPL DLL together as a working system, then you still need to comply with the GPL restrictions. The work-around you've suggested only works if you distribute the non-GPL DLL separately, and have your users plug it together.

by lutorm 15y ago

marshray 15y ago

It sounded like the compiler was properly GPL but the libc was closed source.

tesseract 15y ago
Or peripheral driver code which runs on the Microchip device (and may interact with libc, but not necessarily, and not that it matters from a licensing perspective since there are plenty of non-GPL libc's).
deleted 15y ago
[deleted]

reemrevnivek 15y ago

This has been the subject of many heated discussions in the embedded world. For a start, see http://www.embeddedrelated.com/usenet/embedded/show/91196-1.php http://www.embeddedrelated.com/usenet/embedded/show/91196-1.... and http://www.microchip.com/forums/tm.aspx?m=292995 http://www.microchip.com/forums/tm.aspx?m=292995 for a start. There are code size limitations (your binary must be no larger than 16 kB, some of these devices have 128 kB of Flash), there are optimization restrictions (you can't use -O3 or -Os, and some -f flags are disabled), and the libc is closed-source. These are the things that bug most people. The OP here is pointing out issues with closed-source peripheral stacks. That's a whole different issue.

pnathan 15y ago

As an aside here, what you can do is have your GPL code load a non-GPL DLL. I've seen that before. (Very frustrating when you're trying to understand how the custom GDB works).

caf 15y ago
If you distribute the GPL code and that non-GPL DLL together as a working system, then you still need to comply with the GPL restrictions. The work-around you've suggested only works if you distribute the non-GPL DLL separately, and have your users plug it together.