Zbigniew Jędrzejewski-Szmek wrote: > How so? It was rejected with the request to enhance the motivation section > and to answer some specific questions about upgrades. This has been done. > Why do you say an update to a proposal that answers the issues that were > raised should not be resubmitted? Sorry, I was under the (apparently mistaken) impression that the change was rejected for its whole idea, which IMHO it should have been. > 1. The strong copyleft licenses allow an offer for the source code > OR the source code, and most people pick the first. That statement does not match my experience at all. The GNU GPL "written offer" clause is in practice very hard to comply with. (Especially for GPLv2-only projects. The GPLv3 has made it slightly more practical, admittedly.) In my experience, most projects actually choose to just upload the source code next to the binaries. And those that do pick the "written offer" solution do not actually do so in a fully compliant way. I have actually encountered more projects just redistributing the binaries with no pointer to the source code at all (which is a violation of the GPL and even the LGPL) than valid "written offers". (And you may also be in for a surprise if you attempt to take advantage of such a "written offer", because the source code may have been lost or never properly saved to begin with, or the responsible entity may not even exist anymore.) > 2. A lot of software is under permissive licenses, which don't require > this. In practice, it is going to be almost impossible to build a container with only software under such licenses. Even glibc is LGPL. As are a lot of other "plumbing layer" libraries that cannot simply be replaced by something else (the way, e.g., musl could be used instead of glibc). (E.g., anything outputting sound is usually linked to LGPL PulseAudio libraries.) > 3. And actually if the software is not *distributed*, i.e. stays within > one organization, all of this doesn't even apply. Then that organization should have to deal with how to track what software is installed on their machines. It is not our business. > 4. And even when distributing software, you can have a proposal or a link > to a download at the place where the software is distributed, nothing > obliges *the user* to always download and install both. But for that, the user needs to actually know what binaries they are downloading to begin with. So just redistributing binaries from a random distribution is a bad plan. And I have also not seen any project actually fetching the SRPMs (or the dpkg equivalent, i.e., .orig.tar.gz + -debian.patch.gz) and offering those for download in practice. > 5. This proposal is not about licensing, but if it is adopted, it'll only > make figuring out potential licensing violations easier (in some cases, > primarily when distributing without recompilation). True, but is that worth bloating the entire distribution for all users, even those who are not violating the licenses? > "bloat" == couple hundred of bytes. Note that this is only for *compiled* > objects, which have a few kilobytes of ELF header even in the simplest > cases. Please see the original proposal for a discussion of various > circumstances where this additional information is useful. "couple hundred of bytes" for *every single* ELF binary (executable or library) in the distribution. A typical installation has thousands of them. The product (say as an estimate, 1 kB / file * 10 000 files = 10 MB) is an order of magnitude comparable to the one of the RPM database in containers that you are complaining about. >> And those Dockerfiles are broken, any bug reports from them (i.e., where >> the package information is missing in the report) should be closed as >> INSUFFICIENT_DATA immediately. > > The fact that you don't like what somebody else is doing doesn't make it > "broken" or a "blatant violation of ... license". As discussed in the > other part of my reply, you're just making very general far-fetched > statements that may be true in some cases, but are trivially shown to be > groundless in many other cases. Deleting the RPM database turns a working Fedora image into a corrupt one that can be neither updated nor queried for metadata, how can this not be broken? >> As explained above, those upstreams are illegally redistributing the >> library binaries. > > No. Not (in general) "illegally", not "redistributing", and not "the > library binaries". Have you even read your link: https://hpc.guix.info/blog/2021/09/whats-in-a-package/ ? They are complaining about redistributed library binaries in the PIP package. You can also build the module yourself from bundled library source code, but then you are in the self-built binary case, i.e., whether the result has annotations is entirely unrelated to whether our RPM binaries have them. Even if the PIP package switches to doing that, it will be their decision whether their build output has annotations, entirely independently of whether we enable them for our binaries or not. So "redistributing the library binaries" is exactly the issue. And I have strong doubts that their redistribution method complies to the licenses of everything they are redistributing that way, though it would have to be checked on a case-by-case basis. (E.g., libgomp is apparently "GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD", so that is several licenses to analyze. In particular, I know the GCC Runtime Exception allows statically linking the libraries without shipping their source code, but they are shipping shared libraries, so one needs to check what exactly the exact version of the GCC Runtime Exception relevant in this case allows.) >> Incidentally, this is also why we need to package software properly in >> Fedora instead of pointing users to distro-within-the-distro tools such >> as pip that reinvent the packaging wheel and have no good way to deliver >> compiled C/C++ dependencies. > > This is a completely unrelated subject. Let's not go there. This is very much related, because your change proposal makes it so by bringing up those use cases. > It seems to me that you dislike how some people are distributing > software, and on this dislike you want to build technical and legal > discussion. Sorry, but your analysis of what licensing implies is just > baseless, and I don't think we're going to force people to stop using > docker and pip and curl by not adding metadata to rpms. Sorry, but I do not see what is "baseless" about the licensing issue (see also the further details I added above). And the idea is not to "force people to stop using" stuff, but to not spend time making it easier to do inherently bad things such as redistributing binaries ripped from a package or deleting the RPM database, at the expense of added bloat for everyone. See also the "Fedora minimum hardware requirements" thread where the evergrowing bloat that keeps getting accumulated with every release is being discussed. Changes such as this one are one of the problems. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
