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 >