duckstation: revert removal and update to latest version

[ghost]

Reverts #430501 and updates duckstation to the latest release with the license change. Since NixOS is not a binary distribution, we aren't infringing on the new license as we set it to lib.licenses.unfree in its meta attributes.

This also removes the duckstation-bin package as its merged into duckstation for darwin users and there is a release note and alias to account for this.

I tried to avoid introducing more usage of overrideAttrs but it is done for shaderc since I am stumped on how to migrate the duckstation patches over.

The git variables patch was dropped to make the source derivation simpler and it's not a required feature.

If the old maintainers wish to re-maintain this package and suggest changes they are welcomed to do so.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[matteo-pacini]

@normalcea I wanted to raise a concern regarding the new license and how it applies to nixpkgs packaging.

The upstream license has changed to CC BY-NC-ND 4.0, which is quite restrictive:

ND (No Derivatives): prohibits distribution of modified versions. Packaging in nixpkgs usually involves patches, build system changes, or altered defaults, which could be considered derivative works. Even distributing compiled binaries might fall under this restriction.

NC (NonCommercial): forbids use in commercial contexts, which is difficult to guarantee given that NixOS and nixpkgs are used in both personal and enterprise settings.

BY (Attribution): requires clear attribution, which we’d need to ensure is satisfied.

Given these restrictions, is it legally safe for nixpkgs to reintroduce this package?
Even if we don’t provide prebuilt binaries, Hydra and binary caches may end up distributing them, which could violate the ND clause. And marking the package as unfree in metadata doesn’t resolve the underlying license restrictions.

Please let me know if I am missing something here, or if there is a clear way for us to avoid a licence violation.

[ghost]

Duckstation is one of its kind when it comes to licensing (putting it diplomatically), but I don't believe that it overall would prevent this PR from going through.

ND (No Derivatives): prohibits distribution of modified versions. Packaging in nixpkgs usually involves patches, build system changes, or altered defaults, which could be considered derivative works. Even distributing compiled binaries might fall under this restriction.

I've tried to keep the build system as close to upstream as possible (I've had the update script check for the exact revision of vendored dependencies for example).

Patches may be an issue, but these patches don't change the functionality of the program nor is it enough of the original source code to count as a serious copyright violation in my opinion. I might see if dropping these patches could work (though cubeb/audio stops working if the unvendor patch is removed).

lib.licenses.cc-by-nc-nd-40 also counts as an unfree license in nixpkgs, so no cached sources and compiled binaries will be distributed by nixpkgs CI.

NC (NonCommercial): forbids use in commercial contexts, which is difficult to guarantee given that NixOS and nixpkgs are used in both personal and enterprise settings.

unfree covers this since commercial settings would want to avoid anything even tangentially related to a license violation. If one sells a copy of nixpkgs with this derivation on it, it wouldn't be a violation since it's only a build script to build duckstation.

BY (Attribution): requires clear attribution, which we’d need to ensure is satisfied.

''
      pushd ..
      install -Dm644 LICENSE -t $out/share/doc/duckstation
      install -Dm644 README.* -t $out/share/doc/duckstation
      install -Dm644 CONTRIBUTORS.md -t $out/share/doc/duckstation
      popd
''

I've copied the above files into the output. Nixpkgs currently doesn't have a treewide policy on license attribution outside of the meta.licenses attribute but gestures like this should satisfy BY.

What is being submitted to nixpkgs is not duckstation but a derivation builder (licensed under MIT) to build duckstation as NixOS isn't a source distribution.

Binary caches outside of nixpkgs distributing unfree software shouldn't be in our purview as the same argument can be had for other unfree software and the license violation would be on the admins of that particular cache.

I think the main blocker for duckstation would be if the source fetcher is blocked (Duckstation stops being published publicly on GitHub) or the release tarballs are also blocked (say it's a special link you need a password to use). Other than that, I don't see why we can't distribute a derivation like so.

[matteo-pacini]

As much as I’d like to see DuckStation available in nixpkgs, I’m concerned that CC-BY-NC-ND is a poor fit for our usual workflows. The ND clause in particular conflicts with common practices like patching, wrapping, and even distributing compiled outputs, while the NC clause creates uncertainty for many users. Marking the package as unfree or disabling Hydra doesn’t really address those underlying issues imho.

My suggestion would be to keep this out of nixpkgs proper and instead maintain it as an external flake or overlay where users can opt in knowingly. If there’s strong interest in merging, I think it would need to be very minimal (no patches, local builds only).

Looking forward to hearing what others think on the matter.

[ghost]

I'd also like to hear other people's opinions on this (and I do wish there was more documentation on what to do this in this scenario)

As an aside, I wouldn't be interested in writing a derivation for a pre-compiled binary of duckstation (distributed as an appimage) for nixpkgs if it were to come to that since it's a very trivial to do.

[ghost]

I've removed both patches, so we aren't including any part of the duckstation source code within nixpkgs. This means that cubeb support will be absent, but users can easily use the SDL backend (I've wrapped pipewire, pulseaudio and jack2).

Edit: forgot alsa, added that in next force push.

[ghost]

Rebased and updated duckstation to tag v0.1-9669 given the new SDL3 3.2.22 bump and also modified the update script to match the new version (the pinned revisions for the vendored libraries are located in a different part of the project).

[SuperSandro2000]

The ND clause in particular conflicts with common practices like patching, wrapping, and even distributing compiled outputs, while the NC clause creates uncertainty for many users. Marking the package as unfree or disabling Hydra doesn’t really address those underlying issues imho.

Marking the package as unfree and not distributing it solves that. End users need to verify themselves if they comply with the license and we do not distribute anything falling under that license.

Given these restrictions, is it legally safe for nixpkgs to reintroduce this package?

We have built instructions for software which require a bought commercial license which is way more restrictive.

Even if we don’t provide prebuilt binaries, Hydra and binary caches may end up distributing them, which could violate the ND clause.

How? hydra.nixos.org never builds unfree packages.

And marking the package as unfree in metadata doesn’t resolve the underlying license restrictions.

They don't need to be solved. That is an exercise for the end user.

[h7x4]

IANAL, but we're not distributing the software nor any derivative works right? The only thing we distribute is a "blueprint" text file of how you as the end user would go about making some changes if you were to download the software directly from the upstream distribution. It's up to the end user to actually realize those changes, and even then they are not breaking the license unless they go ahead and send someone their built binaries. As long as hydra does not build and distribute, I don't see any problem.

[ghost]

Re: @SuperSandro2000

I've applied all recommendations, thank you for reviewing.

Re: @h7x4

I've removed all patches, so there's no portion of the duckstation's source code within nixpkgs which is a concern I also had. Packages like duckstation with complicating licenses were designed to deny source-based binary distributions. However, derivations should not apply since the software itself will not be distributed until the derivation is evaluated by a really existing Nix system.

[matteo-pacini]

@SuperSandro2000 Thanks for clarifying — I didn’t mean to stall this; I just had some concerns about how best to proceed in this particular case. I’m happy to approve the PR.

[matteo-pacini]

@normalcea is this good to go?

[matteo-pacini]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 444821
Commit: 315d0f55862ce58e59e2d577d28f0852a6e1bef2 (subsequent changes)
Merge: 3fe79e3b1c49a76038ec55e381aa5f97d7483826

Logs: https://github.com/matteo-pacini/nixpkgs-review-gha/actions/runs/18400555343

---

x86_64-linux

⏩ 1 package blacklisted:

• tests.nixos-functions.nixos-test

✅ 5 packages built:

• duckstation
• gpupad
• nixpkgs-manual
• spirv-cross
• taisei

---

aarch64-linux

⏩ 1 package blacklisted:

• tests.nixos-functions.nixos-test

✅ 5 packages built:

• duckstation
• gpupad
• nixpkgs-manual
• spirv-cross
• taisei

---

x86_64-darwin (sandbox = true)

✅ 2 packages built:

• duckstation
• nixpkgs-manual

---

aarch64-darwin (sandbox = true)

✅ 2 packages built:

• duckstation
• nixpkgs-manual

[ghost]

Yeah, I just fixed a typo where a call to the new cli was not prefixed with --extra-experimental-features this package is ready to go.

Though if anyone wants to put themselves as co-maintainer I would really appreciate it. There are still some TODOs like removing the shaderc overrideAttrs which I will get around to doing when I eventually figure it out (or someone else does)

[matteo-pacini]

@normalcea feel free to add me, happy to help.

[ghost]

@matteo-pacini

Added

[matteo-pacini]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 444821
Commit: 58d045414a13e7c8d966ef95c52de96e3b3b9a1a (subsequent changes)
Merge: 6af62037509cfb35e2f4f8510e651ab63087a7c5

Logs: https://github.com/matteo-pacini/nixpkgs-review-gha/actions/runs/18414095537

---

x86_64-linux

⏩ 1 package blacklisted:

• tests.nixos-functions.nixos-test

✅ 5 packages built:

• duckstation
• gpupad
• nixpkgs-manual
• spirv-cross
• taisei

---

aarch64-linux

⏩ 1 package blacklisted:

• tests.nixos-functions.nixos-test

✅ 5 packages built:

• duckstation
• gpupad
• nixpkgs-manual
• spirv-cross
• taisei

---

x86_64-darwin (sandbox = true)

✅ 2 packages built:

• duckstation
• nixpkgs-manual

---

aarch64-darwin (sandbox = true)

✅ 2 packages built:

• duckstation
• nixpkgs-manual