[sane-devel] License pop-up

[Ralph Little]

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 <adeuring at 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-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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20190918/b77bac64/attachment-0001.html>