On Wed, 27 Jul 2005 00:52:15 -0700 Steve Langasek wrote:
> On Wed, Jul 27, 2005 at 12:28:23AM +0200, Francesco Poli wrote:
[...]
> > 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.
I thought that the famous GR (2004-003, IIRC) clarified that the DFSG
apply to non-program works as well...
The SC version 1.1 (ratified on April 26, 2004) states, in part:
| 1. Debian will remain 100% free
| We provide the guidelines that we use to determine if a work is
| "free" in the document entitled "The Debian Free Software
| Guidelines". We promise that the Debian system and all its
| components will be free according to these guidelines.
>
> > 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?
Are you saying that you claim it's impossible or simply that you think
it's useless?
>
> > 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'm not claiming that all PS files are programs, I'm just reminding the
PostScript case to highlight how blurred is the distinction between
programs, documentation and other data.
>
> 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.
But if you propose to disable DFSG#2 for non-programs, you have to
propose a criterion to tell programs and non-programs apart.
IOW, you must be able to tell when DFSG#2 must be applied and when it
may be ignored...
[...]
> 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".
This is not what *I* am saying: I just say that this non-program (that
is shipped in main) is a component of the Debian system and thus Debian
developers promised that it will be free according to the DFSG.
I fail to see an "apart from DFSG#2, that only applies to programs" in
the SC.
>
> > > 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.
Just to clarify, I meant that, IMHO, it is not so difficult to find out
what constitutes source for a given non-program work.
Reaching consensus is still sometimes hard and time consuming...
There were (maybe) longer discussions about the GFDL, but, nonetheless,
GFDL'd documents in main are now RC-bugs.
Length of the discussion is not an infallible parameter for judging the
outcome.
>
> > > 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?
The DFSG have, IMHO, both practical and philosophical reasons to be how
they are.
What made me sigh was the appeal to "practical" considerations when
trying to persuade others to compromise principles...
I saw this many times, and I believe that it's slippery slope: we
compromised our principles (stated in the SC) for the source of
non-programs, we should now do the same for verbatim-copying documents
as long as they are from FSF, then we should do the same for proprietary
3D video drivers, then ...
> Since obviously any such suggestion is equivalent to
> asking for the inclusion of the Win2K kernel in main.
Are you referring to the Debian GNU/Win2K port?
It's a well known project, but it's encountering surprising difficulties
due to Microsoft which is not exactly happy about the redistribution of
the Windows 2000 kernel...
But these are of course details that will be worked out sooner or later.
I am of course joking! ;-)
But this joke could be on the above-mentioned slippery slope, just far
ahead in the way...
[...]
> > 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.
If the author has the preferred form for modification, while we have
not, we depend on the upstream author when we need to have a
modification done in the optimal way.
We could modify other forms but this is suboptimal.
Note that even patching binary executables is possible: it's almost
never preferred, though.
>
> > * 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.
Suppose I see a beautiful document in PDF format and I guess (judging
from its typographical look) that it's generated from LaTeX source.
Having the LaTeX source would allow me to study how such a beautiful
look was obtained.
The same holds for raster images generated from Blender models, and so
forth...
[...]
> > 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.
In that case the preferred form for modification (and hence the source
code) is clearly the JPEG format (or whatever format the author would
start from to make further modifications).
Note that the author him/herself showed which is his/her preferred form
for modification, by actually making modifications in that form!
Source is defined (by the GPLv2 text) as the "preferred form of the work
for making modifications to it", not for creating it!
Also note that the source form may change during further modifications
by downstream authors (or should I say "forkers" to make it more
clear?). If the original author prefers to modify an image by changing a
3D scene and re-ray-tracing it, the 3D scene description is the source
code for the original image. But someone else could take the raster
image, ignore the 3D scene description, and modify the image directly
with a 2D image manipulation tool. Then the source code for the modified
image is the image itself (or, more probably, a layered form that
includes the original image as a layer).
[...]
> 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."
I don't think it would be a "new" rule.
AFAICT, it was meant from the beginning that the DFSG apply to every
bit in the Debian CDs.
What we are doing now, is just realizing that this rule has been
misapplied in some cases.
The bugs are there, ignoring them and avoiding to file corresponding bug
reports does not make them vanish: quite the opposite...
[...]
> > 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?
Suppose for example that the image is used in a graphical adventure
game, and that the wrong camera position makes something invisible.
Suppose that this something is essential for subsequent puzzle solving.
It's just an example off the top of my head.
I'm confident that better ones can be thought of.
>
> > > 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?
[...]
> The kernel-image binary packages for a single architecture take up
> more space in the archive than the kernel sources do.
OK, I was wrong about the kernel (unless we consider a single kernel
package, rather than a whole architecture with all its kernel
flavours...).
But anyway, are you really pushing the rule "when the source is bigger
than the binary, Debian does not distribute the source at all"?
--
:-( 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:
pgpHJ2KJzS_6y.pgp
Description: PGP signature