I see two low hanging fruits:

1. Install license files into the package output. This is a bare minimum for license compliance and trivial to do. If the package script doesn't already do this by default (many do), it should be done manually.
2. Use "branding" configureFlags where available. Many packages offer configure flags that set a branding string in the resulting program, signifying that it was packaged by us. This ought to be enough to comply with the license requirement because this branding implies that we modified it.

Beyond these, we should look into manually marking packages that do not offer such flags by i.e. inserting a © Nixpkgs contributors into the license text which the program displays to users. (The GPL requires interactive programs to do this. If it doesn't, I think we can assume the author doesn't care about following the GPL extremely strictly.)
This is quite a bit more work, so I think the best course of action is to only do this when prompted to (i.e. upstream requests us to do it) or if it is conceivable that it might upset upstream if we don't. Most upstreams are pretty chill about this sort of thing but some aren't and it's those cases I think we should focus on. Duckstation is a good example.

In case of 1, I still prefer a separate output for this, at least by the typical rationale we provide for splitting outputs in the Nixpkgs manual.

Further, I have some conceptual concerns. Maybe it is too much perfectionism from my side, but oh well.

First, license metadata should be provided for all inputs of an expression - sources, patches, our own machinery etc.
Second, we should have something like a mathematical function that receives all the input above and output the appropriate course of action - things like "GPL requires interactive programs to display some info; create a compliance wrapper that accepts a --print-meta flag".

Third:
According to the manual, meta and passthru can't rebuild the expression.
However, some programs require further action according to their licensing info.

I’m unconvinced that a separate output is sufficient for compliance, or that making every package multi‐output would be well‐received. In fact I suspect that we may be obligated to include the licence and copyright notice in all outputs.

We also cannot just copy template licence files, because the copyright notice differs between packages and must also be retained.

IIRC the interactive program thing doesn’t matter unless we apply patches, thankfully, and GPLv3 loosens the requirement further.

I think that the lowest‐hanging fruit to pick here would be to add code to stdenv that tries to automatically find and copy LICENSE and COPYING files. That won’t get us into full compliance by any means, but it will be a good start. We should also investigate the various automated SPDX/SBOM tools that could help with this kind of thing.

unless we apply patches

Patches from what exactly? Made by us/third party contributors or cherry-picked from upstream?

  2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

[…]

    c) If the modified program normally reads commands interactively
    when run, you must cause it, when started running for such
    interactive use in the most ordinary way, to print or display an
    announcement including an appropriate copyright notice and a
    notice that there is no warranty (or else, saying that you provide
    a warranty) and that users may redistribute the program under
    these conditions, and telling the user how to view a copy of this
    License.  (Exception: if the Program itself is interactive but
    does not normally print such an announcement, your work based on
    the Program is not required to print an announcement.)

I was wrong; even the GPLv2 has the exception that means we don’t really have to care about it.

BTW, I think that encoding full SPDX expressions in meta.license is probably a prerequisite to doing anything at all fancy here beyond my stdenv suggestion.

Disclaimer: IANAL yet.

In fact I suspect that we may be obligated to include the licence and copyright notice in all outputs.

Among the reason we split outputs, is saving some bytes and finer garbage-collection.
The location of the files in the filesystem does not look relevant, in the worst case we can just symlink them and/or force the installation of prog.licenses output.

add code to stdenv that tries to automatically find and copy LICENSE and COPYING files

Well, we can add a installLicense {licenseFiles} function to installShellFiles.

On the other hand I am not a fan of hidden automation.

How about, as a minimum, we set the machine-readable copyright information licenses information to $outputDoc/copyright, and have a common-licenses packages that can be symlinked to?

Duckstation is now actively blocking building on NixOS and seems to have added an additional restriction for packaging on their license after this commit stenzek/duckstation@b20c2b2

To my best knowledge this has zero legal value if you're not directly distributing their files or editing them. Nothing can stop you from making a software completely separate from theirs (aka nix) that happens to download their software directly from them and interact (install/patch) with it.

Even if you didn't want to patch the nixos block, you can just unset the relevant environment variables before you build it and maybe figure out a way to provide a fake /etc/os-release.

That said, even if I like the idea of making assholes angry, I personally believe people like this and their software do not deserve your time at all...

+1. I was debating posting this.
a derivation is a recipe, instructions. The same thing as sending a PDF on discord on how to download a piece of software. So long as marked unfree it is never cached, therefore never packaged. the only time it is packaged is when a user builds it themselves. and in that case, the enduser is responsible for their actions.

Also yeah, reading some of these commits, this person is rather actively hostile, they are removing linux support entirely because apparently bug reports have infuriated them to that point.
This is not worth writing a derivation for just for it to vanish in a few days. Nor honestly should you want to use a piece of software with a developer who clearly does not like you.

My personal guess is they are a primarily windows user, and are frustrated by the fact Linux is different, and in their frustration are making a bit of a show and slandering the community a bit, and pulling support. Which, fine, sure, they're probably just frustrated. Not cool, but humans are humans.

My advice is to just get ahead of the blow and headcanon it as windows software and move on.

Duckstation is now actively blocking building on NixOS and seems to have added an additional restriction for packaging on their license after this commit stenzek/duckstation@b20c2b2

To my best knowledge this has zero legal value if you're not directly distributing their files or editing them. Nothing can stop you from making a software completely separate from theirs (aka nix) that happens to download their software directly from them and interact (install/patch) with it.

Even if you didn't want to patch the nixos block, you can just unset the relevant environment variables before you build it and maybe figure out a way to provide a fake /etc/os-release.

That said, even if I like the idea of making assholes angry, I personally believe people like this and their software do not deserve your time at all...

Despite is this "legal" or not, I personally think that we should "respect" this decision noneless.
We can just ship appimage and mark unfree and that's it.

Correct me if I am wrong, but appimages still require patching. Which is by far illegal in this instance.

Correct me if I am wrong, but appimages still require patching. Which is by far illegal in this instance.

We are not lawyers at the end of that day, so we are not too sure if this is legal or not. So please just stop providing advice if your not qualified, your just making the situation complex and argumentive without being sure if it's right or wrong.

We are not lawyers at the end of that day, so we are not too sure if this is legal or not. So please just stop providing advice if your not qualified, your just making the situation complex and argumentive without being sure if it's right or wrong.

I am sorry for cautioning that illegally patching binaries is illegal.
I withdraw my advice to refrain from shipping this. By all means, disrespect the upstream maintainers wishes, illegally patch their software, and ship support for a deadend project (for linux).
Advising to respect the upstream maintainers wishes and not repackage their software was only making the situation complex and argumentative, as @Eveeifyeve pointed out, I am sorry.

Correct me if I am wrong, but appimages still require patching. Which is by far illegal in this instance.

Quick download, then appimage-run, and indeed, duckstation just crashed at game start.

Wayland with KDE detected, not applying Wayland workarounds.
*************** Unhandled SIGSEGV at 0x7f32314a1424 ***************
  0x0055e62d354d08 LogCallstack [../build/../src/common/crash_handler.cpp:389]
  0x0055e62d354bc8 CrashSignalHandler [../build/../src/common/crash_handler.cpp:423]
  0x007f323144278f
  0x007f32314a1424
  0x007f30e8abbe39
  0x007f30e8a9eca1
  0x007f30dc7122f5
  0x007f30dc712607
  0x007f30dc68e524
  0x007f30dc643200
  0x007f30f855c809
  0x007f30f83237a3
  0x007f30f832f64b
  0x0055e62d4aa546 LockedCreateVulkanInstance [../build/../src/util/vulkan_loader.cpp:0]
  0x0055e62d4acf25 GetAdapterList [../build/../src/util/vulkan_loader.cpp:850]
  0x0055e62d404418 GetAdapterListForAPI [../build/../src/util/gpu_device.cpp:390]
  0x0055e62cfc0e9c operator() [../build/../src/duckstation-qt/graphicssettingswidget.cpp:655]
  0x0055e62cfc0e9c __invoke_impl<(lambda at ../src/duckstation-qt/graphicssettingswidget.cpp:663:14), (lambda at ../src/duckstation-qt/graphicssettingswidget.cpp:652:31) &> [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/invoke.h:61]
  0x0055e62cfc0e9c __invoke_r<std::function<void ()>, (lambda at ../src/duckstation-qt/graphicssettingswidget.cpp:652:31) &> [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/invoke.h:114]
  0x0055e62cfc0e9c _M_invoke [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:290]
  0x0055e62d050c14 operator() [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:591]
  0x0055e62d050c14 operator() [../build/../src/duckstation-qt/qthost.cpp:1717]
  0x0055e62d050c14 __invoke_impl<void, (lambda at ../src/duckstation-qt/qthost.cpp:1716:24) &> [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/invoke.h:61]
  0x0055e62d050c14 __invoke_r<void, (lambda at ../src/duckstation-qt/qthost.cpp:1716:24) &> [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/invoke.h:111]
  0x0055e62d050c14 _M_invoke [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:290]
  0x0055e62d373b38 operator() [/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:591]
  0x0055e62d373b38 ExecuteOneTask [../build/../src/common/task_queue.cpp:76]
  0x0055e62d3738c8 WorkerThreadEntryPoint [../build/../src/common/task_queue.cpp:96]
  0x007f32318f2fa3
  0x007f323149dd52
  0x007f32315255fb
  0xffffffffffffffff
*******************************************************************
Aborting application.

Quick download, then appimage-run, and indeed, duckstation just crashed at game start.

@VeilSilence Try this

@Notarin
IANAL but I'm pretty sure that locally patching a binary:

• can only be illegal when bypassing a license check, encryption, or digital rights management, nothing else.
• can be a breach of contract when explicitly forbidden by a EULA coming with the binary. This can usually lead to things like licence or account termination.
• for the purpose of interoperability is actually protected by law in most jurisdictions (US and EU)

And more importantly, the idea is not to modify and redistribute duckstation ourselves, but to publish a recipe that does it on the end user's computer automatically.

EDIT:
See section (f) of https://www.law.cornell.edu/uscode/text/17/1201

Quick download, then appimage-run, and indeed, duckstation just crashed at game start.

@VeilSilence Try this

Alas, same error.
Tried to package like this:

{
  appimageTools,
  fetchurl,
  pkgs,
}: let
  pname = "duckstation";
  version = "0.1-10693";

  src = fetchurl {
    url = "https://github.com/stenzek/duckstation/releases/download/v${version}/DuckStation-x64-SSE2.AppImage";
    hash = "sha256-ekFdfUTNt7PTry+lgj/UDu+GEO2CzBJqXBMyWOrGcAg=";
  };
in
  appimageTools.wrapType2 {
    inherit pname version src;

    extraPkgs = pkgs:
      with pkgs; [
        vulkan-loader
        libxcb-cursor
      ];
  }

Now I have this error:

/store/kavwy4v9p1jhf952dzipkjj5l1hjx110-qtbase-6.10.1/lib/qt-6/plugins/platforms/../../../libQt6WaylandClient.so.6: undefined symbol: _ZTI28QBasicPlatformVulkanInstance, version Qt_6_PRIVATE_API"

So, from my limited knowledge and understanding, patching is required indeed..

@Notarin In the end, the issues are mostly on the side of duckstation's author because as far as I can see, there's no legal way to forbid a user from patching a program to make it compatible with his computer.

The law is really explicitly on our side in this specific use case.

@Notarin IANAL but I'm pretty sure that locally patching a binary:

* can only be illegal when bypassing a license check, encryption, or digital rights management, nothing else.

* can be a breach of contract when explicitly forbidden by a EULA coming with the binary. This can usually lead to things like licence or account termination.

* for the purpose of interoperability is actually protected by law in most jurisdictions (US and EU)

And more importantly, the idea is not to modify and redistribute duckstation ourselves, but to publish a recipe that does it on the end user's computer automatically.

EDIT: See section (f) of https://www.law.cornell.edu/uscode/text/17/1201

That is correct. I meant patching serverside. I originally missed the "unfree" bit. But yeah, this is mostly what I was saying here.
Publishing "instructions" is very strictly not distribution of the software, and policing such a thing is not possible, or even remotely reasonable, and if it was, it would be incredibly dystopic.

But, I do remain on the stance there is no point in supporting software that will cease upstream support any second. It may even happen today.
I just don't see a point in updating this in nixpkgs when there are alternatives and upstream is cutting us off any second now. imo another repo is a far better place for that.
Also it is usually a good idea to respect an upstream maintainers wishes, even if they are an arse about it, and they prefer the source of their software to be their web portal.

Quick download, then appimage-run, and indeed, duckstation just crashed at game start.

Works out of the box on my end...
Maybe because I have programs.nix-ld.enable = true?

The error message points to issues with Vulkan, so maybe this solves it? (Throwing the idea randomly.)

export LD_LIBRARY_PATH=$(nix-build -E '(import <nixpkgs> {}).vulkan-loader' --no-out-link)/lib

Otherwise, maybe try the OpenGL rendering backend?

@Notarin I agree with your points, but yeah I just wanted to say that we could really do whatever we wanted and we would even be protected by law :)