I agree, although at least from the evidence we see of users in the power chair world, a great many don't have any interest is knowing how their technology works. This seems really strange to me, but is it that much different from the computer owners that don't care about the O/S, programs, etc. as long as they can surf the web, look at FeceBook, write their documents, etc..
This is why I think that my earlier solution of having access to the parameter and adjustments in the software, but not necessarily having easy access to the software itself is a somewhat tolerable, if less than ideal approach... By analogy, if I want to run a custom Linux kernel, I know that if I only play with the options in the kernel conf file, then I have a pretty good chance of ending up with something that works. OTOH if I start changing the kernel source, I've entered a whole new level of risk.... If I go into my chair's Pilot+ controller with the 'escaped into the wild' OEM level programming software, I get a list of parameters that let me change the way the chair operates in a multitude of ways, many of which would make it all but undriveable, and a couple that are dangerous, but all are at least somewhat documented and predictable... Going in and changing the actual software runs all sorts of risks of un-intended and unpredictable results - including possible security risks if the chair is connected to anything (Mine isn't and won't be, but many of the new chairs are...) ART ------------------ Arthur Torrey - <[email protected]> ------------------- ----- Original Message ----- Message: 1 Date: Thu, 18 Aug 2016 13:16:23 -0400 From: Aaron E-J <[email protected]> To: [email protected] Subject: Re: [libreplanet-discuss] We need clear advocacy for software freedom, not proprietary greenwashing Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" I guess where I was going with my line of reasoning is not to limit information on how to modify a device but actually do the opposite ? make modification be easy and safe. It is the fact that there is often little documentation on a device that contributes to accidents. At the same time, it is important to make there be clear warnings when doing something may be dangerous and security must be paramount. To use the car analogy, you need to have a driver's license in order to drive and in order to do that, you need to know /how/ to drive. If people who get medical devices are also trained in how the device works, this would have the potential to save lives, regardless of whether the user has the desire to modify it. Aaron E-J http://otherrealm.org http://theotherrealm.org (Blog) On 2016-08-16 11:27 PM, J.B. Nicholson wrote: > [email protected] wrote: >> There is a very mixed bag situation on medical device hacking, in that >> yes, it is definitely possible to cause potentially life threatening >> situations if one makes modifications the wrong way... > > The problem with this argument is that we wouldn't accept this line of > logic for any other device. We've already dealt with this level of > danger and accepted it on a national scale. There's a strong history > in the US (and I imagine other countries) of people being able to > modify their cars. This goes back to well before computers were in > cars. Cars have long been known to be radically unsafe for both the > passengers and the people in the vicinity of the car (making what > we've already accepted objectively more dangerous than a medical > device such as a pacemaker/defibrillator like what Karen Sandler has) > and yet we have no problem with car owners changing what they like in > their cars so long as the end result doesn't break certain laws. As a > result of car hacking we now enjoy a mix of hobbyists and commercial > garages some of which came up from people learning by experimenting on > their own vehicles. > > We never let those potentially life threatening situations hinder > someone's access to fully control their own devices before and we > ought not do so now that computers and software are involved. > >> I think that what should be done at a minimum is to allow any >> programming parameters to be changed, even if the program itself is more >> thoroughly locked down, or more difficult to modify, while providing a >> good and accessible set of information and warnings on what they do... >> I am far from thrilled by the multiple 'Are you SURE?' checkboxes that >> some proprietary O/S's put you through, but could see some level of that >> on particularly dangerous parameters.... > > That's not software freedom and there's no reason to set such a > minimum. What you're describing is indistinguishable from > highly-configurable proprietary software. > > This fight has to be about software freedom, not half-measures like > open source; open source is a developmental methodology which is okay > with proprietary software and asking proprietors for a chance to help > a commercial developer improve a program. The free software movement > demands software freedom for all computer users on ethical grounds. > >> In terms of the medical device area, I think that it would be VERY good >> to do something on the line of an open source hardware group for medical >> devices. I have had a long time interest in trying to make better >> chairs but have been worried about how to handle the regulatory and >> liability concerns. Among other things, a collected knowledge base of >> how to do things without getting into problems with the government >> bodies dedicated to blocking progress... > > Perhaps, if this group was interested in software freedom and not > "open source" and if membership isn't about identity politics (only > people with medical backgrounds can be members, for instance, thus > negating any chance free software activists would represent the > group). Otherwise it would become important to oppose any such group. > Greenwashing (or as Brad Kuhn put it, "openwashing"[1]) is a real > problem with groups like this because they're often corporate shills > looking to preserve the status quo in service to their interests and > the interests of their employers. > > > [1] > http://mirror.linux.org.au/pub/linux.conf.au/2015/Case_Room_2/Thursday/Considering_the_Future_of_Copyleft_How_Will_The_Next_Generation_Perceive_GPL.webm > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.libreplanet.org/archive/html/libreplanet-discuss/attachments/20160818/715e7460/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3822 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.libreplanet.org/archive/html/libreplanet-discuss/attachments/20160818/715e7460/attachment.bin> ------------------------------ Subject: Digest Footer _______________________________________________ libreplanet-discuss mailing list [email protected] https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss ------------------------------ End of libreplanet-discuss Digest, Vol 78, Issue 17 ***************************************************
