Skip to content

ryujinx: remove; ryubing: remove#425950

Closed
ghost wants to merge 3 commits into
masterfrom
unknown repository
Closed

ryujinx: remove; ryubing: remove#425950
ghost wants to merge 3 commits into
masterfrom
unknown repository

Conversation

@ghost

@ghost ghost commented Jul 16, 2025

Copy link
Copy Markdown

This commit removes ryujinx from nixpkgs and creates an alias to point users to inform them of the removal and to point them towards ryubing instead, which will not be cached in Hydra anymore.

Removes package derivatons for both ryujinx and ryubing from nixpkgs, creates aliases, and adds a release note for their removal.

This comes after a relatively recent DMCA take-down request from Nintendo[1] which targeted Ryujinx forks on GitHub, from what I know, Ryubing also had to move off GitHub for this reason to their own Gitlab instance.

Possible Alternatives

  • Prevent building of Ryujinx on hydra, but keep derivation.
  • Remove Ryujinx, but keep caching Ryubing.
  • Prevent building of both Ryubing and Ryujinx, but keep both derivations.
  • Remove both Ryujinx and Ryubing.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
  • NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

Add a 👍 reaction to pull requests you find important.

@nixpkgs-ci nixpkgs-ci Bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. 9.needs: reviewer This PR currently has no reviewers requested and needs attention. labels Jul 16, 2025
@philiptaron philiptaron requested a review from emilazy July 17, 2025 20:11
@nixpkgs-ci nixpkgs-ci Bot removed the 9.needs: reviewer This PR currently has no reviewers requested and needs attention. label Jul 17, 2025
@ghost

ghost commented Jul 17, 2025

Copy link
Copy Markdown
Author

@ghost ghost requested review from 06kellyjac, Kek5chen and artemist July 17, 2025 22:03
@ghost

ghost commented Jul 17, 2025

Copy link
Copy Markdown
Author

Manually pinging Ryujinx and Ryubing maintainers (didn't occur automatically).

@emilazy

emilazy commented Jul 17, 2025

Copy link
Copy Markdown
Member

Don’t see the argument from a legal perspective for removing Ryujinx but only refusing to build Ryubing. If we’re doing this for legal reasons then the remedy (if any) should be the same for both, and if we’re removing Ryujinx for being unmaintained then that’s a separate matter.

hydraPlatforms = [ ]; is not very reliable since anything else can still pull it in and make it get built. I think I would lean towards just keeping these or removing them both outright, but I don’t have a strong opinion between the two.

Edit: Though I feel like our reasoning for keeping Ryujinx but not Yuzu was basically “DMCAs haven’t happened for Ryujinx yet” so that might point towards removal for consistency.

@artemist

Copy link
Copy Markdown
Member

Has nixpkgs received any request yet, either from Nintendo or a foundation lawyer? nixpkgs includes other packages that some would argue could be used to violate the DMCA and have for years.

I do not see a purpose in complying in advance.

@ghost

ghost commented Jul 18, 2025

Copy link
Copy Markdown
Author

Responding to @artemist

Has nixpkgs received any request yet, either from Nintendo or a foundation lawyer?
...
I do not see a purpose in complying in advance.

Not to my knowledge, no, but this line of reasoning leads to the territory of playing aloof until the legal hammer is brought upon us, I'd like corporate firms not to bring down the hammer on nixpkgs if we can avoid it nor promote the mindset of waiting for things to blow up on us before taking action when we already see red flags in front of us.

nixpkgs includes other packages that some would argue could be used to violate the DMCA and have for years.

I don't find this a compelling argument: the idea that other packages can be considered problematic is something that shouldn't have an effect on whether or not it is okay to keep Ryujinx/Ryubing on nixpkgs. Also, please cite specific cases instead of being vague, and if you think those packages should also be removed, then a PR should be made for them as well as a separate matter.

I can use this same argument in favor of removing Ryujinx as there are other packages that have been removed for similar takedown-related reasons, just like with Yuzu as linked beforehand.


For what it's worth: this is where decentralized package management is more key than ever and Nix helps enable it via flakes/version pinning. Ryubing can host a flake.nix on their own Git forge and Ryubing Nix users would add it as part of their flake inputs (repeat for any non-flake/compatible mechanism). If this isn't an option, then in my own opinion, what was even the point of developing it in the first place if we'll have nixpkgs host unmaintained archival software that's in legal crosshairs (referring to Ryujinx specifically) until we hear a knock on our door?

Are flakes and co. only meant for -git software or dev environments or can it actually be a way for application developers to ship their software without having to be hosted on nixpkgs?

@ghost ghost marked this pull request as draft July 18, 2025 19:44
@ghost

ghost commented Jul 18, 2025

Copy link
Copy Markdown
Author

Setting this PR as draft till a consensus/agreement is reached. I've updated it to remove both Ryujinx and Ryubing.

@ghost ghost changed the title ryujinx: remove (due to legal issues); ryubing: do not cache ryujinx: remove; ryubing: remove Jul 18, 2025
@ghost ghost added the 1.severity: legal This PR or issue raises or fixes a legal issue, e.g. licensing compliance label Jul 18, 2025
@06kellyjac

Copy link
Copy Markdown
Member

It's still packaged in other repos/distros, and Valve was hit with virtually the same DMCA notice (well it was actually a prior warning because it was before it's release) for Dolphin about "illegal circumvention" and use of "proprietary cryptographic keys" but we still package dolphin-emu.

The difference with Yuzu is the team settled a lawsuit with Nintendo, and while the injunction is between Nintendo and Tropic Haze, it's easier to also comply. But I don't believe there's actual legal determinations that Nintendo's claims qualify as violation of the Digital Millennium Copyright Act.

Ryubing/Ryujinx require validation that you own a modded switch with access to "your own" unique prod keys before answering any support questions in their help channel on discord, which I consider to be a good method of combating piracy.

  1. No piracy discussion or demonstrations of any kind, including third party online services. Support will be denied to any participants, and you might even get banned on sight if it's an egregious enough offense.
image

https://github.com/LotP1/SwitchVerifier

@nixpkgs-ci nixpkgs-ci Bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 24, 2025
@ghost

ghost commented Jul 26, 2025

Copy link
Copy Markdown
Author

Responding to @06kellyjac

It's still packaged in other repos/distros,

The other GNU/Linux distributions listed here are the AUR (which points to Ryubing) and Solus which points to the archived version we have. So to say it's still packaged in other repos is misleading. Comparing this with Dolphin Emulator is a night and day difference:

Flathub also lists Ryubing but it is an unverified flatpak and Flathub isn't the greatest legal model for app distribution (many proprietary applications are distributed there with unclear agreements/no consent from their copyright holders).

and Valve was hit with virtually the same DMCA notice

The statement given to the dolphin folks was that they needed approval from Nintendo in order to proceed. This feels too different to our situation, where we (nixpkgs) hosted on GitHub are hosting scripts to obtain Ryujinx and also cache binaries in Hydra. AFAIK, we do not have any approval from Nintendo to distribute binaries of Ryujinx anyway.

Ryubing/Ryujinx require validation that you own a modded switch with access to "your own" unique prod keys before answering any support questions in their help channel on discord, which I consider to be a good method of combating piracy.

Ryujinx sources were still removed off of GitHub. Even if the emulation project stays above aboard and discourages violating copyright law, that didn't seem to affect Nintendo in any way. Maybe if nixpkgs wasn't hosted on GitHub then I wouldn't be as worried about this issue but we are and we are under the whim of GitHub as its guest.

@ghost ghost marked this pull request as ready for review July 27, 2025 00:37
@nixpkgs-ci nixpkgs-ci Bot added 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 8.has: changelog This PR adds or changes release notes 8.has: documentation This PR adds or changes documentation and removed 2.status: merge conflict This PR has merge conflicts with the target branch 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Jul 27, 2025
@06kellyjac

Copy link
Copy Markdown
Member

So to say it's still packaged in other repos is misleading.

According to the Steam hardware survey for June 2025:

  • "SteamOS Holo" 64 bit - 31.04%
    • The most common Linux distro for steam gamers
      • Beats out the next actual distro by 12.47%
      • Beats out entirety of "Other" by 10.17%
    • Flatpak focused, can use AUR but uncommon
  • "Arch Linux" 64 bit - 10.49%
    • AUR or Flatpak
  • Freedesktop SDK 24.08 (Flatpak runtime) 64 bit - 6.62%
    • Literally from flatpak
  • "CachyOS" 64 bit - 3.18%
    • AUR or Flatpak
  • "EndeavourOS Linux" 64 bit - 2.40%
    • AUR or Flatpak
  • "Manjaro Linux" 64 bit - 2.46%
    • AUR or Flatpak
  • "Bazzite 42 (FROM Fedora Kinoite)" 64 bit - 2.37%
    • Primarily Flatpak
Type Percent
Access to AUR (actual) 49.57%
Access to AUR (minus SteamOS) 18.54%
Primarily Flatpak 33.41%
Access to Flatpak ~100%(?)

From this we can derive that Flathub and the AUR alone as repositories likely reflects a significant portion of "Linux Gamers".

As with any survey this is just a sample but the numbers hold pretty strong across each month.

https://www.gamingonlinux.com/steam-tracker/

Additionally Flatpak is cross-distro package-manager like nix and flathub being a repository with it's package source on GitHub like nixpkgs.

(This also ignores case of the popular emudeck, which fetches the pre-compiled ryubing directly from the Ryubing releases. I bring this up last as it's not a "repository" but it's a common method people use to fetch the emulator. Most importantly the source is hosted on GitHub.)


Comparing this with Dolphin Emulator is a night and day difference

I understand Dolphin is part of the discussion but, Dolphin is a 21 year old emulator for the GameCube, released 23 years ago and the Wii released 18 years ago.

More apt comparisons for repo coverage would be looking at modern emulators (which companies try to protect more actively):
("Trimmed" removes AUR like releases, non-linux, and more minor distros)

If you can find a similarly modern emulator that has wide adoption across distros that'd be a more fair comparison and interesting to see.

Ryujinx/Ryubing's repo coverage looks pretty in line with popular emulators of the past 14 years. Appimages, Flatpak, and static single binary releases may explain the reduced need to package emulators within repo.


Flathub also lists Ryubing but it is an unverified flatpak ...

Being unverified just means the Ryubing team aren't involved in it's maintenance. It's still a valid package that lives in the Flathub org on GitHub which is the important part to this discussion.

... and Flathub isn't the greatest legal model for app distribution ...

I find that wholly unfair.

image

https://flathub.org/about

If you have issues with flathub packages submit an email.


The statement given to the dolphin folks was that they needed approval from Nintendo in order to proceed.

This is misleading. Yes Valve said to Dolphin they had to come to an agreement with Nintendo.
The "why" is "a lawyer representing Nintendo of America requested Valve prevent Dolphin from releasing on the Steam store, citing the DMCA as justification."

The terms I referenced from their reasoning were "illegal circumvention" and use of "proprietary cryptographic keys", the same argument used in the recent DMCA. You've not actually addressed this.


Final statement:

I'm of the position that if asked we'll purge it from the cache and remove the nix expressions fully. Until then I think it should stay.

@06kellyjac 06kellyjac left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting this PR as draft till a consensus/agreement is reached. I've updated it to remove both Ryujinx and Ryubing.

Marking this PR as "Request changes" since it's been undrafted despite no consensus/agreement reached.


Summary: 2/3 ryujinx/ryubing package maintainers against, 1/3 yet to comment, 1 vote for and 1 vote of potentially no-preference by general nixpkgs maintainership.


I propose either:

  • escalating this to the steering committee for them to make the decision
  • closing upon unanimous votes against by the package maintainers
  • closing now with majority votes against by the package maintainers

I don't see consensus being achieved in this PR and I don't think a broader vote raised on discourse or elsewhere to be necessary (unless that's the outcome from the steering committee's decision)

@emilazy

emilazy commented Jul 27, 2025

Copy link
Copy Markdown
Member

Is there a reason we should take a different position here to that taken in #293312, #295587, #406445? I don’t think we can relitigate this for every single emulator and I think “active DMCA of source repositories” is a reasonable line to draw here in terms of the legal risk and the ability to sustainably maintain a package. There is relatively little penalty to maintaining these things out‐of‐tree and I encourage people to do so.

@Kek5chen

Copy link
Copy Markdown
Contributor

I was more or less set to not state my opinion here. But I now decided to do so, as a fairly neutral part. Just to clear my position: I'm just another contributor to nixpkgs and one of this packages maintainers. I do not interact with riujinx and its people anymore for personal reasons, while also not harbouring any grimm.

Now to my opinion:
I don't think that nixpkgs should take a role here other than exactly that, a neutral middle ground, with its sole purpose being to package, but not distribute, publicly available software.
(This excludes the existence of binary caches but I will mention this later)

We are not a source distributor.
I don't believe we should take a position as far as endorsing nor discouraging the use of any software, considering it's not of malicious, politically extremist or similar intent. Generally said, as long as it is in "the general users interest".

It's simply not our purpose. We just want to bring software that's available, to our users, in a most efficient, secure and reliable manner.

We have never - and I don't see that we will - host, store or distribute anything related to the original source, data or package contents of the executable in question.

There's just the obvious odd-one-out:
The binary cache. but obviously we can just surpass that by simply forcing users to provide the package or compiling from source, as well as, prohibiting the caching or serving, of the questionable assets from our side.

That's our purpose, and giving private corporations the ability to even take away this part of our responsibility as a software packaging facility- in my opinion; is more than gross.

We shouldn't land in any legal trouble as long as we do not distribute or store any of the copyrighted content. All we do is merely provide the metadata resources which users can use on their own personal accountability.

This is what GitHub did -> that's why they were legally bound to take it down. We simply do not compare.

I don't see why we should act out of fear here. And, while I understand the importance of discussing it in a reasonable scope, I honestly find all the fuss a bit overwhelming and unnecessary.

I hope we can find a consensus on this, and if not, please have the foundation etc. get in contact with lawyers so we can find a general process for this, as this issue exists across more materials than just this. I think it's clear, that we package other things that have the same underlying "legal issues".

This shouldn't be the maintainers problems, but more of the shareholders or whoever sits in responsibility here.

Thanks for taking the time to hear me out, and I wish everyone a great rest of their days.

@Kek5chen Kek5chen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the reasons stated in my commented opinion as well as my political view on this topic, I am also against the removal.

I don't believe we should, out of pure fear, give big private companies the power to silence the publication of simple metadata information used by people to, on their own accountability, build and use artifacts, for which we do not provide or distribute any assets.

@ghost

ghost commented Jul 28, 2025

Copy link
Copy Markdown
Author

Firstly, I apologize for setting this PR as open to review without an explanation, contradicting what I said earlier. I'm still keeping this open for review (the implementation of removing these packages) but I'm still am interested in building a consensus before anything and I think having the Nix steering committee also comment on this would be useful in finding a path forward.

After reading what's been posted here: I think the outcome I was fine seeing is:

  1. Removal of ryujinx with an alias to ryubing on grounds of non-maintenance
  2. Preventing the source and build of ryubing from being cached on grounds of DMCA notices from Nintendo on copies.

Which was my original PR before I changed it to remove both packages since one of my concerns is that we may end up in legal trouble if the derivation code itself could be considered as "trafficking" Ryujinx. The source URL is only obfuscated by a fetchFromGitLab invocation and the domain is clearly visible.

From 17 U.S. Code § 1201 2 (emphasis mine)

No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that—

Full disclosure, not a lawyer, but we basically have a link to download Ryubing binaries since those are hosted on the GitLab instance's releases page. Providing links to download copyright infringing material (as decided by Nintendo) should also be a concern.

I don't see why we should act out of fear here.

A healthy dose of fear of Nintendo is warranted, even if Ryubing and Co. are on top of preventing copyright infringement from occurring in their community spaces, they will all pay for the consequences of Yuzu's settlement which was referenced in the DMCA notice for Ryujinx which in my opinion makes this situation different from Dolphin-Emu in my perspective.

I think it's clear, that we package other things that have the same underlying "legal issues".

If they suffer from DMCA takedowns and a abandoned upstream (ryujinx archive) then they should also be pro-actively dealt with. Also, it would be more helpful if specific derivations were given as examples.

If you have issues with flathub packages submit an email.

I have sent an email to admins [at] flathub [dot] org requesting the removal of Ryubing. I'll post my message and their response when I receive it if that's valuable to the discussion and I'm given permission to publish the correspondence.

Edit:

And as Emilazy pointed out: Yuzu was removed on similar DMCA grounds and now Ryujinx is being removed with even stronger legal threats stemming from Yuzu's settlement. My goal isn't to remove people's access to software but to see that nixpkgs operates in a responsible manner, even if that means capitulating to private corporations with astronomically more capital than us.

@06kellyjac

Copy link
Copy Markdown
Member
  1. Removal of ryujinx with an alias to ryubing on grounds of non-maintenance
  2. Preventing the source and build of ryubing from being cached [...]

I can agree to these changes. The grounds for 2. would only be for our convenience or a gesture of good faith.

Providing links to download copyright infringing material (as decided by Nintendo) should also be a concern.

There is no legal determination on Nintendo's claim. If Nintendo's opinion was the only thing that mattered we'd also have to remove dolphin because they hold an identical position against dolphin.

I hold the same opinion as Dolphin and their legal council (from the article you linked):

We have a very strong argument that Dolphin is not primarily designed or produced for the purpose of circumventing protection. Dolphin is designed to recreate the GameCube and Wii hardware as software, and to provide the means for a user to interact with this emulated environment. Only an incredibly tiny portion of our code is actually related to circumvention.
...
...
Considering that only a small fraction of what we do involves circumvention, we think that the claim that we are "primarily for circumvention" is a reach. We do not believe this angle would be successful in a US courtroom, if it were ever to come to that. ... Of particular note for Dolphin is the reverse engineering exemption in 17 U.S.C. § 1201(f) ...

Until either Nintendo validates their opinion in a court of law, or directly file a DMCA notice with the NixOS Foundation/nixpkgs we don't have to do anything.
The latter is very unlikely when they'd DMCA google to get the website & vcs removed from search results long before bothering with nixpkgs.


I have sent an email to admins [at] flathub [dot] org requesting the removal of Ryubing.

I mostly meant to reach out to flathub regarding other cases you're aware of. I'm not aware of any major differences in nixpkgs or flathub's approaches in "app distribution".

@nixpkgs-ci nixpkgs-ci Bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Aug 2, 2025
@ghost ghost mentioned this pull request Aug 2, 2025
13 tasks
@nixpkgs-ci nixpkgs-ci Bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Aug 2, 2025
@Kek5chen

Kek5chen commented Aug 2, 2025

Copy link
Copy Markdown
Contributor

I share consensus with @06kellyjac.

I generally don't want, or see reason for this software to be removed from Nixpkgs in its entirety, but the old package can be either removed, or aliased.

@nixpkgs-ci nixpkgs-ci Bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Aug 4, 2025
@ghost

ghost commented Aug 6, 2025

Copy link
Copy Markdown
Author

Closing on my end since I've been convinced that this isn't a good approach and I'm personally no longer interested in pursuing this PR.

@ghost ghost closed this Aug 6, 2025
@ghost ghost deleted the remove-ryujinx-package branch August 6, 2025 04:20
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1.severity: legal This PR or issue raises or fixes a legal issue, e.g. licensing compliance 2.status: merge conflict This PR has merge conflicts with the target branch 8.has: changelog This PR adds or changes release notes 8.has: documentation This PR adds or changes documentation 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants