Hello, > I don't know much about the kinks of this, but maybe we could put > licenses for each library in their own folders and symlink to these > folders in the package's license folder, all while keeping the parent > package's license field the same? I feel like there are probably a > lot of issues in this solution, but I haven't thought of any. Sounds like a horrible idea, you would need a package per licence... I dub it "package sprawling". Question: Why can't rust libraries be built from source and installed as shared objects, and then dynamically linked against? I know its not "the rust way" (Which roughly translates to "trying to b break every convention") but it solves every single issue here... I do wonder how many rustls duplicates there are in an oxidised Arch Linux installation, I am aware the licence is truncated and only what is needed is linked into the executable. Anyways if each library is built from source, each licence has its respective package, it integrates right into the build system, no issues, flawless. But I assume "cargo doesn't allow this". I would also like to say this issue exists for Java packages too, I spoke to Artafinde about it and I was told that its not the responsibility of the developer to ensure the program correctly attributes the library authors. So I dropped the topic and only worried about the program and not the dependencies. One way of doing it (which I heard of some codebases doing) is to append all the dependency licences into a single file "DEPENDENCYLICENSES" or "3RDPARTYLICENSES", a lot of android apps do this and then spit out the file in a "licence" screen, I have seen proprietary products do this as well, I believe Discord has a file on their website with all the attribution. Simply install this next to the LICENCE in /usr/share/licenses and all is solved. Although then you would need to stick this in the licenses array, which will again cause sprawling, but this time on your screen. So possible implementation of a "dependency_licenses" array, and then that can be a minimised list or a second page <package url>/dependency-licenses as an example. Although this then needs to be coded into the Arch build system... which isn't ideal either. If rust is going to get looked at for the licence issue, I kindly ask for the same to be done with Java, it would be nice to stop uberjaring and instead package all the dependencies from source (also good for repro no? and keeping dependencies up to date, which would be useful for log4j-like exploits). Java compiles fast too so shouldn't be a huge burden. The issue again discussed with Artafinde is dependency compatibility, lots of Java codebases use old versions of libraries, meaning multiple versions of say slf4j-api would need to be packaged, which is a headache, this would also need tooling to load each classpath of the dependencies... so also not an easy solution. Apologies I went offtopic, TL;DR this issue isn't exclusive to rust, and there doesn't seem to be any "good" solution apart from the standard... compiling all dependencies from source and dynamic linking to them, and installing appropriate licences for each dependency. Questions: - Is this solution worth the manpower? - Has Arch ever been sued or hit with legal action over attribution? - Is it upstreams responsibility to attribute the dependencies? - Does Arch have the manpower to undergo any solution to this problem? Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@xxxxxxxxxxxx
Attachment:
pgp2h6SacTYJJ.pgp
Description: OpenPGP digital signature
