On Wed, Oct 27, 2021 at 02:00:36PM +0200, Kevin Kofler via devel wrote: > 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. Even if it was, I hope anyone feels that they can adjust an idea and resubmit it for discussion. This is an open-source project and nothing is ever final. > > 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. You just proved my point. If you have the source available for download next to the binaries, the license is satisfied. [snip] > > 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. Actually, this proposal is already useful in Fedora itself. But even ignoring that, the goal of Fedora (and most distributions) is to allow people to build things out of that distribution, mixing packaged and locally-packaged and unpackaged stuff. I don't understand why you seem to imply that making that easier and more reliable would be a bad thing. > > 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. Look, it's not hard. If I put up foo.c on a web page, and next to it the matching a.out and GPLv2.txt, even if that a.out is stripped and has no identifying information, I'm satisfying the terms of the GPL, version 2.0, §3a. > > 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? It's a tradeoff, see below. > > "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. This all scales proportionally… Those small images have a smaller number of programs, obviously. A Fedora installation with 10k binaries would be at least a few gigabytes. The estimated overhead (200 bytes, if you want to round that to the nearest kb, that would be 0 kB, not 1 kB), is 2 MB, i.e. within noise, much less than e.g. the license files. > >> 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? It depends on the use case. I assume you are using an initrd built with dracut. It is exactly like this. Do you consider it broken? [snip more discussion about licensing] Zbyszek _______________________________________________ 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
