No source code, of course ?

Can you write a version for OSX 10.5.x please?

Other people might want to do the porting work... but without the source code, it's hard.

+1 for you! I couldn't get kArmTI since I use a Mac, so this is perfect!
Hehe great port

If nspire_emu were licensed under a license that forbids closed-source derivatives, indeed, SpiroH's forks should be taken down.
However, the license of nspire_emu (rather, the lack thereof) allows anybody to fork it, without providing the sources of the fork, without contributing modifications back to upstream, without trying to work with upstream, or anything...

A possible reason for that state of fact (I don't know) is that Goplat assumed that people would be good citizens and would care about the community, so a license that forbids closed-source derivatives would be superfluous.
However, unlike all other persons who worked on nspire_emu and/or its derivatives, SpiroH has proved otherwise. Despite gentle (and explicative, at the beginning) calls from multiple persons to lighten up, he keeps spewing closed source forks based on an outdated version of nspire_emu. That version doesn't have UI improvements, GDB support, partial Nspire CAS+ support - the sum of which represents thousands of lines of changes and reorganization in the source code. The release of that version was delayed as a result of SpiroH's closed-source forks.
Him not showing signs of getting a clue about why what he's doing is harmful to the community, and not providing his reasoning for doing so, has raised exasperation.

If nspire_emu were licensed under a license that forbids closed-source derivatives, indeed, SpiroH's forks should be taken down.
However, the license of nspire_emu (rather, the lack thereof) allows anybody to fork it, without providing the sources of the fork, without contributing modifications back to upstream, without trying to work with upstream, or anything...

A possible reason for that state of fact (I don't know) is that Goplat assumed that people would be good citizens and would care about the community, so a license that forbids closed-source derivatives would be superfluous.
However, unlike all other persons who worked on nspire_emu and/or its derivatives, SpiroH has proved otherwise. Despite gentle (and explicative, at the beginning) calls from multiple persons to lighten up, he keeps spewing closed source forks based on an outdated version of nspire_emu. That version doesn't have UI improvements, GDB support, partial Nspire CAS+ support - the sum of which represents thousands of lines of changes and reorganization in the source code. The release of that version was delayed as a result of SpiroH's closed-source forks.
Him not showing signs of getting a clue about why what he's doing is harmful to the community, and not providing his reasoning for doing so, has raised exasperation.

Ah that sucks. I do not program anymore, but if I ever decided to do it again and my source was available, I would try to choose a license that limits certain rights, while still allowing the use of the source under certain conditions.

Personally, the only real motive I could see from a project that remains closed source far into its progress is to compete head-on with the software the fork originated from.

I wonder if a software license can be changed as it progresses? Can, for example, an open-source software start limiting the usage of its source to only specific TI community users or force people to open-source their softwares, and of course still allowing anyone to update the original project? The current builds could still be forked, but newer versions with added features wouldn't, meaning that any closed-source softwares would eventually be far behind.

And then, if the author of the fork ever decides to add new features himself, then nspire_emu contributors can counter that by copying any new emulation/compatibility features the fork author adds?

Of course the above is assuming that an open-source software can switch to a different licence in the very middle of its development, though.

Yeah I agree, although if nothing is going to change in the next year or so for example, I would rather see Nspire_Emu progress with unnecessary extra work than see it stalled for maybe 1, 2 or even 3 years just because a competing project potentially take that long before becoming open-source.