Re: [GNU-linux-libre] Developing free non-gnu operating systems

[Denis 'GNUtoo' Carikli]

On Wed, 6 Oct 2021 17:12:38 +0300
Jean Louis <bugs@gnu.support> wrote:
> I have not unpacked it to see and verify. That you say something is
> possible, I know this, but I wish to see real world practical example
> of compliance to GPLv2/v3.

This is a real world example, and the information that you are looking
for is in the two READMEs that are in the same directory, especially
README.source that has the following:
> == How was this source tarball was made ==
> The tarball was made with Guix[1], on an x86_64 computer with the
> following commands:
>     tar cf sz1lkq3ryr5iv6amy6f3d2pziks27g28-sources.tar \
>         `guix time-machine \
>             --branch=master \
>             --commit=f9bd4621dd92a9415276706b476b9bd2973411fa -- \
>             build \
>                 --sources=transitive \
>                 git-repo le-certs nss-certs git python-certifi`
>     xz -9e --verbose sz1lkq3ryr5iv6amy6f3d2pziks27g28-sources.tar
Since there are only 4 files in that directory and that one is called
README.source.txt, it's really hard to miss it, so I assume your concern
is probably that you want the READMEs to be included in the tarballs.

In that case, if you want to redistribute the *-sources.tar.xz (I
abbreviated the name for convenience), you can simply do it with:
> tar cf replicant_repo_28-01-2021_sources.tar \
>  sz1lkq3ryr5iv6amy6f3d2pziks27g28-sources.tar.xz \
>  README.sources.txt

And redistribute the replicant_repo_28-01-2021_sources.tar tarball.

And inside that README.source.txt not only it explains that
*-sources.tar.xz is the complete and corresponding source code, but it
also says exactly which commands were used to make that source tarball.

So you can even reuse that information to get also do source code
releases yourself if you ever want to distribute binaries made with
Guix (which is what that information was meant for), or you could also
adapt it to get the source code of any package that can be installed
through Guix (which is what we are talking about here).

And the README.source.txt includes even information about
reproducibility and so on if you want to check the binary releases, and
the two READMEs are signed and contains instructions to verify the
two tarballs too, so it's hard to do it better.

> Distributing binaries does not involve a method, method of obtaining
> binaries can be this or that. You could use Guix package manager, or
> apt-get but also wget or WWW browser, right?
I don't see the issue here. If you download a package through a free
software command line tool, you can also download the source with
that same tool. 

If you want to know if a web browser can get binaries and the source
code you also need to try, and to look in that server for corresponding
source code.

> From GPLv3:
> ,----
> | If the place to copy the object code is a network server, the
> | Corresponding Source may be on a different server (operated by you
> or | a third party) that supports equivalent copying facilities,
> provided | you maintain clear directions next to the object code
> saying where to | find the Corresponding Source.
> `----
> 
> Does your binary package clearly designates where to obtain source?
> https://ftp.osuosl.org/pub/replicant/build-tools/repo/28-01-2021/sz1lkq3ryr5iv6amy6f3d2pziks27g28-tarball-pack.tar.xz
This is in the README.sources.txt that is in the same directory.

It's really hard to make it more clear, so here I really don't get your
point as this counts as maintaining "clear directions next to the
object code saying where to find the Corresponding Source".

And everything is in the same directory on the same server and there
are only 4 files there.

So I probably misunderstood something here, or maybe you didn't read
the README.sources.txt. 

In the case you didn't read it, many people would find a situation like
that offensive as you were pointed to a link which also contains
documentation, and that would assume things without even going to the
link or reading the READMEs, or even looking in the tarballs.

If it was the cases, the next times it would be a good idea to look at
the pointers people give you, and possibly also do a bit of research
yourself. 

Also it's a good idea to assume that on mailing lists, the time of at
least some of the people there is precious, and so when asking questions
it's often a good idea to try to do a bit of research first, especially
if it's easy to find where to look for (like if you have questions about
Guix, the Guix manual is a good starting point for instance).

> Imagine now, I take your binary package and I put it on my server for
> distribution without any modifications whatsover, is the end receiver
> of that package who get it from my server clearly informed through
> that binary package which has probably inside what is called "object
> code" where the source is?
It's up to the people who redistribute it to also include the READMEs.

We redistribute it, we include the READMEs. And there is also all the
information you need to make a release yourself, so you could add the
README in the tarball or whatever method you prefer if you want to do a
release.

The idea of having the READMEs outside the tarball is for security
reasons and convenience: users can simply read the README, and
everything that is inside that README is signed, so all the instructions
are also signed, and in addition they can verify that the release is the
right one and not an older one signed by the exact same key since the
date of the release is also in the README.

And having the README inside the tarball would prevent all that,
especially because the tarball sha512sums are in the README, so all the
release method would need to be changed, but you're also free to do
that if you wish and make your releases in this way. You might want to
adapt it for software you care about though as repo is really specific
to Android.

> In that case I am responsible, not you, to provide sources. I can
> provide it from third party server which is your original, but I have
> to be sure I am complying to GPLv3 (and we only hypothetically say
> that your package is GPLv3 which may not be).
People working on several FSDG compliant distributions already have to
spend a crazy amount of time just to make the basics work, so the
easiest way to improve things is to actually send well made patches to
fix cases where you think it puts people at legal risk if the software
is redistributed, in ways that don't conflict with choices made by the
various distributions out there.

If the patches are refused, on the basis that it's not something that
the distribution wants, you then know how much you could trust that
distribution from your standards. You could also try to fork a
distribution or make one from scratch that address the concerns you
want to be addressed. 

And in that case it might be interesting as it could make it even
easier for some companies to reuse free software as their legal fears
would be lower. And you could also try to get companies to fund
efforts like that if needed.

What is important to understand here is that legal risks are not black
and white, everyone is at risk in one way or another as the legal
systems around the world are way too complex, so distributions (and
people) do make tradeoffs on that all the time.

Just look at software patents for instance. Even if in the USA they
got much weaker than they were before, they still exist in one form or
another in many countries. And before that, to completely avoid them in
the USA, you needed to use software was 20 years old.

And there are also many other laws that applies to software and
computing, and not everybody is a lawyer and not every lawyer knows all
jurisdictions (some of which are even conflicting).

And the issue is that in many cases, lawyers can't even give you
guarantees that what you do is legal. For that they would need at least
one lawsuit (and potentially multiple lawsuits as courts don't always
take the same decisions) to be really sure. So we resort to limiting the
risks the best we can with the knowledge and the time we have.

And in many countries some laws aren't even written in the laws due to
some broken idea that the people who want to change how a country work
are enemy of the state, or due to various interests. And you can see it
in practice all around the world with political opponents that get
detained on bogus charges for instance.

And if you really want to estimate the risk properly, a better way to do
it than look at all these scary details would be to look at the big
picture instead, because from there it doesn't look that bad.

You could for instance look at the amount of people that work on free
software, reuse distributions, redistribute code and so on and look at
how much documented legal cases there are which cover that. I bet that
the number would be extremely small. 

And for potentially undocumented legal threat, we also see with patents
that, even if they are hard to estimate, we at least know about them
because some people or companies do talk, and the threats are also made
by companies and companies do leave traces. 

For instance companies have to be registered, and in many countries
(not all) it's possible to get information about companies relatively
easily, though it's not always free (sometimes there are small fees).

> > - The way to get full source code is less well known with Guix. I
> > had to try and to ask around, but now at least I know how to do it
> > and I can publicize it. I didn't check if that was also in the
> > manual.  
> 
> Well said, thanks for acknowledgment. Though that is least issue. Guix
> package manager can download the source. 
> 
> But the GPLv3 section I have cited is not covered by providing such
> option.
> 
> You see, packages are available over HTTP. But by Guix they are made
> almost inaccessible from Internet if user does not use Guix package
> manager. However, packages can be obtained from Internet without Guix
> package manager. Then where is the compliance in that case?
Do you have precise URLs? Did you look everywhere on the server if that
source code was really missing? 

My guess is that sources also comes from the Guix infrastructure. 

The same applies to Trisquel, PureOS, and probably or any distribution
based on Debian too which have repositories in which source code and
binaries are to be found.

> > So both combined gives some pretty good assurance that in the future
> > you will still be able to build old software because it will also
> > have all the source code of the dependencies and if it built at a
> > given git revision, it's likely to also build in the future at the
> > same git revision.  
> 
> That is good point, maybe it solves it, but let us see example. Please
> try to provide more particular example.
The Replicant release of repo has everything in the READMEs that show
it in practice.

As for your claim that it is or may not be possible to find the
source of a package that is on a Guix repository on the Internet, *you*
would need to do some research to understand if it's actually the case.

> Let us say for example, I have used Guix package manager and I got
> binary for version 1.2 -- now I put that binary on special place on my
> hard disk, and I forgot about it. I upgrade my system and continue
> using version 2.3, somewhere in future version 1.2 may be required on
> less powerful computer -- and we look there in the binary, and we see
> there is no information "next to object code" where is the source.
That's the problem of the users. Users can download binaries from
any distributions and forget which version it was.

What users do on their computers is not the responsibility of
distributions. Users might also compile software and copy the binary
somewhere.

Sometimes binaries do encode version numbers and so on, and sometimes
they don't, and in both cases there are various tradeoffs being made.

In the case of the repo that I released on behalf of Replicant, the
tarball has a name, and the checksums can be verified, and the package
also has a manifest file inside that contains technical information
that can be used to recreate the source code with Guix. And since it
was used for the source release, it works.

> Manual does not matter. When somebody obtains binary from let us say
> HTTP server, no need for Guix manual, he got binary, where is the
> source "next to object code"?
I don't know for all the repositories out there, you'd have to check.
For Trisquel it seems that the source is in the same directory:
http://archive.trisquel.info/trisquel/pool/main/0/0xffff/

For Guix I don't know how that works so you'd have to check for
yourself and possibly come back with precise facts if you manage to
find how it works.

Denis.

pgp_SEWt7mjCk.pgp
Description: OpenPGP digital signature