Bug#830978: Sam's Comments on What I Source Code
I was working on the following comments in hopes of turning them into a
draft resolution for the TC.
The TC adopted not to take that approach, but I thought I'd submit these
as my individual opinion in the interest of sharing them and starting
discussion.
In #730978, the Technical Committee was asked to rule on whether Browserified Javascript files meet the conditions of DFSG #2.
In addition, later in the bug[1], Ian Jackson asked the Technical Committee to clearly communicate the current situation in order to provide input to future discussions, prevent the same points from being debated without new input, and avoid situations where the discussion diverges from the project's overall consensus because key participants have departed in frustration.
[1][🔎] 22410.13949.193515.699808@chiark.greenend.org.uk">https://lists.debian.org/[🔎] 22410.13949.193515.699808@chiark.greenend.org.uk
Here's my understanding of the discussion surrounding source code to
date, particularly as it relates to this bug.
The FTP team is responsible for determining if a package meets the
requirements of DFSG, including whether the source code meets the
conditions of DFSG #2:
2. Source Code
The program must include source code, and must allow distribution
in source code as well as compiled form.
The Release team is responsible for determining whether a particular bug is release critical. The Release team has decided that compliance with the DFSG is release critical and has deferred the determination of DFSG compliance to the FTP team [1]
[1] [🔎] 016cfb0b-076a-9f8f-3b4b-7d3190e5c4fe@debian.org">https://lists.debian.org/[🔎] 016cfb0b-076a-9f8f-3b4b-7d3190e5c4fe@debian.org
With regard to the particular issue of Browserified javascript,
particularly in the libjs-handlebars package, the best way forward is
for the submitter to discuss the question with the FTP team. Such a discussion would be less confusing if it took place after #830986 is resolved.
Background
Various transformations are performed on Javascript as it is presented
to web browsers for consumption. There has been a lot of discussion
of minimization, in which javascript is transformed, removing variable
names, comments and performing other transformations. TheFTP team has
consistently argued that minified Javascript is not source code.
This issue was raised with regard to Browserified Javascript That term
was never defined during the discussion, but has been taken to mean
transformations, especially concatenating files together, in which the
result is human modifyable. The transformations may be reversable.
In the particular case of libjs-handlebars package, the issue is
complicated by #830936: in addition to being browserified, the
Javascript is the result of a parser generator. To date, no one has
disputed the idea that the parser generator output fails to meet the
requirements of DFSG #2.
What is Source Code
The GNU GPL states that source code is the "preferred form of the work
for making modifications to it." The DFSG does not define source code. Ansgar Burchardt, one of the ftp masters, argues that the preferred form for modifications is what we mean when we talk about source code in the DFSG.
We need to distribute source code in order to give our users the
freedom to modify the software, prepare derivative works and to
distribute those works. Considering whether the source of a work
facilitates that process is an important consideration in evaluating
whether the work meets the conditions of DFSG #2.
Another important consideration is what format the upstream uses: our
users need to have the same tools for modifying a given snapshot of a
package as upstream. Ben Finney summarized this concern [1]
[1] [🔎] 20160717230207.GE21693@benfinney.id.au">https://lists.debian.org/[🔎] 20160717230207.GE21693@benfinney.id.au
Reading the discussion on debian-devel, and even reading the
discussion in this bug report, the argument for the source form of the
work rests on *whether* the form of the work allows modification on an
equal basis with upstream.
Neil Williams puts it well in this same bug report:
Where one format can be modified by every user and another format
can only be modified by some users, then the format which can be
modified by everyone *must* be the accepted format or the package
fails DFSG. When the second format is actually generated from the
first format and cannot exactly regenerate the first from the
second, it is obvious that the second format is not the source
code in terms of the DFSG as changes to the second would be lost
when the first is updated and the second gets regenerated.
<URL:https://bugs.debian.org/830978#95>
Nothing about “upstream convenience” there. It's about equal access,
for all recipients of the work, to make and share their own build from
the source form of the work.
That entails receiving the work in such a form, and with all necessary
build scripts, to make modifications (or choose not to modify) and
build the work themselves to get the same result. That is, in brief,
the source form of the work.
some of the rest of Neil's comments in that message appear to give the upstream form more weight than the consensus position--such as it is--would support. My read is that it is probably more important that we as a project have the freedom to modify software in the ways we want to modify it than that we have exactly the bits we'd need to give to upstream. However, giving bits to upstream is one of the ways we often want to modify software, so it is an important concern.
It's also clear from our packaging practices that when we talk about source code we're talking about source code to a specific version, not the overall history of a project.
One factor to consider might be whether we'd have the necessary bits
if upstream disappeared to fork from the source we have and continue
ongoing evolution of the software.
Corner Cases
IN general, this issue is not simple. Here are some cases to consider:
* flight-of-the-amazon-queen: by now, the modified binary is the source code
* When DSP filters, or other digital signal processing/control loop functions are developed it is common to use some sort of mathematical model to tune and test the filter/transfer fuction/control function. Once the function is tuned, it is rendered into software. These models may not be included in the source package, and even when included the tools to run the models may not be in Debian. Such models are not required, but would make future modifications easier.
* Similar issues surround implementations of protocols, codecs and the like. There are often interoperability tests, specifications, and models that significantly simplify modification that may not be included as source code.
* Is a png file a source form? Sometimes? What about when there is a multi-layer image that is combined to for a single icon? What is the source for video? What about audio? Often audio and video are produced in environments that combine multiple sources/ and allow for editing, replaying the edits rendering to a single result only at the end. The games team has struggled with this and similar issues.
* Perl presents an interesting case. It has a configure system called Metaconfig that serves a similar purpose to Autoconf. However, the source of metaconfig is not included in Debian. The resulting configure script is easier to modify (in some ways) than autoconf's configure scripts, but still may not be the preferred form of modification.
* What happens when a configure.ac is included, but when the included configure script is not produced by a version of Autoconf in Debian? What happens when the version in Debian would produce a non-working version of the configure script?
* On the other hand, what is the source when maintainers or upstream have chosen to hand-modify a configure script generated by autoconf? The configure.ac is included, but no longer would produce a configure script that works.
There's a lot to thing about here.
If in each of these instances, we decided that source code was not provided, we'd exclude a lot of software from Debian. Yet, if we decided that all of the above were always fine, we would make some classes of modifications difficult.
Reply to: