perfect_dark: init at 0-unstable-2025-01-05

[PaulGrandperrin]

Description of changes

A PC port of Perfect Dark based on the decompilation of the Nintendo 64 game

https://github.com/fgsfdsfgs/perfect_dark

To play the game, you need to put the corresponding ROM at $XDG_DATA_HOME/perfectdark/data/pd.ntsc-final.z64 and then nix run github:NixOS/nixpkgs/pull/306767/head#pd.

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:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (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.

---

Add a 👍 reaction to pull requests you find important.

[yunfachi]

In 35c30e19cd7a46597f336a08b1d9509a0fb4ba53 you add yourself as a maintainer, but this should be in a separate commit with the message: maintainers: add <handle>.

Also change the pull-request title to pd: init at <version>.

[PaulGrandperrin]

@yunfachi It's done!

Sorry, I missed that the commit needed to be split.. that makes sense actually :)

[PaulGrandperrin]

Upstream just accepted a PR I sent them, so I updated this PR too to remove the patch I had to carry.

[PaulGrandperrin]

@qubitnano I'll create a new commit to make more changes.

What do you think about the name pd? That's what upstream uses for the binary, but the repo is named "perfect_dark".

Perfect Dark is trademarked by Microsoft.

[PaulGrandperrin]

I now pushed a new squashed commit taking into account all the suggestions.
The version has been updated in the commit message and this PR title.

Everyone is happy with the name pd?

[yunfachi]

Everyone is happy with the name pd?

I would prefer perfect-dark, but I won't insist.
You can read https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-naming to make a choice.
In addition, please consider the ripgrep package, which has a single executable rg, but is called ripgrep.

[PaulGrandperrin]

You can read https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-naming to make a choice.

I read that part but it doesn't clear the ambiguity of this situation. And doesn't talk about potential trademark issues.

That kind of projects already make many people anxious with respect to legality.

For instance, the decomp of Ocarina of Time explicitly avoids any references to "Zelda" or "Ocarina of Time".

I really don't like pd (it's slang for fagg*t in french) but I thought maintainers might push back on perfect_dark.

[PaulGrandperrin]

Also, the project says its license is MIT but I'm not even sure it's legal.

It's obviously a derivative work of an unfree piece of software, so I don't really believe it can be MIT.

I think it's important for us because if we mark it as free, its source and binary will be stored and distributed on cache.nixos.org.

This might become a source of pain if Microsoft decides to sue the project in the future, similarly to yuzu.

EDIT: For reference, sm64 and shipwright upstream projects don't have a license (and I think it makes sense) and are therefore considered unfree by NixOS.

[pluiedev]

You can read https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-naming to make a choice.

I read that part but it doesn't clear the ambiguity of this situation. And doesn't talk about potential trademark issues.

That kind of projects already make many people anxious with respect to legality.

For instance, the decomp of Ocarina of Time explicitly avoids any references to "Zelda" or "Ocarina of Time".

I really don't like pd (it's slang for fagg*t in french) but I thought maintainers might push back on perfect_dark.

The thing for me is that it kinda overly obscures what it's for, and usually shorter names are reserved for more 'fundamental' tools like ar and cc, and it's kinda silly to me that Perfect Dark gets to have pd purely to disguise it from Nintendo's eyes. Really, if that's the sole purpose, then there needs to be a formal policy drafted regarding the status of Nintendo property, or other pieces of software that could contain Nintendo property, on Nixpkgs.

Thankfully, the worst you can do is to have one or maybe several repos in nix-community that contain these packages, away from Big N's eyes... 👀

[pluiedev]

Also, the project says its license is MIT but I'm not even sure it's legal.

It's obviously a derivative work of an unfree piece of software, so I don't really believe it can be MIT.

I think it's important for us because if we mark it as free, its source and binary will be stored and distributed on cache.nixos.org.

This might become a source of pain if Microsoft decides to sue the project in the future, similarly to yuzu.

EDIT: For reference, sm64 and shipwright upstream projects don't have a license (and I think it makes sense) and are therefore considered unfree by NixOS.

I am decidedly NOT a lawyer, but judging by the fact the repo contains reverse-engineered code that still compiles to the original binary, I think it would be easier to make the case that the repo contains the original developer's code and cannot be re-licensed under the MIT license by the reverse engineer. However, this is an upstream issue and for now we should follow what's written on the tin.

Maybe add a generic unfree license in the mix of licenses so that it's marked as unfree software with (possibly) FOSS parts?

[PaulGrandperrin]

The thing for me is that it kinda overly obscures what it's for, and usually shorter names are reserved for more 'fundamental' tools like ar and cc, and it's kinda silly to me that Perfect Dark gets to have pd purely to disguise it from Nintendo's eyes. Really, if that's the sole purpose, then there needs to be a formal policy drafted regarding the status of Nintendo property, or other pieces of software that could contain Nintendo property, on Nixpkgs.

Thankfully, the worst you can do is to have one or maybe several repos in nix-community that contain these packages, away from Big N's eyes... 👀

Oh, it's really not about hiding it, or that there exists mentions of it in the project. We can mention trademark and registered name as much as we want. But naming a piece of software with a registered name, that's exactly what registering a name is supposed to protect from.

For instance, the shipwright project is careful about not naming their project with a trademarked name but "Zelda" and "Ocarina of Time" are present hundreds of times in the source code and assets. Also, everyone knows what they are about, including Nintendo, so they're not hiding from anything.

The issue I see here, is officially presenting this piece of software with a trademarked name that we don't own or have a license for.

I think the shipwright project have the exact same understanding of the situation as me on this. They and I can be wrong as IANAL.

[yunfachi]

It's minor, but in the commit perfect_dark: init at 0-unstable-2024-09-02, you formatted the maintainer-list.nix (your keys attr), which should be done in maintainers: add PaulGrandperrin. Additionally, there's no need to ping people, as not everyone has the time to review the pull request every day.

[matteo-pacini]

@PaulGrandperrin I've added Darwin support to harkininan, but it was already present in nixpkgs, so not entirely sure about the process that led to its inclusion back then.

I think it would be good to hear thoughts from the other people you pinged re the process here - if this sort of package is not allowed anymore, then we should remove all the others.

My two cents: This looks fine to me - it's marked unfree, we don't redistribute ROMs, and it's similar to other packages that have already been accepted.

[PaulGrandperrin]

@yunfachi Sorry for the ping then, I thought you added yourself as a reviewer 7 months ago and that it was the first time I asked you to review since.
There's probably something I didn't understand with Github's review system.
I fixed the commit though.

[PaulGrandperrin]

@matteo-pacini

I think it would be good to hear thoughts from the other people you pinged re the process here - if this sort of package is not allowed anymore, then we should remove all the others.

Figuring out a global policy once and for all would be nice indeed, whatever the outcome !

[yunfachi]

@yunfachi Sorry for the ping then, I thought you added yourself as a reviewer 7 months ago and that it was the first time I asked you to review since. There's probably something I didn't understand with Github's review system. I fixed the commit though.

That's not exactly what I meant, but all is good.

[SigmaSquadron]

FWIW, Atemu, Emily, myself and a few others had a discussion in the Nixpkgs contributions chat a couple of days ago about this. https://matrix.to/#/!kjdutkOsheZdjqYmqp:nixos.org/$jf0jebi8EnMowgSXY4xnZGM98B07n--yYUGIOioS34Y I maintain my approval, as this does not redistribute the ROMs, and similar games are already packaged on Nixpkgs. I do not believe such a package will bring harm to the repository, as Nintendo has no legal precedent of abusing the DMCA to take down a package repository that distributes nothing but links to upstream sources and generic patches. In reply to the proposal of deleting this and the rest of the decompiled abandonware, I said the following:

At this point we might as well nuke every other emulation software in Nixpkgs, as well as QEMU (because it enables people to break Apple's Mac EULA), Tor (because naturally everyone using the spooky dark web is a criminal) and probably every package that might happen to have a legal history. We aren't enabling anyone; Nixpkgs is not the one single source of software - it's not even a source of software, but a source of build scripts. If anything, distributing proprietary code in Hydra would be an issue, but it is not in this situation. Distributing: - A list of dependencies - An abstracted link to questionable code - A high-level description of the questionable code - Generic patching needed for any other Nix package is probably not a crime.

The port still requires one to own a valid cartridge. We shouldn't assume that the cartridge won't be obtained legally. Not that any of this matters, of course; we aren't redistributing anything, so I fail to see what kind of legal standing any game company would have against us here.

[Atemu]

I know this is not an excuse, but there's already so many packages in legally gray area in Nixpkgs, many of which are even clearly and explicitly illegal (examples at the end if you are curious).

Those need to receive the same scrutiny, especially the latter category.

AFAIK, there isn't a global policy forbidding those expressions, so the question can either be:

There is no global policy on most things. This is my own opinion on the matter, not anybody else's.

* why `perfect_dark` in particular should be rejected?

The specific game does not matter. I came across this one before I did the others.

* or why isn't there a global policy rejecting all the others?

That'd require an RFC that someone would need to write, get a lawyer's opinion on and push to the end. I imagine we do need such a policy and will have it at some point. Until then, I'd prefer to not jeopardise the entire project in predictable manners; that's just common sense.

I think a more accurate description is "has not been produced through legally-proven-safe (as in court-tested) means".

IANAL but, a decomp from the original machine code is very clearly a derivative work of the machine code which in turn is a derivative work of the original authors's code.

Even Wine/Proton, which has not been developed through clean room R-E, is also in this gray area, Microsoft might attack the project at any time, and NixOS builds and hosts this project's binaries. There's really so many other examples.

Clean-room reverse engineering is court tested AFAIK. It would be absolutely fine IMV.

The WINE project actually has strict policies w.r.t. exactly this in order to minimise the risk of ever receiving legal action from daddy M$.

The actual grey area of looking at a decomp yourself but only to inform yourself on internal interfaces and algorithms and then re-building the code through your own creative processes ("dirty-room" RE?) would be fine IMPV, though still hairy.

Unless you can get the person who did it testify which case it is beyond a reasonable doubt, I'm going to assume a "decomp" is a derivative work.

I'm pretty sure there's nothing they can do in particular.

No, they can do either option of what I said and that would make me give my approval to this PR.

the emulation scene has been living in this gray area for decades, we won't know for sure until it is settled in court

That'd be news to me as emulation in general has been proven legal in court to a point where I don't see a great risk. If even Oracle lawyers can't make APIs copyrightable, we don't need to worry.

for each country in the world.

I'm only concerned about two legal standards here: The U.S.' because we're hosted on Github and the EU's because the NixOS foundation is a Dutch Stichting. All others don't have much bearing on us for now.

The problem is mostly the U.S. here with its batshit crazy corpocracy laws.

(If we moved off of Github onto something with EU domicile, this wouldn't be much of an issue IMV btw. Something, something bagels and ice cream.)

I don't think they care about convincing people that their project is legally safe, they know they can't. They don't even mention anywhere this subject.

That's the reason I'm so apprehensive here.

Neither did game console emulation and decompilation projects convinced other Nixpkgs devs "beyond a reasonable doubt that their code is legally produced such that there is no reasonable way to argue that we knowingly participated in copyright infringement".

I think you're massively misrepresenting the emulation community here. Many projects have taken great efforts in order to stay in the clear legally.

Not all of them and I will advocate for their removal if they too give me a whiff of blatant copyright infringement.

I really think we are taking all the caution necessary. If we are not, dozen of other projects would need to be purged from Nixpkgs at least.

Um, yes.

In Nixpkgs, we already have lots of things derived from Nintendo:

* many **dozens** of emulators for their consoles (RMG, mupen64plus, ryujinx, melonDS, cen64, zsnes, dolphin...)

I'm not intimately familiar with each of them but I recognise a few names that have stood the test of time and what I like to call the "Android-test" (aka. has the android port not stirred legal action from Ninty yet).

* Decompiled games (like this PR):

  * sm64ex (Super Mario 64)
  * shipwright (Zelda: Ocarina of Time)
  * 2Ship2Harkinian (Zelda: Majora's Mask)

As mentioned, clean-room and (depending on the circumstances) perhaps "dirty-room" RE games are fine IMV. We will definitely have to check whether it's actually the case with the ones we currently have and yeet the risky ones.

Importantly, when Nintendo DMCA'd ryujinx

Contrary to popular belief, Ryujinx was not DMCA'd. Its takedown was a private "settlement" between Ninty and gdkchan; we don't know the details. It could have been shut-up money or even the mafia for all we know.
Though if Ninty didn't try legal BS first, that's a pretty good sign that they couldn't if you ask me.

and yuzu, Nixpkgs wasn't affected, because again, nothing is hosted or built on NixOS infra.

Yuzu was hosted on NixOS infra and Ryujinx continues to be.

And btw, Perfect Dark is owned by Microsoft, not Nintendo.

Same difference.

Who is "We" here? Many other contributors did already make it happen :/

You, me; anyone involved in the project.

Just because they may not have been aware of the risks doesn't mean they want the project to be DMCA'd.

Fortunately, it's not owned by Nintendo

Read the cover of the cartridge you're holding more closely and you'll discover that it's "distributed exclusively" by Ninty. While they do not own all of the IP, they still own some rights to it.

(They technically also own much of the N64 "standard" in the form of patents but those must have all expired by now.)

even when they did DCMA'd yuzu and ruyjinx, Nixpkgs wasn't affected.

That's dangerous thinking. Nix isn't even on the radar of most nerds, let alone the general public. We have no way of knowing what Ninty would have done if they were aware of us.

boot.zfs.removeLinuxDRM: clearly breaks the kernel's GPL and therefor illegal

Illegal to distribute and we don't.

You can make such modifications to your Linux kernel and use it yourself but you aren't allowed to distribute it to others in any form. (AFAIK, IANAL.)

networking.wireless.athUserRegulatoryDomain: builds a driver not enforcing radio regulations, extremely illegal.

Illegal to operate depending on where you are. Not an issue of copyright though, so not exactly relevant to this case.

I'm not familiar with the laws surrounding this but I don't think breaking them has nearly the same severity as copyright infringement.

mesa's enablePatentEncumberedCodecs, which is enabled by default: Illegal where software patents are a thing.

Only an issue for the distributor of the binaries which is the NixOS Foundation. The Netherlands doesn't care about software patents to my knowledge. (At least not to a degree that would affect distribution of codecs; see also France's VideoLAN who also don't give a hoot about MPEG's patent trolls when hosting VLC on their website)

maybe you didn't see that this package can't work on its own and still requires the user to provide the actual game's ROM (which contains all the copyrighted data and artwork)

That's not what I'm primarily concerned with. I'm concerned with the license of the upstream project you're packaging because if it's a derivative work of the perfect dark ROM, that means they aren't allowed to distribute it and we shouldn't help people in infringing on copyright this blatantly.

The assets are another issue actually. If you could reasonably make the case that the vast majority of users aren't going to dump their cartridges but rather acquire the ROMs illegally, you could make the argument that the purpose of the program is to pirate. That's the case Ninty made in the Yuzu SLAPP. It was settled out of court, so we don't know whether that argument stands but I could see it given the crazy U.S. copyright laws.

As someone who's looked into dumping N64 cartridges before, I don't think many people are doing that, soooo :/

OTOH we package Mupen which has the same issue but has stood the time- and Android tests, so I'd be willing to take that particular risk.

[PaulGrandperrin]

@Atemu I won't reply to your answers point by point because it feels too argumentative, and I don't want my answer to give this feeling.

I think the main points are:

1. the decompilation projects have a reasonable chance of being illegal (derivative of copyrighted material)
2. the distribution of build scripts for those decompilation projects have a chance of being considered helping 1, which might be enough to be illegal too
3. point 2. might still hold even though those games can't work on their own without the user providing the original ROM (supposedly legally acquired, like myself)
4. if the previous points are true, or some company thinks they are, there's a chance they could take action againt those projects
5. if 4. happens, there's a chance they might also take action against NixOS/Nixpkgs
6. GitHub/Microsoft might follow up and take down Nixpkgs (in the top 20 most active repos) before requesting the maintainers to remove the offending package.

I think everyone can agree with those points.

The divergence is about how likely all those points are to happen, and if that's enough to warrant preemptive self-censuring.

I read the good points from your answer and from matrix and have many counterarguments, but it's not important.
If I had some responsibility for Nixpkgs I would consider the risks more than low enough, but I'm not in that position.

Considering the massive number of Nixpkgs expressions that could be considered as helping the user build/do illegal things (at least in the US and Netherlands/EU), I see two solutions to purge them from Nixpkgs:

• let the maintainers host them individually in personal flakes
• group them on separate repo (in a separate gitub orga, or even on a self-hosted website), while duplicating how Nixpkgs maintenance work (guidelines, processes, maintainers, test bots etc)

I would be happy if we could materialize the second solution to keep a standard of high quality and discoverability. The downside is that this would make a more obvious target to strike, but fortunately, it wouldn't affect Nixpkgs.

[pluiedev]

I would be happy if we could materialize the second solution to keep a standard of high quality and discoverability. The downside is that this would make a more obvious target to strike, but fortunately, it wouldn't affect Nixpkgs.

The NUR fits the bill pretty well though discoverability and standards are considerably poorer, but it's still an option

[PaulGrandperrin]

The NUR fits the bill pretty well though discoverability and standards are considerably poorer, but it's still an option

I don't know NUR that well but it feels to me more like the first solution, with a single point where all the independent packages are linked to.

I think the quality we get by having a monorepo maintained by a dedicated team is much higher.

[Atemu]

The NUR is not a great solution IMHO. It's also going away pretty soon last I've heard because nobody is maintaining it.

You can absolutely make a flake or whatever for this. Perhaps even upstream. I don't think we need to get Nixpkgs maintainers involved in that in any way; you can just do that on your own without our input. We're just here to gatekeep Nixpkgs ;)

Since you didn't intend for this to be built on NixOS infra anyways, you wouldn't lose anything by doing that either. Other than discoverability of course.

[PaulGrandperrin]

If all the decompiled games and the game console emulators are indeed going to be purged from Nixpkgs, I think many people would be happy to find them again in one semi-official place, instead of searching for many independent half-maintained flakes.

If this happens, I'll be happy to help with creating and hosting this nixpkgs-dangerous repository.
In the meantime, I'll keep this PR opened and maintained in case no changes are done to Nixpkgs' policy.

[j0lol]

Hi @j0lol [snip] !

I bother you because I see you contributed to the other n64 decompiled games already present in Nixpkgs.

[snip] blocked this PR asking

Upstream should either clarify the legality of that situation or re-do the original work cleanly.

I think neither of those are realistically going to happen. More details here #306767 (review)

Do you know something that we don't that made it possible to get your packages merged into Nixpkgs?

Hi, original author of the shipwright package (which maybe kicked all this off? maybe not?) We did not get any special information or permission. Nobody blocked my PR when I made the original and nobody raised any flags in unofficial nix channels so I was under the impression it was okay. You should probably remove my package if it violates the rules of the repository. Thanks.

[Atemu]

all the decompiled games and the game console emulators are indeed going to be purged from Nixpkgs

Note that, as mentioned, we don't need to purge all of them, only the ones where a blatant copyright violation is likely.

Most emulators I know do not fall into that category such as Dolphin or Mupen.

I'll be happy to help with creating and hosting this nixpkgs-dangerous repository.

I was thinking something on the line of nixpkgs-illegal but thought that it was perhaps too on the nose :^

[PaulGrandperrin]

Note that, as mentioned, we don't need to purge all of them, only the ones where a blatant copyright violation is likely.

For the record, I just want to reiterate that sharing MIT-licensed build scripts (moreover without any links to the ROM) is certainly not "blatant copyright violation". And there is currently 0 historical events suggesting they might be.

Certainly gray area, but it's only speculation to affirm something stronger.

Most emulators I know do not fall into that category such as Dolphin or Mupen.

I'm sorry to get a little argumentative here, but I really don't get this argument when in fact history says it's by far the emulators that got attacked over the years.

I mean yuzu and ryujinx (which is still in Nixpkgs, built and distributed as a binary) but also dolphin, and basically all the other nintendo emulators. Sony also attacked PS1, PS2 and PS3 emulators, also distributed by Nixpkgs.

Speaking of the decompiled games, Nintendo DCMA'd many website distributing ready-to-play binaries of SM64 that were bundling the ROM, but AFAIK they didn't attack the original project. SM64's decompilation is still on GitHub, in contrast to yuzu and ryujinx.
That says a lot about which type of project is currently more dangerous in practice.

I was thinking something on the line of nixpkgs-illegal but thought that it was perhaps too on the nose :^

I know it's a joke, but as far as I know, only Nixpkgs actually distributes things that are known to be illegal (allowing use of illegal radio freqs which is a serious crime is almost all countries on earth, and violating patent law in the USA, which hosts GitHub...)

The goal of nixpkgs-dangerous would only be to host things that are neither known with certainty to be legal nor illegal, like emulation and build scripts for decompiled games. Of course, it wouldn't contain or link to things that are known to be illegal like ROMs, so "nixpkgs-illegal" wouldn't describe this project.

The main idea would be to remove the burden of legal uncertainty surrounding those project from the official Nixpkgs.

EDIT: a more appropriate name would be nixpkgs-gray-area !

EDIT2: As I saw in the matrix conversation, even the use of patchelf on proprietary binaries is probably illegal, so lot's of things in Nixpkgs are gray area at a minimum :) But to be honest, it seems really fine to me. Any project, big and inovative enough, contains parts that are gray area, cf. AI and big tech in general.

[Atemu]

I just want to reiterate that sharing MIT-licensed build scripts (moreover without any links to the ROM) is certainly not "blatant copyright violation". And there is currently 0 historical events suggesting they might be.

With the "blatant copyright violation" I meant the software itself, not our build scripts.

We generally don't package things that clearly infringe on copyright. I think most of us agree on that. This PR and what we've been discussing so far goes a bit more into the grey area; requiring more nuance.

history says it's by far the emulators that got attacked over the years.

Attacked yes but rarely with much success AFAIR. Yuzu would be the "greatest success" in this regard that I can think of in recent history but their circumstances were quite a bit different to most other emulators. They did some bad moves that got them caught in the DMCA such as marketing TOTK support before it was possible to acquire legally. (That's explicitly prohibited by the DMCA.)

violating patent law in the USA, which hosts GitHub...)

IANAL but I don't see this as a great threat given that we don't distribute patented software in the U.S. I don't see an argument against build package scripts for doing something that is perfectly legal where you are domiciled and where most of your users are.

With patents we also don't have to worry about the DMCA. I personally have never heard of a GH repo being taken down for patent infringement.

As I saw in the matrix conversation, even the use of patchelf on proprietary binaries is probably illegal

IANAL but this isn't as clear as you make it to be. "Infringing" on copyright for the sole purpose for making something compatible with other software is a very different thing to producing a derivative work via decomp. Copyright isn't such a black and white thing.

To give you an idea on how significant such distinctions can be, the DMCA has an explicit exemption to breaking DRM for the purpose of making other software compatible with it:

‘‘(f ) REVERSE ENGINEERING .—(1) Notwithstanding the provi-
sions of subsection (a)(1)(A), a person who has lawfully obtained
the right to use a copy of a computer program may circumvent
a technological measure that effectively controls access to a particu-
lar portion of that program for the sole purpose of identifying
and analyzing those elements of the program that are necessary
to achieve interoperability of an independently created computer
program with other programs, and that have not previously been
readily available to the person engaging in the circumvention, to
the extent any such acts of identification and analysis do not
constitute infringement under this title.

(Emphasis mine.)

[Pandapip1]

As I saw in the matrix conversation, even the use of patchelf on proprietary binaries is probably illegal

I am not a lawyer, but since the only thing that patchelf modifies is the path to the linker and RPATH (i.e. it doesn't touch any copyrighted portions of the binary), it seems unlikely to ever be considered modification of a copyrighted work in the first place.

[SigmaSquadron]

So, I fear this has gone stale, and eventually someone will need to put their foot down. I maintain my approval here, as I remain unconvinced that this is a threat to Nixpkgs, regardless if courts determine upstream to be illegal or not. I see no reason for this to not be included, especially when there are so many examples of packages that actually redistribute proprietary software - link and all - in Nixpkgs. If Atemu or another committer explicitly says no, then this will need to closed and turned into a flake elsewhere. If that turns out to be the case, then I'd be happy to maintain it alongside you, @PaulGrandperrin.

But ideally this turns out to be unnecessary, and this can be included in the tree while a more permanent legal solution is developed elsewhere (RFC time, anyone?), and that solution may choose to keep the questionable packages, move them to another NixOS-managed repo, or delete them from Nixpkgs.

For now, it seems inconsiderate to not reach a conclusion on this seven-month-old PR.

[PaulGrandperrin]

I just updated the expression with the latest upstream version.
The major changes are that it now builds with cmake and supports 64bit!

For now I'm pushing here so that people interested can easily find the code.
No need to review the changes as the PR is blocked anyway.
I wanted to move it back to draft status but I think it's blocked too.

FYI, I'll wait a few more months and see if the other decompilation projects have been removed from nixpkgs. If not, I'll ask the maintainers to reevaluate this package's inclusion.