Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 05:26:49PM -0300, Humberto Massa wrote:
> 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??
Wow. This entire huge block of quotes above, minus <stuff>, is a proposed
definition of source? No, that wouldn't help at all; few people will
even want to read that much, much less figure out exactly what it means,
and figure out if it covers all bases. (I didn't read it--sorry :)--because
I believe any attempt at a strict definition of source will fail, and I
believe a page-long definition of *anything* is doomed from the start.)
I don't really see how a strict definition helps, though. Back up a
little bit. If I create a complex, layered image in Photoshop or Gimp,
I probably prefer to edit it in those programs, using their formats (eg.
PSD). Exports to PNG are nearly uneditable by comparison. I think it's
clear that, for this particular case, the source of the PNG is clearly
the PSD. (This is a day to day, real-life, practical case. I've requested
PSD source from artists on projects many times, in order to edit an image.)
In that case, should we expect the PSD to accompany the PNG (in the
source archive)?
If we can't answer this, then there's no way we can hope to answer similar
questions for cases where "source" is less clear-cut (like fonts).
(To be clear, I'm not asking if DFSG#2 is interpreted to mean that, or if the
SC says that, but rather whether we should or not--is it in the interests of
the Project and its users. I suspect Manoj would say "yes".)
(Also note that I'm purely talking about source requirements, not licensing
freedom. I believe it's extremely clear at this point that we do expect such
images to be licensed under DFSG-free terms, and I fully agree with that.)
--
Glenn Maynard
Reply to: