Adam Borowski <[email protected]> writes: > At this moment, not yet. Obviously, old projects didn't even _have_ a > VCS, and I'm not proposing imposing a VCS workflow on the upstream. I'd > like to consider, at some point in the future, hidden private VCSes > where the upstream occassionally releases a tarball of to be non-free, > just like the same PNG image can be free if there's no XCF file but is > not if the upstream holds a private XCF version they routinely modify -- > a "preferred form for modification" is not required to be good, merely > no worse than what upstream themselves use.
I don't understand why you chose the VCS specifically and alone to elevate to the level of required source. If I had to pick what additional information I'd want over and above the current source code, I'd be way more interested in the bug tracking system than the VCS. I use that an order of magnitude more often than I use Git history when developing software. There are a few other really obvious reductio ad absurdum arguments here, too. For example, most of the critical documentation for the Linux kernel that's practically required in order to understand it well enough to meaningfully maintain it is in LWN or the linux-kernel mailing list archives. Guess we need to start including those in the source package now too.... The line between source and supporting useful stuff that's not source is inherently arbitrary. For better or worse, we have thirty years of history behind drawing the line in one specific place. That doesn't mean there are no good reasons to change that line; it does mean that any other place we draw the line is still going to be arbitrary. Redrawing the line is a *huge* amount of disruption and energy drain because we have to relitigate endless mostly-settled discussions from the past thirty years around what source code means. The payoff needs to be correspondingly large to be worth the effort, and I'm just not seeing it. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
