2014-03-27 0:13 GMT+01:00 Ben Finney <ben+deb...@benfinney.id.au>: > Jonas Smedegaard <d...@jones.dk> writes: > >> DFSG #2: >> >> > The program must include source code, and must allow distribution in >> > source code as well as compiled form. >> >> I believe the term "source code" is in Debian generally interpreted as >> "preferred form of modification". > > (That should be “preferred form of the work for modifying it”. I don't > know what “form of modification” would be.) > >> You may disagree with that interpretation, but that's where you should >> then argue your case - not at definition of "minification" or >> "compilation". > > Indeed. Any transformation – minification, obfuscation, compilation, > encryption, etc. – which makes a form of the work which is not the > preferred form of the work for modifying that work, thereby makes a > non-source form of the work. > > So the distinction being discussed is source versus non-source form of > the work.
Let's take the example of jquery-lazyload [0]. Both these files are provided in the upstream tarball: - jquery.lazyload.js - jquery.lazyload.min.js With the second one being the minified form of the first one. We've got an implicit statement from upstream that the minified file comes from the source file: - same base name - distributed together - updated in the VCS for each release We could ask for an explicit statement from upstream that they are minifying the source file, although I wouldn't suggest doing this. Also, the minified file contains copyright information, indicating that that file is MIT licenced (the upstream author explicitly indicates that this file can be redistributed legally on its own) To take another example: .jpg images. - those are not the source of the image (would be e.g. a Gimp project file) - they are "obfuscated" binary content (no human can read the content of a jpg file and tell you what it represents) - there is no copyright information embedded in the file itself - a .jpg is not the preferred form of the work for modifying that work (quality issues) - and even "worse": Yet we redistribute those binary sourceless files in the binary package based (if the maintainer did his due diligence) on the upstream developer indicating these files are licensed under a DFSG-approved license. If (as we do for .jpg) we accept non-source files based on their licensing information, and even use them as such in the binary package, I don't see how worse it would be to leave a minified file (which has it's explicit copyright notice embedded!) in the orig tarball, and rebuild it on our side to absolutely rule out any evil action or omission of update on upstream's side. I would argue that having minified files in the upstream tarball is no reason for repackaging. Those files are released under the same license as the source, are provided for the user's benefit, we chose to ignore them and rebuild them. I fail to see on which point this is not meeting the DFSG or the Social Contract. +Emilien [0] http://anonscm.debian.org/gitweb/?p=pkg-javascript/jquery-lazyload.git;a=tree _______________________________________________ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
