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