PathScale Open-Sources The EKOPath 4 Compiler Suite

[codestr0m]

<bored>
1) If you're concerned about building proprietary software with a recently open sourced compiler - might want to look elsewhere for help. IANAL and IANYL
2) If you're brittle - might want to unplug now
3) I don't like the guy
4) License issues in general waste time - No discussion needed - point them at the license and tell them to go help themselves.

It wasn't a bad day, but I'd like to set a precedent for the reaction to licensing questions. (Admittedly a FAQ on this wouldn't hurt) There are numerous pro bono and paid legal services which are the appropriate place to ask. A professional building high quality proprietary software wouldn't ever ask this on irc. If he had said *open source* software I'd have cut him some slack.
</bored>

[deanjo]

A professional building high quality proprietary software wouldn't ever ask this on irc. If he had said *open source* software I'd have cut him some slack.

Truth be known "a professional" keeps his cool, period. The moment people start branding others it becomes "unprofessional".

[allquixotic]

If he had said *open source* software I'd have cut him some slack.

Well then maybe you can cut me a little slack? For my part, I have no interest in writing proprietary applications at all, but I do actively contribute to several open source projects -- some of them GPLed, and others licensed under BSD.

Me and the other posters here have made an effort to understand the licensing situation around EkoPath, both as it applies to open source projects, as well as others. Compiling all this information (no pun intended) into a clearly written Wiki document or something would be immensely helpful, and reduce the amount of future discussion necessary on the topic of licenses. "Contact your lawyer" is not always a practical or even necessary step when evaluating software; various organizations go to great lengths to reduce the amount of guesswork (or lawyer-work) required for a software developer to somewhat reliably determine the conditions under which he may use a piece of software. Free Software and Open Source licenses are specially qualified to be interpreted in a user-friendly way in a publicly-accessible document, as opposed to EULAs, because FOSS licenses are used so widely. Since each company has their own unique EULA, making a wiki or other public document for each EULA would be incredibly boring and counter-productive. Also, for most EULA software, the distributor does make a genuine attempt to inform users, in clear language, exactly under what conditions they may use, copy and distribute the software.

As an open source developer, the discussion we've been having is exactly as relevant as it would be if I were a proprietary developer. Because some of the legitimately open source software I write, is not licensed under a GPL-compatible license. But in practice, the software we write, despite being liberally licensed, has always been open source, and the community built up around it is steadfastly in favor of keeping it open source, as much as possible, just by convention (if, indeed, the BSD license doesn't strictly demand it).

Unless you define open source differently than I do, a BSD-licensed project is every bit as open source as EkoPath. But, if the conclusions that I and other posters in this thread have derived are at all true, then we can not distribute our project's compiled binaries if we build them with EkoPath, even if we deliberately include exactly the same source code used to produce the binaries. So it seems that you speak in terms of "open source", and allude to being "open source-friendly", but a project that is above-board and openly willing to remain open source indefinitely, is unable to take full advantage of your software. That's my understanding, though I could be wrong.

If this account is (1) accurate, and (2) perfectly acceptable to you, then there is nothing further for us to discuss. But I think that, at least, to more precisely capture which particular subset of open source software that you are supporting under the license terms as I understand them, you should use the term copyleft free software that is compatible with the GPL, or for shorthand, GPL-compatible software.

So in the quote above, you might have succinctly cleared up our doubts by saying instead: "If he had said *GPL-compatible software* I'd have cut him some slack."

Unless, of course, we have completely misinterpreted the licensing situation of EkoPath, in which case I apologize for my ignorance!

[RealNC]

A professional building high quality proprietary software wouldn't ever ask this on irc.

A non-professional can also build proprietary software. Look at the whole "freeware" and "shareware" stuff created by hobbyists.

He asked an important question, IMO. I have a few projects too that are "free" but not compatible with the GPL. Asking about it does not constitute license trolling. Though if someone's English totally sucks, as in this case, it might appear so.

[bwat47]

Apologies Geri.

[smitty3268]

Unless you define open source differently than I do, a BSD-licensed project is every bit as open source as EkoPath. But, if the conclusions that I and other posters in this thread have derived are at all true, then we can not distribute our project's compiled binaries if we build them with EkoPath, even if we deliberately include exactly the same source code used to produce the binaries. So it seems that you speak in terms of "open source", and allude to being "open source-friendly", but a project that is above-board and openly willing to remain open source indefinitely, is unable to take full advantage of your software. That's my understanding, though I could be wrong.

I'm not sure i understand what you're saying here. I don't think there would be any problem with a BSD-licensed project. You would compile it with EkoPath and then you are correct the binary would be licensed GPL, while all the source code would remain BSD. But then shouldn't you be able to distribute those binaries? They'd just require you to make the source available, etc. like the GPL requires. You'd almost certainly want your project to maintain compatibility with another compiler in order to allow avoiding the GPL, but I don't think it would actually stop you from doing anything in Ekopath if you wanted to add another option.

[codestr0m]

To help clarify the license question

1) GCC injects small pieces of code in your application which are GPLv3 licensed (Our crt* code, which is *very* small, isn't GPL)

2) GCC runtimes are GPLv3 in part (I assume some (all?) may be LGPL. In any event ours are not)

Once again I am not a lawyer and don't take this as legal advice.


My new signature
+
+
v
The opinions expressed here are not approved, reviewed, acknowledged nor do they represent my current employer.

[bug!]

To help clarify the license question

1) GCC injects small pieces of code in your application which are GPLv3 licensed (Our crt* code, which is *very* small, isn't GPL)

2) GCC runtimes are GPLv3 in part (I assume some (all?) may be LGPL. In any event ours are not)

Once again I am not a lawyer and don't take this as legal advice.


My new signature
+
+
v
The opinions expressed here are not approved, reviewed, acknowledged nor do they represent my current employer.

That's seriously flawed.

[ninez]

That's seriously flawed.

the real question is - if it isn't GPL or LGPL, technically what are those bits code licensed under??

..and if it turns out to be totally proprietary, then this compiler suite isn't going to be used much i dont think. maybe phoronix should do some investigative reporting on the subject...?

[energyman]

That's seriously flawed.

only if you want to compile closed source software while being too cheap to buy a licence.