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.
Permalink for comment 477349
To read all comments associated with this story, please click here.
RE: GPL compiler with non-GPL code?
by lemur2 on Thu 16th Jun 2011 03:35 UTC in reply to "GPL compiler with non-GPL code?"
lemur2
Member since:
2007-02-17

lemur2, "As with all GPL programs, the GPL license and the associated copyleft applies to the source code of the program. Youy have unlimited, irrevocable, unconditional permission (under the GPL) to use the program however you wish. The only act to which copyleft provisos apply is if you decide to re-distribute said compiler tools." Hmm, I don't know if that's right. The binary could arguably be a derivative work. I think the FSF uses a different interpretation of the GPL than common sense might infer, which is why they've licensed GCC with GPL exceptions. http://www.gnu.org/licenses/gcc-exception-faq.html In the faq, read this section "Why is compiler intermediate representation excluded from the definition of 'Target Code?'" "...If that program is proprietary, the exception will not be available to any software compiled with it; the object code that GCC ultimately creates will have to be distributed under the terms of the GPL." It's pretty clear that the FSF intends GCC compiled code not covered by the exception to fall under the GPL license. If the FSF interpretation of the GPL is accurate (it would be ironic if it wasn't), then in theory a GPL compiler without exceptions can only be used for GPL projects. Edit: Personally I find this interpretation bizarre. At the extreme, there could be license ramifications for all GPL tools like 'sed' or 'grep' lacking explicit exceptions. Of course I leave it to the capable hands of more knowledgeable posters to explain it to me.


The definition of "derivative work" comes from copyright law, not from the FSF. Copyright law itself is the law, not whatever the FSF says or thinks, or is thought to say or think.

http://en.wikipedia.org/wiki/Derivative_work

"In United States copyright law, a derivative work is an expressive creation that includes major, copyright-protected elements of an original, previously created first work."


Unless your work actually INCLUDES pieces of some other work, it simply is not a derived work under copyright law. In addition, it has to INCLUDE "major elements" of another work ... mere snippets is not enough, nor is non-functional references.

This is why dynamic linking is not an issue ... with dynamic linking the linked code is not actually included, merely referenced. Only static linking actually includes external code to be distributed within another work.

So, in the case of the "EKOPath 4 Compiler Suite", unless your source code actually, literally, INCLUDES (perhaps via via static linking or by direct copy-and-paste) some "major element" of the "EKOPath 4 Compiler Suite" source code, then your work is simply not affected by the license of the "EKOPath 4 Compiler Suite" source code, under copyright law.

That is the law, no matter what the FSF might say or think.

Just as the license for a text editor program has no bearing on the ownership rights of the text one edits using it as long as one doesn't include the source code of the editor, so too does the license of the "EKOPath 4 Compiler Suite" have absolutely nothing to do with the rights to the code compiled with it, unless one includes some major element of the source code of the "EKOPath 4 Compiler Suite" itself.

Edited 2011-06-16 03:44 UTC

Reply Parent Score: 3