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
