[LLVMdev] GPL licensing issues or can GCC be used with llvm for a commercial application?

[Razvan Aciu]

Thanks for your replies. This is indeed a helpful mailing list. I made some 
more researches about the licensing issue and this is what I discovered:

- from FSF it seems that packaging together a GPL application and a 
commercial one it is a corner case of licensing. Here is what they say:
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLInProprietarySystem
It seems that if I use GCC only as a command line tool, it should be ok. 
Anyway, there is a catch: "But if the semantics of the communication are 
intimate enough, exchanging complex internal data structures, that too could 
be a basis to consider the two parts as combined into a larger program.".
In our case, the communication means sending entire programs and command 
line arguments and receiving warnings and error codes. Is this intimate 
enough or not? I think we need a more authoritative answer here.

- other guys understand GPL by strictly forbidding distribution of the GPL 
product with a non-GPL one. The nice XVID codec is released under GPL and 
here is what they say:
http://www.xvid.org/FAQ.42.0.html (go to the license questions).
In that case they say that even I only package the XVID codec with a 
proprietary software with the soly purpose to install it in Windows and 
after that I use only the Windows interface to it (like any other 
proprietary Windows software does) , GPL forbids me to do that.

- I didn't find any commercial projects (not Operating Systems or 
dual-licensed but simple applications) which package GPL applications with 
proprietary ones. If you know such applications, please let me know so I can 
check their license.

- during the testing, I saw that YASM can also assemble a GAS compatible 
syntax. I tried to use it and it worked well, except the fact that the 
segments names were too long for the COFF format, because of a standard 
prefix added to them by the llvm native generator. In that case I don't know 
if the link phase will be done ok (especially if the linker is able to 
remove the unused segments or setup the correct segments attributes).

For now, I think for a commercial developer who wants to create a complete 
compiler toolchain using llvm, trying to package its compiler with GCC is a 
very dangerous decision. If I am myself in that situation I should not do 
it, but instead I should try to use a non-GPL assembler and linker. So, from 
my point of view, the necessity of an I86 native target who address a 
BSD-like licensed assembler, strongly remains.

Razvan