Your message dated Thu, 28 Jul 2016 15:37:54 -0400 with message-id <tsld1lxeep9....@mit.edu> and subject line Re: Bug#830978: Browserified javascript and DFSG 2 has caused the Debian Bug report #830978, regarding Browserified javascript and DFSG 2 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 830978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---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
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---At today's meeting the technical committee decided to close this issue. My understanding of our rationale is as follows: The FTP team is responsible for determining if a package meets the requirements of DFSG, including whether the source code meets the conditions of DFSG #2: 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. The Release team is responsible for determining whether a particular bug is release critical. The Release team has decided that compliance with the DFSG is release critical and has deferred the determination of DFSG compliance to the FTP team [1] [1] https://lists.debian.org/016cfb0b-076a-9f8f-3b4b-7d3190e5c...@debian.org With regard to the particular issue of Browserified javascript, particularly in the libjs-handlebars package, the best way forward is for the submitter to discuss the question with the FTP team. Such a discussion would be less confusing if it took place after #830986 is resolved. In accordance with another discussion today, any member of the project can reopen the bug and ask for a formal vote. In this instance, I'd recommend reading the logs of the meeting before doing that.
--- End Message ---
