Quoting Walter van Holst (2015-01-14 14:07:56) > On 2015-01-14 13:17, Jonas Smedegaard wrote: > >>> What is the take of the Freedom Box project on the boundary problem >>> in open hardware? Especially the lower boundary? At what lower level >>> would such a requirement stop being applied? >> >> Interesting question. Seems you are knowledgeable in that area >> (which I am not) - what is your own opinion? > > My take on it is rather pragmatic: this project aims to enhance > digital freedom for the masses, if my understanding is correct. > Reaching the masses implies that you cannot restrict yourself to > obscure pieces of hardware, but at least temporarily must include > hardware that is widely available if not already lying around in at > least geeky households. Reaching the masses means that you have to go > where they start to be. > > So it becomes more a question: how do we balance the importance of > openness at the hardware level with the need to gain critical mass in > adoption, now and in the foreseeable future. That means developing a > few rules of thumb in the full knowledge that they have to be revised. > > For example: > > "We will not actively target platforms that require binary-only > firmware blobs (which is a fairly objective lower boundary threshold), > but we take exceptions to this rule for platforms that a) are widely > available and b) have a clear and convincing roadmap for reducing if > not eliminating those blobs or are otherwise likely to become more > open in the foreseeable future." > > BTW, the Raspberry Pi would meet this threshold. The Banana Pi less so > (unless you count the likelihood of strongarming them through their > GPL-violations to be more open as meeting the requirements), but the > UDOO and the Parallella probably would. > > "not actively targeting" meaning that contributions will be accepted, > but by default will be treated as deprecated platforms. > > The above should be read as me thinking out loud on how you could > define a lower boundary for hardware openness in light of the goals of > the Freedom Box project. Also, my views on both the GPL and Free > Software advocacy are sometimes considered as heresy. Caveat emptor.
Thanks for your input. Quite relevant! What I propose *now* is to raise the bar at a _board_ being OSHW compliant. That excludes both Raspberry Pi boards (even if future boards from same vendor is likely to be OSHW compliant) and also Banana Pi - but includes other Allwinner-based boards even if documentation of the _chip_ is of substandard quality: Bar is at the _board_ being OSHW, not the _components_ soldered onto the board. What I propose *now* is to not raise the bar on components, beyond what have already been done (requiring boot and normal operation without loading _additional_ proprietary code - e.g. excluding Raspberry Pi due to its need for binary blob to boot, but including boards with wifi chips that require binary blobs as the wifi functionality is optional). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
_______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss