[sane-devel] backend distribution question

[Johannes Meixner]

Hello,

On Jan 25 02:39 Ruell Magpayo wrote (excerpt):
> I would like to  define by what I mean by: "Kyocera home based MFP devices"
> It refers to the newly released(2012) low-cost printers from Kyocera;
> FS-1020, FS-1125, FS-1120 series
>
> Some of these products have network interface but because
> it is low-cost MFP, it does not have the scan to email feature
> unlike the other Kyocera products.
>
> All processing from these devices are done at host PC side
> including the image processing.
> We are considering options on how to support linux scan...

To support scanning under Linux the only reasonable way is
to provide a driver/backend for SANE because scanning via SANE
is practically the only way how scanning happens under Linux.

The only reasonable way to provide a SANE backend to Linux users
is to make the backend in a way so that Linux distributors
can include it in the Linux distributions and that means
to make the backend as free software.

Now you (i.e. Kyocera) has the issue that you need to use
confidential/proprietary functionality which cannot be
implemented as free software.

I.e. you have the issue that you need run proprietary software.

As I explained in my previous mail, separation of proprietary
software from free software is essential.

Therefore you (i.e. Kyocera) must keep your proprietary stuff only
on your servers but you would openly release your free software
so that others can integrate your free software (and only your
free software) into SANE and this way also into Linux distributions.

When your SANE backend runs on the end-user's computer
and when it needs the proprietary functionality,
it has to execute your proprietary stuff preferably
as separated process as I explained in my previous mail.

This means your proprietary stuff must exist as executable
on the end-user's computer.

Therefore Kyocera has to provide its proprietary stuff on
Kyocera servers for download and installation by end-users.

End-user machines are usually x86/i386/i486/i586 (32-bit)
or x86_64 (64-bit) so that Kyocera has to provide its
proprietary stuff at least for those two architectures.

Accordingly Kyocera also has to provide a download and
installation tool so that end-users can easily download
and install the right proprietary stuff from the right
Kyocera servers on the end-user's computer (showing the
right license dialogs and all what is needed to do this
part correctly).

The Kyocera installation tool must also be free software
so that Kyocera users get it "out of the box" in the
Linux distributions.

At least we (i.e. SUSE/openSUSE) can only provide a
free software Kyocera installation tool "as is" and
we could even run such a tool "as is" if needed
(currently our YaST printer setup module can launch
  HP's hp-setup tool "as is" to set up HP devices).

But we would never ever download and install proprietary
stuff from Kyocera on our own (e.g. implement such
a tool on our own) because we will never ever risk
any kind of legal issue because of proprietary stuff
that is required by weak (low-cost) hardware, see
http://en.opensuse.org/SDB:GDI_Printers

Perhaps the Kyocera installation tool cannot be integrated
in SANE. Whether or not this is possible depends on what
the SANE developers decide here.

If the Kyocera installation tool cannot be integrated in SANE,
Kyocera must provide it as separated free source code package
so that Linux distributors can build it separated from SANE.

If your proprietary executable does not exist on the
end-user's computer, your SANE backend must exit appropriately
preferably with a meaningful error message that informs
the user that your proprietary stuff needs to be downloaded
from Kyocera.

This way how to deal with the issue when confidential/proprietary
functionality is needed by free software is currently used
by HPLIP (see http://hplipopensource.com/hplip-web/index.html)
when HP printers or all-in-one devices require proprietary
functionality, see
https://bugzilla.novell.com/show_bug.cgi?id=342704
in particular
https://bugzilla.novell.com/show_bug.cgi?id=342704#c3

This way works optimal for end-users, Linux distributors,
and free software developers ("optimal" means at least currently
there is no better way known how to deal with the issue).

This way is more software programming effort for the manufacturer
(keeping separated parts actually strictly separated instead of
mixing up everything into one big software monster mess).

But on the other hand this way avoids any other trouble
in particular legal issues because of the licensing.

In particular for software developers at the manufacturer
it means that they can "just do their job" (i.e. "just making
their software") which they probably like a bit more than
to deal with their legal department and the legal department
of the Free Software Foundation and the legal departments of
various Linux distributors ;-)


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer