Hello, On Jun 4 21:02 m. allan noah wrote (shortened): > SANE is GPL, with an added exception to allow proprietary front-end > programs to link against it. What you are suggesting is the opposite- > you wish to have a free 'middleware' layer, which loads closed > backends to do that actual work? I think this is in violation of the > spirit of the license exception, though perhaps not the letter. Please > read the file LICENSE in the sane-backends source, it attempts to > clarify the situation, by specifically referring to the 'licensing > status of the _program_ that uses the libraries', not the status of a > library.
The issue was also mentioned in the "SANE2, what do we want ?" mail thread, see for example http://lists.alioth.debian.org/pipermail/sane-devel/2008-April/021642.html Could you explain what the reason behind is that proprietary frontends are allowed but no proprietary plugins/modules for free backends? I.e. why are proprietary frontends considered to be acceptable while "dlopening" proprietary plugins/modules by free backends during runtime is considered to be evil? Is it because a proprietary frontend does not reduce the freedom of the user because there are also free frontends available while a backend which needs proprietary stuff for certain scanners reduces the freedom of the user when there is no free alternative backend available? I have another question: Assume because of whatever reason a scanner manufacturer cannot make a free backend (e.g. because of third-party license stuff, or just because the upper management at the manufacturer is full of fear that another manufacturer might "steal" their one-and-only-best-way-to-drive-a-scanner) but nevertheless wants to provide a SANE compatible driver. How could he do it? Would it be in compliance with the SANE license to do it like HP does it for their proprietary ZJStream printers (because of a third-party JBIG license issue): HP's HPLIP sources are perfectly free and therefore we take only the perfectly free upstream HPLIP sources, compile them, and distribute a perfectly free hplip package. We do not download and/or distribute any proprietray stuff from HP. But the perfectly free hplip package contains a perfectly free hp-setup tool which takes care of everything regarding their proprietray stuff, for example: - display the EULA, - download the right proprietray stuff from the right server, - install the proprietary stuff at the right place with the right permissions - set up the device accordingly, - whatever else... In case of HPLIP any proprietary stuff happens only between the end-user and HP. Therefore - at least from my point of view - the proprietary stuff form HP is ideal because there is nothing a distributor or re-distributor has to care about. We provide only a free tool (hp-setup) so that the end-user has an easy out-of-the-box experience to set up even hardware which requires proprietary software. As far as I know the GPL does not forbid that an end-user installs and runs whatever proprietary stuff on his machine. Therefore I think that it is in compliance with the GPL to have a GPL installation tool which installs proprietary stuff. As far as I know the GPL cares only about the licensing of source code and therefore it is very important to be aware of the strict distinction between source code and whatever binary stuff. For example - as far as I know - it is a GPL license violation to have whatever binary stuff in a GPL source code package. As far as I know any tiny bit of whatever proprietary stuff (regardless if it is binary stuff or proprietary source code) in a source code package makes the whole source code package a proprietary package. But I am neither a lawyer nor a GPL expert! You may like to have a look e.g. at http://lists.alioth.debian.org/pipermail/sane-devel/2008-April/021822.html and http://lists.alioth.debian.org/pipermail/sane-devel/2008-April/021911.html Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
