[sane-devel] incompatible iscan-2.11.0

[m. allan noah]

On 4/30/08, Johannes Meixner <jsmeix at suse.de> wrote:
>
>  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.
>
>
>

or, there is another solution- Novell/Suse (or anyone else, for that
matter) hires a developer to reverse-engineer some of the machines in
question. Legal problems and multi-platform problems all solved. Or,
we keep griping about it until one of us gets fed up enough to go out
and do it on his own, the v200 is only 75 USD...

allan
-- 
"The truth is an offense, but not a sin"