Bug#839570: Browserified javascript and DFSG 2 (reopening)

["Joseph R. Justice" <jayarejay@gmail.com>]

[FWIW: I am not a Debian Developer.  I am not a Debian Maintainer.  I am not someone who (currently) uses Debian (tho I subscribe to some of the mailing lists), nor uses the software being discussed or referred to within this bug.  I don't have a horse in this race.  I do, however, have Male Answer Syndrome, and I'm not afraid to use it!]

On Sun, Oct 2, 2016 at 2:50 PM, Tollef Fog Heen <tfheen@err.no> wrote:

]] Pirate Praveen

> Following up on #830978. I would like this to be reopened and request
> CTTE make a formal vote.

What is the exact question you're trying to get us to answer?  Are you
asking us for advice, are you asking us to overrule a developer or
something else?'

Having reread the bug log for 830978 and I think most if not all of what's referenced there (tho not any broader discussions in d-devel), I *believe* what Mr. Praveen (my apologies if I'm referring to hir incorrectly) is trying to get at is the following:

(1) The current position of the FTP team is that software proposed to be distributed by Debian which:

(1a) has source code written in _javascript_,

(1b) where the _javascript_ source code as distributed by Debian for the software would be "browserified",

(1c) where the _javascript_ source code as released by the original author of the software is *not* "browserified",

(1d) where there is no tool or set of tools currently packaged within the Debian "main" archive which is capable of taking the _javascript_ source code described by (1c) and transforming it into the form described by (1b),

(1e) is not suitable for distribution by Debian within the main archive, because such software does not meet the requirements of the DFSG in terms of source code availability.  However,

(1f) such software might be suitable for distribution in the "non-free" archive if there is no reason prohibiting it from being distributed in non-free.

One such software affected by this is a library package Mr. Praveen was involved in packaging, libjs-handlebars.  (Its source is ruby-handlebars-assets, and that source is currently in non-free.)  Diaspora, which I believe Mr. Praveen was involved in packaging, depends on libjs-handlebars.

There is apparently the software application "grunt" which is capable of resolving the point in (1d) in a satisfactory fashion.  (E.g. if grunt existed in main, (1d) and therefore (1) as a whole would be moot.)  However, this application is not currently in the Debian main archive, and presumably there is no hope of getting it into shape to be added to the main archive in time for the release of Debian "Stretch".

There is also apparently no hope of creating some other software capable of doing what grunt would do to resolve the point in (1d) in satisfactory fashion in time for the release of Debian Stretch.

(2) There is other software currently in Debian (presumably in the main archive), or proposed to be in Debian, which would be affected by the reasoning in (1).  

Bug 814871 refers to libjs-fuzzaldrin-plus, which is depended upon by gitlab.  Apparently gitlab needs libjs-fuzzaldrin-plus to be in browserified form and that form cannot yet be created within / by Debian.

Bug 829046 refers to unspecified _javascript_ libraries which depend on "grunt" (which itself is not currently in Debian), which are bundled by and therefore depended upon by pagure (which has an ITP); presumably the dependency on grunt means that these unspecified _javascript_ libraries are used in a browserified form.  

Bug 835661 refers again to libjs-handlebars, this time being depended upon by prometheus.

All these library packages would, per (1), have to be distributed in the non-free archive.  Presumably at least some of these libraries are currently being distributed in the main archive.

(3) The current position of the FTP team is that software proposed to be distributed by Debian which

(3a) depends on software which is not available in the Debian main archive

(3b) cannot itself be distributed in the Debian main archive.  However, 

(3c) such software might be suitable for distribution in the "contrib" archive if the only reason it cannot be distributed in the main archive is because it depends on software not found in the main archive.

(4) The software depending on the items affected by (1) and (2), e.g. Diaspora, GitLab, Pagure, and Prometheus, will therefore have to be distributed in the contrib archive, and moved from the main archive to contrib if it is currently already in main.

Mr. Praveen further hypothesizes that there will be a number of other important pieces of software, either already in main or that people would like to distribute in main, which will have to be moved to contrib and/or distributed in contrib because they are affected by the same issue: they depend on other software written in _javascript_ which is affected by the issues raised in (1) and (2) and which therefore can only be distributed in non-free (assuming it is otherwise distributable in the first place).

(5) Mr. Praveen suggests that this will cause many people who want to use software packaged by Debian for the Debian Stretch release which is affected under (4) to have to enable the contrib and non-free archives for this release, which they would otherwise have no desire or need to do.

(6) Mr. Praveen suggests that (5) is likely to be seen as an undesirable situation by many within the Debian community (Developers, Maintainers, et al).

(7) Mr. Praveen suggests that one way to prevent (5) and (6) from occurring is for the TC to overrule the decision in (1), that browserified _javascript_ source code does not meet the requirements of the DFSG and that therefore software whose source code is browserified _javascript_ source code is not suitable for release in the Debian main archive, for the duration of Debian Stretch.  

He also suggests that renewed efforts be made to successfully package grunt in the main archive in time for Stretch+1, so that this variance from the normal policy of the FTP Team will not be needed for Stretch+1 (because presumably then all software requiring browserified _javascript_ source code can get it through use of grunt).

(8a) Mr. Praveen therefore requests that the TC vote to overrule the decision in (1).  If the TC chooses to not overrule the decision in (1), then alternatively

(8b1) Mr. Praveen requests that the TC formally state for the record that it sustains the decision in (1), and 

(8b2) that the TC formally state for the record that it realizes this means that many people who wish to use software packaged by Debian for the Debian Stretch release, where the software is affected by point (4), will have to enable the contrib and non-free archives to do so even tho they might otherwise have no need to do this (e.g. they have no other software they want to run which requires software from the contrib and/or non-free archives).

If I have misunderstood in any way Mr. Praveen's position, or if I have misrepresented in any fashion whatsoever what it is he is trying to express, then I sincerely apologize for my error.

Otherwise...  I hope this is of some use, interest, in resolving this issue.  If it is, then I'm glad I could help.  Thanks for your time in reading this.  Be well, and thanks for all of y'all's efforts in creating Debian!

Joseph