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...
Sre, 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
