[sane-devel] Please give me some help to solve the license issues in using sane

[Johannes Meixner]

Hello,

On 5 Jun Wang Mengqiang wrote (shortened):
> we plan to use several special modules  which do not contain
> any open source code from sane or other party, because they
> contain some tecnology that we do not want to open.
> So, that is, our backend is composed of two parts,
> one part is open source code which we refer to the source
> code from sane, and another part is one that should not be open.
> Of course, the first part(open source part) will call the
> functions in the second part(closed source part).
> After compiling and linking them together, we get the backend.

On Jun 5 Daniel Glöckner wrote (shortened):
> ... usually a scanner driver just needs to write some
> registers and accept the incoming image data.
...
> If you want to implement image processing algorithms
> (dust removal, ICC profiles, descreening), don't.
> This should be done in frontends.

On Jun 5 Theodore Kilgore wrote (shortened):
> ... the only things we would be interested in are the basics
> of the interaction with the hardware, any data compression
> algorithms used for imaging data

On Jun 5 Allan Noah wrote (shortened):
> SANE is GPL, with an added exception to allow proprietary
> front-end programs to link against it.
...
> Sane is not here to provide sanei for proprietary
> backends to steal.

On Jun 6 Olaf Meeuwissen wrote (shortened):
> If GPL'd code uses a non-compatible library via dlopen that's just as
> much a violation as linking to it directly.  The code runs in the same
> process space.  That makes the combined work a derivative, so, all the
> terms of the GPL need to be met.
...
> A good rule of thumb is to look at what happens at run-time.  If GPL
> incompatible binary stuff and binary bits built from GPL'd source code
> are used by a _single_ process (as jugded by PID), then that's a big
> fat violation.  However, if both parts run as separate processes (so
> they have different PIDs) and communicate via a socket or some other
> IPC mechanism, using a trivial or open, well-documented protocol, then
> that is not a violation.


Unfortunately Wang Mengqiang didn't tell what kind of
functionality it is which they do not want to open.
Is it basic scanner I/O functionality, or is it data
compression algorithms, or image processing algorithms?

Nevertheless I like to try a proposal how it might be done.

When the backend uses SANE I/O functionality (sanei),
it must be under GPL.

Because the license issue is at least not very clear,
the backend cannot link with proprietary stuff.

But the backend could fork a separated process which runs
whatever proprietary executable and communicate with it
via whatever IPC mechanism e.g. a socket or even via
traditional pipes, see for example the IJS interface
http://hplip.sourceforge.net/tech_docs/hpijs.html

Therefore only the part which does the basic I/O must be
under GPL but e.g. data compression algorithms could run
as proprietary executable in a separated process.

A different case are image processing algorithms which
should run in the frontend. Because of the exception in SANE
this can be done in a proprietary frontend executable.


Therefore it might be done as follows:

When a free frontend is used:
------------------------------------------------------------------
/usr/bin/scanimage (SANE frontend): GPL
   |
   | link via dlopen
   |
/usr/lib/libsane.so (SANE dll meta-backend): GPL
   |
   | link via dlopen
   |
/usr/lib/sane/libsane-backend.so (basic I/O backend): GPL
   |
   | whatever IPC mechanism
   |
/usr/bin/canoncompress (data compression): proprietary executable
------------------------------------------------------------------

When a proprietary frontend is used:
------------------------------------------------------------------
/usr/bin/canonscan (frontend with image processing): proprietary
   |
   | link via dlopen
   |
/usr/lib/libsane.so (SANE dll meta-backend): GPL
   |
   | link via dlopen
   |
/usr/lib/sane/libsane-backend.so (basic I/O backend): GPL
   |
   | whatever IPC mechanism
   |
/usr/bin/canoncompress (data compression): proprietary executable
------------------------------------------------------------------

I would appreciate your comments.


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