Conill: the FSF’s relationship with firmware is harmful to free software users

I made a point to not namedrop anyone, only brought up the odious behaviour of someone acting on authority of the FSF - which was a widely publicised event at the time considering Stallman had just been kicked out, and relevant here since it shows how consistently out of touch they all are with the community they try to claim ownership of.

What's borderline offensive is the immediate attempt to turn this into a litigation of terms and conditions by which FSF members may be held accountable when they barge into other people's living rooms demanding tribute.

No.

All past commits will still be under the original MIT, but a mixed MIT and GPL project effectively becomes GPL. When you release code under permissive licences like MIT, you're allowing others to distribute it and modify it to make it copyleft or proprietary.

I don't think that's actually true. Sometimes perhaps, but sometimes people are simply so worked up about some issue that they try to express the strength of their conviction and feeling using invective.

But be that as it may. Your statement seems to me to suggest that people strive to maintain a polite tone, in order to avoid triggering others into thinking (as you say you would) that they're arguing in bad faith.

E.g. disclosure in patents is hampered by obfuscation.
E.g. copying for fair use and after copyright expiry is hampered by DRM, anti-circumvention laws, and repeated extention.

Hmm, that doesn't seem to describe most of the patents I've looked at.

To pick an arbitrary example that would be relevant for a GPU, the S3TC texture compression patent (now expired, so there should be no risk of liability from reading it) at https://patents.google.com/patent/US5956431A/en has a perfectly readable "Background" and "Summary", explaining broadly what the new technology is for and how it works. Then there's the "Detailed description" which is still not too bad and gives most of the information you'd need to implement it. It's certainly not good technical writing, I guess because it was probably written first by an engineer (who understands the technology but may not be a great writer) and then adapted by a lawyer (who only half understands the technology and really likes saying "preferred embodiment" and referring to stupid flowcharts), but it's not actively obfuscated - if you have a reasonable level of background knowledge then you can skim over the nonsense parts and extract the important information without too much trouble.

I don't think that's an outlier; most patents that I can remember reading have a similar kind of description, some better and some worse, usually written clumsily but making a good-faith attempt to describe the technology. (Perhaps it's different in other fields though, I can't claim to have very wide experience.)

The "Claims" is the largely unreadable legalese, but that section doesn't matter when you're trying to implement the technology described in the readable sections. It only matters when you're trying to _not_ implement what was patented, so you can solve the same problem in a non-infringing way, in which case you need legal advice.

> Otherwise you could just tweak a key part of the patented idea and replace it with something else.

That's why the claims are structured as they are ("claim 6: the system in claim 5, further comprising ...", where each claim is separately enforceable) - it's a tree of variations of the idea, where the root node is the most generic and the leaves are the most specific. You can avoid one of the leaf claims by tweaking a part of the idea, but then you might be infringing a different leaf claim (if the patent writer had already thought of that tweak), and/or you'll still be infringing one of the broader claims. As you get closer to the root, the claims are more likely to get thrown out for being too obvious or for there being prior art - the more specific claims are there in case the broader ones turn out to be invalid. But none of that depends on deliberately obfuscating the idea.

Because it is not reasonable to replace all ROM code (e.g. SoC startup) and it is also not reasonable to demand a vendor to tell you about internal design details just because they made a certain design decision along the way (i.e. use processor + ROM).

> cripple their hardware and insist that this act, somehow, promotes freedom.

Put like that I agree with you. Remove the "promotes freedom" part and phrase "cripple their hardware" a little different and I agree with the FSFs position as well.

If the FSFs said "all software in the device must be free, ROM or otherwise" (I'm guessing that's what you are getting at here) there is not even a remote chance that a single device out there meets that requirement. They tried to draw the line somewhere to make it possible to create a device with their stamp on it, even if it ended up creating some comical implementations. Is their stamp usefull in any way ? Probably not, but the problem they are dancing around is real.

Where I think the FSF is a bit crazy is saying that if you somehow hide loading the firmware it is no different to having a ROM to begin with. I can see the logic, but implementation wise it is comical.

> Removal of my freedoms can not make something “more free”.

In my opinion you are now moving the goal posts very far. First we had "Free software" that was all about user-visible things: kernel, shells, utilities etc. and now the argument seems to be "no, no, we always meant internal hardware details to be open as well".

I think you have all the same freedoms the FSF stood for in the past today as well. The world moved on, technologies changed and so did implementation strategies in chips but that does not mean that all of a sudden your freedoms are removed -- you never did have the freedom to arbitrarily change state machines inside a chip.