Johannes Meixner <jsmeix at suse.de> 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 sign up at http://member.fsf.org/