Re: Non-source Javascript files in upstream source
Le Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen a écrit :
>
> 1. Do we need to check that generated files which we don't use are actually
> generated from the provided source? Main example here is a configure file
> which gets overwritten during build.
>
> 2. What is source for a non-programmatic work such as a rendered bitmap of a
> 3-D model, do we require source for non-programmatic works, and if not, what
> defines a programmatic work?
>
> Neither of these is clarified by their recent statement.
I totally agree: in the FTP team's statement, first there is a quote of the DFSG:
“The program must include source code”
but then it adds later:
”all files in source packages must come with their source as required by the DFSG”
This does not resolve the ambiguity in our Social Contract and the DFSG, where
sometimes we refer to a “work”, sometimes a “component” and sometimes a
“program” (and actually never to “files” in that context).
Regarding the possibility of a GR:
Most of the text of the DFSG is about judging licenses, not files. It refers
to “programs” without defining what they are. Points 2 (related to source
code) and 4 (related to patches) suggest that “program” refers to executables,
but this interpretation may be too naive as it does not take into account how
others defined a “program” before the DFSG were written (in the GPL: a
copyrightable work), nor it takes into account the historical discussions when
the DFSG were written. Altogether, this calls for clarifying what a “program”
is.
Point 2 is also strange from a gramatical point of view:
“The program must […], and must allow distribution in source code”.
I do not think that it was written with DRMs in mind (where programs really
allow or disallow some actions), and it looks like what it intended is rather :
“The program must […], and its license must…”.
We could clarify the DFSG by separating the two issues (freedom by source code
and freedom by license):
- Introduce a point 0 explaining our requirements for the presence of source
code.
- Replace “program must include source code, and” by “license” in point 2.
- Either define what a “program” is in point 0, or introduce a new definition
for “works”, and replace “program” by “work” in the remaining points.
The contents of this new point 0 are the core of the disagreemnts.
I think that GR could be useful to solve the ambiguity of the DFSG it would not
contain too many overlaping options. For instance:
a) Disambiguate in a way that represents a status quo regarding our current
practices.
b) Extend our requirements for source code to explicitely include non-programs
in our source packages.
c) Focus our requirements for source code on the binary packages and the files
necessary to rebuild them from the source packages.
People know which one is my favorite, so I will not repeat it here :)
Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: