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

Re: oaklisp: contains 500kB binary in source



Barak Pearlmutter wrote:
This is a technical issue related to ease of bootstrapping on a new
architecture, and not a legal issue.

As a technical measure, the circular dependency could be broken and
the alternative prebuild-world-in-source kludge eliminated by writing
an Oaklisp interpreter in another language (say, RnRS Scheme, or
Haskell) for invocation when an already-built Oaklisp is not available
on the build platform.  I'm absolutely positive the upstream
maintainer would welcome any such patch.  But, this has nothing to do
with the legal status of the package.

It may not be a legal issue, but I think it is more than merely technical. It does touch the freeness question.

It is about trust that the source provided is actually the true and full source for the given binary. This is not proven just because the source compiled with the binary reproduces the binary (even if it does).

To understand what I mean, you may want to read Ken Thompson's old article[0] on how to hide a Trojan Horse in a compiler without it being present in its "source" at all - just provided you bootstrap it with a given binary that already contains the Trojan Horse.

Now just consider the *possibility* that the upstream bootstrap binary *might* contain such a self-reproducing Trojan Horse.

One important aspect of Free Software is that you have (at least in principle) full control over what your computer does. It is your computer, not the s/w manufacturer's.

Unless/until a clean and free bootstrap from scratch is available, it seems to me the source (with the bootstrap binary removed) may be contrib, but the binary could only be non-free.

Unless/until it can be proved that the binary's behaviour is acurately described by its (alleged) source, it is unclear whether its (true) source is provided or missing. Erring on the side of caution, it would need to be ruled non-free.

The source (with the bootstrap binary removed) could therefore be at most contrib.

Marco

[0] http://www.acm.org/classics/sep95/



Reply to: