[sane-devel] incompatible iscan-2.11.0
olaf.meeuwissen at avasys.jp
Wed Apr 30 02:35:06 UTC 2008
A bit belated perhaps but ...
Replying on personal title again. Nothing below represents my
employer's opinion or that of my employer's customer(s).
Johannes Meixner <jsmeix at suse.de> writes:
> On Apr 24 16:35 Olaf Meeuwissen wrote (shortened):
>> Johannes Meixner <jsmeix at suse.de> writes:
>> > For example I would of course still distribute the free part
>> > of Iscan in our iscan-free package but drop the packages which
>> > contain proprietary stuff and add an explanatory message to
>> > the YaST scanner config to direct the user to the Epson Avasys
>> > web site if a proprietary model is used.
>> You know what would be even better? YaST being able
>> to offer the user to download, install and configure
>> that proprietary "crap" automatically.
> Because of legal issues we cannot do anything automatically
> with proprietary stuff.
> For example when currently a proprietary model requires
> our proprietary iscan package from our CD/DVD/repository,
> I cannot install it via the YaST scanner configuration
> because here the installation would happen somewhat
> silently and automatically in the background.
When a proprietary model requires a proprietary package that does not
mean that SUSE (or any other distributor) has to provide it. What
distributors can provide the user with is a means to conveniently
download the required package from its "canonical" location and
install it. This of course after warning the user that they are about
to download and install third-party software that is absolutely not
supported by their distribution, that is non-free and that they'll
incur the wrath of RMS for using it.
# I guess I'll incur his wrath for even suggesting such an easy way to
# throw away your freedom :-(
This can be as simple as the following proof of concept:
rpm -U $package
What are the _legal_ issues with this? There are of course a few
issues to be worked out on the technical side, like for example
fetching the right architecture, but that is another issue.
> All I can do is to show a message which tells the user
> to install it manually (with the YaST installer module)
> because only the manual installation makes sure that the
> popup regarding the proprietary license is shown and that
> possible conflicts (iscan conflicts with iscan-free)
> are shown in full detail together with the matching
> choices/buttons what to do regarding a proprietary
> license and/or regarding conflicts.
Personally, I'd say your bending over backwards to make proprietary
"crap" work out of the box and expecting a bit too much from your
users on the computer knowledge front ;-)
> We take only the perfectly free-software upstream HPLIP
> package and distribute it.
> We do not download and/or distribute any proprietray stuff
> from HP.
> We distribute the HP setup tool as is in the free-software
> upstream package.
> We rely on HP's setup tool as is to take care of everything
> regarding their proprietray stuff (e.g. displaying the EULA,
> downloading the right proprietray stuff from the right server,
> install the proprietary stuff at the right place with the
> right permissions, set up the printer accordingly,
> whatever else...).
OK, *now* I see what you're getting at. Above I was thinking along
more generic lines. Stuff that would work for all proprietary crap,
not just what comes with iscan. As a I mentioned, the OpenPrinting
people are heading for something more generic and I think that SANE
could take a hint from that.
> I think for future openSUSE versions (not for 11.0 which
> provides iscan 2.10.0 packages as we did before) I will do
> the same for IScan:
> I distribute only the free parts of IScan.
> I do not distribute and/or download and/or install
> any proprietray stuff from Avasys (or elsewhere).
> Because there is no "iscan-setup" tool available,
> I can only show a message to the user to go to
> the Avasys web site.
> Perhaps a free "iscan-setup" tool in the IScan package
> would be nice to have.
Indeed it would, if it did all the things you mentioned. I guess
iscan could even try to run it in the %post of the installation to see
if anything extra needs to be done.
> This way Avasys has full control over their proprietray stuff
> and on the other hand it would remove the load from the
> distributors to deal with their proprietray stuff.
Small correction: it is not Avasys' proprietary stuff. The
proprietary stuff is EPSON's, Avasys is just(?) doing the development,
testing and distribution.
> By the way:
> Again I request to split any non-free stuff from IScan
> (i.e. the whole content of the non-free/ source directory)
> and provide the iscan frontend as separated package.
I'd love to ditch that directory but there is no viable free
alternative for libesmod at the moment and without it there's
not much point in using iscan, really.
>> The LSB's OpenPrinting workgroup is heading in that direction and IIRC
>> Till has already added support for something like that to Fedora's
>> printerconfig if I'm not mistaken. It gets the printer "driver" from
>> the Foomatic database (or via a URL registered) there. Something like
>> this could be done for scanners as well.
> We will support this for printers in the future, see
> (note the preselected "[X] Show Only Free Software").
> For the full story see
Looks interesting. Any plans to integrate scanners and all-in-ones?
> I look forward to the moment when there are LSB compatible
> IScan packages available at the LSB/OpenPrinting server!
Or at least pointers redirecting you to Avasys ;-)
> To make a maximum number of users and distributors happy,
> provide well separated packages:
> - One free software package for all architectures
> which contains the epkowa backend and the free
> iscan-setup tool.
> - One proprietary package for those architectures
> which you like which contains the iscan frontend.
> - For each proprietary model a proprietary package
> for those architectures which you like which contains
> the proprietary plugin.
> - For each proprietary model which needs firmware upload
> a proprietary package for all architectures which contains
> the firmware file.
If it were up to me, I'd do the same. The above is the only thing
that makes sense from a software design perspective.
> Note the difference:
> Proprietary plugins are architecture dependant.
> Firmware files are not architecture dependant.
I'm well aware of the difference but as long as Avasys still uses this
manual download method for packages ... you wouldn't want to download
four packages by hand just to get your device working. Even now, with
only two, people forget to download the plugin.
Hope this helps,
Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962 sign up at http://member.fsf.org/
More information about the sane-devel