On Thu, 27 Oct 2011 09:08:37 +0200, Raphael Hertzog <hertzog@debian.org> wrote: > On Thu, 27 Oct 2011, Paul Wise wrote: > > On Thu, Oct 27, 2011 at 1:08 AM, Raphael Hertzog wrote: > > > I don't agree that minified files are a violation of DFSG #2. If the > > > library is under the GPL then it would be a problem because it's not the > > > preferred form of modification. > > > > I think this is exactly the same as xserver-xorg-video-nv, which > > contained obfuscated C code instead of the actual source code. I > > personally considered that a DFSG violation but I guess you would not? > > I would consider it a DFSG violation. It's all a matter of intent. I don't think we should use the author's intent when trying to determine of a work of software is DFSG free. I don't think we have a good reason to make such a compromise. > Obfuscated != minified. > > In one case we have unreadable C code where you don't have access to > the unobfuscated version and this was done on purpose by the upstream > authors to make it difficul to understand what the code does. In this case we have unreadable javascript code where you don't know whether or not you have access to the unobfuscated version or not and although this may or may not have been done on purpose by the authors to make it more difficult to understand, it has that effect regardless. > > In the other case you have unreadable javascript code but you can easily > find the corresponding source code on numerous places (sometimes in the > corresponding Debian package, sometimes in an older version of it on > snapshot.debian.org and generally on its upstream website). The > minification was not even done by the upstream that uses that file but > by the original project who delivers both files. The minification is not > done to make it more difficult to understand the code or make changes, but > to save time when downloading the file. > > Requiring the non-minified file to be provided in the same source package > is not a very productive use of our time. In particular if you don't go > to the step beyond which is to modify the upstream build process to > regenerate the minified file from the original one. Otherwise modifying > that file in the source and rebuilding it does not have the expected > result. In the case where the code is generated from source code in another package, it seems to make sense to me to package this separately. I think we need to have the 'preferred form of modification' available to the end user in order to comply with the spirit of the DFSG. I also don't think it is feasible to expect that the FTP team would go searching for other projects and try to find the minified version of the javascript file in some other project then try to determine if it is actually generated from its source before deciding if we are complying with the spirit of the DFSG. To me, telling the user that the minified javascript is usable and editable as source is close to saying "yeah, we don't have the C code that generated this but you can disassemble it and edit the asm." I agree that it is more useful to the user if we make sure that the minimized javascript be able to be regenerated when you edit the source and rebuild. > > I think it's great to encourage this sane behaviour, but it's not a > bug that's worth a serious severity. > > > What is the preferred form for modification for a work (aka source) is > > highly context-dependent. > > I share entirely the opinion of Russ who replied to this specific point. > Am I misreading you? or are you making an argument here that it might be preferred to edit minimized javascript instead of the original? stew
Attachment:
pgpgLbQP8lp3v.pgp
Description: PGP signature