On Aug 20, 2021, Legimet <[email protected]> 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> _______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
