[Freedombox-discuss] Intel Compute Stick

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20150114/17802438/attachment-0001.sig>