Re: Bug#830978: Browserified javascript and DFSG 2

[Neil Williams]

On Sat, 16 Jul 2016 06:49:56 -0400
Sam Hartman  wrote:

> > "Neil" == Neil Williams  writes:  
> >> > * 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.  
> 
> Neil> So you consider that upstream are not fully-qualified users
> Neil> somehow and therefore do not get the benefits of the DFSG?
> Neil> If the freedoms of users who choose to interact with
> Neil> upstream are reduced by choices made within the package
> Neil> then the package is breaking the DFSG by penalising a field
> Neil> of endeavour.  
> 
> Neil, I have a fairly strong negative emotional reaction when I read
> the paragraph you wrote.  I'd like to share that because I think if I
> share where I'm coming from it will be easier for me to hear you, and
> easier to participate calmly.
> 
> When I read the above, I'm worried because I think that freedoms I
> care about would be limited, and I don't like to see the DFSG
> reshaped to limit freedoms.
> I'm afraid when I think I hear us seeding the contents of Debian to
> upstream.  We are Debian; we choose what Debian is.
> 
> I want to stress that I think you and I are in agreement on
> handlebars.
> 
> However, I do think the freedom to fork from upstream, to move away
> from upstream practices we disagree with is important.

Absolutely - I think it depends on the upstreams we've each experienced
over time. I have been part of or become the entirety of upstream in
nearly all the packages which I've packaged for Debian and it has
always been friendly. Never a need for a fork, I started to contribute
and shortly afterwards got asked to take over upstream...

So I tend to have a more upstream approach than some other DD's, yet I
haven't needed to fork anything - I just got handed it and told to go
ahead! (It also means I rarely have anything in debian/patches...)
 
> I also think that the freedom to "free," over time software even in
> cases where upstream has a non-free source control system, or where
> we're having to build up a new form of source code because of
> restrictions on what's currently the source code are important.
> 
> I do not agree that being an upstream is a field of endeavour.
> 
> I do not agree that we must always use the same source code form that
> upstream does.  Sometimes upstream is wrong.  Sometimes there are
> multiple upstreams.
> Sometimes we want to fork.

Sometimes we do, yes, and we need to retain that ability. However, that
is actually rare. More often, we are interacting with upstream or
supporting users who want to contribute to upstream themselves.
 
> We do however need to ship the source code we use whatever that is.
> It needs to really be source code.  It needs to be a reasonable form
> in which we would choose to make modifications.  If there are other
> plausible source forms that are being used (even if some of them are
> non-free), and those source forms would make the modifications easier,
> that's a strong argument that the software is probably not free as we
> propose to ship it.
> 
> I do not wish us to make the upstream form of source so special that
> we in our best judgment cannot override it.

OK, I didn't mean that we cannot diverge from upstream ever, just that
the majority of the time we are trying to work with upstream rather
than reaching immediately for a fork. Our decisions should make this
collaboration easy, without denying the possibility of the rather blunt
instrument of forking the package.

Part of this collaboration may involve educating upstream about the
problems of distributing their code. This can include source code
freedom issues, it can include software architecture (lack of stable
APIs preventing a large codebase with plugins being separated out) and
it can include portability issues with assumptions in their code which
don't work on all our architectures. Fixing these things requires a
positive attitude to upstream with few structural barriers.

> I do hear your worry that you want to be able to exchange
> modifications with upstream.  Without modifications, without free
> flow of those modifications, software is not free.  I ask that we
> have the flexibility to reject people who aren't actually shipping
> source they would use to modify software while accepting people who
> legitimately disagree about what the source form is.

Agreed.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpUsrQwI7i5v.pgp
Description: OpenPGP digital signature

Re: Bug#830978: Browserified javascript and DFSG 2

[Ian Jackson]

Sam Hartman writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> [stuff]

There is much that you've said that I don't necessarily disagree with,
but:

> Part of having good governance is to have those discussions on devel.

The problem isn't having the discussion.

The problem is that we keep having the discussion again and again.
The same people rehearse the same points.  Over and over.

This is a terrible pattern in our community, because it invites the
more functional people to disengage.  They leave -devel, or kill these
threads, because they want to get something useful done.

That leaves the less functional to dominate the discourse.  Eventually
we end up with situations where the apparent public discourse elides
large sections of the community, or is even substantially at variance
with the consensus view of the project as a whole.

> The TC isn't going to be able to add anything here.  We have similar
> biases to the ftp team.  We deal with licenses less often, so they are
> probably even more aware of the issues than we are.
> Having two teams say the same thing isn't going to shut up anyone on
> devel frustrated that we're insisting they do significantly more work.

"Adding" does not necessarily mean disagreeing.  If the TC agrees with
ftpmaster, the TC can still help.

The TC can communicate the status quo more clearly, and provide it
with more legitimacy.  The TC members are focused on communication.
TC members are (or should be) able to reason and write exceptionally
clearly.  The TC has an established mechanism by which it can debate
an issue, vote on it, and publish a clear an authoritative statement
of the collective view.

Now I agree that it would be nice if ftpmaster were better at these
things, but ftpmaster have lots of other things to do besides clear up
these kind of disputes.

Specifically, Pirate has acknowledged the authority of the TC by
asking the TC to intervene.  I think it is possibly even rather
disrespectful to Pirate to suggest that if the TC formally disagrees
with them, they'll continue their campaign on -devel as before.

Absent a radical change in the ftpmaster team's approach to
communicating these kind of decisions, the only other way we are going
to settle this is a GR.

To put it another way: could you (the TC) please at least _try_ to
help ?  If it doesn't work then little harm is done.

Ian.

Re: Bug#830978: Browserified javascript and DFSG 2

[Sam Hartman]

> "Neil" == Neil Williams  writes:
>> > * 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.

Neil> So you consider that upstream are not fully-qualified users
Neil> somehow and therefore do not get the benefits of the DFSG? If
Neil> the freedoms of users who choose to interact with upstream are
Neil> reduced by choices made within the package then the package is
Neil> breaking the DFSG by penalising a field of endeavour.

Neil, I have a fairly strong negative emotional reaction when I read the
paragraph you wrote.  I'd like to share that because I think if I share
where I'm coming from it will be easier for me to hear you, and easier
to participate calmly.

When I read the above, I'm worried because I think that freedoms I care
about would be limited, and I don't like to see the DFSG reshaped to
limit freedoms.
I'm afraid when I think I hear us seeding the contents of Debian to
upstream.  We are Debian; we choose what Debian is.

I want to stress that I think you and I are in agreement on handlebars.

However, I do think the freedom to fork from upstream, to move away from
upstream practices we disagree with is important.

I also think that the freedom to "free," over time software even in
cases where upstream has a non-free source control system, or where
we're having to build up a new form of source code because of
restrictions on what's currently the source code are important.

I do not agree that being an upstream is a field of endeavour.

I do not agree that we must always use the same source code form that
upstream does.  Sometimes upstream is wrong.  Sometimes there are
multiple upstreams.
Sometimes we want to fork.

We do however need to ship the source code we use whatever that is.  It
needs to really be source code.  It needs to be a reasonable form in
which we would choose to make modifications.  If there are other
plausible source forms that are being used (even if some of them are
non-free), and those source forms would make the modifications easier,
that's a strong argument that the software is probably not free as we
propose to ship it.

I do not wish us to make the upstream form of source so special that we
in our best judgment cannot override it.

I do hear your worry that you want to be able to exchange modifications
with upstream.  Without modifications, without free flow of those
modifications, software is not free.  I ask that we have the flexibility
to reject people who aren't actually shipping source they would use to
modify software while accepting people who legitimately disagree about
what the source form is.

Re: Bug#830978: Browserified javascript and DFSG 2

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> I would like to comment briefly on the general idea about the
Ian> TC offering advice and making statements of opinion.


Ian> If someone in authority in the project, such as a maintainer of
Ian> the ftpmasters or the release team, is doing something which
Ian> the TC thinks is wrong, then (if the question is important) I
Ian> think it would be entirely appropriate for the TC to issue a
Ian> statement of opinion, disagreeing with the other authority.

Ian> Conversely, if a contributor has been criticised, they may
Ian> welcome a message of support from the TC.  That may help lay to
Ian> rest an unfounded criticism and save the contributor the energy
Ian> required to wonder whether they're really right, rebut any
Ian> public criticisms, and so on.


Ian> And finally if a question needs authoritative input but the
Ian> relevant authority in Debian has not made a clear decision, TC
Ian> involvement might help get the matter properly resolved.

Agreed on both the first two points.
Also, from the discussion on IRC, it seems fairly clear that most TC
members agree that we can give advice if we wish.

I agree in general on the third point about  authority and clear
decisions, with a lot of emphasis on the "might."
Sometimes that's good, sometimes it is not.


Ian> In this case I think that it would be worth TC members
Ian> considering, for themselves, briefly, and without too much
Ian> back-and-forth enquiry, what their initial assessments of the
Ian> merits of the situation are.

I'm fairly sure that's happened for a majority of the TC members.

Ian> If TC members feel that the submitter of #817092 (Luke, who is
Ian> complaining that the aggregated file is not source, along with
Ian> Ben, Jonas etc.) are right, they could ask the release team and
Ian> the ftpmasters (informally, perhaps) whether the release team
Ian> would welcome a supportive TC intervention.

The release team has indicated that this call is the FTP team's.
The members of the TC and members of the FTP team have talked informally.

Ian> That would allow the TC to help settle this long-running
Ian> question (which keeps coming up on -devel and is frankly quite
Ian> annoying).

So, here's why I personally don't think that would be helpful.
I want to emphasize this is pure Sam, not even Sam making a best guess
at how things might fall out if other people got involved, not me giving
my read on anything else.

As best I can tell, the ftp team has a clear position; it is reflected
in their new rejection FAQ, and in their decisions.

(As an aside, there was a keynote at Debconf talking about how it would
(in the speaker's opinion) be better to get more transparency in that.  Based 
on what I heard at
the keynote I think getting the TC involved in that would slow it
down/make it more political)

I haven't seen a lot of doubt expressed from the ftp team about what its
policies are.  You see careful language from people not wanting to step
on each others' toes, but they are all saying the same thing.

Having an outsider to the process like the TC say something isn't going
to help in a case where there is already fairly good internal consensus
and not a lot of doubt.

I think the reason this comes up on -devel is that there may not be a
consensus project-wide, and if there is a rough consensus project-wide
on  this issue, it's really on the rough side.

In general, I think that those who spend a lot of time in Debian are
more radically pro-free-software than the developers as a whole.  That
is, folks on the TC, the DPL, the ftp team, etc are probably not
representative of the developers overall.  I think we've seen this when
we've taken things like getting rid of non-free or binary firmware to a
GR.  The project is clearly pro-free-software, but also fairly clearly
pro-getting-stuff-done-for-real-users even when that gets messy with
regard to free software.

Part of having good governance is to have those discussions on devel.
You have an honest disagreement between parts of your community--between
the people deciding and the people affected by the decisions.
That's not inherently a sign that the people deciding are wrong: Debian
culturally chooses to give significant power to those doing the work.

The TC isn't going to be able to add anything here.  We have similar
biases to the ftp team.  We deal with licenses less often, so they are
probably even more aware of the issues than we are.
Having two teams say the same thing isn't going to shut up anyone on
devel frustrated that we're insisting they do significantly more work.

We also need to continue to pay attention to those discussions and bugs
filed like this.  If we
find that the overall project unhappiness with the balance we strike is
growing, we need to do something.

That said, my personal opinion about this issue is 

Re: Bug#830978: Browserified javascript and DFSG 2

[Neil Williams]

On Fri, 15 Jul 2016 23:45:01 +0530
Pirate Praveen  wrote:

> On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson
>  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 

Re: Bug#830978: Browserified javascript and DFSG 2

[Philip Hands]

Pirate Praveen  writes:

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

Am I right in thinking that this change in the upstream source:

  
https://github.com/wycats/handlebars.js/commit/08781798f564a68abee11c74e2b98272657b2a56#diff-a13581e6dfc1c61c90703da188230cbcR123

becomes this change in the ruby gem that subsequently goes into the package:

  
https://github.com/leshill/handlebars_assets/commit/53443fa7f92c011714bd6aa5831be6074131cfca#diff-49dc26dc0a147a52074ac39c72bd99b1R2119

and if so, are you really trying to claim that these are
indistinguishable as far as anyone working on the code
might be concerned?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#830978: Browserified javascript and DFSG 2

[Pirate Praveen]

On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson  
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 

Re: Bug#830978: Browserified javascript and DFSG 2

[Ian Jackson]

Ian Jackson writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> I would like to comment briefly

I'm sorry that I so evidently failed !

Ian.

Re: Bug#830978: Browserified javascript and DFSG 2

[Ian Jackson]

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.

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.

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

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

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

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


I think this would help save debian-devel a lot of annoying threads.

Ian.

Re: Bug#830978: Browserified javascript and DFSG 2

[Sam Hartman]

Hi.

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.

It doesn't sound like you are looking for help trying to understand
another position.  As I read your message, you understand  what is being
said,you just don't agree with it.
There seems to be general agreement within the TC that it makes sense to
close the bug, effectively saying that it doesn't sound like there is
anything for the TC to do here.


Based on my reading of the discussion, I plan to close the bug some time
next week unless at that time there have been further developments.

I'd especially hold off if a TC member wants to discuss giving
particular advice.  It sounds like some TC members will be skeptical of
doing that, but I'd love to hear the argument.

If the bug gets closed, it will be a soft close--we wouldn't mind the
issue being reopened if there is new information, or a new formulation
of a question, etc.

--Sam

Re: Bug#830978: Browserified javascript and DFSG 2

[Emilio Pozuelo Monfort]

Hi,

On 13/07/16 17:43, Don Armstrong wrote:
> On Wed, 13 Jul 2016, Sam Hartman wrote:
>> However, here we're asked to give advice on whether something is
>> source code. Is the question of what is the source code for a given
>> package technical, and thus within our remit?
> 
> I think that's a narrow enough technical question for us to exercise
> 6.1.1 or 6.1.4, but I think the original decision on this question
> involves the ftpmasters (who have already accepted this package, but
> possibly without addressing this issue) or the release managers (who
> don't appear to have made a decision as to whether this bug is RC or
> not).
> 
> I'd certainly be more comfortable if the ftpmasters and release managers
> would weigh in here.

The release team position on this is:

"All content in main and contrib must meet the DFSG, both in .debs and
in the source (including the .orig.tar.gz)"

(From https://release.debian.org/stretch/rc_policy.txt).

Which I think is perfectly sensible and reasonable, and I doubt there is any
controversy on that.

Now the question is whether this particular code is "source" or not. I think
that is up to the ftp team to decide.

Cheers,
Emilio