Arch Linux

nhermosilla14

Member

Registered: 2014-04-02

Posts: 5

Cortex XDR (traps), legality and good practices

Hi! Due to some corporate policies, I'm required to setup some software in order to be able to use my PC at work. We are allowed to use any Linux distro of our choice, provided we can install such software. That's why I have been trying to install Cortex XDR in Arch, with little to no luck until yesterday, when I realized it wasn't as difficult as I thought, it just had some undocumented flags and a couple of minor issues in the installer.

My questions are as follow:
- If I upload a PKGBUILD to AUR containing only such minor fixes, should I be worried about any legal implication? I'm not changing the software in any way, I'm just slightly changing the install script. And even though I would distribute the patches, the actual installer should be provided by the user.

- The software is distributed as deb, rpm and a makeself shell script. That looks like three different formats, but in reality both packages actually embed the same shell script inside and just run it. The installation has its own uninstaller too, which is executed while removing the package. Is a package built like this allowed in the AUR?

Last edited by nhermosilla14 (2024-05-05 15:06:50)

mpan

Member

Registered: 2012-08-01

Posts: 1,394

Website

Re: Cortex XDR (traps), legality and good practices

Hello. Legal questions may only be reasonably answered by your local lawyers. In particular in the murky waters of IP laws.

PKGBUILD itself doesn’t distribute anything. It’s just information indicating how to build an Arch package.

If you want to include upstream’s install script directly in the PKGBUILD (or as an attached source), keep in mind the install script is intellectual property of the upstream. You must consult the license to know, what you can do with it. Likely it’s illegal for you to even modify it, much less publish the modified version.⁽¹⁾ But that’s something the license has to answer.

Pacman doesn’t support installers or uninstallers. Installation of packages is almost exclusively declarative and you can’t run anything during installation or removal of a package. This would break the core premise of the package management. Packages may contain scripts and hooks, but these are meant to conduct only minimal housekeeping when no other method is available. Anything beyond that is very likely to break promises pacman gives.

So it’s not really a question of whether it’s allowed in AUR, but whether it makes sense to even use system’s package management. If one gives away control over the system to a different tool, why involve pacman in the first place?
____
⁽¹⁾ Based on typical proprietary software attitudes.

Last edited by mpan (2024-05-05 16:39:22)

---

Sometimes I seem a bit harsh — don’t get offended too easily!

nhermosilla14

Member

Registered: 2014-04-02

Posts: 5

Re: Cortex XDR (traps), legality and good practices

PKGBUILD itself doesn’t distribute anything. It’s just information indicating how to build an Arch package.

If you want to include upstream’s install script directly in the PKGBUILD (or as an attached source), keep in mind the install script is intellectual property of the upstream. You must consult the license to know, what you can do with it. Likely it’s illegal for you to even modify it, much less publish the modified version.⁽¹⁾ But that’s something the license has to answer.

I would distribute just the PKGBUILD and some patches (which don't really change any logic, they just fix some quirks that break the installation process). I will take a look at the license, it seems like the right thing to do.

So it’s not really a question of whether it’s allowed in AUR, but whether it makes sense to even use system’s package management. If one gives away control over the system to a different tool, why involve pacman in the first place?

To be honest it's just a convenience. I don't want to actually change the behavior of the installation script, because doing so would not only be most likely illegal, but would also take a lot of time and effort, which I'm not willing to put into it. I thought it would make it easier to repeat the process if I ever so need, and also allow me to link the removal process to pacman, so that I don't need to remember how to do it eventually. It would also make sure I don't accidentally remove dependencies. But the point you make is quite convincing. Sometimes this kind of "script in disguise" can cause more trouble that simply running the script as such in the first place.

jlaehne

Member

Registered: 2019-09-18

Posts: 2

Re: Cortex XDR (traps), legality and good practices

@nhermosilla14 any update on this? I would be interested in this for the same motivation as you :-)

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,311

Re: Cortex XDR (traps), legality and good practices

The installation has its own uninstaller too, which is executed while removing the package.

If that "uninstaller" simply a script then you can (should) replace it with `pre_remove` and `post_remove` functions in .install, if allowed by upstream's license agreement. Since your intention is to put it on the AUR, then make sure you read the Package guidelines. For example, you NEVER touch $HOME, so if the upstream "uninstaller" deletes or alters a user's $HOME, then you have to skip all that.

mpan

Member

Registered: 2012-08-01

Posts: 1,394

Website

Re: Cortex XDR (traps), legality and good practices

twelveeighty, did you read my reply above? You’re of course free to disagree, but it feels like it has been completely skipped.

To summarize: even if one may abuse post_install and post_remove this way, invoking an installer or uninstaller defeats the purpose of making it a pacman package. Just run the installer, instead. Less work, no empty pretense of using packages, same result.

---

Sometimes I seem a bit harsh — don’t get offended too easily!

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,311

Re: Cortex XDR (traps), legality and good practices

No, I didn't skip your reply.

Context is important. Your assumption is that the upstream "uninstaller" does things that should not be handled by PKGBUILD's pre_remove and post_remove functions. But we do not know what the "uninstaller" actually is. My point is that OP should investigate the upstream's uninstaller. If it's a script that does things that logically should be done in the "pre_remove" and "post_remove" phases, do that, while staying with documented packaging guidelines (which is implied by virtue of this being an Arch forum).