LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for August 3, 2006The PostgreSQL businessBack at the beginning of 2005, Pervasive Software decided that there was money to be made by selling support services for the PostgreSQL relational database management system. It seems like a good idea; PostgreSQL is a rock-solid system, increasingly fast, offering a number of interesting features. It is running in no end of production environments - including, it should be said, on the LWN.net server. Free RDBMS systems look poised to create trouble for their proprietary competition just like Linux made life difficult for proprietary Unix systems. PostgreSQL is clearly around for the long haul, and looks like a winning bet.Not for Pervasive, however; the company has just published an open letter to the PostgreSQL community stating that, while the company remains a big fan of PostgreSQL, it is getting out of the PostgreSQL business. The money, it seems, simply wasn't there. Pervasive is not the first to come to this conclusion; a few years ago, a company called Great Bridge failed with the same model, despite employing several high-profile PostgreSQL developers. Red Hat still offers its version of PostgreSQL, but the last posted news for that product is dated November, 2005, and the product is not mentioned anywhere in Red Hat's last annual report. PostgreSQL, it seems, is a hard business. According to Pervasive, the problem is that the free support is just too good:
While we always knew that PostgreSQL is a solid product with
advanced database capabilities and that it has a very real
opportunity to shake up the high-end database market, we
underestimated the high level of quality support and expertise
already available within the PostgreSQL community. In this
environment, we found that the opportunity for Pervasive Software
to meaningfully increase adoption of PostgreSQL by providing an
alternative source for support and services was quite limited.
It is true that the PostgreSQL community is capable and helpful; any company which wishes to offer something better than what the community provides has a very high standard to meet. But there almost certainly has to be more to it than that. MySQL AB has had a fair amount of commercial success - something which companies working with PostgreSQL have not been able to duplicate. One might guess that the PostgreSQL community is more helpful than the MySQL community, and, as a result, there is more commercial opportunity in the MySQL realm. This does not seem like an idea that is likely to go very far. Something else is happening. Perhaps commercial PostgreSQL support is simply an idea whose time has not come. Most PostgreSQL users may still be early adopters - people who are willing and able to handle the support details themselves. The larger market of users who are more interested in buying support services, perhaps, has simply not developed yet. To the extent that this hypothesis holds water, the companies which have tried to create a market in PostgreSQL services have not done an adequate job of selling its merits to potential customers. That would indicate that more work has to be done to spread the word on what a good product PostgreSQL truly is; there needs to be a serious brand-building effort. There is another factor which should be taken into account here, however. Much of MySQL AB's success does not come from support services; instead, it comes from licensing. The MySQL code is licensed under the GPL, and the copyrights are all held by MySQL AB; as a result, MySQL AB is able to offer proprietary-style licenses to companies which wish to use MySQL, but which do not wish to license their own products under the GPL. PostgreSQL, instead, carries a BSD license and its copyrights are held by a number of different groups. So there is no "GPL exception" business model possible for PostgreSQL. Anybody wanting to use PostgreSQL in a proprietary product can do so without asking permission (or buying licenses) from anybody. What all this means is that anybody trying to build a business around PostgreSQL must rely entirely upon services. They must convince potential customers that PostgreSQL is good enough to merit consideration over any number of proprietary alternatives, but not so good that these customers can support it themselves. The latter part should be relatively easy - there's still no end of customers who require support services before they will consider deploying a system. But convincing companies to walk away from their proprietary database vendors remains a hard sell. PostgreSQL, along with a number of other free database management systems, is a high-quality project. Eventually the commercial world will understand that fact, just like it has slowly figured out that Linux is worthy of its attention. But, until that time comes, making money from PostgreSQL will be a challenging task.
GPLv3 beta 2 and LGPLv3 beta 1The Free Software Foundation has released a second draft of version 3 of the GPL. This draft incorporates comments made in the first draft, filtered, of course, by the FSF's goals. The resulting changes tweak some terms, clarify others, and generally increase the international applicability of the license. The fundamental nature of the license and its goals has not changed, however, and quite a few people who disliked the first draft will have reason to be displeased with this version as well.Those interested in the details of the changes and why they were made may want to look at the FSF's rationale document [PDF]. The term which, perhaps, upset the most people was the anti-DRM provision requiring recipients to be able to install and run modified versions of the software. In particular, if GPLv3-licensed software is shipped on a device which will only run binaries signed by a particular private key, that key must be provided with the source code. The wording of this term has changed in the second draft, but its intent has not. It now reads:
The Corresponding Source also includes any encryption or
authorization keys necessary to install and/or execute modified
versions from source code in the recommended or principal context
of use, such that they can implement all the same functionality in
the same range of circumstances. (For instance, if the work is a
DVD player and can play certain DVDs, it must be possible for
modified versions to play those DVDs. If the work communicates with
an online service, it must be possible for modified versions to
communicate with the same online service in the same way such that
the service cannot distinguish.)
The FSF, it seems, is serious about not allowing GPLv3-licensed code to be used on locked-down systems. The first draft included a term saying, in effect, that any covered software was not an "effective technical measure" protecting access to copyrighted work. That term was intended to block use of the DMCA to lock down systems built with GPL-licensed code. That term has been reworded:
When you convey a covered work, you waive any legal power to forbid
circumvention of technical measures that include use of the covered
work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing the legal rights
of third parties against the work's users.
The new wording has the same intent, but it is intended to apply to anti-circumvention laws in other countries (and the EU Copyright Directive in particular). A fundamental term is the one stating that anybody who distributes software under the GPL, and who owns patents covering some of the techniques used by that software, is giving the recipients the right to use those techniques. The first draft expressed this term as an explicit grant of licenses to use the relevant patents. The second draft, instead, requires anybody distributing the software to accept a covenant not to assert their patents against users of the software. The FSF has evidently written a separate opinion document - not yet published - which describes the reasons for making this change. The prohibition on distribution of "covered works that illegally invade users' privacy" has been removed. Evidently, there was a strong public reaction against this term, so it came out. The language in the first draft which allowed charging up to ten times the actual cost for source code distribution is gone. The GPLv2 language, limiting charges to the "reasonable cost" of shipping the source, is back. The second draft has added a new term stating that making the source available for free download (for three years) is sufficient to satisfy the source distribution requirements of the license. It has also been made clear that redistribution of a program through a peer-to-peer client (as happens automatically with a protocol like BitTorrent) does not require accepting the license and taking on the source distribution requirements. The language on additional terms has been changed somewhat. There is now an explicit prohibition on terms regarding who pays attorney's fees, choice-of-venue terms, arbitration clauses, etc. There is also a clause saying that, if the software has been received with any disallowed additional restrictions ("no commercial use" restrictions being given as an example), the recipient may simply ignore those restrictions. The first draft of version 3 of the Lesser GPL is also available. The new LGPL is much shorter and simpler than its predecessor, mostly because it is expressed as a patch to GPLv3. The intent of the LGPL has not changed much. There are terms intended to make it possible to run a proprietary application with a modified version of the LGPL-licensed library, however - including a requirement that installation keys, if needed, be distributed with the source. By the FSF's schedule, the rest of the year will be dedicated to receiving comments on the new draft of the GPLv3. The FSF has previously said that it would like to adopt the final version of the new license in January, 2007, and there is no indication that this timeline has changed. There will be another series of public meetings, with the next meeting happening in Bangalore, India, on August 23 and 24. Anybody who has opinions on the drafts, and who has not yet expressed them to the FSF, may want to do so in the near future or forever hold their peace.
ATI, AMD, and free driversOn July 24, 2006, AMD and ATI announced they will merge in order to combine AMD's strength in microprocessor technology with ATI's proficiency in graphics, chipsets and consumer electronics. The transaction, valued at US $5.4 billion, is expected to close toward the end of 2006, subject to approval by ATI shareholders, regulatory approvals and other customary closing conditions. At first blush, the obvious implications of the merger focus on the market pressure this combination will place on Nvidia and Intel, and how it will enable AMD and ATI to accelerate innovation in the commercial, consumer electronics and mobile computing segments.In the near term, the merger enables the companies to create an integrated graphics business and deliver core logic chipsets to compete with Intel in the consumer market. In the long-term, the combined company should be well positioned to develop coprocessor-based media and physics acceleration technologies which will enable advances in chips beyond today's cores. If viewed from an open source perspective, some additional questions surface: 1) Will AMD, which has cultivated a strong relationship with the Linux community, work with ATI to release open source drivers - including supporting suspend/resume on laptops?; and 2) How will a combined AMD and ATI influence the growth of the Linux desktop and handheld market? There will probably be no comments from the companies until after the sale has closed. But the potential benefits to the open source community resulting from a combined AMD and ATI are intriguing. In this context, it is worth remembering that Intel - AMD's primary competitor - has been working to provide free Linux drivers for its video chipsets. It would be absurd to believe that open source graphics drivers and advances in Linux laptops and handheld devices are the motivation behind this merger. But the opportunity for AMD to prosper in the Linux market from embedded systems to servers, coupled with AMD's long-term goal of beating Intel to market, makes the release of open source drivers possible as a tactical outcome of a larger strategic vision. Any augmentation of AMD's Linux and open source strategies will most likely be revealed subsequent to the merger, so look for possible changes in early 2007.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||