On 2022-12-09 at 14:58, Russ Allbery wrote: > 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.)
(Sorry for not snipping; I couldn't find any part that seemed more worth omitting than any other.) I tend to agree, on your parenthetical last statement. I was not persuaded by Marco's own post, but your more long-winded version has convinced me, I think. I would just like to also note two potentially-relevant questions, in making the analysis - both to do with the possibility of making changes to the file, and both of which are likely to have the same answer: * If upstream were going to change the configure process, what file would they edit? * If you wanted to make changes to the configure process and submit them to upstream for possible inclusion, which file would upstream want the patch with the changes to be against? By the "preferred form for modification" definition, whichever file that is is likely to be the one that is considered the source. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
