[sane-devel] SANE2, what do we want ?

[Olaf Meeuwissen]

Julien BLACHE <jb at jblache.org> writes:

> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>
>> The epkowa backend is free-as-in-freedom software.  It is licensed
>> under the terms of the GPL and carries an exception that allows for
>> the use of non-free extensions.
>
> "It's free software <tiny>(but for this and this and this and this model you
> need a binary-only, proprietary lib, too)</tiny>"
>
> Not exactly free by my book, I'm sorry but it really does make a
> difference.

As free as the epkowa backend software is concerned, it is free.  The
fact that it does not support all the scanner models you would like it
to without a non-free extension does not change anything to the fact
that the backend software is free-as-in-freedom.

> [snip]
>
>> Not claiming that the epkowa backend does a perfect job either, but
>> at least the epson backend does not support a number of all-in-ones.
>
> TTOMK the all-in-ones are all pretty similar devices?

Mostly yes, but the epson backend does not support all of the commands
these devices understand completely.

I remember trying the epson backend at home with an RX520 (PM-A750)
and not being able to scan.  FWIW, I can't use iscan at home because
there are no amd64 Debian packages ;-P

> [snip]
>
>> BTW, many thanks for packaging the epkowa backend in libsane-extras
>> for Debian ;-) but can you tell me why libsane has to depend on it?
>> What breaks in libsane if I yank libsane-extras?
>
> The udev rules in libsane-extras were buggy; it was absolutely harmless
> until I migrated to a new layout for installing udev rules, then all
> hell broke loose and the only option to avoid rendering systems
> unbootable was to have that dependency.

Why was that the only option?  If thee udev rules in libsane-extras
were buggy, why could you not fix that?

If libsane no longer works because libsane-extras is not installed,
then they aren't exactly "extras" in my book ;-)

> And now I no longer have to ask "do you have libsane-extras
> installed?" in bug reports, which is a selling point, really ;)

But that's just convenience.  Rather than Depends: you could have made
it a Recommends:.

>> # We're about to start providing Image Scan! for Linux .debs and this
>> # is a bit of a show-stopper conflict ...
>
> Use a diversion on libsane-epkowa.* to handle that, that's the best
> option.

What about suggestions for the conffile?  I was gonna put them in
dll.d but that doesn't look as attractive as it did before
libsane-extras became a Depends:.

> Note that I would have packaged iScan, had Epson provided a tarball
> with all the interpreters libraries.

Splitting the interpreters off from the source and binary packages was
done to reduce package size and to clearly separate free and non-free
code.  Only the non-free bits needed to build to frontend are included
in the "sources".

With 12 interpreters at the moment (and counting :-() and the need to
cater to two C++ ABIs, the non-free interpreters, which are only
needed by a select few people to begin with (and even fewer will need
all the interpreters) would bloat the packages out of any proportion.

> As it stands, I once managed to grab all the RPMs by playing with
> the webserver but:
>  - no way I was going to do that long-term

Very understandable.

>  - no way I am extracting the files from a collection of RPMs every
>    time

Apart from the interpreters, which files, if any?  Everything is in
the "source" tarball, AFAIK.

>  - redistribution is prohibited IIRC

You recall incorrectly.  Redistribution is allowed.  Modification is
allowed too.  Just about the only thing you are not allowed to do is
reverse engineering (unless for the purposes of debugging your own
applications/modifications -- a LGPL requirement).

Hope this helps,
-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/