>>>>> "Salvo" == Salvo Tomaselli <tipos...@tiscali.it> writes:

    >> In this sense, the history is like comments.  You wouldn't think
    >> it was still the source code if all the comments had been
    >> stripped out.

    Salvo> But if by mistake one upstream adds a proprietary file in git
    Salvo> and then removes it… we can't distribute the whole .git
    Salvo> directory as is.


Can we dig into this a little?
I'd like to compare along two directions:
First, what do you mean by proprietary.
Let's assume you mean that upstream includes a file that they don't have
rights to distribute at all.
For example, someone accidentally checks in confidential passwords to an
internal CI/CD environment, or checks in something that is a trade
secret.

Second, let's compare this to shipping a tar ball.

This same thing can happen with a tar file.
We could discover that we are distributing some file that we do not have
rights to distribute in a stable release--burned onto DVDs and in our
signed images.

We could get a takedown notice for such a stable release years later.
And depending on the circumstances, we might well have to comply.  If we
actually found  ourselves distributing someone's trade secret, we
probably would have to comply.
It would be a huge mess, but legally we would have to find a way to do
it.

But in a lot of cases, we probably could get away with removing it from
future releases, and probably would not even have to stop shipping the
old release.

If for example we found ourselves distributing something that we legally
could distribute, but that did not end up following the DFSG, that's the
approach we would (and have regularly) taken.

It's likely we would have similar options for a git repository.
In the most extreme cases, we would need to rewrite history.
There are tools to do this relatively painlessly.
It absolutely would break the signatures on tags. We could resign the
tags as part of the processes.
In some cases, depending on the legal reason we could not redistribute,
being part of a signed tag might give us legal leverage for not removing
the information.

In other cases, we probably could get away with keeping the information
in tags, but rewriting current branches, and removing the information
from future releases.


we face all these challenges with dgit and salsa today.
We also face these challenges with tar files today and
archive.debian.org and snapshot.debian.org.

Attachment: signature.asc
Description: PGP signature

Reply via email to