-----BEGIN PGP SIGNED MESSAGE----- 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 AIUI.
| 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
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 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.
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCr89wjKeDCxMJCTIRArHcAJsFXbhoxNgiw8nBLCw2PW51YyhiDwCffH2n tKViiaUwZboQc/EwR7j9YZs= =WX7z -----END PGP SIGNATURE-----
