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,321

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.