Linked by Thom Holwerda on Wed 15th Jun 2011 14:23 UTC, submitted by Valhalla
General Development "PathScale announced today that the EKOPath 4 Compiler Suite is now available as an open source project and free download for Linux, FreeBSD and Solaris. This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers." More here.
Thread beginning with comment 477648
To view parent comment, click here.
To read all comments associated with this story, please click here.
boldingd
Member since:
2009-02-19

The question is, if a GPL compiler does not restrict the license of compiled works, why is the GCC GNU exception needed in the first place? Why not place any runtime libraries under LGPL? I'd imagine other people want to know too, but by now they're intimidated from asking.


The reason an exception is needed is because some "trivial libraries" that are covered by the GPL are automatically linked into compiled code. As to why not use the LGPL, I don't know for sure, but my best guess is that the LGPL only allows dynamic linking, whereas what we're talking about sounds more like static linking -- inserting the compiled form of these trivial libraries directly into the resulting executable. The LGPL (IIRC) doesn't allow that (without an exception).

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

"The question is, if a GPL compiler does not restrict the license of compiled works, why is the GCC GNU exception needed in the first place? Why not place any runtime libraries under LGPL? I'd imagine other people want to know too, but by now they're intimidated from asking.


The reason an exception is needed is because some "trivial libraries" that are covered by the GPL are automatically linked into compiled code. As to why not use the LGPL, I don't know for sure, but my best guess is that the LGPL only allows dynamic linking, whereas what we're talking about sounds more like static linking -- inserting the compiled form of these trivial libraries directly into the resulting executable. The LGPL (IIRC) doesn't allow that (without an exception).
"

Copyright law itself says differently. Copyright law says that a later work is a derivative work of an earlier work only when the later work INCLUDES MAJOR ELEMENTS of the earlier work.

Since dynamic linking means that the linked code is not actually included in the distributed code of the later work, under copyright law itself dynamic linking is never a problem.

If you think about it, dynamic linking is no different in essence to calling an OS function anyway. All programs must call OS functions, yet they are not derived works, as they do not actually INCLUDE those OS functions within themselves. Apart from the mechanisms used to invoke the functions, how is dynamic linking any different in principle from this?

With static linked code, however, that code is indeed INCLUDED in the programs that link it in. One needs LGPL-like exemptions in order to static link to someone else's code. The exemptions provide the permissions to use the code in this way under copyright law.

The GCC exemptions are provided only to make it EXPLICITLY clear that the GPL copyleft of the compiler itself does not apply to the programs compiled with it. Under copyright law this is the case anyway (because no MAJOR ELEMENTS of GCC itself are INCLUDED into the compiled binaries), but the GCC developers did not want for people to have to rely on that, they wanted to make it explicitly clear.

Reply Parent Score: 2