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.


Pkg-javascript-devel mailing list

Reply via email to