[This was just a convenient point in the thread to which to reply; it's not really a reply to Sean's specific message.]
I think, instead of pedantically applying the wording of the DFSG, we should be pedantically applying the intended purpose of the DFSG. The legal profession has proven, time and time again, that no written language can perfectly express any sufficiently complex idea (nor can it express perfectly many very simple ideas). The intended purpose is to ensure that the recipient has every reasonable opportunity to modify the software in any reasonable way the recipient desires. The sole purpose of the requirement for source is to protect this freedom, and the requirement should not be applied independently from this purpose. So the question becomes how does the inclusion or exclusion of the binary blob, without inclusion of the full source and build process of the broken version of the software used to produce the binary blob, enhance or detract from the recipient's ability to produce a modified version of the current, good, distributed software. First, recognize that in this case, the software may be built with or without the binary blob present, and the resulting software will be the same. The blob is only used to allow the person modifying the software to check for mistakes made during modification. My opinion would very likely be different if this were not the case. In what way does the absence of the blob's source limit the recipient's ability to modify the current version of the software? What real, reasonable (as opposed to hypothetical and unreasonable) kind of brokenness of the _current_ version of the software would you want to produce a test for, that not having the old broken version of the source code would hinder? The real answer is that the programmer is much more likely to base such tests on slight modifications of the _current_ code rather than the _old_ code that had one specific bug that was the impetus for producing the blob as a test case. So the reduction of freedom by including the blob without its original source is infinitesimally small (if not zero). It is made even smaller in this specific case by the fact that the source is available from an older Debian distribution, though this is really beside the point, as the current application of the DFSG treats one version of Debian as a stand-alone entity that cannot depend on software in other versions of Debian. On the other hand, by including the blob, the test suite used to prevent regressions due to modifications is significantly more robust, which is a huge increase in the recipient's ability to modify the software without unintended consequences. So, in my opinion, the inclusion of the blob provides a significant increase in the freedoms that the DFSG is intended to protect, without any real decrease. ...Marvin
