Submitted by “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.
How fast can i convert the code i have made for compilation with GCC tools. What benefits would i get when using this compiler. Would binaries made with this software be in any legal danger if it is licensed under a different license than the compiler tools?
Lots more of questions i guess, but lastly what would be the performance when using EKOPath compared to GCC when using a small/medium/large code base?
Some of your questions are answered in the linked article…. I think all of them in the forums at Phoronix.
Ok i will look into it more deeply. Thank you.
EDIT: Will the suite make for faster binaries? That i could not find a definite answer for on phoronix.
Edited 2011-06-15 15:18 UTC
As most modern compilers, they know to optimize patterns, sometimes with a wider applicability or lesser one.
EkoPath is optimized for HPC workloads (similar with Intel Compiler to one level) and for Amd64 bit only, meaning that they had in some cases opportunities to make the best code.
So at the end: if you have tight scientific code there will be a visible at least 20% speedup over GCC. Also the runtime have more optimized runtime methods, so if the application will use them, can see more benefits, but who knows!?
At the end, will a distro recompile everything to EkoPath? I think that is unlikely: the binaries are a bit bigger as far as I’ve sow and the speed is not obtained most likely just from this. Will a browser vendor recompile their products to obtain a bit faster layouting? Maybe.
At the end I think you will simply win if you will have to render a thing for a week and worth the price to recompile the raytracer to finish if things will work smooth in 5 days, and one day of you will be free.
Whoa, let’s not make such sweeping statements shall we, even in the very small current Phoronix testbed there’s a benchmark where ekopath loses out to gcc 4.5 (which is what it was benchmarked against). That said, judging by most of the benchmarks there’s potentially alot of performance to be had from this specifically Intel/AMD 64-bit targeted compiler suite.
Also hoping it will have alot better GCC compability than ICC had last time I tried it.
For those of us with Intel/AMD 64-bit systems there could be alot of performance to be had in heavily computational applications, and Pathscale is obviously very set on keeping the bar high, given that ekopath failing to beat GCC or any other compiler in performance is considered a bug by Pathscale.
Gentoo ricers, mount up!
/etc/portage/packages.compiler
I’ve been maintaining the LAPACK build and test infrastructure for ~ 6mo now and we’ve seen great performance numbers out of the PathScale compilers. Typical runtimes for the LAPACK test suite running 4 tests in parallel for 98 tests (this is on a 2 year old quad core xeon):
GNU Fortran : 1.5 min.
Intel Fortran : 0.7 min.
PGI Fortran : 0.7 min.
PathScale Fortran : 0.4 min.
I was blown away by it myself and almost didn’t beleive it. I’ve seen comparable results with other C++ code bases. There are many contributing factors to the performance of your code (often HPC code will depend heavily on an optimized math library) and everybody’s codebase and workload is different, but speaking from experience, for math intensive code the PathScale compiler is really top notch.
CodeMonkey,
“I was blown away by it myself and almost didn’t beleive it. I’ve seen comparable results with other C++ code bases.”
If this is true, I’ll need to take a look into it.
I downloaded the trial, but it wouldn’t run on this 32bit system (silly me).
Unfortunately I cannot afford the price “Starting at $1795”, which is a yearly price?
Like everyone else, I didn’t find any open source code. Technically they might not distribute the source code to non-customers.
Does anyone know what they mean by “open source”? The following statement gives me the impression they’re not going to use GPL3 for the debugger or the compiler.
“In addition to the compiler, this release also includes PathDB, a modern debugger. PathDB has been released under a permissive license, in response to requests from the open source community for a modern debugger that is not encumbered by the GPLv3.”
I hate speculating, does anyone know the details?
https://github.com/path64/repositories
AFAIK these are the source code repositories for path64 compiler and debugger. However, unless I’m mistaken not all proprietary path64 features has yet been added to this repo but they will be (it’s after all the whole point of this announcement).
Meanwhile you can try out prebuilt nightlies from the homepage: http://www.pathscale.com/ekopath-compiler-suite
The compiler suite is open sourced under GPLv3, the debugger is released under BSD (same goes for their libcxx runtime).
The debugger is CDDL and there’s two github accounts to watch.
github.com/path64
github.com/pathscale
The runtimes are at the pathscale account. We’re in the process of also pushing the developer documentation, assembler and some build glue soon.
No, there’s the code and the binaries too http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-4….
The compiler and runtime libraries have been released under gplv3.
If the compiler gives an error about crt1.0, you just need to create a symlink /usr/lib64 who points to /usr/lib
pabloski,
“No, there’s the code and the binaries too http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-4…... ”
Thanks,
I was looking for the source separately and didn’t realize it was packaged in the 64bit executable. I’ll have to wait until I get to a 64bit linux system to look at it. There’s github in the meantime.
Edited 2011-06-16 11:24 UTC
When the announcement was made they didn’t have code published yet. According to PathScale it should be ready “soon”. I believe it will first be on thier website and then pushed to github (not path64 on github, no further commits will be made there).
About 6 months ago I reached out to PathScale along with several other compiler vendors. I asked if they’d be willing to donate a license to thier compiler for use with the LAPACK project and it’s nightly build and test infrastructure. So I wasn’t a customer but they were will to help support the open source community and did in fact donate a license to us.
Wow, that is good.
Yes we’ve joked about that in development, compiler benchmarking (and even language benchmarking) in many cases end up being a comparison of which one comes with the most optimized math lib for your particular platform.
Your timings are meaningless without details!
What compiler versions? What compiler options?
Is this wall-clock or cpu-time?
With pathf95, built from today sources, I
cannot compile lapack from netlib without
hitting an internal compiler error. This,
of course, means that the execution time
of any lapack benchmark cannot be obtained.
Wall clock time
These weren’t with super aggressive optimizations but with “safe” optimizations. Trying to do things like -Ofast on most compilers will often break the numerical accuracy of the LAPACK code so anything over O2 is recommended to be avoided.
gfortran 4.4.0 : -O2 -march=native
ifort 12.0 : -O2 -xHost
pgif90 13.1 : -O2 (pgi does the equiv. of march=native by default)
pathf90 4.0.10 : -O2 -march=native
Perhaps an issue to take up with PathScale and your particular setup but two of the nightly LAPACK svn builds are with the previously linked to 4.0.10 nightly build from 2 days ago.
Please note that this is not designed to be a benchmark but simply the test suite for the code base. It was just one example of code that I’ve seen and worked with that shows great gains from the PathScale compiler.
And for those who might be wondering, this is not using an optimized BLAS imlementation but instead the netlib fortran BLAS was built as part of the LAPACK build. On larger datasets and matricies building against an optimized BLAS (like goto, atlas, mkl, or acml) can make a big difference but for the small data sizes in the software test suite the difference is not significant.
As with all GPL programs, the GPL license and the associated copyleft provisions apply to the source code of the (GPL’d) program itself (in this case, the GPL applies to the source code of the EKOPath 4 Compiler Suite). You have unlimited, irrevocable, unconditional permission (under the GPL) to use (as in run it) such a program however, wherever and whenever you wish, for any purpose. The only act to which copyleft provisos apply is if you decide to re-distribute said compiler tools to other people.
Whatever source code you write is your code, to license as you please. It matters not one whit that you used a particular compiler to compile that code (just as it matters not one whit what particular text editor you used), if you wrote the source code you are still the author, and the copyrights to your source code belong to you. What you do with your code is not at all constrained by the GPL unless you choose to release your code under the GPL.
Edited 2011-06-16 02:37 UTC
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.
Edited 2011-06-16 03:12 UTC
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
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
Apart from the fact that the intentions of the FSF have no bearing on copyright law itself, it is also pertinent to note that while the FSF’s has claims over GCC source code, despite being the original authors of the GPL license template text the FSF does NOT in fact have claims over “EKOPath 4 Compiler Suite” source code.
So the only sane conclusion from this observation is that whatever the FSF might believe in this scenario is DOUBLY irrelevant.
lemur2,
“So the only sane conclusion from this observation is that whatever the FSF might believe in this scenario is DOUBLY irrelevant.”
I didn’t mean to imply the FSF has any say over EKOPath. If PathScale took the same stance as the FSF but uses the GPL without exceptions, it could be their intent that the open source EKOPath should only be used for GPL code.
I agree it sounds ridiculous, but your earlier post made it sound like you weren’t aware of the exceptions for GCC, which is why I brought them up.
Edited 2011-06-16 04:33 UTC
Here is the actual opinion of the FSF on this topic, in their own words, without any agenda-driven interpretations on top of it:
http://www.gnu.org/licenses/gpl-faq.html#DoesUsingTheGPLForAProgram…
The FSF opinion in relation to the copyright law requirement that a derived work results only when a major element of an original work is INCLUDED in another work:
QED. It turns out that the FSF do indeed understand copyright law, and it is only you who is confused.
Your references are now TRIPLY irrelevant to the original question. (PathScale’s views are only SINGLY irrelevant).
You are utterly incorrect on this topic, not only according to copyright law itself, but also according to the FSF.
Edited 2011-06-16 04:54 UTC
Sorry, I should have expressed that differently.
It should have read as follows:
“Your mistaken interpretation of FSF’s views on this topic are now TRIPLY irrelevant to the original question. PathScale’s views, whatever they may be, are only SINGLY irrelevant.”
lemur2,
“Q: Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them?
A: Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.”
The answer above is (apparently) referring to this snippet:
“The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.”
So it’s clear cut for editors, but it’s not so obviously simple for things like compilers.
“Q: Do I have “fair use†rights in using the source code of a GPL-covered program?
A: Yes, you do. ‘Fair use’ is use that is allowed without any special permission. Since you don’t need the developers’ permission for such use, you can do it regardless of what the developers said about it—in the license or elsewhere, whether that license be the GNU GPL or any other free software license.”
No copyright holder can restrict fair use rights, but I don’t see how this is at all relevant to this discussion? Are you suggesting that we have a fair use right to use GCC without a license? I really don’t understand what you are getting at.
“QED. It turns out that the FSF do indeed understand copyright law, and it is only you who is confused.”
Perhaps I am, but I brought up relevant points, and it appears that you are no less confused than I am.
“Your references are now TRIPLY irrelevant to the original question. You are utterly incorrect on this topic, not only according to copyright law itself, but also according to the FSF.”
Wow…what did I trigger to make you lash out like this? While you were counting irrelevant levels of irrelevance, I think you forgot to ponder why the FSF has GPL exceptions for GCC.
Sigh!
There is a concerted effort in anti-free-software camp to spread FUD and misinformation about the GPL. Your triply-irrelevant argument sure reads to me like more of the same.
So, here again was the original question: “Would binaries made with this software be in any legal danger if it is licensed under a different license than the compiler tools?”
The answer to this quetions is NO, NO, NO, binaries made with this software would NOT NOT NOT be in any legal danger if it is licensed under a different license than the compiler tools.
The three-times-over assetrion of “NO” comes about because:
(1) Copyright law itself says that the license of the compiler has no bearing on code you complile with it if that code does not include the source code of the compiler itself.
(2) Although the GPL was written by the FSF, the FSF did not write the EKOPath 4 Compiler Suite, and so any opionion of the FSF has nothing to do with the EKOPath 4 Compiler Suite.
(3) Even if the FSF view on this topic had anything to do with it, that view is clearly stated in the FSF FAQ … “Q: Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them? A: Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.” What could be clearer?
Your argument is, so far, three-times-over wrong.
Now let’s look at your reference to the GPLv3 exceptions, and the stated intent of the FSF regarding that:
http://www.gnu.org/licenses/gcc-exception-faq.html
Here is the up-front text explaining the intent of the FSF:
So, you see, using GCC means that the produced program does necessarily end up INCLUDING some libraries from GCC itself. The exceptions are therefore required, even with GPLv3, to ALLOW “people to distribute the object code GCC produces under any license”, not prevent it.
So, apart from the fact that your code is your code and you license it however you want, apart from the way that copyright law works in regard to derived works, apart from the fact that PathScale is not the FSF, apart from the stated top-level intent of the FSF to allow people to use GPL code for any purpose (including to write nonfree code if they want to), it turns out that you are still wrong about the GPL exemptions because they have the exact opposite intent to what you imagined.
This makes you, now, quintuply wrong with respect to the original question.
Edited 2011-06-16 06:19 UTC
lemur2,
“There is a concerted effort in anti-free-software camp to spread FUD and misinformation about the GPL.”
I’m merely trying to understand why a GPL exception is needed for GCC and not EKOPath? Maybe it’s a mountain out of a molehill, but I honestly want to know.
“The answer to this quetions is NO, NO, NO, binaries made with this software would NOT NOT NOT be in any legal danger if it is licensed under a different license than the compiler tools.”
Man you are dense, the question is whether one is allowed to use a GPL compiler to build non-GPL code (see title). I never suggested that anyone would be punitively forced to release their code as GPL if they were in violation of the GPL.
“So, you see, using GCC means that the produced program does necessarily end up INCLUDING some libraries from GCC itself. The exceptions are therefore required, even with GPLv3, to ALLOW ‘people to distribute the object code GCC produces under any license’, not prevent it.”
The passage you quoted (from my link, btw) agrees that the exception was designed to allow the compiler to be used to produce non GPL binaries, the implication being that without the exception, compiling non-GPL code would not be allowed (and anyways, the gnu-C libraries are LGPL).
“(1) Copyright law itself says that the license of the compiler has no bearing on code you complile with it if that code does not include the source code of the compiler itself.”
You ignored my post here:
http://www.osnews.com/thread?477352
“(2) Although the GPL was written by the FSF, the FSF did not write the EKOPath 4 Compiler Suite, and so any opionion of the FSF has nothing to do with the EKOPath 4 Compiler Suite.”
You ignored my post here:
http://www.osnews.com/thread?477354
“(3) Even if the FSF view on this topic had anything to do with it, that view is clearly stated in the FSF FAQ … “Q: Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them? A: Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.” What could be clearer?”
You ignored my post here:
http://www.osnews.com/thread?477358
“Your arguement is, so far, three-times-wrong.”
You’re one ignorant dude.
“This makes you, now, quintuply wrong with respect to the original question.”
What happened to quadruply?
I’m not trying to win a debate here, just trying to get an answer, you just seem to be obsessed with trolling.
Edit: I don’t see a point in continuing this, and I’m sure you feel the same way.
Edited 2011-06-16 06:49 UTC
Regarding “quadruply” … you are twice wrong about the GCC GPL exemptions.
(1) the exemptions apply to small GCC libraries, the EKOPath 4 Compiler Suite does not necessarily use those same libraries. If it does, then the same exemption from the FSF applies, because the libraries are FSF code, not Pathscale’s code. If it doesn’t use those libraries then the exemptions for those GCC libraries are still not needed for the EKOPath 4 compiler. Der.
(2) the GCC libraries, according to the FSF, are only minor parts of the whole of GCC. The exact text the FSF used to describe this is “the tail wagging the dog”. Even without any exemptions, the equivalent libraries from the EKOPath 4 compiler, if they exist, would still only be a minor part of the whole compiler, and hence they would be allowed under the fair use type provisions of copyright law, even without explicit exemptions. A derived work, remember, results only when MAJOR ELEMENTS of an original work are included. Not small libraries.
The GPL exemptions are only there, as they say, “to be sure, to be sure”. They are there to make absolutely sure that even dolts like you can not get confused.
Apparently, they don’t achieve that aim.
Edited 2011-06-16 07:02 UTC
Not really, it’s just saying “we modified the license of the libraries that get linked in, because if those were under the full and normal GPL, you’d have to GPL the program itself”. That’s different: If they didn’t, you could in theory provide your own libraries as a replacement and still use the gcc – in which case that entire paragraph doesn’t apply, except that it implies that those libraries would have been the only thing keeping you from using it to compile non-GPL programs.
See long rant in post below; you’ve got an incorrect definition of “derivative work” that’s leading you into trouble.
The F.A.Q. snippet that you’re trying to portray as a derivative of something else is stand-alone, and it’s telling you exactly what lemur and I are trying to tell you: the product of a software tool is not itself a derivative work of that tool, unless and only if it includes substantial portions of that tool. Which is essentially what “…the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program)” means in plain English.
First, you’re really having to try, hard, to get the readings out of these texts that you are. They’re in many cases specifically telling you that the tools license never applies to its product, not just as a quirk of the GPL but as a matter of course, and you’re somehow getting from that that “ZOMG GPL APPLIES TO ALL GCC-GENERATE OBJECT CODE.” Which is crazy.
Second, this is old, dead (I thought) F.U.D. It’s frustrating to see it cropping up again.
boldingd,
“See long rant in post below; you’ve got an incorrect definition of ‘derivative work’ that’s leading you into trouble.”
I unadvisedly used “derivative work” instead of “covered work” as the GPL3 uses. The GPL3 is no longer dependent on a legal definition of “derivative work” since it doesn’t use the term anywhere.
In the GPL3, the term “covered work” refers to the work which is covered by the GPLv3 license.
In the case of GCC, GCC is the covered work.
Copyright law defines what is meant by “derived work”. Since the GPL relies on copyright law, no matter what the text of the GPL itself says, the copyright law definition of derived work definitely applies.
Only derived works or literal copies of an original work can violate copyright, there are no other options. This is the law.
lemur2,
“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.”
Then maybe that’s why they got rid of the terminology “derivative work” and replaced it with “covered work” in gpl3.
Hypothetically, MS could release a free educational edition of MS-Word which was only to be used for public domain educational research papers under a license which explicitly revokes the rights for any other use.
Do think someone could obtain MS-Word under this license and legally claim that they’re entitled to use Word for private/commercial work when they get caught?
If not, then how the GCC case different?
Keep in mind that both the GPL2/3 revoke rights in this manor.
GPL2:
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.
GPL3:
12. No Surrender of Others’ Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
No, those are two different (though sometimes related) things. A “derivative work” is, as has already been mentioned, defined in copyright law. A “covered work” is a work “covered” by a particular license (GPL3 in this case). A derivative work of a GPL3 covered work would also be a covered work. But a derivative work of a BSD-licensed covered work might or might not be a covered work.
Hypothetically, Microsoft could do that, yes. The cases are different because that’s not what the GPL says. Again: “derivative work” is a legal term explicitly defined in copyright law.
cmchittom,
“Hypothetically, Microsoft could do that, yes. The cases are different because that’s not what the GPL says. Again: ‘derivative work’ is a legal term explicitly defined in copyright law.”
I don’t know if I want to touch this again, but this is mixing up two separate points. The fact that our documents are not derived from MS sources has no bearing on whether MS can legally specify the types of documents we are permitted to work on under a public/educational Word license.
In the same vein, a visual studio license would have the right to limit our use to non-commercial code, regardless of whether our source code is legally derived from anyone else’s.
Edited 2011-06-16 14:27 UTC
It’s not. This is an old question, with an old answer. Compiled binaries are not derivative works; anything you create with a GPL’ed tool is yours to do with as you please (as is true with any other GPL’ed program that produces something, like the GIMP).
Let me include the whole FAQ entry in question:
What they’re specifically talking about here is preventing some “clever” third party from using GCC’s plug-in architecture to attempt to circumvent the GPL license covering GCC. Basically, if you use a plug-in to operate on the low-level in-memory structures that GCC is using to compile your code, you don’t get the license exception that allows you to include the technically-GPL’ed trivial libraries that GCC is going to link your code with under other licenses. This has no effect on normal use of the compiler.
You really had to torture your reading of that page to get to that conclusion. The very first two paragraphs specifically state that the GCC developers have always intended to support proprietary development, even if they don’t particularly like it. The second and third paragraphs of your own link:
My Bold.
So, first, it is definitely legal to distribute binaries built with GCC under any license, and it is definitely the FSF’s intention that that be the case. Second, that page is in its entirety about including license exceptions for “small, trivial libraries” that GCC automatically links into compiled object files specifically so that they can be distributed under proprietary licenses.
The FSF isn’t claiming that the GCC’s license applies to code that it generates. That isn’t how “derived work” has ever been understood to be defined. What they’re saying is that GCC links trivial libraries into the object code that it generates, and that those are covered by the GPL; that’s where the “GPL infection” is coming from. Exactly because they felt like it would be inappropriate to force the GPL onto any object file built with the GPL, they included exceptions in the license of those trivial libraries allowing them to be included in proprietary programs.
boldingd,
Thank you for trying to understand my points and putting them in the context they needed. I very much appreciate your candid response minus the arrogance and down speaking.
I agree with your conclusion that the FSF wants GCC to compile code under any license.
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.
Edited 2011-06-17 20:45 UTC
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.
This question has already been asked, and answered. The small libraries included by GCC into compiled works are not major elements of GCC, and so the works compiled by GCC are not derived works of GCC, under the definitions in copyright law.
However, the authors of GCC did not want users of GCC to have to rely on this, it would likely be seen by some people as tenuous and indirect. Detractors of free software could spread doubt about using GCC.
Far better to simply say, straight out right there in the GCC license itself, that these small libraries are exempt. Then no-one could possibly have any doubts about them.
Edited 2011-06-18 10:26 UTC
lemur2,
You are saying what you want to hear, rather than what’s true.
What the heck, if it makes you feel any better, I say you’re right about everything. Enjoy your weekend.
Edited 2011-06-18 11:07 UTC
I have said nothing at all untrue.
Copyright law says what it says, I am not making it up.
I offered you a perfectly reasonable, obvious, sensible explanation of why the license for GCC includes exemptions for small libraries, even though these exemptions are not required by copyright law itself.
It makes perfect sense.
You have got nothing. Hence your reply.
Have a good weekend yourself.
lemur2,
“You have got nothing. Hence your reply.”
My reply has to do with me being tired of this. You win, let it be.
Image the impact of this on future Linux/BSD distributions, server software, desktop software, usability, … it will be a step change upwards that the competition will face.
I’m looking forward to faster web application servers, faster encoding, smoother and snappier desktops, quicker bootups, … everything really should see an uplift.
Not sure how much impact it (the compiler, not the C++ library) is going to have on the BSDs, since it is GPL licensed. The viewpoint on licensing of the system compiler seems to vary among the BSD camps, but I suspect at some level they’d all like to see something BSD (or compatible) licensed.
That said, options are always good. The performance with this may overcome some people’s philosophical objections to its license.
So…. Aren’t BSDs already compiled by a GPL GCC?
Edited 2011-06-15 22:13 UTC
You do not need a BSD-licensed compiler to compile BSD.
This is the same deal as for books, in that the exact same copyright laws apply. You can write a book using MS Office, but even in doing so all rights to the book itself still belong to you, and not to Microsoft. Your work is still your work, no matter who made the tools that enabled you to do your work.
However the BSDs do not like non-BSD licensed software in their codebases (OpenBSD especially), therefore they try to exclude GPL licensed code … the PCC project in regards to OpenBSD is a good example.
This means only that because of its GPL license the open source EKOPath4 compiler itself would itself not be chosen by BSD distributions as the included compiler.
I agree.
That does not mean that what I said was incorrect. It still remains true to say that:
There is no requirement that you compile BSD-licensed code on a BSD system.
Edited 2011-06-16 23:20 UTC
Didn’t say it was … I was merely stating that I don’t expect the BSDs to use this because of the license. Also I also suspect it probably doesn’t run on all the platforms that they support … i.e. m68k, SPARC, SPARC64. So I would imagine that this would end up being distributed as a optional component i.e. a package.
I know.
If it is possible to use a compiler for 64-bit the x86_64 architecture which gives a considerable performance boost, why wouldn’t the BSD developers use it to build their BSD distribution? What exactly would be their problem?
As I understand it, BSD distributions have even shipped GCC in the past, which is GPL-licensed. Surely not using a good option for one of your supported platforms such as the EKOPath 4 compiler (even if you don’t ship it) just because it has a GPL license is simply a rather obvious case of cutting your nose to spite your face.
Edited 2011-06-17 11:00 UTC
I dunno about NetBSD or FreeBSD … but with OpenBSD the idea of for pcc was faster compile times so times between testing could be reduced.
I am a web dev so a lot of this stuff goes over my head … however I believe this
http://www.informit.com/articles/article.aspx?p=1168313&seqNum=1
may answer some of your questions.
I think this is important though,
“Having to support only a single compiler can reduce development costs, however.”
BSDs have less developer resources and I think having one compiler for the source tree that works on all target archs and is less complex compiler is a benefit.
Edited 2011-06-17 12:07 UTC
Open-sourcing the suite is definitively great and welcome step from PathScale. But where do I find the sources or at least a download link for EKOPath 4? The only link on product page is for nightly build, which is a binary installer with (presumably) some non-free components, as its license dialog suggests.
I’m not a free software zealot, but just trying to understand: is it only PR for now, or the code is actually released?
Thanks for hints.
The thirsty red chicken walks at midnight with a broken cane.
Ergo:
https://github.com/path64
I didn’t see any links to the source and project page yet too. May be the statement came out before the actual opening took place.
This compiler set is descended from SGI MIPSPro compiler family via Open64. Awh IRIX happy memories.
Not via Open64.
This compiler was forked from Pro64 not Open64. However, Open64 contains patches derived from parts of this compiler that were open source before.
Does this mean anything for us unwashed masses of end users, or is it purely something for the code monkeys to drool over?
Using the EKOPath 4 Compiler Suite for compiling most C, C++ and Fortran code for Intel 64 and AMD should result in significant performace improvements over binaries compared to the same source code compiled with GCC.
This means that 64-bit binaries (for programs where you have the source code) will get faster. FOSS software has the source code … even for drivers and the core OS.
Therefore, any given Linux distribution (for example) now has the opportunity to make significantly faster 64-bit binaries, across the board, than they could previously afford.
Drivers, kernel, graphics layers (including the likes of Cairo, GTK and Qt) … even media players and codec decoders … should all get a significant performance boost. Then there are the applications themselves, which should likewise enjoy a performance boost.
It seems to me to be something to really look forward to for end-users (of Intel and AMD 64-bit FOSS systems).
Sorry I’m late to this conversation (actually I’m not sorry based on some of these other posts)
What I’d like to do is share my biased perspective in general. EKOPath has historically catered to a certain audience and as a result a specific type of code. (HPC which is mostly computationally complex stuff) The performance for that does carry over in most cases (not just EKOPath) to other types of code. I’m happy with a bit of hype, but I want people to have realistic expectations. Something like your cli tools are unlikely to see any gains. Something like mesa which was recently benchmarked could see FPS go from 295 to 301 (I don’t remember the exact numbers, but you get the idea)
Keep in mind we’re not perfect, but…. – If you’re code isn’t faster we’re going to work with you to fix it. So the potential gains long term imho are there for anyone to at least try.
In the future multicore systems are going to be more commonplace. (Even in your mobile phone) The compiler infrastructure needs to be able to handle the different types of optimizations which are needed to ensure best performance. Languages like C++ may get more/less complex. Our goal whether it’s for C++/Fortran/ or something new will be the same.
Nice, going by all this it means that we may even see some nice gains in the CPU limited Gallium3D drivers correct?
Things are looking really good then for my next build if AMD can get Gigabyte to do an A75 Fusion mobo with Coreboot instead of BIOS or UEFI so I can FOSS while I FOSS!