2014-03-26 22:30 GMT+01:00 Ben Finney <ben+deb...@benfinney.id.au>:
> Emilien Klein <emilien+deb...@klein.st> writes:
>> The current policy is made using the assumption that minified == compiled.
>> For my information: Has this ever clearly and definitively been
> I'm not understanding your question. What assumption are you describing?
I am mentioning the fact that our policy mandates to repackage
upstream tarballs if they contain minified files, based on the
assumption that a minified file is a compiled resource (I almost wrote
"compiled binary", which is what I think of when thinking of
file is not a binary file)
> Equating “minified” with “compiled” is not, AFAICT, an assumption; it is
> describing different aspects of the same process.
That is exactly what I want to see confirmed. Is everybody (not just
our smallish team of JS packagers) agreeing on the fact that a
minified file is a compiled file?
If that's the case, the current policy is completely valid, and we
should clearly state that on our policy page.
If we haven't had a full argumented debate, that should take place and
be then stated in the policy page.
>> I agree that we shouldn't be redistributing *compiled* software that
>> we can't guarantee hasn't been fiddled with.
> Would you agree that we should not be shipping non-source forms of works
> that we can't guarantee have not been fiddled with?
Regarding the sentence that you cite below (regarding DFSG §2), I
think there is no issue in redistributing an upstream tarball that
contains the minified file from it's own source code. If the tarball
only contained the minified file, I would obviously object. But if the
tarball contains the source .js and the minified .min.js, I'm not sure
we are in breach of DFSG §2 as the source is provided. Since we
re-minify as part of our build process (should also be specified in
our policy), the binary packages contain the source and the
by-us-ensured-valid minified file. The .orig tarball then remains the
same as provided by upstream.
> One of the guarantees to Debian recipients is that they have full
> freedom to change the behaviour of the software; that entails having the
> corresponding source form of the work.
Exactly. Somebody can get `apt-get source`, modify the non-minified
source file, and rebuild the package if they want to. They will still
get a properly minified file, as that is part of the Debian package's
build process. No need to fiddle with the upstream-provided minified
I believe most upstreams are in good faith, providing the minified
files as a service to their users that can just extract that file and
use it on their servers. Have we ever seen a case where an upstream
shipped an evil minified file in their release tarball? And even if
they did, I still doubt Debian users would even be affected, as the
minified file provided in the binary package has been made by us.
The only way they could be impacted by an evil minified file is if
they use the orig tarball to build their custom Debian package,
modifying the rules to not minify the file themselves but rather use
the file provided by upstream. That would be just plain dumb, doing
extra work to revert the Debian maintainer's carefully reviewed
> so, whether you call the process of generating an executable work
> “compiling” does not matter. What matters is that a non-source form of
> the work is generated and we distribute it; the Social Contract requires
> us to ensure that the resulting non-source form corresponds to the
> source form of the same work.
Please link to that requirement.
Does the Social Contract require that to be done in a specific way? In
particular, do we need to do that in a technical way, or could we use
our human skills and ask the upstream developer to state that the
minified files they provide are the process of minifying the released
source file? (I can already see some upstreams getting all confused,
"why the heck are you asking me this evident quetsion, well of course
I'm minifying my source code, what a weird question" ;) )
>> provider smaller files (mainly for performance reasons), but they
> In other words, they are not the source form of the work.
Completely agree. They are a non-source form that are provided along
with the source form. That is the "accompanied" bit in DFSG §2
sentence you cite: "The work must be accompanied by its source code",
not that The work must *be* its source code.
Again, seems compliant to me...
>> To help make this situation clearer, can somebody point us to (1) the
>> exact part of the DFSG or policy that we're using to base our "exclude
>> minified files from orig tarball" policy and (2) where discussions
>> have been led with folks outside of our team (e.g. -devel) about the
>> undistributable character of minified files in upstream tarballs?
> DFSG §2: The work must be accompanied by its source code. A minified
> file is not the source form of the work, so we must provide, in the
> source package, the source form of the exact same work.
Looking at the DFSG , §2 states:
The program must include source code, and must allow distribution in
source code as well as compiled form.
And §2 of the social contract (just a bit on top of the previous link)
is about giving back to the free software community.
I might not be looking at the correct place, please let me know where
to find the sentence you mention.
> \ “As we enjoy great advantages from the inventions of others, we |
> `\ should be glad to serve others by any invention of ours; and |
> _o__) this we should do freely and generously.” —Benjamin Franklin |
> Ben Finney