Re: FSF continuously harms Free Hardware

[Jacob Hrbek]

> These three are equivalent because, in all three, we are equally 
helplsss.  In theory, in case 3 reverse engineering would be able to fix 
it.  But we can't do any reverse engineering -- we can encourage people 
to do such it. -- RMS

I agree that complicated components such as processors can be 
problematic as they are very often very difficult to review, change and 
fabricate but I don't align with it being a reason to consider Free 
Hardware Designs ("FHD") as not worthy of supporting, because as long as 
the designs are GPLv3-compatible then they can be changed to use more 
appropriate components.

In terms of processors RISC-V would be my quick answer for the 
definitive user-freedom as they are open-source and can be fabricated 
using a modified 3D printer or custom CNC machine (majority of CNC 
machines are GPLv3 compatible and easily changable for this task), but 
the process is complicated and i am not yet an expert on the subject to 
represent it.

That said I don't feel like the use of processors is a freedom issue in 
general thanks to projects such as Rockchip (Arduino, etc..) that make 
the proprietary ARM architecture malware-free to be considered safe 
while providing the required components to use the processor (firmware, 
bootloader, documentation, linux patches, toolkit, etc..) under 
GPLv3-compatible licenses [https://github.com/rockchip-linux] which then 
can be declared as safe and through an independent security review with 
thanks to the provided tools the results can be verified.

---

But again the main issue about which i want to make a case here is that 
FSF supports and endorses proprietary hardware designs at the expense of 
Free Hardware Designs and their developers + that GPLv3 is not made with 
hardware and is problematic for that use.

---

About Creality the required informations are not public (to my 
knowledge), but this is from what i was told, researched and found relevant:

Creality Ender-3 and Original Prusa i3 are both forks of Prusa Mendel 
(https://reprap.org/wiki/Prusa_Mendel) which is a fork of RepRap Mendel 
(https://reprap.org/wiki/Mendel).

Allegedly this video https://www.youtube.com/watch?v=tyVM3-v84I0 
inspired Creality to take the Prusa Mendel design and re-engineer it for 
production to create Creality Ender-3 which was forked by Josef Průša to 
create the Original Prusa i3 (or prusa was first and creality forked it 
and optimized it for production cost).

So all of these printers and their forks were forked from RepRap Mendel 
so they have to follow GPLv3, but they all fail to credit all the authors.

So assuming that RepRap is the copyright holder, I found this on the 
subject:

I was provided a response of a RepRap representative on their forum 
explaining most of the issues with GPLv3 and problems with the 
enforcement of FHD: https://reprap.org/forum/read.php?33,40874

In short my summary of the discussion would be that GPLv3 is not worded 
and made for hardware as it lacks the required protections to enforce 
and maintain the values of four freedoms for hardware.

There is also a statement by OSHW/OSWR on GPL that i find relevant, but 
note that OSHW/OSWR are seemingly not aligned with 4 freedoms: 
https://ohwr.org/project/cernohl/wikis/faq#q-why-not-use-existing-licences-such-as-gpl-and-any-in-the-family-of-creative-commons-licences 


And relevant KiCAD (FOSS EDA) forum post: 
https://forum.kicad.info/t/using-the-l-gpl-as-an-open-source-hardware-license/1925/2

On 1/19/22 05:16, Richard Stallman wrote:
> You're right that the two are similar.  But there is a crucial
> difference.  We can get around the problems at the level above the
> processor level by writing software.  We can't deal with the problems
> inside the processor that way.
>
> Suppose a processor has malicious functionalities.  There are three
> ways it is likely to be implementd:
>
> 1. By unchangeable circuits.
>
> 2. By firmware in ROM.
>
> 3. By secret firmware in RAM.
>
> These three are equivalent because, in all three, we are equally
> helplsss.  In theory, in case 3 reverse engineering would be able to
> fix it.  But we can't do any reverse engineering -- we can encourage
> people to do such it.
>
> Thus, we treat all three cases the same.

--
Jacob Hrbek

publickey - kreyren@rixotstudio.cz - 1677db82.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature