Open friedkeenan opened 5 years ago
Now we also need @fennectech's permission to switch our license to GPL
Ill give it :)
Oh, we also wouldn't have to detect CFW anymore because all CFWs support rebooting to payloads
You can ask SciresM for permission to use his code. Even though atmo is GPL the copyright owner can still override this.
From what I can see in your commit, nxsh_reboot() is a fairly generic function using only libnx dependencies. It's so generic that you'd be hard-pressed to tie it back to Atmosphere in any way, and thus the GPL issue seems moot (feel free to weigh in on this @friedkeenan). Also, I wouldn't consider switching away from a BSD-style license a trivial thing; I chose it for ideological reasons.
I'm not saying that we would need GPL right now, I'm saying that if we wanted to add rebooting to a payload, we would need to go to GPL since I would be using code from Atmosphere to implement it.
And yeah, I personally don't care too much about what license this project has, but if we want to add reboot to payload our license would need to be GPLv2 or GPLv3 or we would be breaking licensing laws.
Ah, my mistake, I misread the original post. In that case, I support reaching out to Atmosphere for permission to include that bit of code in our project. I can't imagine SciresM would be unreasonable about this request.
Pull an compaq bios and RE it. Have someone who hasn’t looked at atmo code write something that does the same thing.
I may have a potential compromise. For a while I've had the idea to create a daemon (implemented as a sysmodule) that listens on a socket for requests, and, upon receiving a request, conducts a reboot with the specified parameters. If either of you are familiar with the way systemd handles reboots, this is loosely similar. The benefits of this are threefold: 1) This can be released as a GPL project and not violate the terms of Atmosphere's license. This also divorces it from nxsh and allows users/developers interested in such a thing to use it without having it inseparably tied into the shell. 2) It potentially allows for network reboots, which could be useful for desktop applications to remotely load payloads. 3) Having it be separate inherently ascribes a somewhat higher significance to it. There are quite a few interesting features that could be added here (scheduled reboots, for example) that go far beyond the scope of a shell, and would require significant development time in their own right. I don't want to hamper active development here by focusing too much on a small aspect of nxsh.
Let me know what your thoughts are on this.
I quite like this suggestion.
@fennectech It has to interface with Exosphere, part of Atmosphere. Reverse engineering code that is open source is stupid, and I don't feel comfortable trying to circumvent licensing laws. I don't want to do anything shady, like saying "Oh it just happens to download this extra module that's weird" or saying "Oh I reverse engineered Exosphere, guess I don't need to license this as GPL."
@Cesura Atmosphere can already reboot to a payload through rebooting normally using its bpc.mitm. If you have it enabled (it is by default), and you run the reboot
command in nxsh, it will reboot to the reboot payload in the atmosphere directory. I think the main use case of adding it to nxsh would be rebooting to any arbitrary payload, perhaps for having multiple CFWs on your card. I do think it's an interesting idea by itself, but I don't really see it as a solution to this problem, especially if it's independent from nxsh.
@friedkeenan I second this, I am not comfortable circumventing licensing laws. Although, I do not think @fennectech was trying to suggest that we do anything ethically questionable.
Can we not implement this by making the payload a symlink to the current payload binary? Thus, "reboot /payload2.bin" would set the symbolic link to point to /payload2.bin and initiate the normal reboot process.
Horizon doesn't support symlinks, so we'd need to either create a format just for nxsh, or we'd have to reimplement fs, neither of which sounds appealing (though the former is definitely much, much easier). Also I'm not sure I understand you. Are you saying that we have this external sysmodule for rebooting, licensed as GPL, but we put special code in nxsh to make it do stuff? Because that seems a little shady to me. Maybe it would be okay if interfacing with services in general were added to nxsh, but that seems like a monumental task, considering there's not really a general way to interface with a service.
Reimplementing FS would, however, have some neat benefits like exFAT support that actually works but that's a pipe dream.
I would've added this in the latest commit, but I would largely be using code from Atmosphere, which has a GPL license, which I think means we would have to switch ours to GPL, which I'm fine with, but it requires every contributor's (@Cesura) consent, which is why I didn't include it in the last commit.
Aside from the license issues, we would also have to detect the user's CFW, since rebooting to a payload only works on Atmosphere. I would prefer everything to be CFW agnostic, but rebooting to a payload is pretty useful.