**** BEGIN LOGGING AT Sat Jul 30 02:59:58 2016 Jul 30 03:09:53 DocScrutinizer05: re the USB ID requirements, could we add that any open firmware *must* be user-updatable? Jul 30 03:12:55 err sure Jul 30 03:13:59 however we don't need to add that, it's common sense and the persons in charge (Paul, Harald, me) would apply such consideration whether it's written down anywhere or not Jul 30 03:15:14 that's what I meant by "rules are made to circumvent them" - the more rules you got, the more people will insist they they are comprehensive and what's not in the rules doesn't apply Jul 30 03:18:39 also OTP chips come to mind, how to handle those then? Would it be ok to sell such hardware with the firmware preflashed or is such a project only qualifying when they tell the user "you need to flash the firmware since we must not do it"? Jul 30 03:19:42 strictly speaking you cannot *update* the firmware of a OTP chip Jul 30 03:20:08 you can Program it OneTime Jul 30 03:25:23 I guess most users would appreciate when the manufacturer offers a programming service Jul 30 03:26:00 this way they can be sure they won't kill the whole device by a failed programming session Jul 30 03:26:33 if we had such rule, that service most likely was not tolerable Jul 30 03:28:28 otoh user could update the firmware for a chip that has no docs regarding the meaning of registers, so with all the update-ability users had no clue how to change the firmware to make anything useful from it, despite code being FOSS and chip reflashable Jul 30 03:30:25 sounds complicated Jul 30 03:30:48 yes. that's why rules usually don't _really_ help Jul 30 03:31:45 antrik: btw, see Oracle v Google, interfaces are copyrightable but then reimplementing them is fair use (at least in the USA) Jul 30 03:32:21 I think one very simple rule will do: the project must be in best FOSS / OpenHardware spirit, and the "committee" decides based on own evaluation of the project Jul 30 03:34:49 honestly, I think we got 0xFFFF minus a few available USB-IDs. We shouldn't worry too much about rules that MUST be obeyed to qualify for receiving one Jul 30 03:36:07 who will suffer if we have less rules? Jul 30 03:39:01 I however know a few people who will suffer from more rules: we, those in charge to decide Jul 30 03:39:33 ;-) Jul 30 03:41:03 rather than rules, maybe we could describe the ideal FOSS/OSHW project we all dream of :-) Jul 30 03:42:42 so everybody can check how much their own projects resemble that and consequently how likely it is the committee will accept their application and grant an USB-ID Jul 30 03:44:31 or they simply apply and ask for feedback, and we tell them what we like and what we don't like so much about their project, and they can consider if they could improve Jul 30 03:46:21 btw, I learned something interesting at DebConf: HPE now default to GPLv3 for new projects they write Jul 30 03:46:50 who/what is HPE? Jul 30 03:50:03 HP Enterprise Jul 30 03:51:57 re rules: it's quite fortunate that we're already two persons deciding, and in case of discern each of us could grant USB-IDs without the help of the other one. So we probably don't need rules that define the rights of people applying for a ID, and as elaborated above I don't think we need rules defining the duties too precisely either Jul 30 03:52:13 ooh, HP. That's nice Jul 30 03:54:11 ~2**32/365/100 Jul 30 03:54:11 117670.336876712332 Jul 30 03:54:54 *cough*, when we do this job a hundred jears, we still could grant 117670 USB IDs *per day* Jul 30 03:55:08 years even Jul 30 03:56:27 so any restrictions who may qualify for a free USB ID are clearly just disciplinary measures to achieve a "political" goal Jul 30 03:57:31 I don't like to think of myself as the executive of a political agenda set up by others Jul 30 04:00:00 my only agenda is: I don't want to do the work for people or projects I don't like Jul 30 04:07:48 with an overprovisioning factor of roughly 100k, there's hardly anything to worry about except handling of own workload Jul 30 04:08:56 more rules mean higher workload per event, but also less events in total per time Jul 30 04:11:29 anyway, applies accordingly: Jul 30 04:11:35 ~7282 Jul 30 04:11:35 [7282] https://tools.ietf.org/html/rfc7282 or >>We reject: kings, presidents and voting. We believe in: rough consensus and running code.<< Jul 30 04:12:41 let's humm it out ;-) Jul 30 04:14:39 ooh, you seen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508 ? Jul 30 04:15:13 that was fast Jul 30 04:19:00 it becomes more and more obvious why devuan is *needed* Jul 30 15:02:23 https://www.crowdsupply.com/eoma68/micro-desktop/ **** BEGIN LOGGING AT Sun Jul 31 02:35:17 2016 **** ENDING LOGGING AT Sun Jul 31 02:59:58 2016