Slashdot Mirror
Stallman's Legacy Halts At Hardware (hackaday.com)
szczys writes: To say Richard Stallman had a profound effect on free software is not a bold enough statement. The power of the GPL, and his advocacy for software freedom have changed the world. But there is one frontier that has yet to hear this gospel. These days, no hardware is an island. Almost every type of electronics we use is running some type of code, and in almost every case some of that code is secret in more ways than one. From beefy processors to graphics controllers, boot ROMs and binary blobs run in the silicon we base our systems upon. The code is not published and in the rare case that you are able to view the source it is only under strict NDA. This represents one of the biggest barriers to true open hardware.
Stallman has always had the right idea IMHO, but that 'ideal' put up against Corp Profit will never win sadly.
"Those who don't understand code, will be owned by those who do"
I'm all for a hardware manufacturer who creates and promotes 100% open hardware with public code provided.....................know any?
Source: e-mail exchange with him, based on my shmoocon presentation on hacking USB flash drives.
In short: I said there's no way you can have open source firmware for a proprietary undocumented ASIC, that has to keep track with new developments in flash memory every 3 months.
He want on to ask if there was a way to buy a USB flash drive that wasn't field-reprogrammable, or to "convince a company to make USBs [sic] that way". I'm not aware of any, and it's impossible as-is to A) ask a vendor "What chips are you using?" and B) have the vendor use the same controller/flash chips on the same device.
Dude wouldn't listen, and I gave up trying to educate him.
da w00t. mtfnpy?
The biggest barrier to true open hardware is the fact someone has to pay for a tangible good, and that tangible good - hardware - is designed for a specific purpose. The BIOS and bootloaders and such are immaterial, and do not limit you from using a piece of silicon as you desire. The block is silicon that does what you want to do in the first place. And that carries with it costs beyond just software creation.
i'm designing Libre Hardware, right now. i've been on this task for the past five years, since the embarrassing time when i encouraged 20 software libre developers to join me in buying one of the very first ARM netbooks to come out (back in 2010) that turned out to be GPL-violating. i had to spend a frantic 3 weeks reverse-engineering the hardware in order to provide those people with a GPL-compliant linux kernel.
this example just on its own demonstrates that what you have said is simply untrue in a very profound and subtle way. you claim "The BIOS and bootloaders and such are immaterial, and do not limit you from using a piece of silicon" - how can you load a kernel into memory using the BIOS's bootloader (if there is one) if you do not know how the BIOS *actually works*? how can you load a kernel into memory if you don't have the hardware's documentation? what if the proprietary bootloader (if there is one) has some sort of checksum or DRM where you are not provided the keys?
another example is the IBM / Lenovo laptops, where the BIOS had the PCIe device and MAC address of the WIFI adapter *burned into EEPROM*. quite literally the only way for people to replace the WIFI adapter was to *replace the entire BIOS*. that required a *massive* reverse-engineering effort and we now have coreboot support for many Lenovo laptops.
time and time again i have had to cut certain SoCs and ICs from the list of products because i cannot get the SDK, cannot get the Datasheet, cannot get *any* information about how the SoC or IC works.
so you claim "the block is silicon that does what you want to do" - it only does what you want to do via a hardware API which requires an extremely comprehensive bit-level and timing-critical software-driven understanding of that "block". without that, the hardware is LITERALLY useless. [remember NDISWRAPPER for WIFI cards?]
can you see, therefore, through these examples, that you've fundamentally misunderstood the complexity of the issue, and why there are such severe barriers to entry in the hardware arena?
i *do* understand this, so it's why i have been working for the past five years on creating Libre-compliant eco-conscious hardware, where the hardware - all of it - will be vetted for GPL-compliance before putting it into production. sounds mad? but it's the only way, i feel, that instead of waiting for someone else to tackle this, i'm *actively* taking responsibility for ensuring that there exists Libre-compliant Hardware.
Nothing in the GPL forces you to contribute back changes. You can download GPL'd code, change it however you want, and use it on your own systems to your heart's desire, without having to contribute anything.
However, if you download GPL'd code, modify it, and distribute a binary, you must distribute your code changes under the GPL. If you don't want to do that, write your own damn code from scratch. None of this is forced upon you.
Without the GPL we wouldn't have much of the freedom we now enjoy. Would Linux be so popular, would it get as much contribution from private companies if they were able to release their own proprietary versions? Look at BSD. It doesn't benefit much from Sony using it on their games consoles and in their smart TVs, because they don't have to give anything back.
Without GPL software, software that wouldn't exist in the way it does without the GPL, we would be much more reliant on non-free products. We would be less free to compute.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Saying BSD-style licenses are "truly free" and the GPL isn't is like saying that you're only truly free if you have the right to use a gun to hold others captive. The ability to revoke freedoms from others does not make one more free in any logical sense.
The BSD and MIT licenses offer true freedom. The GPL offers restriction and the elimination of freedom.
this is a very subtle and dangerous perspective that has one extremely large software project which has ended up in complete chaos, causing headaches for many people, including misunderstandings and ignorance by vendors who assume that because the majority of the software is BSD/MIT, the linux kernel's GPL license is somehow magically transmuted to a BSD/MIT license as well.
that software is android.
the only reason why we have things like cyanogen, thank god, is because there is one last bastion of fundamental GPL code left in android devices: u-boot and the linux kernel. without that, the smartphone industry would be viewed with extreme hostility. it's *already* bad enough in cases where companies such as Mediatek blatantly and continuously violate the GPL.
look at what happened with Fairphone, for example. great product, yes? envisioned as being sustainable, yes? and after 2 years, what happened? well, there turned out to be some security vulnerabilities in the version of android that was supplied (by Mediatek). it was *critical* that the users upgrade. but, because Fairphone had naively bought a binary-only GPL-violating OS from a 3rd party OEM company that *DIDN'T EVEN HAVE THE SOURCE CODE*, there was no way to provide updates of *ANY KIND*. the buyers therefore had to abandon their products for security reasons. bear in mind that this is supposed to be eco-conscious *sustainable* hardware that's supposed to be re-usable. it was extremely embarrassing for Fairphone, and a very hard lesson for them.
so that's even when there's a GPL kernel. imagine what it would be like - imagine the situation if the linux kernel *wasn't* GPL? you would end up with the exact same situation as with apple. apple _used_ to release the kernel source code (based on FreeBSD) back to the community... they stopped recently. the end result: people no longer actually own their own hardware.
the GPL is, at its heart, a recognition that collaboration is better than competition and secrecy. the BSD and MIT licenses were developed when everybody released source code *anyway*. the licenses were therefore more about fighting the liability that is inherent in releasing code as "Public Domain". everyone *trusted* that the code modifications would be released.... and then suddenly they weren't [did you even *know* for example that Windows 95's TCP/IP stack is actually BSD-licensed?]
google's insistence on using BSD licenses - to the point of re-implementing entire GPL-based pre-existing libraries - has resulted in untold very subtle harm to end-users and to software freedom in general - harm that is very difficult to quantify and explain because it's long-term, and the consequences are ongoing.
the one thing that really really stinks about what google did with android is summed up in this simple question: they replicated dozens of critical low-level libraries and applications that had perfectly-functional GPL versions that were proven and had stable communities based around them (that could really have done with the financial support of google).... so why did they not replicate the Linux Kernel as a BSD-based project as well? that hypocrisy - that they did not also re-create the Linux Kernel as a BSD/MIT project - tells you everything that you need to know.