Hi Abel, An interesting perspective, thank you. I should probably add that a hospital (or any critical environment) should be using certified equipment and software, although it is easy to imagine a situation where this is not so. For this reason, I think it is wise to at least state that there is no warranty and users use at their own risk.
Cheers, Ralph On Wed, Sep 18, 2019 at 12:18 PM abel deuring <adeur...@gmx.net> wrote: > I thought that I should give my 2 cents when you wrote your first mail > in this thread but I got distracted by a number of completely unrelated > things. TL; DR: I like your suggestion about a splash screen that > reminds about the GPL and "no warranty claims" and that is always shown > when Xsane starts (or scans for devices – I don't care about that point > ;). For the reason, see below. > > Am 17.09.19 um 23:48 schrieb Ralph Little: > > Hi, > > > > On Tue, Sep 17, 2019 at 2:28 PM Olaf Meeuwissen < > paddy-h...@member.fsf.org> > > wrote: > > > >> > >> No matter who's to "blame", Oliver, while still the author of (almost) > >> all the code, is no longer maintaining XSane. The SANE Project has > >> taken over (with Oliver's "blessing") and now continues the maintenance > >> of XSane. As such, I think we are at liberty to make some changes in > >> this area. > >> > > > > Thanks for the clarity in this area. > > > > > >> > >> I would > >> > >> - not make users accept the GPL (because they don't have to in the > >> first place), but instead make the GPL (version 2) available via an > >> "About" dialog, either in full or via a link. > >> > > > > Agreed. > > > > > >> - replace any kind of "NO WARRANTY" click-through with a warning about > >> the unlikely possibility of damaging users' hardware. > >> # Untested and newly added devices are somewhat more prone to damage > >> # than devices that have been supported for a long time. > >> The warning should be shown at program start-up until the user opts > >> out of this behaviour. This should not be a system-wide opt-out. It > >> should be a *per user* opt-out. > >> > > > > That squares with my idea for a splashscreen, so it sounds like we are in > > agreement. > > Although for my suggestion, the splashscreen would always show because > > XSane is probing for devices. > > I'll think about it a bit. > > > A long time ago, Kazuya Fukuda and myself worked on the sharp backend. > The usual development work, nothing remarkable to write about – except > for one bug and a fix for this bug that made me feel somewhat > uncomfortable for a few months. > > It must have been in the late 90ies or so that I received an email from > somebody working for one of the larger Linux distributors asking me to > fix a bug in the sharp backend that occurred regularly when a customer > of the distributor tried to start a scan. > > Technically, the bug was nothing remarkable, "only" a segfault caused by > dereferencing an invalid pointer. Easy to fix. > > Somewhat more interesting, but not the main point I want to make here, > was that the bug occurred in a code path that deals with handling a > transparency unit. Such a transparency unit is an optional accessory for > the Sharp scanners – and neither Kazuya nor I had such a unit at that > time. I am not sure that I would nowadays still want to write code that > I can't test myself… > > A more important detail was this: The segfault occurred in a part of the > backend which handles a status message from the scanner that scan sensor > calibration failed. So my first attempt for a bug fix was to just fix > the segfault, let the backend return an error code to the frontend and > add a DBG() macro to "report" the failed calibration. > > Now things became somewhat odd: The guy from the Linux distributor told > me that their customer insisted that it should be possible to continue a > scan even if the calibration failed. I asked the guy from the > distributor if the customer was aware of the drawbacks of scanning with > with an uncalibrated scan sensor. He answered, yes, they konw it and in > fact the scans of the X-rays images made with the Windows driver have > some "streaks". > > Ewwww. X-ray images. Is the customer a hospital or a doctor's practice > and they want to replace their physical X-ray archive with digital data? > The folks from the distributor did not want to tell me until their > project would be finished. > > So… what should I do? A few years before somebody who had worked as a > salesman for a company producing "electronic equipment" for hospitals > told me a slightly scary story: A hospital sued the manufacturer of a > cardiotocograph claiming that the device was not working well: The > device could raise an alarm to alert nurses or doctors when something > was developing badly (sorry – I have no clue what medical conditions can > be measured/estimated/assessed with these devices). The problem was that > the alarm threshold could be adjusted and users had to balance possible > false alarms against the risk of missing serious medical issues. > According to the salesguy the users in this hospital opted for a > threshold setting that raised an alarm very late because they felt that > thay had too many false alarm with a more sensitive threshold > adjustment. The consequence: A dead-born baby. The conclusion of the > salesguy (and I agree): Doctors sometimes have no real clue what they > can expect from technical equipment they are working with. > > Now, crappy archive scans of X-ray images are not such a serious matter > – but on the other hand it is easier to sue a single developer than a > company that knows what can happen in the, how should I say, > "medical-technical business". So I felt a bit uncomfortable with the > request that the backend should ignore the calibration error. > > Eventually, I came up with this solution: By default, the backend still > returns an error for calibration failures but if some option in the > config file is set, this error will be ignored. And I asked the folks > from the distributor to explain to their customer that ignoring the > error is generally not a good idea. > > And finally it also turned out that my concerns about "scary users" were > unfounded: The customer of the Linux distributor was not a hospital but > a (German) organsation called Bundesanstalt für Fleischforschung – > federal institute for meat research (Seriously, such an organisation > exists – ask Google if you don't believe me ;). And I've never heard a > complaint about the low quality of the scans. > > Anyway, I had a short look into the discussion around the Debian bug > report. On first glance, Oliver's concerns about inadvertently deleted > files may sound a bit far fetched (we don't make this kind of > programming mistakes, do we?), but scanners damaged by a backend in > alpha or beta status are probably more realistic. And users with > unrealisic expectations can always be a risk. As discussed on the Debian > bug tracker and also here in this thread, pointing to the "no warranty" > clause probably does not help in every situation – but I think users > should be reminded about it nevertheless. > > cheers > Abel > > > > Perhaps I could knock up some prototypes for people to try to see what > they > > like. > > > > > >> The warning could include a link to the full license terms. > >> The opt-out could be reset when a newer backend version is detected > >> (as newer backend might introduce breakage). In this case, it should > >> be made clear what caused the need to opt out again. > >> > >> > > That sounds fair, but personally, I find those splashscreens that > re-appear > > after previously opting out irritating. > > > > Cheers, > > Ralph > > > >