IRC #olimex 2018-04-08

[13:36:46] <ep_> hi everybody. is there a reason why olimex isnt RYF certified?
[13:37:04] <ep_> i mean the olinuxino board especially
[13:37:10] <ep_> boards*
[13:39:40] <ep_> (https://www.fsf.org/resources/hw/endorsement/respects-your-freedom)
[13:48:49] <jo0nas> I guess simply a matter of noone driving that effort of convincing FSF of the compliance - perhaps you would volunteer for that, ep_?
[13:53:33] <ep_> jo0nas, yea why not!
[13:56:48] <ep_> hm.. arm isnt open source i guess :/
[14:00:21] <jo0nas> I don't follow
[14:01:06] <ep_> i mean arm architectures are all proprietary
[14:02:12] <jo0nas> do RYF compliance require full sources to the SoC? I highly doubt that
[14:03:26] <ep_> yea i just read something about certain exceptions
[14:04:31] <ep_> ..but if there are no sources to the SoC.. nobody can guarantee that its free o.O
[14:04:36] <jo0nas> volunteering for driving this obviously involves being sharp on the related definitions
[14:05:16] <jo0nas> it seems you are now not following definitions but inventing your own - that is quite unlikely to be helpful here
[14:06:04] <ep_> not planning to invent my own
[14:06:48] <jo0nas> what is needed, I believe, is someone convincing FSF that some specific Olimex products comply with RYF rules
[14:07:26] <jo0nas> do RYF rules say anywhere that someone must quarantee that SoC is free?
[14:09:26] <jo0nas> it seems you are reasoning abstractly on whether something *like* RYF is sensible for ARM-based products - but such reasoning is helpful for designing a _competing set of rules than RYF, not for seeking compliance approval for that already invented set of rules
[14:10:17] <jo0nas> your thoughts are interesting, but out of scope for a compliance approval process
[14:10:34] <ep_> i ll ask them for somthing like a checklist and a comprehensive guideline
[14:10:46] <jo0nas> don't expect them to make it simple for you
[14:11:25] <jo0nas> FSF deliberately phrase things vaguely at places, to leave room for reasoning _tied_ to their rules and the intentions behind them
[14:11:31] <ep_> i expect them to support free and open hardware and software
[14:11:54] <jo0nas> they support pushing the boundaries and requirements
[14:12:21] <jo0nas> they do not support embracing and praising most possible products - they try to praise the _least_ possible
[14:14:34] <jo0nas> I currently work for Purism where I am tasked with ensuring that PureOS comply with GNU FSDG
[14:15:30] <jo0nas> it took Purism several years to achieve compliance approval - mostly, as I understand it, because FSF deliberately were vague about what _exactly_ was required
[14:16:07] <ep_> ok. thats a very valueable information
[14:16:47] <jo0nas> ...and I see how that makes sense to them, but it can become quite frustrating to work with - especially if not aware of their intent
[14:20:18] <jo0nas> I dearly encourage you to try drive an approval process - and will be happy to help (but won't take on the task of driving it myself)
[14:39:37] <ep_> thanks a lot jo0nas. i ve mailed them.
[14:40:49] <jo0nas> cool!
[14:45:03] <ep_> im a fan of doing ;) lets see what returns