Change:
- `service.borgmatic.settings.location` and `services.borgmatic.configurations.<name>.location` are deprecated, please move your options out of sections to the global scope. <ins> - `dagger` was removed because using a package called `dagger` and packaging it from source violates their trademark policy. </ins> ## Other Notable Changes {#sec-release-23.11-notable-changes} - The Cinnamon module now enables XDG desktop integration by default. If you are experiencing collisions related to xdg-desktop-portal-gtk you can safely remove `xdg.portal.extraPortals = [ pkgs.xdg-desktop-portal-gtk ];` from your NixOS configuration.

Discussion:
I just had a conversation with who mentioned we (nixpkgs) might be violating Dagger's trademark policy by providing a package called that's not their official build. You can find the trademark guidelines (under I am a package manager. Am I allowed to create a package named Dagger?) The alternative would be switching to their prebuilt binaries (published on .
All the other from source package managers call it dagger too Does upstream suggest a name for source built packages
chances are they are also in violation... "Anything, but Dagger" as far as I can tell. I'm talking to the Dagger folks to figure out a solution. Switching to their prebuilt packages is their official position right now.
Hello Trademark aside, we recommend not packaging Dagger from source at all, under any name, as we anticipate changes to the upstream build process that will prevent a naive “go build” from working. As Mark said, we don’t allow using the Dagger name for downstream source packages. This is so that, when a downstream repackager inevitably screws up their custom build, or decides to modify our source while they’re at it, the reputation of our product does not suffer. In order to protect against this, we have no choice but to apply the same rule consistently across all downstream packagers. Yes, these other source packages you mention are probably in violation too. Now that we’re aware of their existence we will get in touch to let them know as well. Is it possible for nixpkgs to bundle upstream binary builds? That would allow Nixpkg users to benefit from having a Dagger package, without violating upstream trademark rules. Happy to discuss further. Thanks and sorry for being a downer, I appreciate your work Mark!
While bundling upstream binaries is possible in nixpkgs, it goes against the spirit of Nix: we loose the ability to analyse the static dependency graph to find vulnerable dependencies, we have to conform to the upstream supported architectures, etc... Would a rename to or something close be acceptable for you ?
We should just avoid all the software from them. Seems like a legal minefield.
Thank you all. Just to summarize for future reference: There’s no need to avoid the software for legal reasons: it’s OSI licensed and we have no plan to change that.

Our build process will change in the future and become more complex and custom, making it likely that downstream source packages will break. To avoid being on the hook for supporting downstream breakage that we didn’t cause and don’t have the power to fix, we are asking downstream source packagers to not use the Dagger brand. There is no “legal minefield”, just a straightforward combination of strict trademark policy + permissive copyright.
Not a problem in nix as package manager, if it's building it will keep doing. Anyway, I agree with
I think the only realistic option would be to contact the legal team at the specified address in the trademark policy and get explicit permission for e.g. "dagger-built-from-source" or "sourcebuild-for-dagger" or "unofficial-dagger" or "unsupported-sourcebuild-for-dagger" or something like that.