On Fri, 15 Jul 2016 23:45:01 +0530
Pirate Praveen <praveen@onenetbeyond.org> wrote:
> On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> >Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG
> >2"):
> >> Speaking as an individual TC member, here's my personal reading
> >> of
> >the
> >> TC discussion.
> >>
> >> It's not clear that the TC is the right body for this discussion.
> >> We certainly could offer advice, but it's not clear that the
> >> ftpmasters
> >or
> >> release team--the parties most likely to need such advice-- would
> >> benefit from our advice.
> >
> >I would like to comment briefly on the general idea about the TC
> >offering advice and making statements of opinion.
> >
> >
> >If someone in authority in the project, such as a maintainer of the
> >ftpmasters or the release team, is doing something which the TC
> >thinks is wrong, then (if the question is important) I think it
> >would be entirely appropriate for the TC to issue a statement of
> >opinion, disagreeing with the other authority.
> >
> >Conversely, if a contributor has been criticised, they may welcome a
> >message of support from the TC. That may help lay to rest an
> >unfounded criticism and save the contributor the energy required to
> >wonder whether they're really right, rebut any public criticisms, and
> >so on.
>
> I agree.
>
> >And finally if a question needs authoritative input but the relevant
> >authority in Debian has not made a clear decision, TC involvement
> >might help get the matter properly resolved.
> >
> >
> >In this case I think that it would be worth TC members considering,
> >for themselves, briefly, and without too much back-and-forth enquiry,
> >what their initial assessments of the merits of the situation are.
> >
> >If TC members feel that the submitter of #817092 (Luke, who is
> >complaining that the aggregated file is not source, along with Ben,
> >Jonas etc.) are right, they could ask the release team and the
> >ftpmasters (informally, perhaps) whether the release team would
> >welcome a supportive TC intervention.
> >
> >That would allow the TC to help settle this long-running question
> >(which keeps coming up on -devel and is frankly quite annoying).
> >
> >This is true even though it seems the specific case of
> >libjs-handlebars has a more clear-cut problem, as found by Ansgar and
> >described in #830986.
> >
> >
> >Concretely, as one of the people who agree with the submitter of
> >#817092, I would like to see the TC pass a resolution along these
> >lines:
> >
> > The TC gives a non-binding statement of opinion:
> >
> > * The point of having the source code (with an appropriate licence
> > etc.) is so that all our contributors, downstreams, and users are
> > able to modify the code and to share their modifications with each
> > other, with Debian, and with upstream.
>
> I agree this is an important consideration, but not serious enough to
> reject a package.
So you consider that upstream are not fully-qualified users somehow and
therefore do not get the benefits of the DFSG? If the freedoms of users
who choose to interact with upstream are reduced by choices made within
the package then the package is breaking the DFSG by penalising a
field of endeavour.
> If this argument is accepted, we will not be able to package a fork
> because the original upstream won't accept a patch against the fork.
> Similarly we'd be able to package only HEAD of the vcs as they
> usually accept patched only against HEAD. Porting patches is an
> essential part of packaging. By choosing to maintain this source, I
> accept this challenge. If I cannot keep the package rc bug free
> otherwise, it will be removed any way.
>
> > * In particular, Debian will often want to share modifications with
> > upstream, which means that we need to be working with the software
> > in a form which lets us do so.
>
> This is ideal thing, but should not be a requirement to qualify as
> dfsg-free.
>
> > * For Debian, therefore, the source code for a file or program is
> > the form which can be conveniently modified and shared;
> > specifically, the form in which upstream will accept patches.
>
> This was never the intention of dfsg, it was always about freedoms of
> the user receiving the source code.
>
> Our only consideration for dfsg qualification would be to see if a
> user can exercise freedoms in a generally accepted way. In this case,
> would some comfortable with javascript modify the code? If they are
> able to modify the split files, they will be able to modify the
> browserified files as well without any extra complexity.
>
> As for patches from upstream, the effort is similar to backporting.
> Same for sending patches upstream, effort is similar to rebasing.
Where do you get this crazy and fanciful notion that upstream are
somehow second-class community members? Upstream are users of the
software and all users must be free to choose how to use the freedoms
assigned by the DFSG, including to interact with upstream if they choose
to do so. There is no division - upstream is a subset of the users of
the software. Any freedom granted to a user is given to upstream as
well.
This is not just about one subset of users - it is about all users,
within Debian, upstream of Debian and downstream of Debian. Debian and
the DFSG must serve them all equally or it is not worth having.
A stream that blocks the flow back to the source will not flow for long.
Working on the upstream of a package is just a field of endeavour in
terms of the source code and the DFSG. As such, working with or as
upstream is fully covered by the DFSG. No package is allowed to penalise
users merely due to their particular field of endeavour.
So, by your own argument, upstream - as users of the software - are
part of the choice of what is the generally accepted way of exercising
freedoms given to all users by the DFSG. As such, if upstream have a
preference for a format, then that needs to be respected as the
accepted way of handling that data in that package. The DFSG does not
allow packages to discriminate between upstream and other users.
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.
> > * There may be exceptions to this principle but none of them apply
> > in the case of libjs-handlebars. We do not expect that any such
> > exception would be applicable to other concatenated or
> > `browserified' JavaScript files generated with tools like Grunt,
> > even if the JavaScript output is not minified or obfuscated.
>
> Any JavaScript source that is not obfuscated or minified should be
> considered source.
Concatenation / browserification is a form of obfuscation for the
benefit of another program, not to make it easier for a human to modify.
Therefore the question is resolved - the generated form is not source
code.
It makes absolutely no sense to have two formats of the one source and
as one is blatantly generated from the other and cannot be reverse
engineered back to the original, then the generated form is not source
code.
> > * So in the case of bug #817092 against libjs-handlebars, the
> > concatened JavaScript is not, in our opinion, source code. This
> > would remain true even if the parser-generator input mentioned in
> > bug #830986 were available.
>
> It should be considered dfsg-free.
It is not, by your own argument.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgpJiAChGvr3S.pgp
Description: OpenPGP digital signature