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

"Razvan Aciu" <admin at kam.ro> writes:

[snip]
> The problem is with the gcc and binutils licence. This is GPL and
[snip]

I agree with Owen Anderson on this one (altough IANAL, etc).

[snip]
> In that respect, if someone can adapt the MASM templates to produce
> NASM directives (it is the only thing that needs to be changed), these
> updates will be more than welcome.
Did you notice that YASM claims support for GAS syntax?

-- 
Oscar

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

On May 13, 2008, at 10:04 PM, Razvan Aciu wrote:
> 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:
> 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.
Hi Razvan,

I don't want to discourage you, but you are basically asking for  
interpretation of legal documents.  This is a very tricky area, and  
taking advise from random people on the internet is not a great idea  
(extension of the "on the internet noone knows you're a dog"
theory).
If you really really need to know the answer to questions like these,  
the best bet is to hire legal council.

If you just want a reasonably sure bet, you can look to the lead of  
others.  In the US, there are many organizations comfortable with  
integrating LLVM and GCC and using GNU tools in the toolchain of  
proprietary compilers.  If your situation is similar to those, you may  
be satisfied that you won't have a problem.
> 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.
As I mentioned before, I would support people who wanted to extend the  
scope of this project to include new toolchain pieces.  All that we're  
missing is for someone to actually do the work :).

-Chris

On Wed, 2008-05-14 at 08:04 +0300, Razvan Aciu wrote:
> So, from 
> my point of view, the necessity of an I86 native target who address a 
> BSD-like licensed assembler, strongly remains.

-x86-asm-syntax=intel and NASM don't work for some reason?

-- 
Michael T. Richter <ttmrichter at gmail.com> (GoogleTalk:
ttmrichter at gmail.com)
In his errors a man is true to type. Observe the errors and you will
know the man. (孔夫子)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080514/c01466da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080514/c01466da/attachment.sig>

On May 13, 2008, at 10:04 PM, Razvan Aciu wrote:
> 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?
No.  Notice the lack of internal data structures.  The interface used  
is the defined by the language standard, the command line, and the  
normal compiler output (error messages and warning messages).
> I think we need a more authoritative answer here.
You'd have to ask the copyright holder, if you cared enough.
> - other guys understand GPL by strictly forbidding distribution of  
> the GPL
> product with a non-GPL one.
Each use can be different, different uses, different answers.  codec  
are not similar to gcc as a command line tool.
> - I didn't find any commercial projects (not Operating Systems or
> dual-licensed but simple applications) which package GPL  
> applications with
> proprietary ones.
Xcode does.
> 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.
Yes, it is dangerous if you violate copyright.  Hint, don't do that If  
you don't do that, there is no danger.

Oh, and the canonical place to ask about GNU owned code or the GPL  
would be gnu.misc.discuss, this isn't the right place.