* On 9/27/23 16:41, John Thorvald Wodder II wrote: > On 2023 Sep 26, at 20:36, Paul Wise <p...@debian.org> wrote: >> Your analysis is correct, some extra context for this problem: >> >> The problem you have identified applies to other statically linked >> languages too, so I have updated the wiki page to link to it. >> >> https://wiki.debian.org/StaticLinking > > So was this problem previously known but under-acknowledged, or was it simply > not brought up before now? I find it surprising that Debian would allow so > many license violations to get this far.
The reason is likely a lot more mundane: it's terribly difficult to get license information right (and to comply with licensing terms verbatim) in such cases. When just linking in a shared fashion, the work is split up into small, manageable packages, and every package that depends on another package needs not care about the other dependencies (as long as one knows that they are compatible). Static linking is a beast. Rather, I'd wager that it's important for maintainers to provide the software in question at all than to delve into such issues for extended periods of time. The severity of the issue is also very debatable. If it were the case that non-free parts are mixed with free parts and statically linked, or incompatible licenses mixed through static linking, than that would be a much graver concern. In this case, we're "just" talking about missing notices for dependencies that are pulled in, which might not be nice, but also, realistically, nobody would really care about or try to enforce it (unless somebody has malicious intent, which indeed did happen in the past). Richard Laager wrote a beautiful statement on this list a few months ago, albeit regarding a different matter, which I want to quote: > Furthermore, courts are not robots blindly executing code. Seriously, > can you imagine standing in court trying to argue to a judge that this > distinction matters and somehow causes you damage‽ This also extends to Sam Hartman: > Sometimes the best approach to licensing is to take a defensible > position and not to try and find problems. > Is fixing the tooling to handle this > considered a priority? If the author of an uncredited dependency were to > complain, would Debian be more likely to focus on fixing the tooling posthaste > or to just pull whatever packages use the dependency in question? If someone were to complain and the complain were to be rightful, the easiest way to handle the situation would be to remove the affected packages from the archives. Fixing it properly would take more time. Truth be told, in my opinion, this whole thing is a bit blown out of proportion. The real-world implications are minimal, and while it does make sense to rectify the blunders that probably exist, it feels more like a trade-off between a very complicated situation that binds maintainer's time tightly (particularly because no automated solution exists and manual intervention for packages with hundreds of dependencies that are then statically linked is a time drain nightmare) for minimal benefits of having it gotten it done absolutely waterproof. Which is not to say that slips shouldn't be eventually fixed - it does make sense to actually point them out and to start working on them. Mihai
OpenPGP_signature
Description: OpenPGP digital signature
