If someone shared ROMs 20 years ago and stopped, Nintendo wouldn’t be able to do anything about it today. The statute of limitations does apply.

But if someone started sharing ROMs 20 years ago, and continued doing it every day until today, then that means they shared ROMs yesterday. The “crime” still happened yesterday.

Edit: but they care a lot more about preventing it from happening tomorrow.

I don’t think that’s a good argument. In a more general case, if you didn’t pursue your rights 10 years ago that doesn’t mean you can’t get your shit together and do it today. Maybe you’ve lost some of what you deserved but you still should get future benefits.

As for statue of limitations, if it keeps happening today then it doesn’t matter when it started. They could only talk about things that happened in the past year - it’s still being hosted and shared.

To be clear, I’m not taking Nintendo’s side, all efforts to preserve these games are amazing and I love to see everyone keep it up :)

FWIW I am not one of the jerks who downvoted you, I think your comment contributes to discussion even if I’m the end it turns out to be wrong. I think people just see the downvote button as a “disagree” or “you’re wrong” button, don’t let it get to you.

You need to hire a proofreader :P I can’t read that, I’ve tried

Could have been just a hypothetical or rhetorical question from my POV

In case this is a real question: AFAIK* that is not possible for them to do. The project was open source and it accepted code contributions from everyone using a FOSS license. This means:

1. Everyone who has seen the code explicitly has rights to redistribute it, and this right cannot be revoked
2. The core team does not own the entirety of the code - to transfer ownership to Nintendo they would have to get approval from every single contributor that ever made a pull request that got merged. This is impractical to say the least

So no, there is no and there cannot be legal basis for Nintendo to claim copyright on Yuzu. They might have other claims, but I won’t weigh in on how good they might be because I’m way out of my depth already.

* I’m actually making a bunch of assumptions about Yuzu’s licence and number of contributors that I haven’t bothered to check, so take this with a grain of salt. I’m still pretty confident about point 1 though, I’d be really surprised if this was a wrong assumption, and it alone is enough.

This should be an optional feature for moderators. Mods from both communities must virtually shake hands and merge their communities into one. They could tweak how cross-moderation works. If one side becomes unmanageable, the other side can cut the line and split the community again.

Genuinely sounds like a solid idea to me. There are some lingering questions - both technical and non-technical - but they’re fairly small. Such as:

1. How easy or hard is it to implement?
2. When communities merge, do their histories merge too or do only new posts show up to both? (My opinion: only new posts)
3. When a merged community splits, do both sides keep a full copy of the posts from the time they were merged, or do they delete the posts that were posted to the other community? (My opinion: keep the history)
4. Do they have to match everything - community description, exact wording of rules, graphics, exact name, etc - or do they just need to show each other’s posts? (My opinion: just show each other’s posts. It should basically be an automatic cross-post.)
5. Should Lemmy software make this apparent to users, or should the responsibility lie on the mods to make the announcement? This question could be asked separately for merge events, split events, and the merged steady state - i.e. should Lemmy show some info about it while the communities are merged. (My opinion: I think especially for splits, it’s important to let the users know especially if the mods want to hide it. The other cases I think it could be left up to the mods, although it would do no harm if Lemmy let you know which communities are merged)

My opinion to those questions is what I think is the “right” way to do it, but I also suspect my opinions to 2-4 are the easiest to implement.