[sane-devel] backend distribution question

[Johannes Meixner]

Hello,

On Jan 24 01:44 Ruell Magpayo wrote (excerpt):
> I am an engineer from Kyocera and we are writing
> the SANE support for Kyocera home based MFP devices,

I appreciate it very much when engineers from device manufacturers
get in contact with free software developers!

Out of curiosity:

Are there "Kyocera home based MFP devices" with built-in
network interface?

If yes, is there no longer support for "stand-alone scanning to e-mail"
as described in
http://en.opensuse.org/SDB:Configuring_Scanners#Scanning_via_Network

I ask because a longer time ago I was in contact with Kyocera engineers
who asked me about SANE support for Kyocera network MFP devices and
I asked them regarding "stand-alone scanning to e-mail" support and
they told me that all Kyocera network MFP devices have built-in
"stand-alone scanning to e-mail" functionality so that there was
no need for SANE support for Kyocera network MFP devices at that
time (some years ago).

Has something changed here?


> We came across a problem that needs feedback from SANE community,
> our situation is, all Kyocera scanner uses a 3rd party API for
> bank notes scanning prevention, this library is confidential
> and cannot be distributed along with the source code.
> Even Kyocera driver engineers does not have access to the
> source code of the said library.
>
> So we are left with the following options;
>
> 1.
> Distribute Kyocera backends(*.so,etc) as binaries only.

Never ever do this - unless you really want to run into
endless troubles because this means that Kyocera cannot get
any kind of support for their software:

Free software developers (in particular SANE developers)
cannot support your software without free sources.

Linux distributors cannot provide your software "out of the box"
in their Linux distributions without free sources, compare
http://en.opensuse.org/SDB:Information_for_Printer_Manufacturers_Regarding_Linux_Support#Conditions
--------------------------------------------------------------------
Linux drivers ... must

have an open source code,

be subject to a sufficiently free license (e.g., GPL, BSD)
that permits modification of the source code, distribution,
and redistribution

have a platform-independent source code.

Thus, we will be able to integrate it in our products, as the
standard software for our products is compiled separately
for the various hardware platforms from the source code.
--------------------------------------------------------------------


> 2.
> Include the backend source code to sane distribution
> and just link the 3rd party API

What exactly do you mean with "just link"?

If "just link" means to link it as usual in a mandatory way
at run-time during start-up of the executable by the linker
so that your software would not run at all without having it
linked with those proprietary library, then you also run
into endless troubles:

License troubles because usually one cannot "combine"
free software parts and proprietary software parts
into a resulting software without causing license issues.

When your software would not run at all without the proprietary stuff
you would hardly get any kind of support for your software because
free software developers and users and Linux distributors
are usually not interested in software that does not run at all
without proprietary stuff.

In contrast if "just link" means to use the proprietary parts
only in an optional way at run-time only if really needed
so that your software can also run without the proprietary stuff,
then it should be o.k.

To avoid license issues it is required to get the proprietary parts
very well separated from the free software.

Separation of proprietary parts from free parts is essential!

Both for the sources (free sources must not contain any tiny
proprietary part) and for the binaries (free software
binaries/executables must not require proprietary stuff to run).

The best separation is when the proprietary stuff is a separated
executable that is run by the free software only if really needed.

In this case the free software executable would fork a child
process where the child process runs the proprietary executable
that communicates with its free software parent process via pipes
or any other standard process communication method.

E.g. this is used by Ghostscript which can run an IJS child process
(called "IJS server") where the IJS child process does the actual
printer driver functionality (convert Ghostscript bitmap into a
printer-specific data stream) that communicates with Ghostscript
via pipes (one pipe from Ghostscript to the IJS child to send
the Ghostscript bitmap to the IJS child and another pipe from
the IJS child to Ghostscript to send the printer-specific data
back to Ghostscript).


> We have no problem in including the backend source code
> to the standard SANE distribution if not for the 3rd party
> library I mention above.

Is it allowed for end-users to use "Kyocera home based MFP devices"
even without those "bank notes scanning prevention" functionality?

Or is "bank notes scanning prevention" required by laws in this
or that countries (in addition to the usual laws that of course
generally forbid to counterfeit money regardless of the method)?

As far as I understand your description it seems the "Kyocera home
based MFP devices" do not have "bank notes scanning prevention"
functionality built-in in their hardware/firmware so that
"bank notes scanning prevention" happens in the scanner driver
software that runs on the end-users machines.

Is my understanding correct?


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