In one case, this is due to the ignorance of the writer and I have already dealt with it in detail; in the second, it appears to be a wilful misinterpretation of the conditions imposed by the GPLv3, for reasons best known to the author.
No matter what the reason, Edmund J. Walsh, a lawyer based in Boston, has made some claims about the GPLv3 that do merit some comment.
Walsh starts out by saying that for-profit companies should re-evaluate the ways in which they use free and open source software because of what he calls recent developments - the release of the GPLv3 (released last July, 11 months ago) and cases filed against four companies for GPL violations (this occurred in December 2007, six months ago - and all the cases have been settled out of court).
It's actually fairly easy to verify these dates and events before putting finger to keyboard.
Walsh goes on to talk of "the irreconcilable conflict between open source software and its widespread use by for-profit companies." What conflict? Red Hat is selling open source software and always has and last I heard, they are starting to talk of the B word - billions. Free and open source software is issued under licensing terms which differ from those utilised by proprietary software companies and the license has nothing to do with the fact that the software can be sold.
Let me say it plainly: free software can be sold. Yes, free software can be sold. There is no restriction on how much you can charge for services connected to free software. The word free refers to the rights granted to the user.
Written by Richard Stallman in 1991, six years after he founded the Free Software Foundation, the GPLv2 concerned itself with freedoms that the software should provide to any user: freedom to run the program for any purpose; to study the source code and then change it if one wished; redistribution to help one's neighbour, and freedom to change it and redistribute one's improvements along with the original code.
The same rights are granted in the GPLv3.
FREE WHITEPAPER - RISKS OF MOVING DATABASES TO VMWAREVMware changed the rules about the server resources required to keep a database responding
It's now more difficult for DBAs to see interaction between the database and server resources
This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware
1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance
Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!
A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.