Bug#830978: Browserified javascript and DFSG 2
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.
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.
> * 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.
> * 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.
>
>I think this would help save debian-devel a lot of annoying threads.
I agree.
>Ian.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: