Potentially depricate or change source for Duckstation due to License Change

[Faeranne]

Issue description

As of Duckstation commit 7690675, they only permit unmodified distribution, and based on the readme as of that commit, Please note that pre-configured settings and packages are considered modifications. and the commit message states Packaging is still **not** permitted, since it is effectively a modified/derived work. This has already been directed at AUR, and likely will be pointed at Nixpkgs for the same reason, should new code be packaged.

Suggestion

As of right now this probably needs to be a discussion, not a direct fix, but at the very least, until a fork is chosen, or a path is decided, probably best to point any attempts at updating Duckstation at this info, since it could potentially violate the new license. Most software would best be covered by doing patchelf on the binary in this case, but given the author seems adamant on preventing any repackaging, for any reason, this probably warrants either discussion, or at least monitoring. Old versions remain under GPLv3, and there are already forks showing up, but at least for me, it isn't clear what is a good next step.

Maintainers

Pinging the maintainers, purely to keep things from getting lost. I'm fairly sure they've both already seen this info, but incase I haven't missed an existing issue/discussion on this, wanna keep them looped in too: @guibou @AndersonTorres

(PS: I have no idea for sure if this license change is even allowed or not. Lead dev has stated he received permission from all contributors, but others are suggesting this is not the case? Not sure it even really matters here. If it's a legal change, something has to be decided here, if it isn't then nothing changes anyways)

[AndersonTorres]

Attribution-NonCommercial-NoDerivatives 4.0 International

https://github.com/stenzek/duckstation/blob/master/LICENSE

Does it apply to scripts? We can just change license then prohibiting it to be built on Hydra.

Plus finding a fork :)

[Faeranne]

Does it apply to scripts?

Legally? Probably not. Question there is, is that better than finding a fork, given the history of the project and the author's pretty "anti-packaging" stance, or does nixpkgs trust that this is sufficient to avoid any issues? Probably short-term it's fine, but given the history (eg: duckstation vs swanstation & libretro), I wouldn't put my time into that significant of a process, given it very much could still result in conflict. (Note: I'm also not directly linking anything to avoid triggering notifications. The lead dev is their own person and welcome to do what they want, within reason. I'd just rather not draw any drama around the choice into here, and historically, the lead author has been the center of a lot of drama.)

[matteo-pacini]

Would #336021 be affected by this? duckstation-bin was created to have something working on Darwin, as the project cannot be compiled from source there.

The precompiled macOS app gets copied directly, without modifications.

[Atemu]

Disclaimer: IANAL.

There has been no such license change. You cannot change the license of other people's code without their explicit consent or revoke the GPL on your own. The only thing the author can do is dual-license their own parts of the code but they must still obey the GPL for any new code until they actually relicense their project by either getting all other past contributors to consent to relicensing or removing their code.

The code therefore remains GPL and the primary author is in violation of it due to their "relicensing" attempt 2 weeks ago. Any code newer than https://github.com/stenzek/duckstation/commit/25bc8a64803df7e702db66e0f11d7b7d0fdc99f2 is in violation of the GPL. Since they're in violation, we'd be in violation too if we shipped their code. There is no legal way to ship the "relicensed" Duckstation I'm afraid.

Our current options are to either remove the package which isn't too far fetched as upstream is clearly an malicious actor or to ship the last version not in violation of the GPLv3. I'd favour the latter as there will surely be a new upstream or a massive backpedal of the current upstream in the coming weeks.

[Faeranne]

by either getting all other past contibutors to consent...

According to https://github.com/stenzek/duckstation/pull/3295#issuecomment-2348988362 this has (allegedly) been done.

I posted this issue under the good faith assumption that this comment is accurate. Either way, it doesn't actually change the discussion more than simply adding a "this might all be resolved before any decision is made" outcome, though that too remained an option given it's possible the author simply undoes everything due to pressure. I would guess that assuming that outcome is unproductive, even if the final decision ends up being "do nothing." The only way this becomes an important factor is if a previous contributor comes forward and actually asserts that they did not authorize this, and that isn't really in the scope of nixpkgs (unless someone here also contributed to duckstation. I have not taken the time to cross reference every contributor)

[Faeranne]

Would #336021 be affected by this?

Entirely depends on if the author argues that the scripting step qualifies as "packaging". If so, then probably. Either way it boils down to if it makes sense to find an alternative, deal with this as it approaches, or simply move on.

EDIT: Should probably add that probably it won't, since that pr is based on a version prior to the license change, but it would throw updates into doubt.

[emilazy]

What an unfortunate situation.

The relicensing does not affect old versions, as FOSS licences are irrevocable by design. Even contributors that agreed to relicense their contributions under the new licence cannot revoke their previous grant to us, so we can package the current version indefinitely.

I think that continuing to include packaging expressions for future versions of DuckStation should not in itself be a licence violation, since they are not by themselves derivative works of DuckStation, so long as we have the license set appropriately to ensure that Hydra does not create any derivative works itself. On the other hand, we would essentially be providing code that can only be used by infringing copyright. There’s precedent for that, though, like the options in the FFmpeg package that allow you to combine incompatibly‐licensed dependencies.

[emilazy]

The maintainer is also correct that NixOS (and many other distributions) technically violate the GPL on a mass scale by not clearly marking our derivative works and reproducing the copyright and licence notices with all derivative works (though the latter is something other distros do better than us). So if upstream is explicit about licence‐lawyering this, we should probably not be carrying the current version marked as free either :(

[AndersonTorres]

What is the most recent FOSS-licensed commit of duckstation?

In terms of forks, libretro has swanstation: https://github.com/libretro/swanstation

[AndersonTorres]

technically violate the GPL on a mass scale by not clearly marking our derivative works and reproducing the copyright and licence notices with all derivative works

Is this a problem for the git repo? Technically the repo provides scripts to modify code, the Hydra caches are more of a useful add-on.

[Atemu]

What is the most recent FOSS-licensed commit of duckstation?

Anything before (including) https://github.com/stenzek/duckstation/commit/25bc8a64803df7e702db66e0f11d7b7d0fdc99f2

Is this a problem for the git repo? Technically the repo provides scripts to modify code, the Hydra caches are more of a useful add-on.

Emily meant that, in order to comply with the GPL, we technically must prominently state that we "modified" the licensed code because building a binary counts as a derivative work in the current western copyright system and the GPL requires all derivative works to carry "prominent notices" of modifications.

We actually do this in many cases where the project provides a convenient method such as coreutils' --with-packager= configureFlag or the kernel's KBUILD_BUILD_VERSION but by far not in every package.

[emilazy]

Emily meant that, in order to comply with the GPL, we technically must prominently state that we "modified" the licensed code because building a binary counts as a derivative work in the current western copyright system and the GPL requires all derivative works to carry "prominent notices" of modifications.

Yes, but also the derivative work must retain the copyright/warranty notice and GPL text, and we don’t currently copy licence files. This is something I’d like to work on, preferably with as much automation as possible, but obviously it’s pretty thankless work and we rely on general FOSS community goodwill as a package distribution.

I don’t think it’s a problem for our Nix expressions, although it’s possible that a court could look askance at shipping software that can only be used by violating other people’s copyright (so at least in the case of DuckStation I’d be wary given the maintainer’s established stance on packages violating the GPL). I think our patches, as derivative works of the upstream projects that we don’t MIT‐license, may be a source of chronic licence violations, though…

[AndersonTorres]

What about softwares like aegisub, that are BSD but link with GPL libs?

---

I would suggest something like a passthru that installs licenses in a dedicated directory, say /nix/store/licenses/, to not affect the current Nix Store.

I never asked, but how Guix deals with this?

[Atemu]

What about softwares like aegisub, that are BSD but link with GPL libs?

If it's a derivative work, it needs to be licensed under the GPL's terms. Most BSD licenses are "GPL-compatible" though, so that's usually trivially possible but IIRC there was a weird BSD license variant that was incompatible.

Whether linking is a derivative work is a hotly debated topic and currently unclear but there are good indications that it is and that's been how the GPL has been commonly interpreted to the point where that may even be a consideration for a court deciding on this.

I would suggest something like a passthru that installs licenses in a dedicated directory, say /nix/store/licenses/, to not affect the current Nix Store.

I don't see why that'd be necessary. Packages usually install their license into their share/ directory. A bunch of our packages already do this by default, no action required.

[camtauxe]

Would the same solution used for Aseprite work here as well?

As I understand it, Aseprite is source-available but not redistributable. The package to build it from source is still in Nixpkgs but is set so that it must be run locally. In a sense, it just amounts to distributing an easy-to-use script to create your own personal build. So it isn't really modification.

[AndersonTorres]

I don't see why that'd be necessary. Packages usually install their license into their share/ directory. A bunch of our packages already do this by default, no action required.

My concern is with the global - not merely mass - rebuild.

To begin with, each possible src should have its meta.license clearly set. After that, we need to calculate the interactions among the *Inputs, all of them - possibly expanding it to all derivation machinery -, so that we can determine the license of outputs.

With all this info, we can establish the course of action.

In order to not generate a global rebuild and not flooding the already-established /nix/store/, I am thinking in something like outputs = [ . . . "licenses"]; and a passthru.

[emilazy]

We do global rebuilds every staging cycle, and separate outputs would not prevent it.

[Faeranne]

@camtauxe

Would the same solution used for Aseprite work here as well?

In theory it should. In theory, the AUR should be doing something similar, but has already been mentioned in the past as a "gpl violator" due to packaging, so based purely on what I have actually read, it still throws into question this particular package.

I do feel that a lot of discussion has been going on around handling the license files themselves, which is good, but also is overshadowing the original issue, that this particular package is (allegedly) not GPL anymore, and that the creator (allegedly) insists that any form of packaging, script or otherwise, is a derivation and thus a violation.

Would it make sense to create a separate issue regarding handling packaging license files? I would rather keep this focused on duckstation and it's future on nixpkgs.

[AndersonTorres]

Would it make sense to create a separate issue regarding handling packaging license files?

https://github.com/NixOS/nixpkgs/issues/342570

[AndersonTorres]

For the record, Leah Rowe archived Duckstation before the new license:

https://vimuser.org/duckstation.html

https://codeberg.org/vimuser/duckstation/commit/f974166e827268e5fe2b0ea75b05a898152e9d9d

[Faeranne]

That article is actually where I originally learned about this. I would be surprised if stenzek actually wiped the old commits, but it's always good to have backups. Beyond a backup existing for someone else to fork, I'm not sure how useful a pure archive copy is to nixpkgs.

[Faeranne]

Oh! I did not see the update on Leah's article. Hopefully that leads somewhere productive for Nixpkgs. Probably should still have an idea what to do if that doesn't end well, but maybe that staves off this discussion to another package.