Debian Bug report logs - #830978

Browserified javascript and DFSG 2

Reported by: Pirate Praveen <praveen@debian.org> Date: Wed, 13 Jul 2016 13:54:01 UTC Severity: normal Done: Sam Hartman <hartmans@debian.org> Bug is archived. No further changes may be made.

Toggle useless messages

Report forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 13:54:05 GMT) (full text, mbox, link).

Acknowledgement sent to Pirate Praveen <praveen@debian.org> :

New Bug report received and forwarded. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 13:54:05 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Pirate Praveen <praveen@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 19:20:15 +0530

package: tech-ctte Background: Javascript on the server (with nodejs) uses modules to split libraries, but using the same on browser requires combining these modules to single file. DFSG Section 2 [1] gives requirement for source code "Source Code The program must include source code, and must allow distribution in source code as well as compiled form." Browserified files are readable and editable javascript files. I believe this meets DFSG 2 requirements. Someone who is familiar with javascript can easily modify and run modified versions. Some believe this is not enough and the tool required to browserify should be in debian so we can integrate patches from upstream and also send patches upstream (they expect patches against original split module instead of the browserified file). [2][3][4]. The tool required for browserifying is grunt and it has long chain of dependencies and has not been packaged yet.[5] Those who care about the issue should help package grunt instead of using DFSG as a way of blocking perfectly Free Software (with ability to use, modify, share and distribute changes), albeit with some extra effort to port patches. I agree with the concern, but not with the severity. I think the severity should be 'important', instead of 'serious'. I consider the situation as simliar to maintaining an older release or forking (wodim for example) or a hostile upstream that does not want their software packaged at all (like diaspora). In all those cases upstream will not accept a patch against the version shipped in debian and will need extra work to adapt the patches to latest vcs tree. I don't think preferred format of upstream to accept patches should not be a criteria to keep a package away from main. I request CTTE to make a ruling on this issue. Thanks Praveen [1] https://www.debian.org/social_contract [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817092 [3] https://lists.debian.org/debian-devel/2016/07/msg00238.html [4] https://lists.debian.org/debian-devel/2016/07/msg00255.html [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 14:18:08 GMT) (full text, mbox, link).

Acknowledgement sent to Sam Hartman <hartmans@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 14:18:08 GMT) (full text, mbox, link).

Message #10 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 10:15:16 -0400

So, my first question is whether this is a matter that it's reasonable for the TC to rule on. I definitely think we're not an appropriate body to rule on a question like whether a particular license is DFSG free. 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'd be very interested in opinions on this.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 14:30:03 GMT) (full text, mbox, link).

Acknowledgement sent to "Paul R. Tagliamonte" <paultag@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 14:30:03 GMT) (full text, mbox, link).

Message #15 received at 830978@bugs.debian.org (full text, mbox, reply):

From: "Paul R. Tagliamonte" <paultag@gmail.com> To: Sam Hartman <hartmans@debian.org>, 830978@bugs.debian.org, Luca Falavigna <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 10:26:16 -0400

Traditionally, ftpteam has had to take this role, since it is the body that decides if an upload is fit for main. I am one of those folks that treat minified JS as binary, since things like removing comments and renaming variables to `a`, `b` `c` is done. Dead code can also be trimmed (closure compiler). In my mind it's not hugely different than compiling nasm to an ELF. It may relate closely, but it's not how you'd modify it. Upstreams don't modify it in minified form. And just because you can ghex an ELF to fix an asm bug, that doesn't make it the correct way for us to ship code. I haven't talked in-depth with the rest of the ftpteam, but I assume they agree. CC'ing in case there's an objection. Not completely sure why this was filed with TC Paul On Wed, Jul 13, 2016 at 10:15 AM, Sam Hartman <hartmans@debian.org> wrote: > So, my first question is whether this is a matter that it's reasonable > for the TC to rule on. > > > I definitely think we're not an appropriate body to rule on a question > like whether a particular license is DFSG free. > > 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'd be very interested in opinions on this. > -- :wq

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 14:57:13 GMT) (full text, mbox, link).

Acknowledgement sent to Philipp Kern <pkern@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 14:57:13 GMT) (full text, mbox, link).

Message #20 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Philipp Kern <pkern@debian.org> To: "Paul R. Tagliamonte" <paultag@gmail.com>, 830978@bugs.debian.org Cc: Sam Hartman <hartmans@debian.org>, Luca Falavigna <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 16:52:34 +0200

On 2016-07-13 16:26, Paul R. Tagliamonte wrote: > Traditionally, ftpteam has had to take this role, since it is the body > that decides if an upload is fit for main. > > I am one of those folks that treat minified JS as binary, since things > like removing comments and renaming variables to `a`, `b` `c` is done. > Dead code can also be trimmed (closure compiler). In my mind it's not > hugely different than compiling nasm to an ELF. It may relate closely, > but it's not how you'd modify it. > > Upstreams don't modify it in minified form. And just because you can > ghex an ELF to fix an asm bug, that doesn't make it the correct way > for us to ship code. > > I haven't talked in-depth with the rest of the ftpteam, but I assume > they agree. CC'ing in case there's an objection. > > Not completely sure why this was filed with TC Because this isn't about minification. It's about collating multiple files into one, still resembling source code. Kind regards Philipp Kern

Added indication that bug 830978 blocks 817092 Request was from Pirate Praveen <praveen@debian.org> to control@bugs.debian.org . (Wed, 13 Jul 2016 15:06:04 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 15:30:08 GMT) (full text, mbox, link).

Acknowledgement sent to Sam Hartman <hartmans@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 15:30:08 GMT) (full text, mbox, link).

Message #27 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org> To: "Paul R. Tagliamonte" <paultag@gmail.com> Cc: 830978@bugs.debian.org, Luca Falavigna <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 11:27:10 -0400

>>>>> "Paul" == Paul R Tagliamonte <paultag@gmail.com> writes: Paul> Traditionally, ftpteam has had to take this role, since it is Paul> the body that decides if an upload is fit for main. Paul> I am one of those folks that treat minified JS as binary, Paul> since things like removing comments and renaming variables to Paul> `a`, `b` `c` is done. Dead code can also be trimmed (closure Paul> compiler). In my mind it's not hugely different than compiling Paul> nasm to an ELF. It may relate closely, but it's not how you'd Paul> modify it. Paul, ftpmaster, would you be willing to give us a bit of time to figure out if there's anything here for the TC to get involved in before we jump into reopening the discussion of what is source code? I'd hate to be a week into a long involved discussion and then realize that the bug is in the wrong place. --Sam

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 15:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to "Paul R. Tagliamonte" <paultag@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 15:33:03 GMT) (full text, mbox, link).

Message #32 received at 830978@bugs.debian.org (full text, mbox, reply):

From: "Paul R. Tagliamonte" <paultag@gmail.com> To: Sam Hartman <hartmans@debian.org> Cc: 830978@bugs.debian.org, Luca Falavigna <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 11:29:46 -0400

I would love nothing more than to do other things :) Have at it! Paul On Wed, Jul 13, 2016 at 11:27 AM, Sam Hartman <hartmans@debian.org> wrote: >>>>>> "Paul" == Paul R Tagliamonte <paultag@gmail.com> writes: > > Paul> Traditionally, ftpteam has had to take this role, since it is > Paul> the body that decides if an upload is fit for main. > > Paul> I am one of those folks that treat minified JS as binary, > Paul> since things like removing comments and renaming variables to > Paul> `a`, `b` `c` is done. Dead code can also be trimmed (closure > Paul> compiler). In my mind it's not hugely different than compiling > Paul> nasm to an ELF. It may relate closely, but it's not how you'd > Paul> modify it. > > Paul, ftpmaster, would you be willing to give us a bit of time to figure > out if there's anything here for the TC to get involved in before we > jump into reopening the discussion of what is source code? > I'd hate to be a week into a long involved discussion and then realize > that the bug is in the wrong place. > --Sam -- :wq

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 15:54:08 GMT) (full text, mbox, link).

Message #35 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org> To: Pirate Praveen <praveen@debian.org>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 10:43:34 -0500

On Wed, 13 Jul 2016, Pirate Praveen wrote: > Browserified files are readable and editable javascript files. I > believe this meets DFSG 2 requirements. Someone who is familiar with > javascript can easily modify and run modified versions. [...] > I don't think preferred format of upstream to accept patches should not > be a criteria to keep a package away from main. > > I request CTTE to make a ruling on this issue. Could you clarify what the precise question is that you'd like the CTTE to answer? Are you asking the CTTE to make a non-binding formal announcement using 6.1.5 as to whether, in the opinion of the CTTE, browerified source is source under the DFSG? Or are you asking us to potentially overrule the ftpmasters inclusion of libjs-handlebars? Or potentially overrule the release managers determination of whether this particular bug is RC or not? On Wed, 13 Jul 2016, Sam Hartman wrote: > I definitely think we're not an appropriate body to rule on a question > like whether a particular license is DFSG free. I agree. We can make a statement, but that's about it. > 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. -- Don Armstrong https://www.donarmstrong.com "You have many years to live--do things you will be proud to remember when you are old." -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 16:24:10 GMT) (full text, mbox, link).

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 16:24:10 GMT) (full text, mbox, link).

Message #40 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Jonas Smedegaard <dr@jones.dk> To: Pirate Praveen <praveen@debian.org>, 817092@bugs.debian.org Cc: 830978@bugs.debian.org Subject: Re: [Pkg-javascript-devel] Bug#817092: this browserified Date: Wed, 13 Jul 2016 18:21:55 +0200

Hi Praveen, and others, Quoting Jonas Smedegaard (2016-07-10 19:41:17) > Quoting Pirate Praveen (2016-07-10 18:40:53) > > This is not a minified file, only browserified. Though ideally we > > should browserify it in debian, grunt is still not packaged. Since its > > still a human readable and modifiable format, I don't think DFSG > > applies here. > > The requirement of source format of redistributed code is not about it > being possible/easy to edit by those receiving it¹, but about it being > in the format preferred by _upstream_ to edit - e.g. for passing patches > upstream. > > If "browserifying" is a process simple to apply and revert, then ship > the code _not_ browserified and browserify during install (yes, I > understand that the tool upstream uses for that process is not yet in > Debian - which either means you need to imitate that process or that it > is _not such simple process). Above from bug#817092 is possibly what Praveen paraphrased in bug#830978 as "Some believe [included files being readable and editable] is not enough and the tool required to browserify should be in debian". For the record, my point was and is *not* that upstream process should be used¹ - I even explicitly mention an alternative in above quote. My point (also spelled out in first paragraph above) is that "source" is not had by files being "readable and editable". - Jonas ¹ at least not for DFSG compliance. Might make sense for other reasons, e.g. (when result is not identical) that upstream process has had more eyeballs and is therefore arguably preferred for security reasons. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 16:39:13 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 16:39:13 GMT) (full text, mbox, link).

Message #45 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org> To: Pirate Praveen <praveen@debian.org>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 17:37:11 +0100

On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote: > Or are you asking us to potentially overrule the ftpmasters inclusion > of libjs-handlebars? Or potentially overrule the release managers > determination of whether this particular bug is RC or not? [...] > I'd certainly be more comfortable if the ftpmasters and release > managers would weigh in here. On the concrete case of libjs-handlebars: the JS files we distribute seem to be generated by a parser-generator and thus certainly shouldn't qualify as source. I filed a seperate bug for this to keep it apart from the browserification issue, see [1]. [1] https://bugs.debian.org/830986 The ftp team can only catch shipping generated source by chance as we mostly just look at license headers. Avoiding such issues by using what upstream considers "source" already counts as a good reason to me. For the general case, I haven't yet looked into what "browserified" means exactly, but from skimming over the discussion on -devel@ it sounded like it was a glorified "cat"? In that case shouldn't one be able to easily use "cat" instead of "grunt" to build the package from the files upstream considers source? If it is more than "cat", some more information would be helpful. Ansgar

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 16:48:11 GMT) (full text, mbox, link).

Acknowledgement sent to Keith Packard <keithp@keithp.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 16:48:11 GMT) (full text, mbox, link).

Message #50 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com> To: "Paul R. Tagliamonte" <paultag@gmail.com>, 830978@bugs.debian.org, Sam Hartman <hartmans@debian.org>, 830978@bugs.debian.org, Luca Falavigna <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 09:39:40 -0700

"Paul R. Tagliamonte" <paultag@gmail.com> writes: > Traditionally, ftpteam has had to take this role, since it is the body > that decides if an upload is fit for main. Yup. > I haven't talked in-depth with the rest of the ftpteam, but I assume > they agree. CC'ing in case there's an objection. > > Not completely sure why this was filed with TC Neither am I, but if the ftpteam wants advice from the TC on this issue, we'd be happy to oblige. It doesn't seem like there's any serious argument that the 'compiled' javascript delivered is DSFG-free though. -- -keith

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 17:15:13 GMT) (full text, mbox, link).

Acknowledgement sent to Pirate Praveen <praveen@onenetbeyond.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 17:15:13 GMT) (full text, mbox, link).

Message #55 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Pirate Praveen <praveen@onenetbeyond.org> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 22:42:47 +0530

On Wed, 13 Jul 2016 10:43:34 -0500 Don Armstrong <don@debian.org> wrote: > On Wed, 13 Jul 2016, Pirate Praveen wrote: > > Browserified files are readable and editable javascript files. I > > believe this meets DFSG 2 requirements. Someone who is familiar with > > javascript can easily modify and run modified versions. > > [...] > > > I don't think preferred format of upstream to accept patches should not > > be a criteria to keep a package away from main. > > > > I request CTTE to make a ruling on this issue. > > Could you clarify what the precise question is that you'd like the CTTE > to answer? > > Are you asking the CTTE to make a non-binding formal announcement using > 6.1.5 as to whether, in the opinion of the CTTE, browerified source is > source under the DFSG? Yes. > Or are you asking us to potentially overrule the ftpmasters inclusion of > libjs-handlebars? No. I want to keep libjs-handlebars in the archive. > Or potentially overrule the release managers > determination of whether this particular bug is RC or not? Yes, this would be a result of first question (whether browserified source is dfsg free). If browserified source is dfsg free, this bug cannot be rc. > On Wed, 13 Jul 2016, Sam Hartman wrote: > > I definitely think we're not an appropriate body to rule on a question > > like whether a particular license is DFSG free. > > I agree. We can make a statement, but that's about it. The issue is not about license. > > 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 approached ctte because I thought it was a technical question. Whether browserified (mostly conatenated and slightly rearranged code) can be considered source. I have no objection to removing minified code (which renames variables, removes white spaces etc and makes it unreadable and impossible to debug or patch). I have seen some folks mixing these two issues. I also agree its not an ideal solution, but my contention is about its severity. > 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. > > -- > Don Armstrong https://www.donarmstrong.com > > "You have many years to live--do things you will be proud to remember > when you are old." > -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413) > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 13 Jul 2016 18:15:08 GMT) (full text, mbox, link).

Acknowledgement sent to Don Armstrong <don@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 13 Jul 2016 18:15:08 GMT) (full text, mbox, link).

Message #60 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org> To: Pirate Praveen <praveen@onenetbeyond.org>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 13 Jul 2016 13:12:11 -0500

On Wed, 13 Jul 2016, Pirate Praveen wrote: > On Wed, 13 Jul 2016 10:43:34 -0500 Don Armstrong <don@debian.org> wrote: > > Are you asking the CTTE to make a non-binding formal announcement > > using 6.1.5 as to whether, in the opinion of the CTTE, browerified > > source is source under the DFSG? > > Yes. [...] > > Or potentially overrule the release managers determination of > > whether this particular bug is RC or not? > > Yes, this would be a result of first question (whether browserified > source is dfsg free). If browserified source is dfsg free, this bug > cannot be rc. If we addressed the first question (non-binding announcement), the release managers could still decide differently. The RMs are the people who decide whether a bug is RC or not. The RMs can decide to delegate the decision to us, but I don't think that the CTTE is able to decide this without the RMs making the first decision. -- Don Armstrong https://www.donarmstrong.com The sheer ponderousness of the panel's opinion [...] refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it---and is just as likely to succeed. -- Alex Kozinski, Dissenting in Silveira v. Lockyer (CV-00-00411-WBS p5983-4)

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Thu, 14 Jul 2016 15:42:09 GMT) (full text, mbox, link).

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 14 Jul 2016 15:42:09 GMT) (full text, mbox, link).

Message #65 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org> To: 830978@bugs.debian.org Cc: debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Thu, 14 Jul 2016 17:39:04 +0200

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

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Fri, 15 Jul 2016 09:45:04 GMT) (full text, mbox, link).

Acknowledgement sent to Sam Hartman <hartmans@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 15 Jul 2016 09:45:04 GMT) (full text, mbox, link).

Message #70 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org> To: Emilio Pozuelo Monfort <pochu@debian.org> Cc: 830978@bugs.debian.org, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Fri, 15 Jul 2016 05:43:26 -0400

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

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Fri, 15 Jul 2016 17:21:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 15 Jul 2016 17:21:04 GMT) (full text, mbox, link).

Message #75 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk> To: Sam Hartman <hartmans@debian.org>, 830978@bugs.debian.org Cc: Emilio Pozuelo Monfort <pochu@debian.org>, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Fri, 15 Jul 2016 18:16:51 +0100

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.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Fri, 15 Jul 2016 17:21:06 GMT) (full text, mbox, link).

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 15 Jul 2016 17:21:06 GMT) (full text, mbox, link).

Message #80 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk> To: Sam Hartman <hartmans@debian.org>, 830978@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Fri, 15 Jul 2016 18:17:36 +0100

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.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Fri, 15 Jul 2016 18:18:04 GMT) (full text, mbox, link).

Acknowledgement sent to Pirate Praveen <praveen@onenetbeyond.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 15 Jul 2016 18:18:04 GMT) (full text, mbox, link).

Message #85 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Pirate Praveen <praveen@onenetbeyond.org> To: Ian Jackson <ijackson@chiark.greenend.org.uk>,830978@bugs.debian.org,Sam Hartman <hartmans@debian.org> Cc: Emilio Pozuelo Monfort <pochu@debian.org>,debian-release <debian-release@lists.debian.org>,FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Fri, 15 Jul 2016 23:45:01 +0530

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.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Fri, 15 Jul 2016 21:33:08 GMT) (full text, mbox, link).

Acknowledgement sent to Philip Hands <phil@hands.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 15 Jul 2016 21:33:08 GMT) (full text, mbox, link).

Message #90 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com> To: Pirate Praveen <praveen@onenetbeyond.org>, 830978@bugs.debian.org Cc: debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Fri, 15 Jul 2016 23:24:57 +0200

Pirate Praveen <praveen@onenetbeyond.org> 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

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Fri, 15 Jul 2016 23:06:04 GMT) (full text, mbox, link).

Acknowledgement sent to Neil Williams <codehelp@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 15 Jul 2016 23:06:04 GMT) (full text, mbox, link).

Message #95 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org> To: Pirate Praveen <praveen@onenetbeyond.org> Cc: 830978@bugs.debian.org, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Sat, 16 Jul 2016 00:02:55 +0100

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/

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sat, 16 Jul 2016 09:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sam Hartman <hartmans@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 16 Jul 2016 09:21:04 GMT) (full text, mbox, link).

Message #100 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org> To: Ian Jackson <ijackson@chiark.greenend.org.uk> Cc: 830978@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Sat, 16 Jul 2016 05:16:25 -0400

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> 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 that it is a datapoint, not a trend. In closing, I hear Pirate's hope that we have a project in which we can fork software, and that the preferred form of source code can shift over time for given software. It's clear to me that the ftp team folks I've talked to and the TC are all sensitive to this issue. We are humans making subjective interpretations, and we can deal with those sorts of situations. For example if the handlebars gem community had a vibrant culture of patching the aggregated form, I would consider that aggregate the source code for this package. However, as it stands, i think a more realistic interpretation is that the handlebars gem is not really in the business of changing handlebars much and as such doesn't include source for handlebars, only the handlebars aggregate. Yes, members of the TC did look at things like how often the aggregate was changed in the gem's git and what form those changes took in making up their individual minds. Past ftp team decisions make it clear that ftpmaster is willing to listen to arguments like that.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sat, 16 Jul 2016 10:54:07 GMT) (full text, mbox, link).

Acknowledgement sent to Sam Hartman <hartmans@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 16 Jul 2016 10:54:07 GMT) (full text, mbox, link).

Message #105 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org> To: Neil Williams <codehelp@debian.org> Cc: Pirate Praveen <praveen@onenetbeyond.org>, 830978@bugs.debian.org, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Sat, 16 Jul 2016 06:49:56 -0400

>>>>> "Neil" == Neil Williams <codehelp@debian.org> 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.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sat, 16 Jul 2016 13:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 16 Jul 2016 13:33:03 GMT) (full text, mbox, link).

Message #110 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk> To: Sam Hartman <hartmans@debian.org> Cc: 830978@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Sat, 16 Jul 2016 14:28:29 +0100

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.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sat, 16 Jul 2016 13:42:20 GMT) (full text, mbox, link).

Acknowledgement sent to Neil Williams <codehelp@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 16 Jul 2016 13:42:20 GMT) (full text, mbox, link).

Message #115 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org> To: Sam Hartman <hartmans@debian.org> Cc: Pirate Praveen <praveen@onenetbeyond.org>, 830978@bugs.debian.org, debian-release <debian-release@lists.debian.org>, FTP masters <ftpmaster@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Sat, 16 Jul 2016 14:41:34 +0100

On Sat, 16 Jul 2016 06:49:56 -0400 Sam Hartman <hartmans@debian.org> wrote: > >>>>> "Neil" == Neil Williams <codehelp@debian.org> 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/

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sun, 17 Jul 2016 20:57:08 GMT) (full text, mbox, link).

Acknowledgement sent to Uoti Urpala <uoti.urpala@pp1.inet.fi> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sun, 17 Jul 2016 20:57:08 GMT) (full text, mbox, link).

Message #120 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Sun, 17 Jul 2016 23:55:56 +0300

On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams <codehelp@debian.org> wrote: > On Fri, 15 Jul 2016 23:45:01 +0530 > Pirate Praveen <praveen@onenetbeyond.org> wrote: >> 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. I think the part about packaging only VCS HEAD is an excellent point, and really needs to be addressed by people who want to argue that concatenating files should be an RC bug. > Where do you get this crazy and fanciful notion that upstream are > somehow second-class community members? Upstream are users of the I don't think he was saying that at all. If I consider this from an upstream point of view, I'd say that the packaging being behind latest upstream version is a more significant issue than the packaging using source transformations like concatenating files. People who want to make large, complex changes are likely to use upstream files directly anyway, so that limits the extra work caused by working around such transformations. Packaging old versions causes similar issues for patches based on outdated code, and additionally several other issues, like preventing upstream from getting timely feedback about changes and causing upstream to receive complaints about already fixed bugs. In essence, my central point is that you cannot consistently believe BOTH of these: * packaging not being up to date with latest upstream is just a wishlist bug * packaging concatenating source files is such a horrible bug that the package should be removed from Debian If you want to argue "upstream convenience" as a reason for the second, then you must also accept that being behind latest upstream is a lot more serious than wishlist. If the TC wants to make a statement against concatenating files, then I hope any such statement also mentions that being behind latest upstream should be considered an equally serious bug. If the TC is not willing to consider such an addition, then they should IMO also reconsider whether it's really valid to use upstream preferences as a justification for such a statement at all.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sun, 17 Jul 2016 22:09:08 GMT) (full text, mbox, link).

Acknowledgement sent to Tony Hoffman <tonyhoff@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sun, 17 Jul 2016 22:09:08 GMT) (full text, mbox, link).

Message #125 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Tony Hoffman <tonyhoff@gmail.com> To: 830978@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi> Cc: 830977@bugs.debian.org Subject: RE: tonyhoff,Boost Your Credit Today Date: Sun, 17 Jul 2016 15:06:33 -0700

Fuck you cock suckers, take me off your list. On Jul 17, 2016 3:05 PM, "RapidCreditSolutions" <uotiurpala@pp1.inet.fi> wrote: > Don't Let Your Credit Score Hold You Back > Check-Now > <http://alonbuy.com/34ott.Y8Z.DOEoa.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R5>

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sun, 17 Jul 2016 22:15:10 GMT) (full text, mbox, link).

Acknowledgement sent to Ayanna Wright <ayannawright96@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sun, 17 Jul 2016 22:15:10 GMT) (full text, mbox, link).

Message #130 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ayanna Wright <ayannawright96@gmail.com> To: 830978@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi> Subject: RE: ayanna,Boost Your Credit Today Date: Sun, 17 Jul 2016 18:13:06 -0400

How can I check my credit score On Jul 17, 2016 6:05 PM, "RapidCreditSolutions" <uotiurpala@pp1.inet.fi> wrote: > Don't Let Your Credit Score Hold You Back > Check-Now > <http://alonbuy.com/34ots.VRt.CVYvo.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R2>

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sun, 17 Jul 2016 22:15:12 GMT) (full text, mbox, link).

Acknowledgement sent to elle p h <el.pea35@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sun, 17 Jul 2016 22:15:12 GMT) (full text, mbox, link).

Message #135 received at 830978@bugs.debian.org (full text, mbox, reply):

From: elle p h <el.pea35@gmail.com> To: 830978@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi> Subject: RE: el.pea35,Boost Your Credit Today Date: Sun, 17 Jul 2016 18:14:16 -0400

Fuckoff El jul. 17, 2016 6:05 PM, "RapidCreditSolutions" <uotiurpala@pp1.inet.fi> escribió: > Don't Let Your Credit Score Hold You Back > Check-Now > <http://alonbuy.com/34ott.Y8C.DNqXS.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R0>

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sun, 17 Jul 2016 22:36:11 GMT) (full text, mbox, link).

Acknowledgement sent to Debra Laskonis <dlaskonis@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sun, 17 Jul 2016 22:36:11 GMT) (full text, mbox, link).

Message #140 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Debra Laskonis <dlaskonis@gmail.com> To: 830978@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi> Subject: RE: dlaskonis,Boost Your Credit Today Date: Sun, 17 Jul 2016 17:33:47 -0500

Unsubscribe! On Jul 17, 2016 5:05 PM, "RapidCreditSolutions" <uotiurpala@pp1.inet.fi> wrote: > Don't Let Your Credit Score Hold You Back > Check-Now > <http://alonbuy.com/34ott.Y8X.D6VHb.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R4>

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Sun, 17 Jul 2016 23:06:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ben Finney <ben+debian@benfinney.id.au> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sun, 17 Jul 2016 23:06:03 GMT) (full text, mbox, link).

Message #145 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ben Finney <ben+debian@benfinney.id.au> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Mon, 18 Jul 2016 09:02:08 +1000

On 17-Jul-2016, Uoti Urpala wrote: > In essence, my central point is that you cannot consistently believe > BOTH of these: > * packaging not being up to date with latest upstream is just a > wishlist bug > * packaging concatenating source files is such a horrible bug that the > package should be removed from Debian > > If you want to argue "upstream convenience" as a reason for the > second, Maybe if that were the only justification offered. That's not the case though. Reading the discussion on debian-devel, and even reading the discussion in this bug report, the argument for the source form of the work rests on *whether* the form of the work allows modification on an equal basis with upstream. Neil Williams puts it well in this same bug report: 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. <URL:https://bugs.debian.org/830978#95> Nothing about “upstream convenience” there. It's about equal access, for all recipients of the work, to make and share their own build from the source form of the work. That entails receiving the work in such a form, and with all necessary build scripts, to make modifications (or choose not to modify) and build the work themselves to get the same result. That is, in brief, the source form of the work. Without the form of the work that is the *input* to the build tools, and the build tools and script themselves as free software in Debian, then the recipient cannot be said to have what they need to exercise DFSG freedoms. These points have already been made, but maybe not clearly enough so far in this bug report. I hope that helps. -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney <ben@benfinney.id.au>

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Mon, 18 Jul 2016 02:03:04 GMT) (full text, mbox, link).

Acknowledgement sent to Uoti Urpala <uoti.urpala@pp1.inet.fi> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 18 Jul 2016 02:03:04 GMT) (full text, mbox, link).

Message #150 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Mon, 18 Jul 2016 05:00:08 +0300

On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney <ben+debian@benfinney.id. au> wrote: > On 17-Jul-2016, Uoti Urpala wrote: > > If you want to argue "upstream convenience" as a reason for the > > second, > > Maybe if that were the only justification offered. That's not the case > though. > > > Reading the discussion on debian-devel, and even reading the > discussion in this bug report, the argument for the source form of the > work rests on *whether* the form of the work allows modification on an > equal basis with upstream. > > Neil Williams puts it well in this same bug report: > > 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. > > <URL:https://bugs.debian.org/830978#95>; > > Nothing about “upstream convenience” there. That's exactly the post I was replying to, and it does spend a lot of time talking about ability to get the changes upstream - both from upstream point of view and ability of the person doing the changes to get them there. As for this particular quote, the terminology of "a format that can be modified by every user" is not clear at all to me. In what sense couldn't everyone modify the concatenated form? And if you get too picky about preferred format, then that's a git repo, not a tarball. If I want to make upstreamable changes to some software in Debian, then first I clone the upstream git; that's the form I prefer for doing modifications, and the single-version tarball exports Debian distributes are a distinctly inferior form generated from that. > It's about equal access, > for all recipients of the work, to make and share their own build from > the source form of the work. > > That entails receiving the work in such a form, and with all necessary > build scripts, to make modifications (or choose not to modify) and > build the work themselves to get the same result. That is, in brief, > the source form of the work. > > Without the form of the work that is the *input* to the build tools, > and the build tools and script themselves as free software in Debian, > then the recipient cannot be said to have what they need to exercise > DFSG freedoms. You're not really saying anything meaningful here IMO. The recipients would be able to make modifications to a concatenated form and build the work themselves to get the same result. They would have all the necessary build scripts etc to do the work. So what you're talking about here does not in any way imply they wouldn't have the source. Of course, if you've already declared that what they have isn't source then there's a problem - but unless you _start_ from that assumption, what you write above does not give any criteria which could be used to arrive to that conclusion.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Mon, 18 Jul 2016 09:18:03 GMT) (full text, mbox, link).

Acknowledgement sent to Philip Hands <phil@hands.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 18 Jul 2016 09:18:03 GMT) (full text, mbox, link).

Message #155 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com> To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Mon, 18 Jul 2016 11:15:59 +0200

Uoti Urpala <uoti.urpala@pp1.inet.fi> writes: > In what sense couldn't everyone modify the concatenated form? Perhaps if I frame my question from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90 in another way, I'll get an answer. Given the existence of the upstream source, would you really consider editing the value of 'lexer.rules' in the post-grunt output? See: https://github.com/wycats/handlebars.js/commit/08781798f564a68abee11c74e2b98272657b2a56#diff-a13581e6dfc1c61c90703da188230cbcR123 vs: https://github.com/leshill/handlebars_assets/commit/53443fa7f92c011714bd6aa5831be6074131cfca#diff-49dc26dc0a147a52074ac39c72bd99b1R2119 and if so, why would you want to do that? Of course, one could do that, in the same way that one could apply a hex editor to a binary file -- that does not make it source. 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

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Mon, 18 Jul 2016 13:48:04 GMT) (full text, mbox, link).

Acknowledgement sent to Uoti Urpala <uoti.urpala@pp1.inet.fi> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 18 Jul 2016 13:48:04 GMT) (full text, mbox, link).

Message #160 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Mon, 18 Jul 2016 16:45:14 +0300

On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands <phil@hands.com> wrote: > Uoti Urpala <uoti.urpala@pp1.inet.fi> writes: > > > In what sense couldn't everyone modify the concatenated form? > > Perhaps if I frame my question from: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90 > > in another way, I'll get an answer. Isn't this the separate issue Ansgar already mentioned in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#45

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Mon, 18 Jul 2016 16:24:03 GMT) (full text, mbox, link).

Acknowledgement sent to Philip Hands <phil@hands.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 18 Jul 2016 16:24:04 GMT) (full text, mbox, link).

Message #165 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com> To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Mon, 18 Jul 2016 18:10:18 +0200

Uoti Urpala <uoti.urpala@pp1.inet.fi> writes: > On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands <phil@hands.com> wrote: >> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes: >> >> > In what sense couldn't everyone modify the concatenated form? >> >> Perhaps if I frame my question from: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90 >> >> in another way, I'll get an answer. > > Isn't this the separate issue Ansgar already mentioned in: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#45 Ah, I'd missed Ansgar's mail it seems. Thanks for the pointer. I don't see that it is a separate issue though. If one repeatedly argues that something is just a case of concatenation, and therefore should be allowed, and it turns out not to be concatenation at all, then there's no real need to go into worrying if concatenation would have been OK. I can imagine some odd circumstances in which it might be OK to abandon the idea of starting from original source, but this one fails on so many fronts that I was just picking on the most obvious flaw. The fact that all the work is clearly being done in the original source is also pretty damning (I could only find two commits that were not just dumping whatever arrives from upstream, and I'm not convinced either of those were edits to the browserified source -- they look more like patching the upstream and re-doing the grunt bit). 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

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Mon, 18 Jul 2016 17:15:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ricky Sauce <sbprorickysauce@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 18 Jul 2016 17:15:04 GMT) (full text, mbox, link).

Message #170 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ricky Sauce <sbprorickysauce@gmail.com> To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 830978@bugs.debian.org Subject: I need the phone number and a new phone. U screwed mine up Date: Mon, 18 Jul 2016 12:13:06 -0500

I have a voice and I have made a video I'm case something happens to me. U won't find it because I sent it one of the few times I had alone. Why can u use my account , then promise money and yet I haven't seen shitb. Arbitration and all that shot iscourt binding yada yada. But On Monday, July 18, 2016, Ricky Sauce <sbprorickysauce@gmail.com> wrote: > > Or drink or work. You have not given me a penny.not one penny. I'm broke . I'm sick of you teasing and acting like I gonna do sonething6great. Bs > > On Monday, July 18, 2016, Ricky Sauce <sbprorickysauce@gmail.com> wrote: >> >> I'm about sick of this. It's the money part. You have stuck me out and now I think you mean harm. The following wasn't bad until I realized you don't want a person to eat >> >> On Sunday, July 17, 2016, RapidCreditSolutions <uotiurpala@pp1.inet.fi> wrote: >>> <http://alonbuy.com/34ott.Y8D.D3bXw.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R9> >>> Don't Let Your Credit Score Hold You Back <http://alonbuy.com/34ott.Y8D.D3bXw.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R9> >>> Check-Now <http://alonbuy.com/34ott.Y8D.D3bXw.FS.e.O.1.1.1.1.OK.Fa.1.1.1.R9>

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Mon, 18 Jul 2016 17:21:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ricky Sauce <sbprorickysauce@gmail.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 18 Jul 2016 17:21:04 GMT) (full text, mbox, link).

Message #175 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ricky Sauce <sbprorickysauce@gmail.com> To: 830978@bugs.debian.org Subject: Re: Bug#830978: Info received (I need the phone number and a new phone. U screwed mine up) Date: Mon, 18 Jul 2016 12:17:02 -0500

K. Need number for .credit solutions On Jul 18, 2016 12:15 PM, "Debian Bug Tracking System" < owner@bugs.debian.org> wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Technical Committee <debian-ctte@lists.debian.org> > > If you wish to submit further information on this problem, please > send it to 830978@bugs.debian.org. > > Please do not send mail to owner@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 830978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 > Debian Bug Tracking System > Contact owner@bugs.debian.org with problems >

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Tue, 19 Jul 2016 20:39:04 GMT) (full text, mbox, link).

Acknowledgement sent to Helmut Grohne <helmut@subdivi.de> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Tue, 19 Jul 2016 20:39:04 GMT) (full text, mbox, link).

Message #180 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de> To: Ansgar Burchardt <ansgar@debian.org>, 830978@bugs.debian.org Cc: Pirate Praveen <praveen@debian.org> Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Tue, 19 Jul 2016 22:32:11 +0200

On Wed, Jul 13, 2016 at 05:37:11PM +0100, Ansgar Burchardt wrote: > On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote: > > Or are you asking us to potentially overrule the ftpmasters inclusion > > of libjs-handlebars? Or potentially overrule the release managers > > determination of whether this particular bug is RC or not? > [...] > > I'd certainly be more comfortable if the ftpmasters and release > > managers would weigh in here. > > On the concrete case of libjs-handlebars: the JS files we distribute > seem to be generated by a parser-generator and thus certainly shouldn't > qualify as source. I filed a seperate bug for this to keep it apart > from the browserification issue, see [1]. > > [1] https://bugs.debian.org/830986 Now I'm confused as to how we handled Perl (#762638). It has a Configure script that claims[2] to be generated by a configure-generator called metaconfig. A significant part of metaconfig's job (like grunt's) is concatenating snippets, but there are some generated parts (e.g. the variable lists[3]). Neither metaconfig nor the sources for Configure reside in any Debian package[4]. Contrary to their claims[5], upstream doesn't[6] even take patches when they hit the generated parts. To me, this sounds entirely parallel to libjs-handlebars. The one difference that remains is that Perl's Configure really is patched in Debian. I'd assume Pirate Praveen to be able to produce a patch for libjs-handlebars if needed. Wouldn't it be fair to allow libjs-handlebars as is? What is it that makes us treat it differently? Lower popcon? Helmut [2] http://sources.debian.net/src/perl/5.24.0-1/Configure/#L14 [3] http://sources.debian.net/src/perl/5.24.0-1/Configure/#L208 and http://sources.debian.net/src/perl/5.24.0-1/Configure/#L24098 [4] In relevant versions. There is the dist package, but trying to regenerate Perl's Configure with that results in a diff changing half of its lines. [5] Last sentence of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762638#34 [6] https://rt.perl.org/Public/Bug/Display.html?id=124326#txn-1351869

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Tue, 19 Jul 2016 22:33:04 GMT) (full text, mbox, link).

Acknowledgement sent to Don Armstrong <don@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Tue, 19 Jul 2016 22:33:04 GMT) (full text, mbox, link).

Message #185 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org> To: Helmut Grohne <helmut@subdivi.de>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Tue, 19 Jul 2016 17:30:24 -0500

On Tue, 19 Jul 2016, Helmut Grohne wrote: > Now I'm confused as to how we handled Perl (#762638). It has a > Configure script that claims[2] to be generated by a > configure-generator called metaconfig. A significant part of > metaconfig's job (like grunt's) is concatenating snippets, but there > are some generated parts (e.g. the variable lists[3]). Neither > metaconfig nor the sources for Configure reside in any Debian > package[4]. Contrary to their claims[5], upstream doesn't[6] even take > patches when they hit the generated parts. This certainly looks similar, and my gut reaction is that perl's Configure doesn't meet our requirements for source in Debian either. > What is it that makes us treat it differently? Lower popcon? To some extent, yes. There's also the case that the Configure isn't actually part of the binary that is distributed, and can be patched separately, which mitigates the issue of not actually distributing source and carrying around an embedded copy somewhat. I certainly think that both of these are issues that should be fixed... but I'm sympathetic to the idea that we can't kick everything out of the archive, and that some issues of source are bugs that we can release with, and some issues of source are bugs that we cannot release with. [And now that enough people have read this thread, we probably could have re-implemented grunt by now and solved the libjs-handlebars problem.] -- Don Armstrong https://www.donarmstrong.com It can sometimes happen that a scholar, his task completed, discovers that he has no one to thank. Never mind. He will invent some debts. Research without indebtedness is suspect, and somebody must always, somehow, be thanked. -- Umberto Eco "How to Write an Introduction"

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 20 Jul 2016 02:09:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ben Finney <ben+debian@benfinney.id.au> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 20 Jul 2016 02:09:04 GMT) (full text, mbox, link).

Message #190 received at 830978@bugs.debian.org (full text, mbox, reply):

From: Ben Finney <ben+debian@benfinney.id.au> To: Don Armstrong <don@debian.org>, 830978@bugs.debian.org Subject: Re: Bug#830978: Browserified javascript and DFSG 2 Date: Wed, 20 Jul 2016 12:04:54 +1000

On 19-Jul-2016, Don Armstrong wrote: > And now that enough people have read this thread, we probably could > have re-implemented grunt by now and solved the libjs-handlebars > problem. Thanks. I have started a discussion for this on <URL:http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-July/013427.html> the Debian JavaScript maintainers discussion forum. -- \ “One thing vampire children have to be taught early on is, | `\ don't run with a wooden stake.” —Jack Handey | _o__) | Ben Finney <ben@benfinney.id.au>

Added indication that bug 830978 blocks 718367 Request was from Pirate Praveen <praveen@debian.org> to 718367-submit@bugs.debian.org . (Wed, 27 Jul 2016 17:39:05 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#830978 ; Package tech-ctte . (Wed, 27 Jul 2016 17:48:03 GMT) (full text, mbox, link).

Acknowledgement sent to Pirate Praveen <praveen@debian.org> :

Extra info received and forwarded to list. Copy sent