Re: Minified files and source code requirement
Russ Allbery writes ("Re: Minified files and source code requirement"):
> Paul Wise <email@example.com> writes:
> > What is the preferred form for modification for a work (aka source) is
> > highly context-dependent.
> I'd like to poke a little bit at the assumption that these two things are
> the same and that Debian necessarily uses the GPL term as our definition
> of source.
I think it's a good rule of thumb. Another alternative formulation is
that the source is the form actually used by upstream to make their
One thing we and our users need to be able to do is to modify the code
we distribute and still continue to take other changes from upstream.
So any format that is unnecessarily hard to merge (see below for more
discussion of this) is not suitable.
Another way to look at this is that if what we have is actually the
ouput of some automated process done by upstream from secret (or
unpalatably licensed) input files, anyone who modifies our source
package will be committing the cardinal programming sin of editing an
So considering minified JS: even if we run a formatter over it to put
the whitespace back, what we have differs from source code in the
* The variable names are still all smashed, so it's hard to see
what's going on;
* Future versions from upstream may suffer from wholesale changes,
invalidating our local patches, if upstream change their minifier
or perhaps even if they make minor changes to the original source.
(Eg sequentially named variables might all get changed.)
* The original source may have been transformed by an optimiser into
something which is much harder to edit due to being more fragile.
Also I think the question of fairness is important: someone who forks
the work based on the source code in Debian should not inherently be
in a worse a position than the original author, as regards ability to
modify and update the work.
Now obviously there are all sorts of advantages to original authors:
they are most familiar with the code; they may have private tools
which help with editing the source; they have the benefit of the
inertia of downstreams; etc.
But I think we should draw the line at software whose original authors
prevent us from using the most convenient form for our modifications.
That is not Free Software and it should not be in Debian.
Otherwise where are we to draw the line ? The difference between
preprocessed C, or C compiled to assembly language, or even C compiled
to object files, is just a matter of degree in awkwardness, not a
difference in kind.
And asking for the *actual source* is in no way unreasonable, if
upstream are claiming to be a Free Software or Open Source project.
> To me, the source of something is *a* form suitable for modification of
> the work. This is *not* necessarily the same thing as the GPL's "the
> preferred form of the work for making modifications to it." I think
> Debian's term means that the form has to be suitable for modification by a
> reasonable "average person" who is technically skilled enough to be able
> to modify the work. I think it's a bit of a leap that it necessarily
> means that it has to be whatever form that the author of the work
> personally prefers, and even more of a leap that it has to be the form
> that the author of the work used originally.
So for the reasons above I think this is the wrong approach.
> For example, suppose I include an image in a piece of software that I
> generated by taking a digital photograph of something in RAW, manipulating
> it in Photoshop, and then exporting it as a JPEG. What's the source? In
> the GPL sense, one can make an argument that the original RAW image is the
> preferred form for modification, since if I had it available I'd probably
> use it rather than the JPEG to make further changes.
No, the source is not the RAW image. It is the Photoshop file, which
contains the additional layers information and metadata. If you had
the choice you would use that to edit the file again. And yes, that
means that many images which have been manipulated in Photoshop can't
be in Debian because they can't be built from source using software in
Debian main. (Unless, I guess, GIMP can read the file and produce the
JPEG. I have no idea about that.)
If you throw the Photoshop file away for some reason, then the JPEG
itself is the best starting point for further changes. That's because
going back to the RAW would lose all your manipulations which you
wouldn't want to do again.
Or to put it another way, if upstream keep a GIMP file and distribute
a JPEG, they have put themselves in the privileged position: they find
it easier to do certain transformations. For example, if the image
has text overlayed on it, the person who has the layered GIMP file can
easily move the text about or change what it says. Someone who only
has the JPEG will have trouble because they have to (a) retrace the
letter boundaries somehow (b) invent new background where the old text
Images are of course a bit of a special case because we don't have any
useful merge algorithms for them; AFAIK there isn't even a useful
merger for GIMP files let alone possibly-compressed pixmaps.
But when the true source format is a text file which can be readily
the actual source so that merges work.