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.
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.
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, ...)
Which criterion are you proposing to tell *when* DFSG#2 must be taken
into account?
> 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...
> 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!
>
> 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
* allowing user to study how the work is created by looking at its
internals
>
> Well, the first of these isn't applicable to data;
That's true.
[...]
> 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?
>
> 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...
> 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?
[...]
> 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".
That's how it works for programs too...
> 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?
> 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.
I think we *should* be willing to distribute source: that's one of the
key elements of free software!
--
:-( This Universe is buggy! Where's the Creator's BTS? ;-)
......................................................................
Francesco Poli GnuPG Key ID = DD6DFCF4
Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpaRVIq3xXuv.pgp
Description: PGP signature