Re: Minified files and source code requirement
On Thu, Oct 27, 2011 at 1:08 AM, Raphael Hertzog wrote:
> I don't agree that minified files are a violation of DFSG #2. If the
> library is under the GPL then it would be a problem because it's not the
> preferred form of modification.
I think this is exactly the same as xserver-xorg-video-nv, which
contained obfuscated C code instead of the actual source code. I
personally considered that a DFSG violation but I guess you would not?
> But with more liberal licenses, we should certainly accept that the
> minified files are their own sources much like we accept any other blob of
> data under a free license. For instance we know that almost none of the
> firmwares are hand-crafted yet I think we have many firmware under
> DFSG-free licenses (and we adequately pointed out that GPL firmwares were
> not ok).
What is the preferred form for modification for a work (aka source) is
A TTF font file might be source or FontForge .sfd files might be the source.
A PNG image might be source or the SVG or XCF it was rendered from
might be the source.
A firmware blob might be written using a hex editor or it might be
built from assembly code or C compiler. There are cases of both in the
An ELF executable might be written using a hex editor (haven't seen
that yet) or compiled from assembly, C or other code.
Just accepting what we are given is not enough to actually know what
the source actually is (here I'm thinking of MegaGlest).
Further than that, some forms that are currently used as source might
be better converted to other forms. For example given a hand-crafted
binary firmware file, we should suggest that upstream convert that to
assembler and use that instead.
> (Furthermore there are tools which can reindent such minified files, while
> this doesn't restore variable names and the like, it really helps if one
> wants to analyze this code.)
Thats irrelevant, it will not restore the original source, just like
ELF or Java decompilers cannot.