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

Hello, Razvan

after that I use only the Windows interface to it (like any other
proprietary Windows software does) , GPL forbids me to do that.

That's due to nature of the interface. Binary interface to codec make
the proprietary application 'derived work'.

- 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.

Owen have given bunch of them. I'll just repeat: Apple's XCode IDE + gcc
+ gdb. Also - it uses gas and bunch of stuff from binutils, but
proprietary linker.

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).

That's linker job.

my point of view, the necessity of an I86 native target who address a
BSD-like licensed assembler, strongly remains.

I'd suggest consult a good lawyer instead, without even trying to
interpret anything by yourself.

Hello, Razvan

Just a note, Anton: your e-mail client doesn't preserve threads.
Any idea on if you could fix this?

(I've heard of hacks/patches/addons for Outlook if you're using
that beast)

Hello, Razvan

> after that I use only the Windows interface to it (like any other
> proprietary Windows software does) , GPL forbids me to do that.
That's due to nature of the interface. Binary interface to codec make
the proprietary application 'derived work'.

This is what the FSF would like the world to believe.

If you distribute the GPLed library and the proprietary application
separately, and make sure that they are linked at installation time, the
link step creates a derived work indeed but that's inconsequential
because it isn't redistributed.
IANAL etc., and there are issues regarding the use of interface files
(.h files etc.) from proprietary code, but it should hold up well
enough.

(Not that I don't like the intentions of the FSF. I just don't think
their legal strategy will hold up in the long run.)

I'd suggest consult a good lawyer instead, without even trying to
interpret anything by yourself.

I'd suggest doing both.
The interpretation may be wrong, but it might help get the lawyer
thinking outside preestablished boundaries. That would be crucial if
these boundaries originated e.g. in what the FSF has published.

Regards,
Jo

Hi,

If you distribute the GPLed library and the proprietary application
separately, and make sure that they are linked at installation time, the
link step creates a derived work indeed but that's inconsequential
because it isn't redistributed.

Interestingly enough, you need a linker at the target system to do that. And
guess what this discussion started at :-p

Gr.

Matthijs

This thread is completely off topic. Please stop.

GPL vs BSD flamewars have no place on llvmdev. The technical discussion of this thread ended when I suggested that if he wants a BSD toolchain that he go build one. If you want to discuss details of making it happen, go for it. Until then, stop talking dragging out a pointless thread.

-Chris