On Sat, Nov 25, 2017 at 12:36:33PM -0800, Benj. Mako Hill wrote: > I agree that a hand-modified binary a binary would not mean that you > don't need to provide source for that binary. I think there's likely > going to be consensus on that in Debian.
That put's you in a difficult spot as to where to draw the line. > I also think this situation is different because I think that a > configure file is more like computer-generated, hand-modified, > /source/ than like a binary. What makes configure source? It doesn't come with indentation or things that make normal source code human-consumable. Even though shell scripting supports scoped variables, autoconf deliberately avoids using them. Thus they are much closer to named, global memory locations. Generated configure scripts are much closer to a disassembly of a binary. > I think one could also argue that there is an difference between the > program binary and a build script which is used to build the package > in question. So do you argue that you can use a pre-built binary during build, but you cannot ship in the binary package? > To say that DFSG#3 is moot (i.e., that you /can not/ make > modifications or derived versions) seems to me to be an > exaggeration. It is more difficult than it might be if the software > and build scripts were created in a different way. But that's not > necessary a DFSG issue. Writing your software in a obscure programming > language makes it harder to modify as well and that is obviously > allowed. DFSG #3 is about enabling users. It doesn't really matter if users refrain from modifying due to licensing or due to being impractical. The end result is, that the purported freedom hasn't transferred into reality. By your very same argument you could ship binaries, because you can simply disassemble them, edit them and reassemble. It might be a bit more difficult, but if the binary was liberally licensed would that prevent you from doing so? > Are you willing to say that source code can never contain code that > was partially generated by another program that is provided? Even if > it is generated by computers and then modified by hand? That's a much > stronger position than I think is supportable by any reading of the > DFSG than I've ever heard and it would eliminate many hundreds or even > thousands of packages from Debian. That's a tough question indeed. Half a year ago, the strict answer would have eliminated nothing less than perl (#762638). Even though the Debian perl maintainers were heavily patching the generated file, they are now generating it at build time. To evade answering it, I try to work from the impact. Whenever fixing a bug is impeded by the inability to regenerate build artifacts, I file a bug, because it clearly demonstrates that the freedom to modify is limited here. > This is distinctly different. The source code in the JS example is > obviously not minified the Javascript if we use the GPL's "preferred > form for modification" heuristic regardless of the change in > question. If upstream wanted to make a change to the Javascript in > their program, they would almost never use the minified version. If > most's upstream wanted to make a change to their configure file, they > would likely modify the pre-built version. Or they would go through > rebuilding it again. Most commonly, Javascript is not copy-left, but something like MIT. Downstream projects commonly embed minified, embedded copies and just update them whenever convenient. So yes, some upstreams (e.g. a past Doxygen) do prefer to deal with minified Javascript. > I agree! But I think that having packages removed from testing (as has > now happened to most) over this interpretation is an overreaction to > what I think constitutes an annoyance. The removal happened due to not responding to the bug. You can defer automatic removals indefinitely by continuously mailing the bug. Do you think DFGS #2 would be a better justification for the severity? The configure script in question was generated with autoconf 2.61. This version of autoconf has been removed from Debian. Now, most is missing the source for regenerating configure. Compare this to bumping gcc versions. When a package fails to build with a more recent gcc, it receives a FTBFS bug as well. You can temporarily avoid them by explicitly selecting a lower version, but when that version gets removed, such a package inevitably becomes RC buggy. The only difference here is that by not rebuilding from source at build time, you get the RC bug with a delay as has happened here. That's why debhelper 10 autoreconfs by default. I believe that the inability to fix bugs is a serious issue. Helmut
