EOMA68 crowdfunding campaign (the last few days) plus ways forward for Libre Computing

[Paul Boddie]

On Wednesday 24. August 2016 18.01.07 Xavi Drudis Ferran wrote:
> 
> I'm too uninformed on hardware design to be able to say much, but I find
> that in the discussions I've seen it boils down to :
> 
> - identifying components (chips) that are not encumbered by
> GPL-violations, proprietary drivers, tivoization, DRM, or signature
> verfication not controllable by the user.

I think Luke did a nice job summarising some of these things in the "Picking a 
Processor" update:

https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor

Of course, a lot of arguments are generated by certain things that can be 
interpreted in more than one way. For instance, Allwinner, and the company's 
licence violations involving code that won't even be used in this campaign's 
products, gets people angry about that company's attitude to copyright law.

However, the copyright holders of Linux (or of the other affected software 
that is actually not used in this campaign's products), including major 
corporations also belonging to the Linux Foundation, don't seem to be bothered 
enough to take action. Meanwhile, a fully Free Software distribution is being 
offered to run on the A20.

So, on the one hand, the corporate behaviour is poor (albeit no different from 
a lot of the other SoC vendors such as Mediatek, apparently), but the actual 
Free Software support is good (probably a lot better than Mediatek, going by 
things I've read). People can decide for themselves where their tolerance lies 
with regard to the situation if suitably described.

> - establishing enough of a relationship with the chip vendors to
> obtain:
> 
>   - datasheets and technical info (in principle without NDAs, I don't
>     know if there are "light" NDAs that might be acceptable, but I think
>     not)
> 
>   - software, like drivers or firmware, under free licenses (ideally
> mainlined).
> 
>   - the needed quantity of chips at an affordable enough price.

I think there was a recent discussion about datasheets and "light" datasheets 
where the latter cannot possibly be all there is for technical documentation. 
I know that one SoC/CPU vendor has datasheets and "programming manuals" where 
the latter are generally not available but seem to "do the rounds" anyway, 
providing the actual information you would need to know how to use the 
hardware. This kind of distinction is definitely worth encoding in any 
summary.

Things like driver and firmware availability are also important, and 
mainlining is also very pertinent. Linux doesn't make mainlining that easy 
from what I've seen, especially when the starting point may well be vendor-
written code that was based on an old kernel and done in the vendor's own "get 
it done" style, and that restricts the ability to track kernel upgrades.

And yes, the last point above - the minimum order quantity (MOQ) - is the 
thing that a lot of people don't understand. Luke doesn't even mention that in 
his table, but as I mentioned in my blog post, such things can completely sink 
a small-scale hardware effort when the vendor insists that the project place 
an order for a million SoCs. (Meanwhile, you can buy certain products like the 
A20 individually from some resellers.)

> I wonder if it would be conceivable to create some institution that
> defines some clear criterium for components procurement, possibly some
> criteria for libre hardware projects served, and continually
> investigates the market and then pools demand from different libre
> hardware projects to increase order quantities. It might also pool
> access to production facilities like PCB manufacturing or the like,
> but I find that harder, because the designs are going to be different,
> so manufacturers possibky won't offer better deals just for bringing a
> bunch of smallish different jobs.

The idea of pooling is very interesting - the kind of group purchasing thing 
that took off briefly with more general "consumer goods" - and it is even 
being done informally: the Neo900 and GTA04 projects have pooled their SoC 
purchases, as I understand it, meaning that the latter project can offer an 
upgrade for little or no additional cost purely because the former had a more 
demanding minimum specification, found a suitable product (compatible with the 
OMAP-based SoC used in both projects), and then persuaded the latter to get on 
board.

PCB pooling is sort of done already, too. Organisations like Fritzing 
effectively batch numerous different designs and put them all on the same 
panel, charging by the area needed by each design in order to cover the 
necessary costs. Other services do this, too, perhaps with more of an emphasis 
on price. Commercial 3D-printing services like Shapeways have volume- and 
shape-related pricing so that they can maximise the number of designs that get 
made in each print run (and receive quite a few complaints when they change 
the pricing model because some designs may go up considerably in price as a 
result).

Of course, there's an argument for more standardisation so that PCB pooling 
might well involve the production of more identical designs which might then 
be produced in a more typical and less expensive way (without the need to 
identify different designs, trim the boards, incur a certain amount of 
unnecessary waste, and so on).

> You could add here more off-topic-here but important requirements such
> as labour conditions, conflict-free minerals, responsible tax
> behaviour, carbon impact, corporate social responsability, etc.

Here, although I think initiatives like Fairphone have done good work, there 
is a lot of data that will be difficult to obtain without regulators and 
regulations becoming involved. But it would be nice to encourage transparency, 
certainly.

> If achievable this might help libre hardware projects overcome some of
> the price and availability problems, and could also help concentrate
> driver mainlining and software efforts to a less diverse set of
> components so that one can hope for better support. Better support
> should lead to more sales for the component manufacturer (to the
> institution partners or other customers) and could progressively
> improve the institution negotiating margin. It might also encourage
> libre hardware projects to collaborate earlier in the design phase
> instead of publishing the design at the end when it is ready for
> production.

I agree with you here completely. The thing I like about EOMA68 (and the other 
EOMA concepts) is that it's about standardising designs so that people aren't 
doing yet another different-looking board that offers similar capabilities and 
hardware to previous boards but which can't be used with the accessories and 
peripherals of those other boards. Instead, people can make computer cards 
that work with existing peripherals and peripherals that work with existing 
computer cards.

> The institution could be a more formal organisation with legal entity,
> budget and ability to enter into contracts or could be some wiki
> somewhere where different tinkerers commit different efforts as best
> they can and finally any pooling of demand depends on the trust among
> the participants.
> 
> But I repeat, it is surely easier said that done and there are
> probably hundreds of reasons unknown to me that make it inviable or
> very unlikely. And even if possible, it'd still take someone to start
> it. Or maybe it even has been tried and I haven't heard of it.

I am quite sure variants have been done of this kind of thing, and most 
definitely at different levels and in different areas: purchase pooling, 
production pooling, and so on. There may even have been some kind of site that 
combined some of these things - it sounds really quite familiar - but I can't 
dig up any notes I might have made about it.

Even collaborating to order through supposedly more expensive resellers (like 
Digikey and Mouser) might be worthwhile if there are "price breaks", meaning 
that larger orders give lower pricing, but I don't know what the legal 
consequences of this would be, whether projects would need to be participants 
in the coordinating entity, or whatever else might need considering with 
regard to any warranty coverage or other things where the manufacturer might 
only consider the coordinating entity as the purchaser.

But even some kind of clearing house for projects, as opposed to a fully-
automated solution, would be beneficial, certainly.

Paul