> It isn't against the rules to compile from source and host the binaries on your own repository especially if the original repository does not provide any or doesn't provide them for specific architectures
I'm not aware of the history (if any) of previous discussions of this package, so take the following with a grain of salt. It looks to me that there is a clear licensing issue here. The developers of sm64ex have been asked about licensing in the past [1] and it seems that (a) there is no license for the project, (b) the project is a fork of code written by others that had no license, and (c) builds of the project rely on the builder to supply a proprietary ROM with copyright by Nintendo for assets. The implication of (c) is that even if we could resolve all the issues with the source code licensing, distributing a binary package will never be possible. It isn't clear to me exactly what your Gitlab project provides because there's no documentation. It only includes some completely opaque tarballs you've uploaded. But assuming that you have not figured out some way to build a package that is independent of Nintendo's code and assets, your binary package cannot legally be shared. If you *have* figured out some way to do this, I would suggest contributing it back to the sm64ex upstream so that everyone can benefit. You're correct that it's generally okay to provide a -bin package that just takes an upstream build and repackages for Arch systems. In your case, however, the approach of hosting the binaries yourself and then repackaging them seems to serve no purpose other than attempting to subvert legal objections to distributing the project. sm64ex can't distribute a binary package, Arch Linux can't distribute a binary package, so you're "stepping in" to take on the legal risk by hosting copyrighted materials. I can't imagine AUR moderators looking too kindly on this sort of workaround. Compare a similar case: it seems obviously inappropriate for the AUR to host a PKGBUILD that downloads Microsoft Windows over BitTorrent and packages it for use in VirtualBox, but if your package were allowed I don't see how one could consistently object to this. If you compare what you are providing to existing packages on the AUR like sm64ex-us-git [2], you will notice that these packages require the builder to provide their own sm64 ROM. That is the difference between these packages and your own, *not* the source versus binary distinction. Also, I think at bare minimum you should include a build script in your Gitlab repo to allow reproducing the contents. As it is, I don't think users should trust your package. Obviously, you are probably compiling the binaries from source code in exactly the way you say. But having a fully reproducible build would allow auditing this; using Gitlab's automated release workflow [3] would further increase trust in your builds. > For example NZPortable-bin binaries are provided from my git repository for the nzportable-bin package but I am officially supported by the team to do so It looks to me like your justification for doing this is because the official releases [4] created by the project's automatic build system get automatically deleted every 24 hours. I think this project should be strongly encouraged to provide actual releases that don't disappear so that this kind of archival work that you are doing is not needed. Also, I note that your AUR package is tagged with the GPL2 license, but if you are sharing the project assets in this package, those need to be tagged with CC-BY-SA 4.0, according to the project wiki. The actual status of contributed source code to that project is somewhat dubitable, as they haven't included a license file. Cheers, Adam [1] https://github.com/sm64pc/sm64ex/issues/89 [2] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=sm64ex-us-git [3] https://about.gitlab.com/blog/2023/11/01/tutorial-automated-release-and- release-notes-with-gitlab/ [4] https://github.com/nzp-team/nzportable/releases
