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

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

[I realize there have been several messages subsequent to this, but I'm working down the list in order of presentation by the GMail web interface.]

On Tue, Oct 4, 2016 at 4:13 AM, Didier 'OdyX' Raboud <odyx@debian.org> wrote:

Le dimanche, 2 octobre 2016, 14.29:49 h CEST Pirate Praveen a écrit :

 

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

The discussion that lead to closing #830978 happened on IRC [0] , see the full
log from line 172 [1] , and Sam put a clear rationale in the mail closing the
bug [2]. I'll quote on specific part of it:
> 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.

(#830986 isn't resolved)

FWIW, it's not clear to me at least that ""browserified" _javascript_" necessarily includes the issue pointed out in 830986, e.g. the generated lexer/parser code.  (I'm not saying it *doesn't* include the 830986 issue, mind you!  I'm just not saying either that it *does* include it.  Reviewing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 , I see some comments that, to me at least, imply that browserification does not necessarily imply the 830986 issue in in play for any given instance of browserified code.)

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 , Mr. Praveen lists bugs which ultimately refer to several other _javascript_ library packages beyond that of libjs-handlebars.  I suppose it's possible that all of them include generated lexer/parser code, but if there are some that do not then apparently "browserification" does not necessarily involve use of external lexer/parser generators (tho certainly it's possible that browserification, in the form Mr. Praveen means it, might include always having the capability to invoke a lexer/parser as part of the process of browserifying _javascript_ libraries).  In any event, for any browserified libraries which do *not* include code generated by a lexer/parser, the bug at 830986 should not apply to them.

Further, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#35 , Mr. Praveen says "the browserified _javascript_ can be modified by anyone who understand _javascript_ without difficulty and can satisfy dfsg requirement for source" where the browserified _javascript_ refers to "libjs-handlebars, libjs-fuzzaldrin-plus and other browserified _javascript_".  Given what I understand about the sort of code typically generated by lexer/parsers, e.g. that it typically can *not* be modified, in generated form, by "anyone" "without difficulty", I have to think that either (a) Mr. Praveen does not mean libraries of this sort (e.g. containing generated lexer/parser code) when he is speaking of browserification in general, or else (b) he is mistaken in his claim about how easy to modify such libraries.

So...  If there can be / are browserified libraries which do not suffer from an issue of containing generated lexer/parser code, then it may make sense to consider whether such libraries are suitable for inclusion in the "main" archive separately from the issue of any such libraries which *do* suffer from an issue of containing generated lexer/parser code.  (For the record, I myself do not know if there are any such libraries, nor am I claiming that there are any such.  I'm just raising the possibility as a "What if?" sort of thing.)

 

Now, moving forwards… We decided to close the bug without a formal vote,
because it was clear for all the present TC members that we were in agreement.
We have also agreed (amongst us) to avoid the use of unnecessary bureaucracy
when possible; hence our delegation to close the bug to Sam. Now, the offer to
"repoen the bug and ask for a formal vote"  [3] stood to enable anyone to ask
for the bug closure to respect our formal procedures (saying "please don't
close the bug because you think you're in agreement, but run a formal vote").

For what I'm concerned, the situation hasn't evolved, and the conclusion that
Sam outlined still stands (FTP Team is responsible for DFSG, and has decided,
Release Team has decided DFSG is RC and has deferred DFSG-compliance
determination to FTP Team).

I'll go into this point in more detail in other responses, I expect, but I'll at least say for now that I think it is possible to find that there are differing levels or degrees of DFSG non-compliance, in terms of their severity of non-compliance or the amount of harm that can be done by distributing them despite the fact that they are not fully compliant with *all* the terms of the DSFG and their current interpretation by Debian, and that therefore it is possible that it might be reasonable in some circumstances to decide that a variance from finding something to be a RC bug for a period of time (such as for the duration in lifespan of the in-preparation version of Debian Linux), while efforts to resolve the non-compliance are ongoing, might be appropriate to apply for some packages.

 

I'm therefore putting the following ballot up for discussion within the TC:

==
C: Close 830978 as not being something for the TC to decide
FD: Further Discussion
==

With respect, I would suggest that if you have a ballot of this form, you word it in something similar to the following fashion:

==

C: Close 830978 by sustaining and affirming the decision of the FTP Team that software proposed to be distributed by Debian which has source code written in _javascript_, where the _javascript_ source code as distributed by Debian for the software would be "browserified", where the _javascript_ source code as released by the original author of the software is *not* "browserified", and 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 as released by the original author of the software and transforming it into "browserified" form, 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.  The TC further recognizes and acknowledges this will require that any software depending on such "browserified" _javascript_ software can itself not be distributed by Debian within the main archive.

FD: Further Discussion

==

I see what's going on here as being akin to asking for a decision from a person's national ultimate court of appeal.  In my country, the USA, that would be the U.S. Supreme Court.

When a (losing) party in a court case appeals to the U.S. Supreme Court (usually after first having appealed to the applicable regional Court of Appeals and lost there), the Supreme Court may _generally speaking_ (there can be exceptions) choose to either:

(1) refuse to hear the appeal, in which case the decision by the regional Court of Appeals stands and is applicable precedent within that region;

(2) agree to hear the appeal, and subsequent to hearing the appeal decide to sustain and affirm the decision by the regional Court of Appeals, in which case the decision stands and is applicable precedent nationally according to whatever grounds the Supreme Court decided to affirm the lower court decision;

(3) agree to hear the appeal, and subsequent to hearing the appeal decide to reverse and overturn the decision by the regional Court of Appeals (often sending the court case back down to a lower court to be re-decided taking into account what the Supreme Court has said), in which case the reversal of the decision stands and is applicable precedent nationally etc etc etc.

By closing this bug as "not something for the TC to decide", to me, you appear to be refusing even to hear the appeal.  

But, if the TC as a body agrees with the FTP Team, that browserified _javascript_ source code is not DFSG compliant and therefore software with such source code is not suitable to be shipped in the Debian main archive (and as well that other software depending on software with browserified _javascript_ source code is itself also not suitable to be shipped in Debian main), then it seems to me that it would be a more satisfactory outcome for Mr. Praveen for the TC to just come out and explicitly say so.  

Indeed, he's even said as much, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 -- he wrote "If that (more people depending on non-free/contrib) is really what the community wants, I want it formally declared".


 
> To make things maybe clearer: we have said through the initial bug closure
> (and would be reaffirming this) that deciding about DFSG compliance is not for
> the TC to decide (we're refusing to rule about something clearly in the FTP
> Team's jurisdiction; that is).
>
> You seem to be asking us to decide on DFSG compliance (in place of the FTP

Team); but it's not at all clear that the constitution enables the TC to
override Delegates or decisions made by delegates (see §6.1). We have
recommended you (through Sam's message when closing the bug) to discuss this
question with the FTP Team:

Mmmm.  I don't know that Mr. Praveen necessarily wants a decision about DFSG compliance in absolute terms, as much as he wants a decision that what's available in terms of source code available is good enough *for* *now* (but *not* necessarily for later), so that software can be shipped in the main archive for the current version in preparation, while efforts are made to improve source code availability of the software for future release versions of Debian (where what's good enough now may not be good enough *then*).

In support of my claim, I note https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 where he writes "I suggest including browserified js IN STRETCH and make an effort to package grunt FOR STRETCH+1" (emphasis mine).  To me, this suggests that, while he himself might feel that browserified _javascript_ is fully DFSG-compliant, he recognizes that there is disagreement on this point, and he is offering to alleviate that disagreement (presumably packaging grunt will allow software to be browserified using software only available in the main archive, which will resolve this concern about browserified software) in a time frame he can achieve it in while getting a variance from full and perfect DFSG compliance for the interim.

I also note https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#35, where Mr. Praveen writes:

"libjs-handlebars, libjs-fuzzaldrin-plus and other browserified _javascript_ should be allowed in main (the browserified _javascript_ can be modified by anyone who understand _javascript_ without difficulty and can satisfy dfsg requirement for source). This would result in diaspora, gitlab, pagure, prometheus (and likely other afftected packages) to be shipped in main instead of contrib.

But it would be better to ship the source code used by upstream (consider it as severity important and not serious), so we should try to package grunt for stretch+1 and browserify during build."

To me, this reads that while he might believe he is sufficiently DFSG-compliant as-is, he is willing to concede the point that he is fully and perfectly DFSG-compliant (because, otherwise, he would not be willing to agree that not using source code shipped by upstream is a bug of *some* level, nor that efforts to resolve that bug should occur).

Now...  This (getting a variance from RC-bug status to get software permitted to be in the main archive for the in-preparation release of the next version of Debian) is at least in part a political issue.  Unfortunately, and much as the TC might not like it, that's something that comes to them, just as it does to the U.S. Supreme Court in my country.  (It's not polite here to talk about such things, of course, but that doesn't mean it doesn't occur.)

Oh, while I'm speaking of politics...  I note that Mr. Praveen's original message opening this bug (the #5 message) itself makes reference to politics.  Namely, he writes "Because, 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" and "This will encourage more people to depend on non-free/contrib and I don't think debian community wants to move in that direction".  Given what Debian emphasizes as its core principles, that's a political statement if anything is, IMO.

 

> With regard to the particular issue of Browserified _javascript_ (…) the best
> way forward is for the submitter to discuss the question with the FTP team.

Has this happened? What was the outcome?

(For completeness, if you had discussed with FTP Team, reached a point of
disagreement, noticed that the TC would continue to decline to rule in place
of the FTP Team, your next recourses would be to go through a GR (§4.1.3) to
override the FTP Team's decision on interpreting DFSG for the specific cases
you have in mind; or through amending the DFSG itself (through §4.1.5). )

Honestly (as I'll also say elsewhere), I figured the discussion had already happened and the FTP Team had ruled that browserified _javascript_ source was not fully DFSG-compliant in all situations and circumstances.  Because, if not, then why is Mr. Praveen coming yet to the TC?  But, all the same, that's a fair question to ask.

I recognize however that subsequent to this message Mr. Praveen has raised a bug (I haven't looked at it yet at the moment I write this) with the FTP Team, and I'll be interested to see what's there.

I also note that, again using my analogy of the U.S. Supreme Court, that when the Supreme Court declines to overrule a lower court's ruling (allowing it to stand as law), or when it does rule to sustain or to overturn a lower court's ruling, that the only way to overturn this action is to seek a amendment to the U.S. Constitution changing whatever it is the Supreme Court has said is constitutional.  This (seeking a change to the Constitution) would be analogous to, within Debian, seeking a GR to override the FTP Team's decision interpreting the DFSG and/or to amend the DFSG itself.  But, generally, you do want to go to the Supreme Court first, because that is a far lighter-weight process than is seeking a amendment to the Constitution, and because it helps clarify any subsequent attempt to seek an amendment to the Constitution.  Now, I realize that seeking a Debian GR decision is lighter-weight within the context of Debian than is seeking an amendment to the Constitution to the U.S. political system and process.  However, it's still probably heavier-weight than is going to the TC, in my opinion.

Thanks for your time.  Hope this is of some use, interest.  Be well, and thanks for your work on Debian.

Joseph