[sane-devel] Please give me some help to solve the license issues in using sane

[Olaf Meeuwissen]

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/