[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

On 7/27/05, Steve Langasek <vorlon@debian.org> 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



Reply to: