Homebrew So that tiicu thread has been deleted?

  • Thread starter Thread starter lordelan
  • Start date Start date
  • Views Views 13,719
  • Replies Replies 105
  • Likes Likes 6
Status
Not open for further replies.
As for releasing the source — the decision will be mine, made on my own terms, not yours or anyone else's.

That's strictly against the gpl. If you aren't providing the source code, you must provide an offer to all third parties. Anybody then who receives the binary, from you or from others, has a right to receive the source code from you for no more than the cost of the digital distribution. This must be provided for the first three years. This begins the moment you distribute a binary to anyone but yourself.

You aren't the first person on this forum to falsely believe you can provide the source code whenever you want. But it begins when you distribute the first binary, as the written offer must accompany it.

If you'd rather do your own work and release things on your own schedule, then don't use already licensed projects that require you to release the source earlier. Or don't release the binary to anybody. You can use it for your own private use. But as soon as you give somebody else the binary, you are obligated to offer them the source for three years.

Complain all you want. That's the language of the license of the project you're using.

I have no idea why this thread is still alive and not locked. You are very obviously violating the original license if you're distributing the modified work to anybody, without an offer for the source code.

Oh, and if somebody gets the binary from you and then that person sends the binary to somebody else, that somebody else also has the right to receive the source code from you upon request.
 
So, what happens if someone just says "I don't care!"? No, really.
This has happened with some keyboards using derivatives of QMK/VIA and not providing the source due to them running proprietary wireless stuff and they basically got blacklisted from QMK and no new PCBs are releasing with these features, so they either comply with the QMK/VIA license or get their own software not a single soul wants to use thus losing sales

*modsnip*
 
Last edited by DinohScene,
  • Like
Reactions: OrGoN3
Worth noting: mx4w's last repository update was August 16, 2023, yet compiled NRO files have been distributed through Patreon and private Discord channels as recently as January 2026.
Not really interested in participating in your argument but just my two cents on this:
It is highly likely that the (since 2023 untouched) source code was simply recompiled using newer libnx versions to be compatible with newer firmwares.
 
It is highly likely that the (since 2023 untouched) source code was simply recompiled using newer libnx versions to be compatible with newer firmwares.

There was at least a significant citra update last year (right eye rendering).

The source code may be available behind the paywall, though. IDK.
 
They are in violation of the license and can be reported, dmcad, sued, etc. Depending on what they're doing with it.

This has happened with some keyboards using derivatives of QMK/VIA and not providing the source due to them running proprietary wireless stuff and they basically got blacklisted from QMK and no new PCBs are releasing with these features, so they either comply with the QMK/VIA license or get their own software not a single soul wants to use thus losing sales

*modsnip*
Oh, i always seen that license brought up, and was just always curious what would legit happen if someone just said "no". lol
 
  • Like
Reactions: OrGoN3
Oh, i always seen that license brought up, and was just always curious what would legit happen if someone just said "no". lol
Yeah. It's a license that implements a copyleft (opposed to a copyright). GPL allows people to charge for their work, while being obligated to provide the source code to any holder of the binary that sends a written request.

If somebody just said no, distribution of their work may be suspended. Further actions are available to the original author. The author may choose to act or not act on the matter.
 
TICO 0.6 has been released with significant new features like N64 emulation and Retroachievements support, along with improvements like updated mesa drivers.

https://github.com/ticohq/tico/releases/tag/0.6.0

All cores have been open sourced and have their own repositories.

https://github.com/ticohq

Dev did what he promised, can't wait for the next thing people will make up to bully on him.
 
TICO 0.6 has been released with significant new features like N64 emulation and Retroachievements support, along with improvements like updated mesa drivers.

https://github.com/ticohq/tico/releases/tag/0.6.0

All cores have been open sourced and have their own repositories.

https://github.com/ticohq

Dev did what he promised, can't wait for the next thing people will make up to bully on him.
Good to know things are moving in the right direction! That said, there don't seem to be any commits from the dev in either the Flycast or Yabasanshiro repos yet

https://github.com/ticohq/tico-flycast/commits?author=dantiicu
https://github.com/ticohq/tico-yabasanshiro/commits?author=dantiicu
 
I see he's using the libretro cores and he's just making a custom frontend to use them. What I don't understand is why he forked them instead of just using the upstream cores. It just creates additional maintenance burden and the upstream cores already work with any frontend that supports the libretro API. That's how ozone/xmb/etc work.
 
That's how ozone/xmb/etc work.
Those are "just" display drivers for RetroArch though while ticu is a frontend for RetroArch itself, chainloading RetroArch with the core and the game in the background when launching anything.
It works similar to ES-DE for example.
That doesn't take away from your point that the dev may could have used the upstreamed cores (I'm not technically deep enough into this) but just wanted to make this clear. :)
 
  • Like
Reactions: SuffahBish
I see he's using the libretro cores and he's just making a custom frontend to use them. What I don't understand is why he forked them instead of just using the upstream cores. It just creates additional maintenance burden and the upstream cores already work with any frontend that supports the libretro API. That's how ozone/xmb/etc work.

Guy is clearly doing work on the cores themselves as he said it was. As I said in my post a while ago, we would have already seen retroarch being viable for platforms like Dreamcast and Saturn on Switch if it was "just" upstream.

He is also still being petty about the Saturn core, as that one has seen an updated release but no change in the repo. I do think he should change that and upload the source code changes.

it's almost as if the guy was legit just slapping open source emulators on his vibecoded frontend!!!!

Again with the groundless accusation of vibecoding and undermining the work of the guy and acting as if the emulator cores were never attributed from the beginning...
 
Those are "just" display drivers for RetroArch though while ticu is a frontend for RetroArch itself, chainloading RetroArch with the core and the game in the background when launching anything.
It works similar to ES-DE for example.
That doesn't take away from your point that the dev may could have used the upstreamed cores (I'm not technically deep enough into this) but just wanted to make this clear. :)
Yeah. Probably should've used Lemuroid as an example instead. That's an actual alternate frontend.
Guy is clearly doing work on the cores themselves as he said it was. As I said in my post a while ago, we would have already seen retroarch being viable for platforms like Dreamcast and Saturn on Switch if it was "just" upstream.

He is also still being petty about the Saturn core, as that one has seen an updated release but no change in the repo. I do think he should change that and upload the source code changes.
Well that's fine and all but why would he need to fork and maintain the low end cores too? I can understand the hard to run high end cores but something like GB/GBA runs on literally anything. Just use the upstream core.
 
Last edited by SuffahBish,
  • Like
Reactions: lordelan
Well that's fine and all but why would he need to fork and maintain the low end cores too? I can understand the hard to run high end cores but something like GB/GBA runs on literally anything. Just use the upstream core.

Look into the commits, and you'll see things like updated libraries and drivers, and explicit integration with the frontend ecosystem and UX, so it doesn't look like just retroarch when the cores are being used, like in ES-DE
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum