[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OT: GPL Question

Hash: SHA1

Tony Nelson unwisely wrote:

| No, you /should/ make your own icons.  Make them really ugly, even make
| them bitmapped words, make them look like a progammer made them.  (Look at
| my website for programmer-drawn icons: bold, obvious (mostly), and crude.)
| If your customer wants better icons he can pay a /graphics artist/ to make
| them.

What???  The artist GPL'd his icons so they would be *used* compliant
with his license choice.  If Andy is doing that he can just use them
without fear and with the approval of the artist.  You might want to
degrade your product for some reason but why should you advise Andy to
do so too for your philosophical pleasure?

| You could also make a deal with the copyright holder for different
| licensing arrangements for the icons.  You would have to offer
something in
| return (money, usually :).  If there are many copyright holders this is
| hard.

This is true, the copyright holder can dual-license how he likes.  Is it
true that this guy needs any more licensing than GPL in this case?  Not

| Personally, I find the GPL to be pretty clear, and viral, in that any
| stuff in a product makes the product GPL'd.  That doesn't mean one can't

This seems to me to be a very wrong understanding.  Look at nVidia and
their binary kernel module.

| sell such products (Redhat does), 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).

And what is the 'source code' for icons?  The icons themselves suffice
since they are editable, same way a PHP script is its own 'binary' and
shipped as 'source' too.

| 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.

| 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.
~ 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.

| 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
| 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.

GPL stuff has a great future in proprietary products, the reason is that
for novel products new capabilities must be implemented on both the
proprietary and the GPL side of the fence by these companies.  As part
of the GPL deal, we then get the GPL-side improvements contributed back.
~ The companies love the boost of getting great code for free, we should
love the contributions back free for us to use how we like, even in
competing implementations of the proprietary product.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]