On Nov 27, 2012, at 4:50 PM, "Joseph S. Myers" <jos...@codesourcery.com> wrote: > On Tue, 27 Nov 2012, Mike Stump wrote: > >> A review of the change and approval of the change should be enough to >> catch issues going into the FSF tree. The build should just copy the >> generated file to the source tree, if changed. The build failed for me, > > The rule from the FSF is that tm.texi is treated more like a source file > than a generated file, because no actual dual-licensing notice for > target.def could be produced (if it could, we wouldn't need a checked-in > tm.texi at all - checked-in generated files are only for cases where they > are needed in the bootstrap process or to reduce the external dependencies > for a build). Someone can write new text and put it in both places for > licensing in each source file under its respective license - the makefile > rules are providing a tool to assist someone choosing to do so and so > ensure that the source files target.def, tm.texi.in, tm.texi are kept in > sync in a way that we wish to keep them in sync. Or someone can copy > existing doc strings from tm.texi to target.def, or from comments to both > target.def and tm.texi, keeping the three files in sync in the desired > way, but with approval for the patch from one of the docstring relicensing > maintainers being required in that case. > > Thus, the makefile rules are not rules for updating a generated file in > the usual sense - they are rules to assist developers, who have made a > conscious decision to put the same text in multiple source files under > different licenses, in making changes to those multiple source files in > sync with each other. > > Perhaps the error message should be phrased differently to make clear that > it is about the three source files not being in sync with each other.
You failed to state a single case where a violation is caught. Do that now, I'll wait. If I modify the tree in a way that the generated tm.texi file changes, and that file is copied into the source tree, and I distribute it, then, there are only two cases to consider, either, I did that in violation of the copyright law, or I did not. If I did, then, exactly how the law is violated is beyond the grasp of software, or I did not, and in that case, there is no aide to me for failing the build. You're under the mistaken idea that you can write software to catch violations of law, stop. You cannot. Failing the build because I merely _changed_ the software is _not_ an indication of a violation of law is about to take place. If you want to argue that it is possible to catch a violation of law, go for it. For the counter proof, there can be no violation of law, without a copy, or, say, a distribution. I'm not going to distribute, therefore, there can be no violation of law, QED. All failures from any development I might undertake that fail the build in this way, are _always_ false positives. Please fix all false positives.
