Hello everyone, I hope you are all doing well I just wanted to talk about the discussion about my package sm64ex-bin, I was informed to chat about it on the mailing list so I wanted to make sure I was in the right place. I will admit the initial issue frustrated me and felt a little targeted especially when most of my other bin packages use binaries from my repository but I wanted to discuss the issue and resolve any allegations of slander that was put on with no factual evidence to provide when I have been a long time package developer on the AUR and a longer time developer on Github and Gitlab which I use now. 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 wanted to create a bin package for a project for user to use and enjoy the project without needing to wait for compiling times especially on Raspberry pi devices every time while also bundling it with my launch scripts if needed,. 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 and it's a bit harsh to slander me with assumptions that I am a bad actor with no evidence, it's also pretty rule and a bit insulting to my credibility. All I ask is to have the ability to re upload my package and continue to maintain the bin package for sm64ex-bin for all the users who use it including myself, I am happy to talk about any upstanding issues and fix any concerns if there is any. Thank you Corey Bruce
Sep 10, 2024, 04:46 by cdfrosty@gmail.com:
Hello everyone, I hope you are all doing well
I just wanted to talk about the discussion about my package sm64ex-bin, I was informed to chat about it on the mailing list so I wanted to make sure I was in the right place. I will admit the initial issue frustrated me and felt a little targeted especially when most of my other bin packages use binaries from my repository but I wanted to discuss the issue and resolve any allegations of slander that was put on with no factual evidence to provide when I have been a long time package developer on the AUR and a longer time developer on Github and Gitlab which I use now.
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 wanted to create a bin package for a project for user to use and enjoy the project without needing to wait for compiling times especially on Raspberry pi devices every time while also bundling it with my launch scripts if needed,. 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 and it's a bit harsh to slander me with assumptions that I am a bad actor with no evidence, it's also pretty rule and a bit insulting to my credibility.
All I ask is to have the ability to re upload my package and continue to maintain the bin package for sm64ex-bin for all the users who use it including myself, I am happy to talk about any upstanding issues and fix any concerns if there is any.
Thank you
Corey Bruce
Hey Corey, From a user perspective, my main concern would be that the source used to compile the hosted binary file is available. If you're literally only hosting a binary file, then I expect the source code used to compile said file would be the original source - in this case from the sm64ex repo. If you're including source modifications during the build process, then I would expect the modified source to be available, and ideally (though not a hard requirement), I'd prefer the binary file hosted as a GitHub/GitLab release asset on the same repo. The other issue I could see is if a compiled form of sm64ex no longer requires the user to provide the game ROM. If your sm64ex-bin package can be installed and run without the user ever providing a ROM file, then I can understand an AUR admin being hesitant to host that package. I'm not privy to any previous comments or allegations, so I can't speak to those. And I'm not an AUR admin or Arch staff member. But again, from a user perspective, as long as the source used to compile the binary file is available, it doesn't really bother me where the file is hosted or who's hosting it. I don't see a big difference between you hosting the file and maintaining the AUR package versus an original developer doing so. Hopefully this issue can be resolved amicably. Brian Allred
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
participants (3)
-
Adam Fontenot
-
Brian Allred
-
corey bruce