Browserified JavaScript in Debian

A disagreement about the status of certain arguably non-free JavaScript components and their inclusion into the "main" Debian archives (as opposed to "contrib" or "non-free") is interesting in its own right, but it also raises some governance questions for the distribution. Debian is known for its strict adherence to the Debian Free Software Guidelines (DFSG), so it won't be a surprise that the question about the JavaScript components revolves around their fitness under those guidelines. The other piece, though, goes even deeper, perhaps, as it centers on the role and powers of the Technical Committee (TC) as laid out in the Debian Constitution.

JavaScript is increasingly used in a variety of different projects and there is often some kind of processing done on the raw JavaScript code for various purposes. "Minified" JavaScript gets obfuscated by making variable and function names as small as possible and removing extra white space, which is largely done to reduce its size for sending over the network, but has the effect of making it unusable as source code. Other projects use "browserified" JavaScript, which collects up several different modules into one file—sometimes performing other transformations along the way. And, of course, some projects use both.

Many of the projects that minify or browserify code use Grunt as a build system. But, Grunt is not packaged for Debian due to its reliance on the non-free JSHint component. That makes it problematic for Debian packages to build these files as part of the packaging procedure, so the packagers end up just including the processed files from upstream. The DFSG is quite clear, though, that Debian packages must come with source code—and it seems to be generally accepted that this processed JavaScript code does not qualify.

The issue raised its head again recently, when Pirate Praveen filed a bug requesting that the TC grant an exception for browserified JavaScript to be included in the Stretch (Debian 9) release, which is nearing its freeze date. In the bug, Praveen said that "every major web based software will have to be moved to contrib because its likely at least one of the javascript dependencies are in browserified form". He listed Diaspora, GitLab, Pagure, and Prometheus as being affected and suggested that there be an effort to get Grunt packaged for the release after Stretch so that the problem would be resolved in that release.

But, as happened with a similar bug Praveen filed back in July, the Technical Committee members are not quite sure what they are being asked to do—nor whether they actually have the power to make a ruling on the issue. In July, TC member Don Armstrong asked: "Could you clarify what the precise question is that you'd like the CTTE to answer?" In the more recent bug, TC member Tollef Fog Heen echoed that:

Joseph R. Justice, who is something of a neutral party with regard to the dispute, provided a helpful summary of some of the previous discussions of the issue. He tried to make it more clear what decision was being sought: effectively, either overriding the FTP team (which decides what can go into the main archive) with regard to Stretch or making a statement that the TC agrees with the decision and recognizes that it means users will have to enable the contrib and/or non-free archives for these types of packages.

TC member Sam Hartman responded, noting that the FTP team had not yet decided that the browserified JavaScript makes a package unqualified for the main archive, though he admitted that it was pretty clear the team would rule that way. But he also raised a constitutional question:

Beyond that, Hartman said that he wasn't comfortable making a blanket ruling about browserified JavaScript and would rather see some kind of intellectual framework that could be more widely applied, rather than make some ad hoc decision. "User convenience is something we're likely to consider, but 'source is what we need source to be so things work well for users,' is going to be a really improbable sell." But that didn't sit well with Adrian Bunk, who pointed to a bug filed against the Perl Configure script, which cannot be generated from the Debian sources. The Perl maintainer seems to have more or less routed around the DFSG question. Bunk said:

Hartman admitted that he disagreed with the Perl maintainer's decision, but that still leaves the browserified JavaScript question (and the libjs-handlebars bug that Praveen is most concerned about) unresolved. Several in the thread suggested that Praveen take the question directly to the FTP team, which he did. The response indicated that the team would not oppose the Release team granting an exception for Stretch. So Praveen, who appears to be dogged in his persistence, filed a bug requesting such an exception. The request was a bit overbroad, perhaps, but it seems likely that something will be worked out for libjs-handlebars at least.

In the thread, both Bunk and Ian Jackson expressed frustration with the seeming inability of the TC members to find a way to help resolve the situation—or at least to move it along in a positive direction. It is an issue that apparently pops up with some frequency (not necessarily with regard to browserified JavaScript, but for Perl, SQLite, and others), but never seems to get resolved. However, the TC members seem to feel that they don't really have the proper authority.

On the tech-ctte mailing list, TC member Didier Raboud asked Debian Project Secretary Kurt Roeckx for some assistance in determining what authority the TC has in overriding decisions made by teams who have been delegated their authority by the Debian Project Leader (DPL), such as the FTP and Release teams. Roeckx's answer was not entirely clear-cut, in part because the TC has broad powers, but the main takeaway is the following: "The only way I can see how to overrule a delegate of the DPL is by using a GR [General Resolution]." He did note that it is possible the TC could "overrule" a delegate by using a different power that ended up having the same effect. It is a little hard to see that ever happening without it causing some major upheaval within Debian, though.

It would seem that progress has been made here—in typical Debian style. The project has built up its processes and procedures over the years and it sometimes looks rather bureaucratic in its deliberations and decision-making, but project members mostly seem to respect and even revere how it all works. That type of organization may not be for everyone, but there are plenty of choices in the free software world for those who find Debian too constraining. As a large, and largely smoothly functioning, group, though, Debian shines in its ability to work things out without rancor for the most part.