Got it, thanks for your support! -----Original Message----- From: sane-devel-bounces+ruell.magpayo=ddp.kyocera.com at lists.alioth.debian.org [mailto:sane-devel-bounces+ruell.magpayo=ddp.kyocera....@lists.alioth.debian.org] On Behalf Of Johannes Meixner Sent: Friday, January 25, 2013 6:18 PM To: sane-devel at lists.alioth.debian.org Subject: Re: [sane-devel] backend distribution question
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 -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-request at lists.alioth.debian.org
