Re: Is an autogenerated configure shell script non-editable source
On Fri, Dec 09, 2022 at 11:58:56AM -0800, Russ Allbery wrote:
> Bart Martens <bartm@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.
Interesting angle. It illustrates indeed what Free Software is meant for.
Still, dfsgness should be evaluated on what's in the package, not on someone
holding back some (easier modifiable) source code or their motive for that.
>
> 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.)
Well, if Debian says that the lack of the old Autoconf makes a software
non-dfsg, then Debian can still choose to keep that software dfsg by still
shipping that old Autoconf along with that software. My point is that it
matters what is provided together, not what is in one technical package.
>
> 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 that the easiness/difficulty of modifying some form of source code is
about dfsgness on the one end and about maintainability on the other, without a
sharp line between them. Just to name two extremes: One could argue that any
binary is editable after using a disassembler. Someone else might argue that
nowadays C source code should be regeneratable from some newer language.
>
> (I think this is mostly a long-winded way of saying the same thing Marco
> said.)
>
> --
> Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
>
Reply to: