Potential nonfree code in Linux-libre

[Alexandre Oliva]

On Aug 20, 2021, Legimet <legimet.calc at gmail.com> wrote:

> I would argue that configuration data falls in the "information for
> practical use" category

It does, but being just data, rather than software, its form is not as
important as it is for software.  Configuration data is not
Turing-complete.  Comments and symbolic names can be useful, but even
software can be written without them, and it doesn't cease to be source
code if that's the form in which it's developed.

> the "data" is found in files with a GPL license header, and the GPL
> requires all source code (in the preferred form for modification) to be
> available.

... when distributing object code.  We distribute sources received from
third parties, and binaries built out of them, so we provide
corresponding sources for the binaries we distribute.

Now, your statement could make sense if you could argue that the data
files are *not* in a preferred form for modification, i.e., that they
are object code, compiled or otherwise transformed from source code that
some third party has withheld.  That could mean the party that withheld
that form did not behave in line with the GPL (which might still be
legal, depending on various details), but as long as we can use what we
got for development, those are sources for us, and if nothing stands in
the way of the enjoyment of the four essential freedoms, those sources
are Free.

I don't see any evidence that it isn't, when it comes to the
configuration data, or even to the undocumented configuration code.

Assuming the existence of some nicely-documented form used for initial
development, stripped of the documentation before it was contributed, is
not evidence that such a form ever existed.

It's not nice when code is written in obscure ways, or has documentation
about it withheld, but that doesn't make what has been made available
object code, and that doesn't make it non-Free.  Finding some form
inconvenient doesn't imply another, more convenient form ever existed.

When it comes to software, streams of binary code are obviously not the
form in which the program was developed, with the possible exception of
tiny programs.  Sequences of statements without comments and with
uninformative names and incomprehensible constants, OTOH, may very well
be the form in which a fragment of a program was written.  It's poor
form (pun not intended), but it takes more than that to conclude it's
non-Free.


> Anyway, at least micropatch.c is clearly microcode, so I don't see how
> it can be justified for inclusion in Linux-libre.

I don't have the facts that guided that decision, but I've been a party
of other decisions that may have involved similar calls.

For some time, we've believed pc-card configuration files (*.cis)
contained non-Free Software.  Later on, we learned that they were just
no more than a compact encoding of configuration data, and that there
were programs that decoded them into readable text files, and back, in
non-lossy ways.  In a way, these files were no less source-ish than a
compressed tarball.

I vaguely recall another piece of firmware that was actually executable
code, rather than configuration data.  It was so small that a
disassembler turned it into an equivalent, perfectly readable code
fragment, that was successfully modified and reassembled.  It was not
hard to believe that this was the way that fragment was actually
developed.  There was no obstacle to the enjoyment of any of the four
essential freedoms there.

It could be that the decision to keep the arrays in micropatch.c was
similar to these.  Or it could have been a mistake.  It would be nice if
we could ask them whether they know of something I don't, because to me
some of those bits look a lot like executable code.  ppc code, even, but
not sensible ppc code, so that's probably not what it is.  

I could believe it's just configuration data, if someone I trust told me
so, and that's how it has come to remain: I am trusting the judgment of
those who first cleaned up Linux, and decided these bits were ok to
retain.

That said, I guess it makes sense to look into this and try to find out
why it was retained and, more importantly, whether we should keep on
retaining it.  It's a convenient time to do so, as I take the first
steps towards creating a blob-free git history for Linux-libre,
mirrorring Linux commits.  I'm getting close to a cleaned-up initial
commit, to then start replaying the (cleaned-up) commit history on top
of it, and it would kind of suck to have to redo that because something
else should have been cleaned up.

Thanks,

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>