in short, I disputed the point that the additional permission was not an integral part of the autoconf license, as you'd suggested. the license is the complete set of applicable permissions and conditions, not just an identifiable and recognizable variant (subset?) thereof, even if those combined permissions and conditions allow the distribution under the variant.
indeed, the easy fix for the OSD would be to recognize and endorse such arrangements in which the program is licensed under conditions that allow the distribution under alternate terms that satisfy the definition
Ah, okay, this is about clause 3 of the OSD and its requirement of "same license".
However, in the case of Autoconf, is it not true that one can distribute Autoconf under exactly the same terms one received it under? That is, one is not required to apply any of the exceptions offered in the
Autoconf Configure Script Exception. The offer of exception is just there to allow a special kind of entangled derivative to be distributed -- and in those cases in which the derivative is distributed under a set of terms that differs from Autoconf's original terms but is still FSD- and OSD-compliant, then downstreams get those new terms as well.
IOW, I see what you mean about the glitch in the OSD (I'd call it a bug), in which redistribution under different-but-still-OSD-compliant terms is not included in the definition. So now I see that there is, in principle, a possible slight difference in the actual meanings of the two definitions -- thank you! -- but isn't Autoconf itself, as a distributed package, still OSD-compliant?
By analogy: someone might distribute software under the MIT license. Then someone else might make a derivative work under different (perhaps even non-FOSS) terms. But that wouldn't make the original software not be under MIT. If I can receive Autoconf under a set of terms X, and I can redistribute it under the exact same set of terms X, and I can redistribute modified versions under the exact same set of terms X, then... isn't that satisfying OSD #3?
Oh, wait, maybe what you're saying is that, in the specific case of Autoconf, a recipient/redistributor may not expand the set of "Normally Copied Code" as defined in the exception? Thus activating this clause in the exception: "You have permission to propagate output of Autoconf, even if such
propagation would otherwise violate the terms of GPLv3. However, if
by modifying Autoconf you cause any Ineligible Code of the version you
received to become Normally Copied Code of your modified version, then
you void this Exception for the resulting covered work. If you convey
that resulting covered work, you must remove this Exception in accordance
with the second paragraph of Section 7 of GPLv3."
Okay. That's fascinating: it does indeed fail test #3 of the OSD. Though frankly I'll bet that's just an accident of drafting in the OSD and that no one at OSI would seriously object (semantics-wise) to simply fixing the OSD in the obvious way -- though they might object on the grounds of perception of stability. Still, though, you're right: drafting accident or not, there is a way in which the OSD differs substantively from the FSD, even though it's a rare corner case in practice.
Thanks, Alexandre.