"m. allan noah" <kitno455 at gmail.com> writes: > [snip] >> >> 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?
As anyone can infer from the epkowa sources, it dlopen()s interpreters and passes two callbacks for USB I/O. These callbacks ultimately call the sanei_usb read and write functions. The fact that epkowa dlopen()s instead of dynamically linking does not make any difference license wise. It is a convenience that allows for the separate distribution of non-free plugins. # Older versions of the epkowa backend would segfault without them! Also, the epkowa backend started out life as a clone of the epson backend (around sane-1.0.3). As a result, it relies on sanei to take care of a few things (I/O, config, etc) and most of the epkowa backend code is licensed under the GPL + SANE exception. The bits that are under a (slightly) different license, the epkowa_ip* files, are GPL + an exception that is more restrictive than the SANE exception. WRT the possibility of violating the license, you've stated[1] that the way in which components are combined (as in who uses who) does not make a difference. Also, in personal communication, you've mentioned that you think the SANE exception is ambiguous enough to work in both directions (even though the LICENSE file tries to clarify the issue). So, I would think that the epkowa backend is in the clear here. [1] http://lists.alioth.debian.org/pipermail/sane-devel/2008-June/022199.html # Not saying I like the current situation with the epkowa backend but # that's a personal issue. Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
