On Sat, Jul 23, 2005 at 01:01:07AM +0200, Florian Weimer wrote: > * Steve Langasek: > >> It's clear from the context (and previous discussion) that this has to > >> be interpreted as "software". > > No, it isn't. Considering we went through all the effort of a GR to amend > > the DFSG and this still says "program", not "software", I don't see how you > > can claim it *has* to be read as "software". > So you think that the DFSG clauses 2, 6, 7, 8 do not apply to > documentation, only to executables? > This is certainly an interesting position. Whether it's a valid one > is indeed harder to decide than I thought. I think that clauses 6, 7, and 8 are applicable to documentation and data as well as to programs, and I think that they're rules that Debian should follow for everything we distribute. I think that clause 2 is *not* clearly applicable to things that aren't programs. Aside from (or perhaps entwined with) the issue of trying to reach a consensus on what constitutes "source" for all of these things, I think we need to consider what the practical aims are that lead us to insist on the availability of source. The ones that strike me as most important are: being able to recompile the source code for porting (to a different architecture, a different library ABI, etc); being able to fix bugs (and security bugs in particular) in the program; and allowing our users to modify the work to meet their needs. Well, the first of these isn't applicable to data; it's just not meaningful to talk about "porting" of data (just as this is largely meaningless when discussing programs written in interpreted languages). It may be useful to be able to *convert* your data from one form to another, but that's not the same thing as porting; and there may be a particular form that's more convenient for use in converting to other forms, but this may or may not be the "preferred form for modification" which most people seem to be arguing should be the definition of source, so insisting on source code here doesn't ensure that we get this benefit. Fixing bugs is important for data as well as for programs, of course; though it's much less likely that data or documentation would contain a security bug or other RC bug. But more importantly, the presence or absence of true "source" in the case of data and documentation is simply not a good proxy for the question of whether we can fix bugs. Source v. binary is important for programs, because fixing bugs in the machine code for a typical program is several orders of magnitude more difficult than fixing the source and recompiling. This is not the case for most data formats! Although there are some opaque documentation formats like PDF that are a concern, most data formats (especially images and video) are edited directly using binary editors; and as for fonts, my personal experience is that trying to edit them is a PITA regardless of whether you have a "source" format available. :P And finally, giving our users the ability to modify data in the same manner that the author would is a nice idea, but they only actually get this if Debian is going to *distribute* all of those "sources". Many of these are quite large (much larger than the resulting target data files), and there's far from universal agreement that Debian *should* distribute all of these pristine sources. I don't think it makes any sense to insist that our upstreams make available sources that we ourselves are unwilling to commit to distributing. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature