[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Minified files and source code requirement



Ian Jackson <ijackson <at> chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Minified files and source code requirement"):
> > 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
> modifications.

I think that rule of thumb is not as practical as you seem to assume.


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

Who qualifies as "upstream"? What if upstream reformats his own code (the
version he himself works on) every week, making merging changes from past
versions difficult? Does that render his code "non-free" in your opinion?


> 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
> following ways:
> 
>  * 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.

As for the first and third points, Russ clearly talked about versions that _are
suitable_ for modification. If the code is unreasonably unreadable or fragile
then it doesn't pass that test either. As for the second, there are various
unambiguously free modifications that cause the same problems.


> 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:

So you accept that this "not inherently worse" requirement is not reasonable in
practice, but you still insist that it should be strictly followed in at least
one case?


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

Why should we draw the line there? If original author A is a dick and withholds
something, while original author B is an idiot and writes bad code, should the
code from author B really be preferred? Even if the code from author A is
overall a perfectly reasonable free software project and much more convenient to
modify (even given the missing data) than the code from author B?


> Otherwise where are we to draw the line ?  The difference between
> being editing minified javascript, or deliberately-obfuscated C, or
> 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.

You do have to draw the line at some arbitrarily picked unimportant difference.
If you are not willing to accept this fact you'll end up arguing for completely
absurd positions.

Suppose someone starts with a sourceless binary blob released under a free
license. He runs a decompiler on it, producing a C file that contains unreadable
messy code. He then edits the file, each change a minimal one that modifies a
couple of lines. Eventually he has a C file that is higher quality than the one
the original blob was produced from (at which point this happens may be
impossible to know for people who don't have the original source). He then
continues fixing bugs and adding features, eventually completely superseding the
original blob. In the end his version is unambiguously the "upstream source". At
exactly which minimal change do you draw the line?


> And asking for the *actual source* is in no way unreasonable, if
> upstream are claiming to be a Free Software or Open Source project.

I think that involving the other upstream behavior this way (as opposed to the
specific code considered for inclusion in Debian by itself) is problematic when
talking about basic "what is considered free software" or "what is acceptable in
Debian" questions. Does previously unacceptable software really turn acceptable
if the upstream says "OK we deleted those files so we don't have them either"?
At what point does a fork become the "new upstream" that is modifying the code
without using those files (after all the assumption was that even without those
files the code was in a reasonably modifiable form, so they wouldn't be
necessary to create a fork)?



Reply to: