>>>>> "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.
signature.asc
Description: PGP signature