[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 <o...@debian.org>

> 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

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
> 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

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.


Reply via email to