[Pkg-javascript-devel] JavaScript policy?

[Jonas Smedegaard]

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 [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.

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 
irrelevant.

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.

JPEG code is less important to keep strict source for than Javascript, 
because consequences of flaws or malware in JPEG are only visual 
(consequences beyond that is bugs in _interpreters_ of JPEG code).


 - Jonas

-- 
 * 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...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20140327/5d61af7f/attachment.sig>