[sane-devel] problems with genesys and MD6228
Le Friday 06 June 2008 20:15:36 Werner Holtfreter, vous avez ?crit?: > Am Mittwoch, 4. Juni 2008 21:09:56 schrieb stef: > > you can compile and test CVS without installing it system-wide. > > In a command shell, create a directory then 'cd' to it. > > First you have to get the sources with (see > > http://www.sane-project.org/cvs.html): > > > > cvs -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane > > login cvs -z3 > > -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane co > > sane-backends > > > > Once you have the sources, 'cd' to sane-backends, then configure > > the build with: > > ./configure --prefix=/usr --sysconfdir=/etc > > > > then compile with: > > make > > > > Then you can use the attached 'genesys' script (which must be > > copied in the sane-backends/backend directory) and run it to test > > your scanner with the new backend without installing it. It runs > > with full debug. You can edit it to change resolution, width, > > height and coordinates. The scanned picture will be in > > 'scan.pnm'. > > Hallo Stef, > > thank you for the helpfully instruction! > > > In case you run any problem, let us know. > > The scanner didn't do anything. > > When compiling (or configure) I read a warning "without usb"... > > The scan.log: > > [sanei_debug] Setting debug level of genesys to 511. > [genesys] SANE Genesys backend version 1.1 build 9 from sane-backends > 1.1.0-cvs [genesys] sane_init: authorize != null > [genesys] sane_init: little endian machine > [genesys] sane_init: reading config file `genesys.conf' > [genesys] sane_init: config file line 1: ignoring comment line > [genesys] sane_init: config file line 2: ignoring empty line > [genesys] sane_init: config file line 3: ignoring comment line > [genesys] sane_init: config file line 4: ignoring comment line > [genesys] sane_init: config file line 5: ignoring comment line > [genesys] sane_init: config file line 6: ignoring comment line > [genesys] sane_init: config file line 7: ignoring empty line > [genesys] sane_init: config file line 8: ignoring comment line > [genesys] sane_init: config file line 9: ignoring comment line > [genesys] sane_init: config file line 10: ignoring empty line > [genesys] sane_init: config file line 11: ignoring comment line > [genesys] sane_init: config file line 12: ignoring comment line > [genesys] sane_init: config file line 13: ignoring empty line > [genesys] sane_init: config file line 14: ignoring comment line > [genesys] sane_init: config file line 15: ignoring comment line > [genesys] sane_init: config file line 16: ignoring empty line > [genesys] sane_init: config file line 17: ignoring comment line > [genesys] sane_init: config file line 18: ignoring comment line > [genesys] sane_init: config file line 19: ignoring empty line > [genesys] sane_init: config file line 20: ignoring empty line > [genesys] sane_init: config file line 21: ignoring comment line > [genesys] sane_init: config file line 22: ignoring comment line > [genesys] sane_init: config file line 23: ignoring comment line > [genesys] sane_init: config file line 24: ignoring empty line > [genesys] sane_init: config file line 25: ignoring comment line > [genesys] sane_init: config file line 26: trying to attach `usb 0x0461 > 0x0377' [genesys] sane_init: config file line 27: ignoring empty line > [genesys] sane_init: config file line 28: ignoring comment line > [genesys] sane_init: config file line 29: trying to attach `usb 0x03f0 > 0x0901' [genesys] sane_init: config file line 30: ignoring empty line > [genesys] sane_init: config file line 31: ignoring comment line > [genesys] sane_init: config file line 32: trying to attach `usb 0x04a9 > 0x2213' [genesys] sane_init: config file line 33: ignoring empty line > [genesys] sane_init: config file line 34: ignoring comment line > [genesys] sane_init: config file line 35: trying to attach `usb 0x04a9 > 0x221c' [genesys] sane_init: exit > [genesys] sane_open: start (devicename = `genesys') > lt-scanimage: open of device genesys failed: Invalid argument > [genesys] sane_exit: start > [genesys] sane_exit: exit > -- > Viele Gr??e > Werner Holtfreter Hello, this strange. This could be related to the possible lack of libusb you mention. On distributions, libraries are often split in two packages, one for runtime and another for development. You may have to check you have the 'devel' libusb package installed (there should be an /usr/include/usb.h file and a /usr/lib/libusb.a or libusb.so on your system). Also, when running configure, you may add the '--enable-libusb' switch to be sure libusb support is compiled in. To be sure run the following commands: make distclean ./configure --prefix=/usr --sysconfdir=/etc --enable-libsub Regards, Stef
[sane-devel] problems with genesys and MD6228
Am Mittwoch, 4. Juni 2008 21:09:56 schrieb stef: > you can compile and test CVS without installing it system-wide. > In a command shell, create a directory then 'cd' to it. > First you have to get the sources with (see > http://www.sane-project.org/cvs.html): > > cvs -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane > login cvs -z3 > -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane co > sane-backends > > Once you have the sources, 'cd' to sane-backends, then configure > the build with: > ./configure --prefix=/usr --sysconfdir=/etc > > then compile with: > make > > Then you can use the attached 'genesys' script (which must be > copied in the sane-backends/backend directory) and run it to test > your scanner with the new backend without installing it. It runs > with full debug. You can edit it to change resolution, width, > height and coordinates. The scanned picture will be in > 'scan.pnm'. Hallo Stef, thank you for the helpfully instruction! > In case you run any problem, let us know. The scanner didn't do anything. When compiling (or configure) I read a warning "without usb"... The scan.log: [sanei_debug] Setting debug level of genesys to 511. [genesys] SANE Genesys backend version 1.1 build 9 from sane-backends 1.1.0-cvs [genesys] sane_init: authorize != null [genesys] sane_init: little endian machine [genesys] sane_init: reading config file `genesys.conf' [genesys] sane_init: config file line 1: ignoring comment line [genesys] sane_init: config file line 2: ignoring empty line [genesys] sane_init: config file line 3: ignoring comment line [genesys] sane_init: config file line 4: ignoring comment line [genesys] sane_init: config file line 5: ignoring comment line [genesys] sane_init: config file line 6: ignoring comment line [genesys] sane_init: config file line 7: ignoring empty line [genesys] sane_init: config file line 8: ignoring comment line [genesys] sane_init: config file line 9: ignoring comment line [genesys] sane_init: config file line 10: ignoring empty line [genesys] sane_init: config file line 11: ignoring comment line [genesys] sane_init: config file line 12: ignoring comment line [genesys] sane_init: config file line 13: ignoring empty line [genesys] sane_init: config file line 14: ignoring comment line [genesys] sane_init: config file line 15: ignoring comment line [genesys] sane_init: config file line 16: ignoring empty line [genesys] sane_init: config file line 17: ignoring comment line [genesys] sane_init: config file line 18: ignoring comment line [genesys] sane_init: config file line 19: ignoring empty line [genesys] sane_init: config file line 20: ignoring empty line [genesys] sane_init: config file line 21: ignoring comment line [genesys] sane_init: config file line 22: ignoring comment line [genesys] sane_init: config file line 23: ignoring comment line [genesys] sane_init: config file line 24: ignoring empty line [genesys] sane_init: config file line 25: ignoring comment line [genesys] sane_init: config file line 26: trying to attach `usb 0x0461 0x0377' [genesys] sane_init: config file line 27: ignoring empty line [genesys] sane_init: config file line 28: ignoring comment line [genesys] sane_init: config file line 29: trying to attach `usb 0x03f0 0x0901' [genesys] sane_init: config file line 30: ignoring empty line [genesys] sane_init: config file line 31: ignoring comment line [genesys] sane_init: config file line 32: trying to attach `usb 0x04a9 0x2213' [genesys] sane_init: config file line 33: ignoring empty line [genesys] sane_init: config file line 34: ignoring comment line [genesys] sane_init: config file line 35: trying to attach `usb 0x04a9 0x221c' [genesys] sane_init: exit [genesys] sane_open: start (devicename = `genesys') lt-scanimage: open of device genesys failed: Invalid argument [genesys] sane_exit: start [genesys] sane_exit: exit -- Viele Gr??e Werner Holtfreter
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, Jun 06, 2008 at 11:10:52AM -0400, m. allan noah wrote: > 3. you can write a partly free backend, that dynamically links to the > closed parts, provided that you place a license exception in the free > part allowing said linking. you cannot use any code from SANE, other > than sane.h and the sane specification, in either part. > > 4. you can write an entirely closed backend. you cannot use any code > from SANE, other than sane.h and the sane specification. All GPL frontends using these backends would need a license exception as well. Daniel
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, 6 Jun 2008 11:10:52 -0400 "m. allan noah" wrote: > yes- this seems reasonable, however, this 'program' cannot be derived > from existing GPL'd software that does not already have this added > permission, because that would change the original program's license > without permission of the authors. correct. > so, is our answer to Mengqiang that there are only four choices? > > 1. you can write an entirely free backend, and use code from SANE. yay! :) > 2. you can write a partly free backend, that runs the closed parts as > a separate process, and use code from SANE in the free part, provided > that the interface to the closed parts is simple and well documented. this is the hp way if i've got it corretly. I find it a bit ugly. > 3. you can write a partly free backend, that dynamically links to the > closed parts, provided that you place a license exception in the free > part allowing said linking. you cannot use any code from SANE, other > than sane.h and the sane specification, in either part. this means that the sane I/O facilities cannot be used. however it may be the cleanest thing. that's similar to the epkowa way, which uses sane io facilities iirc? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Please give me some help to solve the license issues in using sane
Theodore Kilgore, Thank you for your ardent reply. I feel your earnest expectation to improve the communication with hardware manufacture. But, very sorry, I am afraid I have no ability to take this responsibility. Thank you sharing the possible reasons on the block of communication. Whatever, please don't consume too much time to annoy yourself. The communication and cooperation must base on the common interest ,or benefit especially for commerce. So, I think, the major factor is whether the hardware manufacturer's has the relative strategy and whether manufaturer will obtain, but not lost the benefit. You know, company has to keep careful to business secret against competitor, and risk of patent or license. IMHO, a developer can be proud that he is able to learn more knowledge by interrup, inverse programming, but as a company it has to consider whether it is proper or legal. In fact, I understand and respect the spirit of open and free in open source world. I feel it will be very important and meaningful if open source and commerce(non open source) software can benefit each other in the cooperation. Maybe, it need understanding and some concede from both sides. it is necessary to avoid either absolute commerce or absolute free. That will benefit the end user finally. your politeness and enthusiasm impressed me deeply. very glad to exchange personal opinion. Wang mengqiang >;-Original Message- >;From: kilgota at banach.math.auburn.edu >;[mailto:kilgota at banach.math.auburn.edu] >;Sent: Friday, June 06, 2008 9:00 AM >;To: Alessandro Zummo >;Cc: Wang Mengqiang; SPD-GW; sane-devel at lists.alioth.debian.org >;Subject: Re: [sane-devel] Please give me some help to solve >;the license issues in using sane >; >; >;Wang Mengqiang, >; >;I am not one of the regular SANE developers, but I am quite >;active in another, similar project, Gphoto, which supports >;digital still cameras. I find this thread interesting because >;it raises issues which affect us all. >;I hope very much that the SANE developers will not mind if I >;join this discussion. >; >;Wang (or should I address you by Mengqiang; please excuse my >;ignorance of your national customs), thank you very much for >;bringing these questions to us. >; >;Why do I say this in spite of the fact that some of the >;answers you got seem to be somewhat negative? The reason I >;say this is that any kind of communication at all with >;hardware manufacturers is practically impossible for us to >;carry out. It seems that there is an extreme cultural divide >;and lack of understanding. Far more typical it is that we, >;free software developers, send letters or e-mails and we get >;totally ignored. Just as a recent example, three days ago, I >;sent to a company in Taiwan a very polite request for >;information about a certain camera chip. It was not the first >;time that I tried to write to them. This request, just like >;all previous ones, has obviously been simply ignored. I know >;for a fact, too, that the SANE project has similar >;difficulties of communication as we do. >;I would like to take this seeming opportunity to ask you why >;such communication problems exist. Why is the most usual >;response to any such request from any of us simply to ignore >;the request and not even to acknowledge that the request has >;been received? >; >;I can imagine several reasons behind this lack of two-way >;communication. I do not know which, if any, of the following >;apply, or whether the problem is something else. Please help >;me understand: >; >;1. Somehow we do not know how to address our letters >;properly, or how to ask in a manner which is perceived as >;polite. Some of us may be guilty of that. In my case, at >;least, and in the case of most individuals who have some >;cross-cultural knowledge, we do not knowingly do that. >; >;2. Somehow it is perceived that we are in competition with >;the company. If this is the situation, then I do not >;understand. We are not in the business of making hardware, >;whether processor chips, scanners, or cameras. We do not >;intend to enter such business and thereby to rob the sons and >;daughters of other countries of the ability to earn a decent >;living. We are interested in making the hardware work, >;possibly to work better, and to write good support software >;for it. We would be even happier to do this in active >;cooperation with hardware manufacturers, believe me, and it >;also appears to me that they would thereby sell more hardware. >; >;3. Perhaps the manufacturer perceives that cooperation with >;us would impair the relationships with the other companies >;which write the software drivers for the hardware. If so, I >;do not completely understand this, either. Our software is >;not intended to run on Microsoft Windows, the dominant >;operating system. Rather, it is intended to work on operating >;systems for which the hardware ma
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, 6 Jun 2008 16:36:39 +0200 Alessandro Zummo wrote: > On Fri, 6 Jun 2008 10:26:04 -0400 > "m. allan noah" wrote: > > > > > no, the GPL is all about derivative works and combining code, it makes > > no difference the direction: > > You are probably right, the closest entry in the faq that describes this > situation > seems to be http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins but also relevant are: http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs so if I am the author of the GPLed software it seems that I'm able to give an exception and link against a non GPL lib. If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, 6 Jun 2008 10:26:04 -0400 "m. allan noah" wrote: > > no, the GPL is all about derivative works and combining code, it makes > no difference the direction: You are probably right, the closest entry in the faq that describes this situation seems to be http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case. So, for example, if a GPL backend uses a closed source "plugin" to decode the received data, that would be a borderline case. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, 6 Jun 2008 09:54:13 -0400 "m. allan noah" > gpl faq is pretty clear on this one: > > If the modules are included in the same executable file, they are > definitely combined in one program. If modules are designed to run > linked together in a shared address space, that almost surely means > combining them into one program. Ok, but where it is saying that a GPL app cannot use a non GPL library? I think the faq has been written from the point of view of someone who tries to use a GPL library in a closed source program. Here we have a GPL app that may be using a closed source library. Unless the license of the library forbids that, it should be fine, right? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, 06 Jun 2008 09:24:25 +0900 Olaf Meeuwissen wrote: > > 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. I'm not a lawyer, but I'm not sure of this. I always thought that using dynamic linking would allow for a proper separation of GPL/non-GPL code. That means that a GPL caller and a non-GPL library should be ok, while the inverse it's not. right? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Please give me some help to solve the license issues in using sane
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
[sane-devel] Please give me some help to solve the license issues in using sane
On 6/6/08, Alessandro Zummo wrote: > On Fri, 6 Jun 2008 11:10:52 -0400 > > "m. allan noah" wrote: > > > > yes- this seems reasonable, however, this 'program' cannot be derived > > from existing GPL'd software that does not already have this added > > permission, because that would change the original program's license > > without permission of the authors. > > > correct. > > > > so, is our answer to Mengqiang that there are only four choices? > > > > 1. you can write an entirely free backend, and use code from SANE. > > > yay! :) > > > > > 2. you can write a partly free backend, that runs the closed parts as > > a separate process, and use code from SANE in the free part, provided > > that the interface to the closed parts is simple and well documented. > > > this is the hp way if i've got it corretly. I find it a bit ugly. > > > > > 3. you can write a partly free backend, that dynamically links to the > > closed parts, provided that you place a license exception in the free > > part allowing said linking. you cannot use any code from SANE, other > > than sane.h and the sane specification, in either part. > > > this means that the sane I/O facilities cannot be used. however > it may be the cleanest thing. > > that's similar to the epkowa way, which uses sane io facilities > iirc? well, if epkowa dynamically links and uses sanei, then it is not using #3- it might be violating the license? Olaf- can you describe the mechanism? allan -- "The truth is an offense, but not a sin"
[sane-devel] Please give me some help to solve the license issues in using sane
On 6/6/08, Alessandro Zummo wrote: > On Fri, 6 Jun 2008 16:36:39 +0200 > > Alessandro Zummo wrote: > > > > On Fri, 6 Jun 2008 10:26:04 -0400 > > "m. allan noah" wrote: > > > > > > > > no, the GPL is all about derivative works and combining code, it makes > > > no difference the direction: > > > > You are probably right, the closest entry in the faq that describes this > situation > > seems to be http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins > > > > but also relevant are: > > http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs > http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs > > so if I am the author of the GPLed software it seems that I'm able > to give an exception and link against a non GPL lib. > > > If you want your program to link against a library not covered by the system > library exception, you need to provide permission to do that. > > yes- this seems reasonable, however, this 'program' cannot be derived from existing GPL'd software that does not already have this added permission, because that would change the original program's license without permission of the authors. so, is our answer to Mengqiang that there are only four choices? 1. you can write an entirely free backend, and use code from SANE. 2. you can write a partly free backend, that runs the closed parts as a separate process, and use code from SANE in the free part, provided that the interface to the closed parts is simple and well documented. 3. you can write a partly free backend, that dynamically links to the closed parts, provided that you place a license exception in the free part allowing said linking. you cannot use any code from SANE, other than sane.h and the sane specification, in either part. 4. you can write an entirely closed backend. you cannot use any code from SANE, other than sane.h and the sane specification. Note that Mengqiang's original suggestion of having a combined library (or even collection of libs) that has some SANE code in it is specifically not allowed? allan -- "The truth is an offense, but not a sin"
[sane-devel] Please give me some help to solve the license issues in using sane
Hello, On Jun 5 11:30 m. allan noah wrote (shortened): > Sane is not here to provide sanei for proprietary backends to steal. Many thanks! Now it is clear for me! Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] Please give me some help to solve the license issues in using sane
On 6/6/08, Alessandro Zummo wrote: > On Fri, 6 Jun 2008 09:54:13 -0400 > "m. allan noah" > > > > gpl faq is pretty clear on this one: > > > > If the modules are included in the same executable file, they are > > definitely combined in one program. If modules are designed to run > > linked together in a shared address space, that almost surely means > > combining them into one program. > > > Ok, but where it is saying that a GPL app cannot use a non GPL > library? > > I think the faq has been written from the point of view > of someone who tries to use a GPL library in a closed > source program. > > > Here we have a GPL app that may be using a closed source > library. Unless the license of the library forbids that, > it should be fine, right? no, the GPL is all about derivative works and combining code, it makes no difference the direction: However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and "incorporating" the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. source: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem also: No. The X11 license is compatible with the GPL, so you can add a module to the GPL-covered program and put it under the X11 license. But if you were to incorporate them both in a larger program, that whole would include the GPL-covered part, so it would have to be licensed as a whole under the GNU GPL. The fact that proprietary module A communicates with GPL-covered module C only through X11-licensed module B is legally irrelevant; what matters is the fact that module C is included in the whole. source: http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper You'll notice that both of these quotes hinge on the definition of 'incorporation', which the GPL seems to define primarily as running under the same PID, with no matter which part (the program or the library) is the GPL part. allan -- "The truth is an offense, but not a sin"
[sane-devel] Please give me some help to solve the license issues in using sane
On 6/6/08, Alessandro Zummo wrote: > On Fri, 06 Jun 2008 09:24:25 +0900 > > Olaf Meeuwissen wrote: > > > > > 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. > > > I'm not a lawyer, but I'm not sure of this. I always thought > that using dynamic linking would allow for a proper separation > of GPL/non-GPL code. > > That means that a GPL caller and a non-GPL library should be > ok, while the inverse it's not. gpl faq is pretty clear on this one: If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. source: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation allan -- "The truth is an offense, but not a sin"
[sane-devel] Please give me some help to solve the license issues in using sane
On Fri, 6 Jun 2008, Wang Mengqiang wrote: > Theodore Kilgore, > > Thank you for your ardent reply. > > I feel your earnest expectation to improve the communication with hardware > manufacture. But, very sorry, I am afraid I have no ability to take this > responsibility. > > Thank you sharing the possible reasons on the block of communication. > Whatever, please don't consume too much time to annoy yourself. The > communication and cooperation must base on the common interest ,or benefit > especially for commerce. So, I think, the major factor is whether the > hardware manufacturer's has the relative strategy and whether manufaturer > will obtain, but not lost the benefit. You know, company has to keep careful > to business secret against competitor, and risk of patent or license. IMHO, a > developer can be proud that he is able to learn more knowledge by interrup, > inverse programming, but as a company it has to consider whether it is > proper or legal. > > In fact, I understand and respect the spirit of open and free in open source > world. I feel it will be very important and meaningful if open source and > commerce(non open source) software can benefit each other in the cooperation. > Maybe, it need understanding and some concede from both sides. it is > necessary to avoid either absolute commerce or absolute free. That will > benefit the end user finally. > > your politeness and enthusiasm impressed me deeply. very glad to exchange > personal opinion. > Wang mengqiang Thank you very much for the reply. I am aware that there are issues and problems, and I totally agree that there needs to be dialog. The difficulty is, as I see it, there has been no dialog. Communication needs to take place in both directions and it does not. These are the facts as I have experienced them. I mean, if a company would at least reply and say that "We cannot release any information about X, because of the following issues" then that would be a reply, would it not? And then perhaps there would be something to talk about. But in my experience there is not even a reply. We all have our sensitivities. I mentioned politeness. If one sends to someone a request for information, which seems not unreasonable to the sender, and the request is not even dignified with a response, then that does not seem very polite, either. I mention this while we are on the topic of possible cultural differences and sources of misunderstanding. Now, as to the topic at hand, between your company and the SANE project, I am something of a bystander. I subscribe to this list because of general interest and because, years ago, I was given for Christmas a Canon N640U scanner which needed to be supported and Canon was either unwilling or unable to provide that support. However, as something of a bystander, I will make two observations: 1. I notice that several responses to you are asking that, just what part of the scanner's functioning is supposed to be a proprietary module and what part is intended to be supported code coming from SANE. That seems to me a reasonable request, and probably without an answer it is not possible to proceed. 2. Not all projects have precisely the same license. For example, some other large projects use the LGPL license, which can more easily permit linking of a proprietary executable program than the GPL can do. Thus, depending on the questions you ask and depending on what the answer to a question analogous to item 1 is, you might get a different response to a similar question from some other project using LGPL. I do not want you or anyone else who reads this to assume that I am recommending one of these licenses over the other in the context of this discussion, or for that matter outside of it. I merely mention that the terms and conditions of the two licenses are not identical. Permit me to make a comparison in order to illustrate what you are dealing with, here. I do not know how it fits the history of some societies of eastern Asia, but in Europe and the Middle East there is a long history of craft guilds. You are not negotiating with individuals. You are negotiating with the guild. The guild has its collective interests. That is why it exists and continues to exist. The guild has its own property. That property is in the open, but it is licenced in such a way that it cannot easily be misappropriated. The guild will guard its property with at least equal zealousness to the companies which will not answer letters from the guild members. This is an apparently new phenomenon in the computer and software industry. Most of the big companies did not expect it. But it is here. Theodore Kilgore
[sane-devel] Please give me some help to solve the license issues in using sane
"m. allan noah" writes: > On Thu, Jun 5, 2008 at 3:49 AM, Johannes Meixner wrote: >> >> 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? >> > > Please note that I was not around when the SANE license exception was > added, but i have tried to research the spirit of the decision. I > think the idea was that proprietary frontends were considered a > value-add by some (and a necessary evil by others), but proprietary > backends specifically remove the freedom of the user. It is > unfortunate that the wording of the exception does not make this more > clear. Actually, the same value-add logic applies to backends and the same removal of freedom argument holds for the frontends. However, in the case of frontends, we already have unencumbered alternatives. With backends this is (somewhat?) less likely to be the case. Maybe that explains the attempt at exerting more pressure on backend writers? >> 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? > > Simple- he must recreate any parts of sane that are not in the public > domain, which he wishes to use in his backend. Sane is not here to > provide sanei for proprietary backends to steal. > >> 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): > > Not in my opinion, since this requires more than an installer, there > must be some free code somewhere that does a dlopen on some > proprietary code, which could be interpreted to violate the GPL. 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. # If the GPL'd code is really GPL with an exception that allows this # particular scenario, then that is not a violation. > > >> >> As far as I know the GPL does not forbid that an end-user >> installs and runs whatever proprietary stuff on his machine. > > no, but it seems to forbid that _code_ under the GPL load proprietary > code in order to function. The GPL does not explicitly forbid this. It merely requires that any such proprietary code meets the conditions spelt out in the GPL ;-) -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] Please give me some help to solve the license issues in using sane
Johannes Meixner writes: > 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? The hard way: reinvent the wheel for everything that is only available under licensing conditions that are not compatible with the ones that manufacturer wants to use. Same manufacturer should get legal council, read and understand the GPL and become intimitaly familiar with the GPL FAQ[1], especially all the information in the section "Combining work with code released under the GNU licenses", if it wants to re-use any GPL'd source code (with or without exceptions) either directly or via linking or dynamically loading libraries. [1] http://www.gnu.org/licenses/gpl-faq.html > [snip HP example case] > > In case of HPLIP any proprietary stuff happens only between > the end-user and HP. That is not the issue. GPL related issues are typically tied to programs, not to the steps used to find and install the various pieces needed to use them. > 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. Convenient in case there are redistribution restrictions on the HP stuff, but it still doesn't absolve HP from taking care of any GPL related runtime issues. > As far as I know the GPL does not forbid that an end-user > installs and runs whatever proprietary stuff on his machine. True if and only if the proprietary stuff does not re-use GPL'd bits. > Therefore I think that it is in compliance with the GPL > to have a GPL installation tool which installs proprietary > stuff. True if and only if the proprietary stuff does not re-use GPL'd bits. > 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. Licenses are attached to the source code. However, licensing terms can have a lot to say about how you are allowed to use that source code . That includes privileges and restrictions about how you may use and may not use the resulting 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. Not true. First of all, it utterly depends on the licensing condition of the binary stuff. Even if these are not compatible with the GPL, it is still no problem to combine GPL'd source code and incompatibly licensed binary stuff in a single package or distribution unit. The picture changes a bit when we start looking at the results of the build process. If the program resulting from GPL'd code uses or is used by the incompatibly licensed binary stuff, then that is _almost_ always a problem. 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. > 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. As explained above, that's not true. Of course, packaging your stuff that way is probably not a great idea. It makes it cumbersome for redistributors to figure out whether or not your packages, be they source or otherwise, are legally distributable. If anything, packages benefit from sticking to a single, well-known license. Unfortunately, it is almost never possible to do so and the result may be a license violation, GPL or otherwise, if the _combined_ licensing terms are in one way or another incompatible. # It's really just an exercise in establishing the simultaneous # satisfiability of the total set of licensing terms but the way them # lawyer folks write down those terms makes it far from a trivial # exercise. > But I am neither a lawyer nor a GPL expert! Same story here, but hands-on experience with a GPL violation has taught me a thing or two (and made me sign up as an FSF Associate Member ;-). > 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 Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962
[sane-devel] Branch for sane-frontends
Le Thursday 05 June 2008 14:00:22 m. allan noah, vous avez ?crit?: > On 6/4/08, stef wrote: > > Hello, > > > > to maintain the curent 1.0.x version of sane-backends I propose > > to tag current sources with: > > DEVEL_1_0_TRUNK > > i just made this tag. > > > Then make a branch: > > DEVEL_1_0_BRANCH > > i did not make the branch, we can make it later from the tag if we > want to do another 1.0 release. > > allan > -- > "The truth is an offense, but not a sin" Thanks allan. I have committed the changes for sane-frontends to work with SANE 1.1. However the newer image formats are not yet handled since I have no real hardware or virtual device to test them with. Regards, Stef
