[sane-devel] License pop-up

[abel deuring]

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-hack at 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
>