On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote: > Uh, I don't? I said that the other guidelines are *applicable* to > non-program works, and *should be applied* to non-program works -- not that, > as presently written, we are obliged to apply them to non-program works.
I'd prefer to approach this issue from a different direction. The point behind the DFSG is that we need to be able to solve problems in the stuff we distribute. Security fixes are probably the most important, but also important are porting to other architectures, making our packages reasonable or at least plausible to some significant set of our users, and so on. The source code requirement is aimed at that issue. And it can easily apply to documents (for example, a document spit out by ghostscript is typically not in its source form) But... there's all sorts of opinions about what is and is not important, and as currently written the DFSG doesn't let us assign priorities to things. This means we have difficulty neglecting less important issues in favor of dealing with more important issues. One possibility involves hypothetical situations (new platforms, undiscovered buffer overruns, and so on). If we allow ourselves to consider hypothetical situations we can then ask ourselves -- when is this situation likely to show up? What would we have to do to fix this situation? and so on... In that context, a DFSG violation which would prevent us from fixing a "not impossible" grave security bug could be treated as a grave problem. Likewise, a DFSG violation which could prevent us from fixing a "wishlist" bug could be treated as a wishlist problem. This is a somewhat crude idea -- different people will have different ideas of what's possible, what's likely and so on. But I think it's a better system than what we've got. The problems we seem to be talking about, at the moment, seem to be more like "this arguable DFSG violation could prevent us from solving a wishlist bug in this package", not "this issue which most everyone agrees is a DFSG violation could prevent us from solving a critical bug in this package". Obviously, approaching DFSG issues in this fashion would be a change -- we'd be specifically acknowledging that some things are more important than other things. But I don't think this should be too scary, and I do think that we need to be at least somewhat intelligent in how we approach DFSG issues. Thanks, -- Raul
