@ 26/04/2004 16:17 : wrote Glenn Maynard :
I would tend to think that there's no need to define that further--"program" seems to obviously include /bin/ls and firmware blobs, and exclude documentation, fonts[1] and images--but the RM is apparently claiming that the old SC didn't apply to firmware, as if firmware isn't software (a very strange claim, IMO). Of course, this wouldn't change the need to remove non-free firmware or GFDL'd documentation. [1] Oops. Hinted fonts have programs in them. I'm not even sure where to start on that.
There is more to it...PostScript documents are programs. So are PDF documents. Some PostScript programs are their source file; others are generated from other formats. All KDE Crystal icons are PNG generated from SVG; some of those SVGs are generated from other vectorial formats. Ah, and SVGs are programs, in a way, too. The problem IMHO is not what is the format of software (and I mean software in the widest definition: that "thing" that is not hardware and is not wetware). The problem, IMHO, is defining what is "source code".
In my opinion, the GPL definition of "source code" is somewhat weak, "preferred form of modification" implies "preference", that is a subjective term; it does not even specify whose "preference" it is. Maybe a GR should define what is "source", in the Debian sense, or what does Debian prefers.
It should specify, p.ex., equivalence of two formats that are trivially interchangeable (as in "three command line commands maximum, within the shell of an all-free-debian system"). It should take into account (maybe?) the original programming source code (!?). It should take into account which modifications were made in the scope of Debian and in which format were those made.
Something starting in the lines of: <what is in angle brackets is not part of the draft draft>
The Debian Project defines as Source Code for any work the Form that may be assumed by the work, in which the Debian Project prefers to make modifications to the work. Trivial examples of Source Code are: .c/.h/Makefile files to trivial projects written exclusively in the C programming language; those plus configure/config.test to automake-generated projects;.dpr/.pas to Pascal language projects; <.... can do a lot of examples here, maybe stating that the exemples are not limitating>.
Some non-trivial examples of Source Code are: the SVG source to a PNG file, that was originally done as an SVG; the TeX source to a PDF file, that originally was a roff man page, but was converted to TeX via the tool roff2tex <bogus>, and maintained as TeX from this point forth, at least in the scope of Debian; <... more, more, more>.
If some Source Code file requires an ancient, non-currently available or otherwise modified version of a tool that otherwise is in Debian <yacc, bison, lex, flex and others come to mind, bug>, it's OK to accompany the sources with some processed, intermediate form (yylex.c in the case of lex, p.ex.), if and only if the original form is also shipped.
If two forms of the same final work are interchangeable, as per the definition in the next paragraph, than even if one of them is the Source Code as defined above, the other is just as acceptable as Source, for obvious reasons.
Two forms of the same work are deemed interchangeable if in a normal Debian system, they can be, without any loss of information, transformed from one form to the other and back, using at most <some number>3 command line commands, <or some number/15 clicks in a graphical, non-automatable program??>, requiring of the user no knowledge respecting to its form, content or structure, and requiring no further installation of packages not available in Debian itself.
A binary program or hex chunk of programming code is acceptable under some conditions <or is never acceptable?? if it is, state the conditions: could be if size less than something> as source code.
Hex chunks of code are assumed to be firmware, and binary programs by extension, if <nothing else is said about them/we think so/Release Manager says so/Project Leader says so>, applying to them the contents of the last paragraph.
Some things are not to be considered binary chunks of programs, <this, this, and that>?
Would this help?? -- br,M