On Wed, Jul 27, 2005 at 12:28:23AM +0200, Francesco Poli wrote: > On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote: > > 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. > I fail to understand how you justify your reading of "program" as > program in DFSG#2 while you read "program" as work in the other > guidelines at the same time. 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. > IOW, why do you agree with me that the other guidelines must be applied > to anything in Debian (excluding texts of licenses covering the works, > as often reminded) and, at the same time, disagree with me on the scope > of DFSG#2, stating that it applies to programs only. Because I don't think it makes any *sense* for Debian to apply DFSG#2 as a hard requirement for data? > Moreover, in the long discussions about the GFDL, the "what is > software?" tangent came up many many times. > Several people pointed out that there's no clear line to tell programs > and non-programs apart: the distinction is blurred (many examples were > proposed at the time: e.g. PostScript is a Turing-complete programming > language, literate programming creates works that are both program and > documentation, ...) I think it's disingenuous to claim that all PS files are "programs" just because PostScript is Turing-complete, when the corresponding "source" that has been mechanically converted into PostScript is not a program at all. I also think that the lack of a clear binary distinction between programs and non-programs is not a hindrance here. I'm not proposing that non-programs be exempted from complying with the DFSG; I'm observing that one clause of the DFSG isn't meaningful for non-programs as written, and twisting it into something that *is* meaningful for non-programs is not beneficial. This doesn't mean giving a free pass to literate programming (I've always felt that if we did have a separate set of guidelines for documentation, things that are both program and documentation should be held to *both* sets of guidelines); it does mean coming up with a more sensible guideline than "this documentation/font is a program because it's implemented in a Turing-complete language, therefore you must give us the source for it... even though the 'source' in question isn't implemented in a Turing-complete language". > > Aside from (or perhaps entwined with) the issue of > > trying to reach a consensus on what constitutes "source" for all of > > these things, > which is not so difficult as you seem to imply, IMHO... Suuuure, we've just been arguing about it on this list for two solid years for no reason at all. > > I think we need to consider what the practical aims are > > that lead us to insist on the availability of source. > Are we *again* going to talk about practical points of view? From a > practical point of view, nVidia proprietary drivers seem to work well > and make many people happy: are we going to ship them in main? > I really hope we aren't! Yes, I guess I should have known better than to suggest on debian-legal that our standards should have some bearing on reality, shouldn't I? Since obviously any such suggestion is equivalent to asking for the inclusion of the Win2K kernel in main. > > 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. > Please add > * avoiding dependence on a single provider This is only relevant if we accept that there's anything the author is holding back that leads to a dependence. > * allowing user to study how the work is created by looking at its > internals Fair enough, though I don't think it applies in all cases and I don't personally think that this is of prime importance for the works we're talking about. > [...] > > 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. > Could you show a concrete practical example in which the "preferred > form for modification" is *not* the preferred form to start with for > conversions to other formats? When the author has no interest in those other formats, and therefore regards this "preferred form" as merely an intermediate form on the way to a form that will be edited. E.g., a file containing data for a rendering engine (povray, etc) may be "source" that the author uses only for the purpose of producing a jpeg which is further edited using GIMP. > > 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. > So you say that lacking the preconditions for fixing non-RC bugs is > fine... No, I say "fixing bugs is important for data as well as for programs, of course". If I were to elaborate on that point, I would note that there are thousands of bugs reported in the Debian BTS that are chronically unfixed, and that all maintainers have to prioritize which bugs to work on; and consequently if we're going to consider a <ahem> *practical* argument that we need to be able to fix bugs, we ought to look at the big picture and evaluate just how many of these bugs get fixed *anyway* before we impose a project-wide rule that will elevate an entire class of new bugs to RC status." > > 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; > With no source, how are you going to fix a bug due to the camera > position in a pov-ray generated image? I'm sorry, I don't see how I can seriously regard a camera position choice as a "bug" that Debian needs to fix. Can you elaborate? > > 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. > Correct me if I'm wrong: Linux kernel source packages are much larger > than the corresponding vmlinuz images... > Are we going to stop distributing kernel sources? $ du -sh k/kernel-image-2.6.11-i386/kernel-image-2.6.11-*2.6.11-7* 14M k/kernel-image-2.6.11-i386/kernel-image-2.6.11-1-386_2.6.11-7_i386.deb 16M k/kernel-image-2.6.11-i386/kernel-image-2.6.11-1-686-smp_2.6.11-7_i386.deb 16M k/kernel-image-2.6.11-i386/kernel-image-2.6.11-1-686_2.6.11-7_i386.deb 15M k/kernel-image-2.6.11-i386/kernel-image-2.6.11-1-k7-smp_2.6.11-7_i386.deb 15M k/kernel-image-2.6.11-i386/kernel-image-2.6.11-1-k7_2.6.11-7_i386.deb 4.0k k/kernel-image-2.6.11-i386/kernel-image-2.6.11-i386_2.6.11-7.dsc 100k k/kernel-image-2.6.11-i386/kernel-image-2.6.11-i386_2.6.11-7.tar.gz $ du -sh k/kernel-source-2.6.11/kernel-source-2.6.11_2.6.11*gz 372k k/kernel-source-2.6.11/kernel-source-2.6.11_2.6.11-7.diff.gz 44M k/kernel-source-2.6.11/kernel-source-2.6.11_2.6.11.orig.tar.gz $ The kernel-image binary packages for a single architecture take up more space in the archive than the kernel sources do. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature