Bart Martens <ba...@debian.org> writes: > That file may be available online for this particular software. The > debate is about whether such configure.ac file must be included in the > distributed package for making the package dfsg. And more in general, > about where to draw the line on how easily editable (think: time well > spent) the included source code must be for making the package dfsg. In > my opinion there is no sharp line, and ftpmaster is well positioned for > making fair choices in a +/- uniform way for all packages. And there is > always be room for questioning those choices and allowing the meaning of > dfsg evolve over time. Back to configure.ac, I'd support a choice of > making a missing configure.ac an 'important' bug, and not enough for > rejecting the package as non-dfsg.
The general rule of thumb that I've followed in similar situations in the past (PDF files where the original source has been completely lost, for example) is that the underlying purpose of the DFSG source provision and of free software in general is to ensure that the recipient of the software is not at a disadvantage. In other words, the distributor isn't allowed to hold back pieces that make it harder for the recipient to modify the software (within the general definition of "source," of course). Therefore, it matters what the distributor has. If they have the true source used to generate the file but are keeping it secret, then to me that's a violation of the DFSG and we shouldn't participate (even if their actions aren't technically a violation of the license since if they own the copyright they don't need a license). This is creating that disadvantage for the recipient that free software is designed to prevent. But if the original source has been lost, then everyone is on an equal footing, and I don't think there's a DFSG violation. We may not have the true source in the intended sense, but *no one* has the source, and therefore everyone is on an equal footing and has equal ability to modify the software. There is a different wrinkle in this specific case: we may have the source but not the software that was used to generate the file from the source. In this case, it sounds like an old version of Autoconf was used, and we don't package that version of Autoconf any more, so while the source is present in one sense, one can't regenerate the file. I'm not sure the DFSG is the most useful framework for analyzing that situation, since to me it feels more practical than freedom-based. Everyone is still in basically the same situation: the source is available to everyone, but some work may be required to go hunt up the old tool and regenerate the file. (This assumes a case like Autoconf where the old releases of the tool are readily available and not kept secret, but may be hard to get working.) The real problem in this case is less about the DFSG and more about the practical problems of maintaining Debian as a software distribution: if we can't regenerate configure using software in Debian, there are a lot of porting tasks and some bug-fixing tasks that we can't do, and that's a problem for us. But I'm dubious that it's a *software freedom* problem; it's more of a *software maintenance* problem, and thus the bug severity should be based on how much of a problem that is in practice. (I think this is mostly a long-winded way of saying the same thing Marco said.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
