OT: GPL Question

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremiah Foster wrote:
| Andy Green wrote:

Just to be clear, Andy Green quoted the passage below.  Tony Nelson 'wrote'.

|> | Personally, I find the GPL to be pretty clear, and viral, in that any
|> GPL'd  stuff in a product makes the product GPL'd.  That doesn't mean
|> one can't
|> | sell such products (Redhat does)
|
|
| Not really. Red Hat sells licenses and support for their products which
| in turn are based on GPL'd code.

Does Redhat sell licenses for their GPL products?  The GPL has a "thou
shalt have no other terms" line IIRC.

|> all it means is that one must also give
|> | away the source code and the rights to use the source code for any
|> purpose
|> | the GPL permits (thus, others can also sell it or give it away).
|
|
|> | Generally, one should not have any GPL'd code in a commercial
|> product, and
|>
|> Wrong advice.  The GPL says NOTHING about "commercial products".  You
|> can have an entirely GPL'd "commercial product" perfectly fine, and so
|> long as you take care with the boundaries, you can mix and match GPL and
|> proprietary code in the same "commercial product" no problem.
|
| As long as you release the end result as GPL'd code.

Depends of how you integrated the GPL'd code.  If you linked it to a
single app, it's generally accepted you must GPL the whole of your app
sources in order to distribute the binary.  But if you exec a GPL app
from a proprietary app for example, it's not the same at all.  (Or
display GPL'd icons from a resource file).  But whatever the case, you
certainly have to abide by the GPL *for any GPL code* and that means
making those sources available.

|> | there aren't any cute disclaimers or licensing or distribution
|> tricks that
|> | will let one evade the GPL, and it is at best a waste of money to pay a
|> | lawyer for such tricks.
|>
|> Just follow what the GPL asks for and you'll be fine.  If your sources
|> *link to GPL stuff at compile-time*, you should GPL your sources or get
|> a proprietary license from the copyright holder: this is the viral case.
|
| Not should - must. Using GPL'd libraries forces your new binary to be
| GPL'd otherwise you are violating the terms of the license.

Yeah -- 'must' *if* you want to be compliant.

|> ~ If you simply execute a GPL'd app in your proprietary product, you only
|> need to provide matching sources for the GPL'd part and can keep the
|> rest of your product proprietary.  Same goes for if you insert a
|> proprietary kernel module into Linux - the GPL does not leak through the
|> module API and into your sources, which can remain private if you choose.
|
| No. Simply inserting a proprietary kernel module into the kernel does
| not make the entire kernel proprietary.

I did not say this.  (For clarity, I agree with it despite it being
apropos of nothing).

| Exactly the opposite - it makes
| the module GPL'd when you distribute the new kernel which has to be
| under the GPL.

I am talking about a *module* in the modprobe sense.  This can be
compiled up fine without amending the GPL'd kernel sources, as can be
seen with the nVidia driver for example.  They seem to have a thin
source shim that then calls through to their opaque binary, abstracting
it away from ANY contact with the kernel directly.

| The interaction of Free Software with unfree software is tricky. You do
| not have to make your fancy php module open source if you are running it
| on Apache. But if you insert a program that uses a C library from GNU
| your new program has to be GPL'd or you cannot distribute the new
| program outside the rules laid out in the GPL.

Agreed.  The LGPL is the deliberate get-out from this situation.

|> | Note that the LGPL is different, in that it is not viral; all you
|> need to
|> | distribute under the LGPL is the LGPL'd code you used.  The GPL authors
|> | don't like the LGPL for that reason.  A few things are available under
|> both
|> | licenses.
|>
|> That much is true.  But to catch the 'virus' you have to "get initmate"
|> with the GPL code.  Displaying GPL'd icons is not enough.
|
| If you use GPL'd icons, you may not take them and make them proprietary,
| you have to release those icons as GPL licensed icons and allow access
| to them accordingly.

Yeah.  But with a bitmapped icon, simply shipping them is providing the
"source" and thereby being in compliance with the GPL, not "making the
icons proprietary" (I guess they might be rendered SVF in which case
you'd have to ship the SVF too, etc).  The GPL seems to have been
designed from a C-centric view where there is transparent source and
opaque binaries.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFCsXuejKeDCxMJCTIRAjp4AKCL3reAksAbKJO2fx3S5WENu6ZKVwCdGBia
eMqGuIVV56mhBj3Db63YeyI=
=2LU7
-----END PGP SIGNATURE-----