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