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/
