[sane-devel] incompatible iscan-2.11.0

[Johannes Meixner]

Hello,

On Apr 30 11:35 Olaf Meeuwissen wrote (shortened):
> Johannes Meixner <jsmeix at suse.de> writes:
> > On Apr 24 16:35 Olaf Meeuwissen wrote (shortened):
> >> Johannes Meixner <jsmeix at suse.de> writes:
> >
> > Because of legal issues we cannot do anything automatically
> > with proprietary stuff.
...
> 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 ...

Yes.
But this is not the "automatically" which I mean.
When I say "automatically", I mean something without
user interaction.
A user dialog is what I call "manually" - i.e. the user
must actively do something - even if this "something" is
perfectly guided by YaST.


> This can be as simple as the following proof of concept:
> 
>   wget $url_to_proprietary_package
>   rpm -U $package

No.
Before the wget I would have to show the right proprietary
license dialog so that the correct proof of concept is:

wget $url_to_license_text
show the proprietary license dialog
if the user accepts the license
then wget $url_to_proprietary_package && rpm -U $package
else show a "it cannot work" message.

This leads again to the same old question:

What are the reliable fixed URLs for the right versions
of your proprietary packages?

And to a new question:

What are the reliable fixed URLs for the right license
text for the right version of your proprietary packages?

Note that on the usres's computer an older version of the
epkowa backend may run.
I would have to make sure that YaST downloads the right
version of the proprietary package.
For example our business products Suse Linux Enterprise
Server (SLES) and Suse Linux Enterprise Desktop (SLED)
have a lifetime of several years (about 5 years, sometimes
even longer).
Usually there are no package version upgrades during
lifetime (except for severe bugs, e.g. security issues,
but e.g. not just because there are some more supported
models or some new features) so that it can happen that
a SLES/SLED user runs a 5 years old epkowa backend.
Compare
https://answers.launchpad.net/hplip/+question/30595

I cannot have the license texts preinstalled.
Guess what happens if a user finds them and wonders
why the hell he has proprietary software installed
(otherwise there would be no proprietary license text)
and where the hell this proprietary software is installed?
Don't have only usual home users in mind!
Think about enterprise admins who do care about the exact
licenses of their installed systems (e.g. the workstations
where SLED runs).
I will never ever risk any tiny license issue with any
of our customers because of whatever quick and dirty
"proof of concept" hack with proprietary software.

I cannot even have the license texts on our CDs/DVDs
and install them only just before YaST shows them
because the license texts on our CDs/DVDs might be
outdated for the actually downloaded proprietary package
(have the possibly 5 years old SLED system in mind).

If I would implement something like the "proof of concept",
I need the currently right matching license text downloaded
at the same time as the proprietary package is downloaded.
I need the currently right license text separated before
any proprietary stuff is stored on the system.
I will not download and unpack any proprietary stuff
and then show the license dialog.

Alternativery provide a free "iscan-setup" tool which
does all what is necessary regarding proprietary stuff.
I can call such a tool from YaST if a model is set up
which requires proprietary stuff.


> What are the _legal_ issues with this?

Do you really want an authoritative answer?
As soon as the Avasys lawyers and our lawyers start a
discussion about the legal issues, you can probably wait
very long until I might start to implement something.
Perhaps in the end everything is very simple but likely
the lawyers need much time until the issue is finished.

Just trust me and provide what I request to get good support
with reasonable effort in a reasonable time or you might
get no support at all (depending on what the lawyers do).


> Above I was thinking along more generic lines.  Stuff that
> would work for all proprietary crap,
> not just what comes with iscan.

Usually each proprietary stuff has its own special issues
(which are introduced by each special proprietary license)
so that usually each proprietary stuff requires its own
special handling.

The proprietary crap form HP is ideal because there is nothing
a distributor has to care about - just provide HP's free stuff.


> Small correction: it is not Avasys' proprietary stuff.  The
> proprietary stuff is EPSON's, Avasys is just(?) doing the
> development, testing and distribution.

A good example why I must get the right proprietary license
text from an URL from you so that the right spelling is shown
to the user.

Think about the very unlikely case that company names change
which might make a pre-installed license text outdated
(have the possibly 5 years old SLED system in mind)
e.g. when a company which does no longer exists with
this name grants an old license for a package which is
downloaded and installed right now - I am no lawyer but
this looks at least plain wrong.

Alternativery provide a free "iscan-setup" tool which
does all what is necessary regarding proprietary stuff
and I would no longer have to care about proprietary
issues because then it is totally up to you.


> > 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.

Perhaps my request was not clear enough:
I request to split any non-free stuff from IScan (i.e. the
whole content of the non-free/ source directory) to have
free sources for the epkowa backend and whatever else
free stuff in IScan (e.g. a iscan-setup tool) and
provide the free sources as one source code package
and on the other hand provide the iscan frontend with
its proprietary library as separated source code package.


> > We will support this for printers in the future, see
> > http://en.opensuse.org/Image:Printer_mschmidkunz_rc2_driverwizard_greyed.png
> > (note the preselected "[X] Show Only Free Software").
> > For the full story see
> > http://en.opensuse.org/YaST/Development/Printer_Enhancement
> 
> Looks interesting.  Any plans to integrate scanners and all-in-ones?

As soon as scanner stuff appears at the LSB/OpenPrinting server,
we will of course think about how to integrate them too.

Currently I don't know if and how LSB compatible packages
could be provided on another server.
There are discussions regarding trust.
E.g. how to make sure that what is downloaded from whatever
URL is actually what was tested and certified by the LSB.
See the mail thread with subject
"There is no good package management for LSB packages"
on the lsb-discuss at lists.linux-foundation.org list:
https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-February/004642.html
in particular see
https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-February/004647.html
I answered too but unfortunately only on lf_driver_backport, see
https://lists.linux-foundation.org/pipermail/lf_driver_backport/2008-February/000201.html


> > 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.

The above is also the only thing that makes sense from
a legal/lawyers perspective.

I must split always the proprietary stuff manually from the IScan
sources to make our iscan-free package because I cannot provide
proprietary stuff in our iscan-free source package.

(I explained this a long time ago in exhaustive detail.)

 
> > 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.

I noticed the issues.

But what hinders Avasys to make big all-in-one packages
for the different kind of models?

I talk about how to split the sources and how to provide the
sources so that distributors and lawers are happy.

Avasys is of course totally free to take all sources
and make one big-and-fat all-in-one binary package with
all plugins for all models or several all-in-one binary
packages with only one plugin for each kind of model
or whatever Avasys likes.

Do not mix up source packages and binary packages!

Clean up your sources!

Provide clean source packages!

Make it easy for the distributors to make very most
of your users happy out of the box.

Optionally provide whatever binary packages you like
for those cases where the distributors cannot make
your users happy out of the box.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex