dr at jones.dk
Thu Mar 27 13:26:53 UTC 2014
Quoting Emilien Klein (2014-03-27 13:30:23)
> 2014-03-27 0:13 GMT+01:00 Ben Finney <ben+debian at benfinney.id.au>:
> > Jonas Smedegaard <dr at 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 .
> 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.
How do you know for certain that they are related like that?
> 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.
Issue is not licensing, so indications or statements from upstream are
Issue is certainty of computation. For us (if we use the code) and for
our users (when we offer them the code through redistribution either in
binary packages or in source tarball).
> 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.
Two wrongs don't make a right ;-)
Preferrably we should include sources also for JPEG files (e.g. SVG
files) but that is not always possible (e.g. when source is not digital)
or not sensible (e.g. when source is gigantic).
> 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.
because consequences of flaws or malware in JPEG are only visual
(consequences beyond that is bugs in _interpreters_ of JPEG code).
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 966 bytes