<quote who="Helmut Grohne" date="Sun, Nov 26, 2017 at 08:28:38AM +0100"> > 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.
Drawing lines on these sort of issues involves judgment calls—often difficult ones. We're not going to avoid that. > > 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. We agree on this. It should also be clear that we allow some amount of annoyance, difficulty, and practicality in modifying software in that we allow software in allow advertising clauses, esoteric programming languages, single character variable names, no comments, etc. We also, generally speaking, have allowed software that involves hand-modified versions of auto-generated build scripts and other code. > > 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. That's still just a bug about an autoconf-generated configure script. I was asking a much bigger question. Much of what we would both agree is the source code of many /programs/ (like the .c files or whatever) is at least partially generated by programs. How often to programmers create keyboard macros to autogenerate code? How often do they include them? > 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. I agree that this is the right approach. But that bug is still to have one severity or another and I'm still not convinced that this is a serious DFSG issue. > > 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. The GPL defines source as preferred form for modification. Upstreams may prefer to just use/update their minified Javascript with a new one but there is no way athat the minified version is the version nearly anybody would turn to if they wanted to make a modification. It's nearly impossible to do so! Again, it's a judgment call. But if it came to a copyright case someone would have to make the argument in front of a judge that the minified version was the preferred form for modification. It would not be hard to find expert witnesses to convince any reasonable judge otherwise. > > 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. I'm sure that neither one of us thinks that this is an actually solution. Either there's a serious bug, and it should be marked as much, or there's not. > Do you think DFGS #2 would be a better justification for the > severity? Yes. I think it's much more plausible but I still don't think it applies for reasons I've described here and that you've not talked me out of. Later, Mako -- Benjamin Mako Hill http://mako.cc/academic/ Creativity can be a social contribution, but only in so far as society is free to use the results. --GNU Manifesto
