[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 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

> > 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

Reply to: