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.

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 (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 2022-12-09 at 14:58, 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.

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


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmOTl7gACgkQBKk1jTQo MmsBGQ//Wa+nz8pHerNsLg48sBzuii9DBqoWCq/05rqaNz3GnC+I8IFWtj6kqZfI q8owYGjmTDosY+e9Bejv4Kh6p8948xSRqjbfjKdUMrv/xWU3OPolB4KRh639EP1h PsGhsL5iwZ6rABM2wy3xS/gUjbkfYsbUYAc9ARX7I0GGMk6X1c8mBoQrzTMa+KDP dXXw/BE7HQH7CFMsjnzf1lGLIQ2Al8/UbVXokDsEYKjp3OG+e1771CglinCCqtjx H9dfWbGWF/Xku5INFmn0cbzN1KrvWab7VKO1Zy5zPdroHqTORYThhljAUXBJlLuQ IQpiU4kdB+JndvnkHUGDKRWDoJ20IAszwjOnQElSwaVkBy7k8eoDnHGI5+MCnH/a dFHd+TzDBWG1W7ylvw/IBv2/tXTh8XQQdQLxWaaSwBjgeoOqufpzSZ/S0UFaJIxi 3LjovcbIk8xd8yf1fDwSYGZ7MYk1eoGl3kkYPpjhKN78twOUqfSXuL9vxxJJFB7A qKs8MXBM2in9MyfDVgExRcyxfvAFVUpNe894y40Fru755LfUnNQ/PZjtmhhmfZM+ AnkELAkl430Y2EtKafpWjEQufNqeOqMzLbZRSgEkuTjbn5vOv5c0STAqeIyX2gWw qhDYvH+ebHtTAsRsUiD/Y3Ln+dSi

Andreas Tille <andreas@an3as.eu> writes:

For the general case I somehow understand the consensus here on the list
that a missing configure.ac can be considered a bug but the severity
serious is not really rectified. If I understood this correctly I would reset the severity to important at the beginning of next week.

I think that seems fine baesd on my reading of the thread, although since
we have now found the configure.ac, I would also stuff that in the Debian package somewhere so that all the pieces are available to someone who has
the Debian source package.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 12/11/22 16:47, Andreas Tille wrote:

May be I interpreted
posts in this thread wrongly but I read it like serious is a to high severity. Moreover what does this mean for other packages where
configure.ac is missing?

It depends on the licence, to some extent.

The GPL's definition of "source code" is:

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

So for GPL'd software, shipping a configure script without its
configure.ac is a case of missing source code.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-12-11 at 16:47 +0100, Andreas Tille wrote:

Could you give some arguents for your feeling.

See the posts I made in this and earlier threads:

https://lists.debian.org/msgid-search/4363a2435e61bf351c7d3605136c3652118eae2f.camel@debian.org
https://lists.debian.org/msgid-search/50184a59271c953a3f9a3c99bb193dc05e61f2aa.camel@debian.org

what does this mean for other packages where configure.ac is missing?

That should be decided on a case-by-case basis, since not every
configure is generated from a configure.ac and not every instance of configure.ac being missing is due to it being withheld from view,
some instances could be due to it genuinely no longer existing,
although that is very unlikely. In the case where it genuinely doesn't
exist, I would still regard that as an important bug, to fix upstream.

I think the fact whether a fix is simple or not does not matter for the severity of a bug.  Unfortunately the solution is not as simple as
described (as I wrote in response to the said mail).

Agreed in general, in this case it did turn out to be simple though.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmOWhZAACgkQMRa6Xp/6 aaPy2hAArqkdL59jvmTelPr3Zk73Ngci5QRYfbCPRQjJlUElwHu8/7tYFEu9wozG BdfAZIh+cdEW9tLLaWxwDv8FmuJlt6wXbQwWfLbokdxQP+3KaInOVXX8fTwNv0NA LND7PDSxxs56Mvws+jsg4m701D7UTq3fEhEaBcg5Zr3NiwRrNAROHuRzpw6cuJQe IwfbHPpGoki/+ITtW7vwaOR/4WyfUfmUYZy1VL6fCC5efqAZmZByPfPQtJ69TC2G PF4d7hAQxVBdDAsmyCwhao4fuoCcl2FfpxvK1dlEWEY4T1C3khj9DHI0Jvt68dVh 4liyuQOQCXHPFAHur5AdHiBPmFDqjxMz1axPt+s0bPvMTPLPbxy1BQzFhiDSOoEi 8N7QhRcFbDiq/pn3wlcWrRAE3/wxqb3eRL6prW88b7qux+bF+OqSTR12X+2mvZ4F leo7lP1kliEXJOzDvnnhmTXj4L3KgUPGM/EnpL2aPAwe59G9JYYqr2yI/FQ041oJ nPZlJvZYZHFZJsCNL+gbhwFH7iAie1+t2L8qhHw3N4bEj1w4u8F6fnl5kX30ZsFi jiRHxV4iIufmnIJeZeVSyLDWr9PTXM8G4UItogSORzCI9J/iC7Nf7kbXxByvrGYe kfHiVl5LjewIx1tt7kfBP7KBTnaEbh+PzpRVlQnTPlTF/8JL2iU=
=uhxh
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)