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]https://lists.debian.org/22410.13949.193515.699...@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] https://lists.debian.org/016cfb0b-076a-9f8f-3b4b-7d3190e5c...@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] https://lists.debian.org/20160717230207.ge21...@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.
