llvm dev - May 2008 - [LLVMdev] 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.

--
WBR, Anton Korobeynikov

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

Am Mittwoch, den 14.05.2008, 11:27 +0400 schrieb Anton
Korobeynikov:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080514/4ae9f5c6/attachment.sig>