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