Slashdot Mirror

Berkley DB XML is a new product. i have not tested it though... so this is not a reccomendation.

You've invented an Object-Oriented database! Wowee zowie! Wait, what's that? You say this is nothing new? Well, you're right. Of course it's faster than an Oracle database stored in RAM. Oracle is not designed for the purpose of storing objects. It's a relational database, which is something else entirely.

I can't believe I haven't seen Berkeley DB mentioned a LOT more here as a great alternative to both RDBMS and OODBMS.

BDB is a key-value DB -- it doesn't do SQL. Each DB is a simple "table" of keys to blocks of data. Tell BDB how to compare keys and augment BDB to convert the blocks of data into whatever you like (e.g. - un/serialize your objects). If you won't be doing too much convoluted SQL-like logic and you need an ACID datastore, then BDB is the way to go.

It has most everything you could want:
-- fully ACID (trnxns/rollback/snapshots)
-- single or multi-threaded/process access
-- fine grain locking
-- multi-node failover/balancing
-- multiple indexes per DB
-- SUPER flexible (trade features for speed)
-- AWESOME performance
-- little to no DB administration
-- under development for more than 10 years (debugged)
-- can handle DB sizes up to 256TB
-- can handle record sizes up to 4GB
-- supports most popular languages
-- is maintained by a world class company
-- you can buy support from the maintainers
-- open source + FREE for a lot of uses

I don't think anything out there with a similiar feature set can consistenly outpeform BDB.

Those instructions note that you'll get an error during "make test" because of the old, buggy version of Berkeley DB included with Mac OS X. If you plan on using perl's DB functionality, upgrade to a more recent version. You can either use fink ("fink install db41") to get 4.1.24, or compile from source (available here) to get 4.1.25. If you compile from source, you'll need to link /usr/local/BerkeleyDB->/usr/local/BerkeleyDB.4. 1

You do understant that MySQL is not much more than a filesystem with a SQL interface, don't you?

Yup. I also understand that for many applications, all you need is a filesystem with an SQL interface.

A department's home built inventory system doesn't really call out for the power of DB2. The registration system at one of my prior employers just held names, addresses, and a simple join to their registration keys, and all of this was done without the scalability of Oracle.

Choices are good. Heck, sometimes you need a database, but don't need anything more complicated than the ability to store key-value pairs. There is even a free solution for that.

Flippant, yes, but serious. Regardless of who sits in the 800 lb. gorilla chair, the fact that they stabilize the market will be lost in the chorus of whining about the methods employed.
Your point about intellectual dishonesty is an interesting one. RMS is a self-described fanatic, and delivers regular jeremiads at anyone to the left of his position. The rest of the usual suspects seem ambivalent about the point, e.g. Perl, with the Artistic License or GPL deemed kosher, as you see fit.
Wired, IIRC, talked about business models that actually work, and held forth SleepyCat as a good example. You get the open source version for free and can pay them for a suitable license that meets particular requirements.

Most applications don't need relational abilities at all. Simple key-value databases like BerkeleyDB meet the needs of probably 99% of applications.

If you need indexed tables and performance is critical then why not use this instead of mySQL? I mean, for the limited SQL syntax that is actually available in mySQL, you may as well not bother using it.

Perhaps the problem is the overinsistence on advertising the products as free software as opposed to advertising them as useful products that can be licensed, for a price, at whatever terms the buyer wishes. The problem appears similar to that solved by Sleepycat.

The claims of hackerlab and arch are that they are technically superior solutions to important subareas of computer science. This is precisely what Sleepycat claims for Berkeley DB. As a GPLed library, hackerlab already qualifies as a product that cannot be used commercially unless the distributor wishes to distribute the source code for the application under the GPL. If hackerlab really has value, that ought to be enough to pry some money to continue its support. Similar considerations should apply to arch if it was designed properly.

I really don't know why in this case the market isn't a perfect judge of the true value of this project.

Check out the Citadel system. (Disclaimer: I am one of the developers, so my opinion on this is kind of strong.) We use Berkeley DB from Sleepycat Software for the data store. Yes, this is the same Berkeley DB that Sendmail uses to store its alias tables, access tables, etc. But it's capable of so much more than that. It's a robust, non-relational database that is hugely scalable and even has transactions/logging support!

We store all messages in the database.

Works like a charm. No pounding through ugly directory hierarchies or insanely long flat files. No need to escape out the word "From" when it appears at the start of a line. None of the cruft.

Ok, so it's a black box. But it's an open source server that uses an open source database backend, and since it supports SMTP/POP/IMAP plus webmail all by itself, you can still plug your favorite utilities into it (Pine, elm, fetchmail, etc.) and you don't have to graft together Sendmail+IMAP+whatever to make your mail system work.

The traditional Unix mail utilities are getting a little long in the tooth. I'm going to get flamed for saying this but look at what's happened to the email world: Lotus and Microsoft have run away with most of the market because Unix traditionalists won't give up their flat files. It's time for us to evolve, folks.

Absolutely. It has to be. But that doesn't automatically make Oracle king :-). We were pushing data around for a long time before Oracle (or any other relational database) came along.

Storing data in flat files in not conducive to doing complex analysis or reasearch against. This is the primary reason in my experience that a working flat file system has been moved into a relational database.

I agree with you - you may always decide, at some time in the future, to access the data in a different way. Then just being able to write a SQL statement, rather than a custom program, is a big win.

But for the vast majority of "turnkey" systems the data is very simple and/or is always accessed in the same way every time. In these cases, Oracle (and the attendants needed to keep the Oracle database running smoothly) is complete overkill. Something like Berkeley DB will probably be more important. See the "Do you need Berkeley DB" page for a very brief introduction as to when you really do need a relational DB (which in my opinion is really a very small fraction of the time) and when you do not need a full relational DB (which in my experience is the vast majority of the time).

Absolutely. It has to be. But that doesn't automatically make Oracle king :-). We were pushing data around for a long time before Oracle (or any other relational database) came along.

Storing data in flat files in not conducive to doing complex analysis or reasearch against. This is the primary reason in my experience that a working flat file system has been moved into a relational database.

I agree with you - you may always decide, at some time in the future, to access the data in a different way. Then just being able to write a SQL statement, rather than a custom program, is a big win.

But for the vast majority of "turnkey" systems the data is very simple and/or is always accessed in the same way every time. In these cases, Oracle (and the attendants needed to keep the Oracle database running smoothly) is complete overkill. Something like Berkeley DB will probably be more important. See the "Do you need Berkeley DB" page for a very brief introduction as to when you really do need a relational DB (which in my opinion is really a very small fraction of the time) and when you do not need a full relational DB (which in my experience is the vast majority of the time).

The problem with this analogy is that it assumes no innovation on the part of the commercial party. Let's say, for example, that someone creates a GPL'd pump. Now let's say that a company wants to use the pump as a built-in bilge pump in a boat design. Either they GPL the entire boat design (which means they have to expand into the boat servicing industry) or they design their own (potentially sub-standard) pump.

Now imagine if the pump was under a license similar to that used for the Berkeley DB. Under that license, the pump is free for non-commercial use (allowing John Q. Hacker to make his own pumps in the backyard and such), but requires a fee for commercial use (forcing the boat maker to pay out money but also allowing the boat maker to charge for the boat design).

Sleepycat Software makes Berkeley DB available for download over the World-Wide Web at no charge. The package includes complete source code, documentation, and support for building the library on a large number of operating systems and hardware platforms.

"Like the software? Buy the book! Order the Berkeley DB book on Amazon.com"

And with Qt ... only the X11 version is released under both the QPL and the GPL ... the other stuff require purchase or it's crippleware. Nice try.

From what I've seen of the anti-GPL rhetoric that has come out of MSFT, they are primarily against Richard Stallman's political agenda that comes with the GPL.

They see nothing wrong with altruistically giving away code (which is what the BSD license and its ilk are about) but licenses like the GPL that attempt to devalue the cost of software are anathema to such people. The GPL drives the cost of software to 0 or at worst the cost of distribution media (just take a look at Cheapbytes for a living example of this). This means that any entity that produces GPL software most augment their income in some way be it through moonlighting, consulting, support, selling hardware, etc.

This is not a mere side-effect but was an explicit goal of the GPL which can be garnered by reading Richard Stallman's early writings especially the gunk about software developers should work as waiters so that we can afford to give our software away.

So I looked for another alternative [to writing proprietary software], and there was an obvious one. I could leave the software field, and do something else. Now I had no other special noteworthy skills, but I'm sure I could have become a waiter. [Laughter] Not at a fancy restaurant, they wouldn't hire me, [Laughter] but I could be a waiter somewhere. And many programmers, they say to me "the people who hire programmers demand this, this and this -- If I don't do those things, I'll starve." It's literally the word they use. Well, you know, as a waiter, you're not going to starve. [Laughter] So, really their [sic] in no danger. But -- and this is important, you see -- because sometimes you can justify doing something that hurts other people by saying "otherwise something worse is going to happen to me." You know, if you were really going to starve, you'd be justified in writing proprietary software. [Laughter] If somebody's pointing a gun at you, then I would say it's forgivable. [Laughter] But, I had found a way that I could survive without doing something unethical, so that excuse was not available. So, I realized though that being a waiter would be no fun for me, and it would be wasting my skills as an operating system developer. It would avoid misusing my skills. Developing proprietary software would be misusing my skills. Encouraging other people to live in the world of proprietary software would be misusing my skills. So it's better to waste them than misuse them, but it's still not really good.

Since the GPL makes it near impossible for an entity to simply produce and sell software as its core business,

... it is unsurprising that the world's largest software company would be wary of doing anything that encouraged the spread of this meme. What is surprising is that most observers find it difficult to realize this and instead of applying Occam's Razor, resort to conspiracy theories about how MSFT wants to steal their code.

There are different kinds of software businesses. Slashdot once posted this interview with Sleepycat Software. They seem to do just fine with a dual copyleft/proprietary license. Note that they do not produce end-user software however.

The Wine project might be well served by imitating Sleepycat and their dual-licensing model for Berkeley DB.

Berkeley DB started as a small embedded database library which only supported hash tables and btrees. Since it was written for BSD Unix as a replacement, it was released under the BSD license. After a few years, it was widely used, but it still only offered access methods. When Netscape wanted more features, such as transactions, disaster recovery and multiple-user support, Sleepycat Software was founded to further develop Berkeley DB (on the strength of a licensing deal with Netscape).

The new version of the software was released under the Sleepycat license, an OSI-approved license which allows Open Source applications to use Berkeley DB, but (unlike the GPL) appears to be compatible with any Open Source license. For proprietary applications, Sleepycat offers a more traditional licensing option to companies who don't wish to distribute their source code. Revenue from such licensing funds additional development of Berkeley DB, to the benefit of all. (For example, Berkeley DB 4.x adds replication and high-availability functionality that surely would not exist without the funding received through this dual licensing.)

Perhaps the Wine project should follow this example? Wine could be placed under a license like Sleepycat's, which would allow Wine to be freely used by Open Source projects (whether GPL or not), and proprietary companies could pay for a license which allows proprietary use. Funding from such licensing could be used to further develop Wine, to the benefit of proprietary and Open Source users alike.

BSD or LGPL licensing allows proprietary companies to profit from the hard work of the Open Source developers without giving anything back. Sleepycat's licensing model forces them to give something back, either by contributing more Open Source code back to the community, or by paying cash for the privilege of avoiding that -- which could then be used to fund development that would benefit the Open Source community.

It's a win-win situation, and it would ensure that contributors don't get exploited. It could also lead to funding that might greatly accelerate the development of Wine, even more than relying on companies like Corel to contribute back changes they've made to the codebase.

I'm not a contributor to Wine, but I'd suggest they consider following Sleepycat's example -- it appears to work well for them, why not for Wine?

The Wine project might be well served by imitating Sleepycat and their dual-licensing model for Berkeley DB.

Berkeley DB started as a small embedded database library which only supported hash tables and btrees. Since it was written for BSD Unix as a replacement, it was released under the BSD license. After a few years, it was widely used, but it still only offered access methods. When Netscape wanted more features, such as transactions, disaster recovery and multiple-user support, Sleepycat Software was founded to further develop Berkeley DB (on the strength of a licensing deal with Netscape).

The new version of the software was released under the Sleepycat license, an OSI-approved license which allows Open Source applications to use Berkeley DB, but (unlike the GPL) appears to be compatible with any Open Source license. For proprietary applications, Sleepycat offers a more traditional licensing option to companies who don't wish to distribute their source code. Revenue from such licensing funds additional development of Berkeley DB, to the benefit of all. (For example, Berkeley DB 4.x adds replication and high-availability functionality that surely would not exist without the funding received through this dual licensing.)

Perhaps the Wine project should follow this example? Wine could be placed under a license like Sleepycat's, which would allow Wine to be freely used by Open Source projects (whether GPL or not), and proprietary companies could pay for a license which allows proprietary use. Funding from such licensing could be used to further develop Wine, to the benefit of proprietary and Open Source users alike.

BSD or LGPL licensing allows proprietary companies to profit from the hard work of the Open Source developers without giving anything back. Sleepycat's licensing model forces them to give something back, either by contributing more Open Source code back to the community, or by paying cash for the privilege of avoiding that -- which could then be used to fund development that would benefit the Open Source community.

It's a win-win situation, and it would ensure that contributors don't get exploited. It could also lead to funding that might greatly accelerate the development of Wine, even more than relying on companies like Corel to contribute back changes they've made to the codebase.

I'm not a contributor to Wine, but I'd suggest they consider following Sleepycat's example -- it appears to work well for them, why not for Wine?

One of the nice features of MySQL is the capability of having pluggable persistence managers. An example of that is the default, MyISAM, which you are correct in saying does not support ACID. But with the release of MySQL-Max, which happened awhileago(tm), and MySQL v4 out of the box, support for 3 additional backends was added, BerkelyDB, Gemini, and InnoDB, all of which have complete ACID support. InnoDB also supports row level locking and even an initial implementation of foreign keys.

InnoDb is is in use here at Slashdot as well as a good deal of other sites demanding high-transaction throughput with full ACID support.

With the addition of foreign keys and stored procedures functionality, all of which are on the slate for the 4.x series, the reasons not to use MySQL are lessening every day.

Side note: Yeah, I know Gemini is the red-haired stepchild of the MySQL world. It's still a decent table manager.

There are good reasons for putting data in a conventional server-based SQL database, but there's also good reasons not to. There are a number of cases where another application (and even the database server itself) has no business accessing or potentially modifying the data. It's for things like this that I would like to have such an embeded version. For example, if I'm making a mail server, or something, perhaps bad things can happen if the data is not updated in a particular way, I don't want just any old app making changes, obviously. It also helps reduce namespace conflicts between programs, and so on.

Sleepycat does this for their Berkeley DB software. They use (their version of) GPL and you can obtain a commercial license as well for commercial, redistributed, proprietary software. That's how they make a living.

Bas

there was a Slashdot article on how sleepycat does their licensing not long ago. It may not be a perfect match to your situation, but it is worth a look.

This is exactly what Sleepycat Software does with Berkely DB.
They will accept patches to their code, but not many of them ever make it in, and the ones that do make it in have the requirement of having the copyright signed over to Sleepycat. Effectively making them the sole owner of the codebase. Which, in turn, allows them to sell a relicensed version of their code to embedded manufacturers. Using this model, they've kept a positive income since day 1.

Sleepcat Software's open source Berkeley DB has "been profitable since inception" in 1996

Using multiple licensing models L. Peter Deutsch is able to provide Ghostscript under the GPL and make enough money to retire.

Cygnus Support (now part of Red Hat), was founded in 1989 and was "profitable, increasingly profitable, every single year" before the Red Hat buyout.

It's very unconvential, O'Reilly must be happy enough with sales of books to pay Larry Wall to keep developing Perl.

Open Source works. Maybe not as well as VA Linu... erm... Systems wants it to, but it does.

Sleepcat Software's open source Berkeley DB has "been profitable since inception" in 1996

Using multiple licensing models L. Peter Deutsch is able to provide Ghostscript under the GPL and make enough money to retire.

Cygnus Support (now part of Red Hat), was founded in 1989 and was "profitable, increasingly profitable, every single year" before the Red Hat buyout.

It's very unconvential, O'Reilly must be happy enough with sales of books to pay Larry Wall to keep developing Perl.

Open Source works. Maybe not as well as VA Linu... erm... Systems wants it to, but it does.

1: No, just like you can't reuse GPL code under the (less restrictive / more Free depending on which camp you belong to) BSD license.

2: Reading the license I don't see why not.

3: He says in the interview, "Both Sleepycat and the Free Software Foundation have looked hard at the two licenses, and we agree that the Sleepycat license is compatible with the GPL."

*Cough* A good RDBMS is many things, but fast isn't one of them. The reason the industry moved to relational databases (and SQL in particular) was flexibility. Non-relational databases like Berkeley DB or BTrieve are significantly faster. The reason they're not more widely used is that the flexibility of SQL vastly outweighs the performance loss it incurs. It's a matter of using the right tool for the job. Netscape and Sendmail use Berkely DB because it makes sense to do so for what they need. Similarly, Remedy uses Oracle because it needs the flexibility more than the speed. Yes, a good RDBMS is faster than a poor one, but they're both slower than a good non-relational database.

But who says that you have to make your money by selling the software? The issue is whether a company can make money by developing Free Software and then building their business around some combination of selling that software, customizing it, consulting, training, etc. MySQL is an excellent example of a company that does this kind of thing. They spend money developing a product that people like and releasing it under the GPL. They make money by providing training, support, and consulting. They also maintain the copyright to the whole program, so they can sell the right to use it as an embedded database in non-GPLed products, and the trademark, which must be licensed to advertize the use of MySQL as part of a product. IIRC, SleepyCat Software does something similar with the BerkelyDB. DB development seems to be an area where this model is quite reasonable, which is one reason that people think that Oracle could probably GPL their DB engine and remain very profitable.

This, though, seems to be the approach the corporate world, by and large, is taking to OSS: either create it in-house (like Java) or suck in a BSD-licensed product and hack on it (like Berkeley DB -- and either close the source (countless BSD derivatives) or keep it on a leashed license like APSL. The GPL prevents this sort of thing, but scares off a lot of companies in the process. (Then again, some provisions of the APSL do too...)

The upshot is that you should probably release code under whatever license you and your cohorts feel comfortable with, and deal with it when people do things you don't like but are within the rules of the license. After all, we're supposed to be responsible people, right?

Both formats have problems. A true enterprise-grade message store will use an embedded database with transactions support.

Fortunately, a solution to this problem is being developed right now. The Citadel/UX project is developing a robust communications server that will compete with products like OpenMail, Groupwise, and Exchange. SMTP and POP3 are already in place; IMAP will be available by the end of the year. Web-based access works as well. After that's done we'll be writing plug-ins for both Evolution and Outlook, in order to facilitate all of the 'shiny things' working as well: calendars, address books, etc.

So, you might ask, what mailbox format does it use? None of the above. Messages are stored in a database, like they should be. The Berkeley DB package from Sleepycat Software (yes, it's open source) is used for robust back-end storage, including transaction and logging support.

I'd encourage any developers who are looking for the open source world's "Exchange Killer" to get involved in this project.
--

Please note that this benchmark (and any benchmark, for that matter) applies only to the system and application that it's testing. Database applications vary so widely that it's very difficult to get any meaningful numbers outside of very specific areas.

As an example, I recently ran some tests that came up with the exact opposite results. My application is a large message tracking database. Query speed is secondary; insertion speed is critical. MySQL handles my test data set in 20 minutes; PostgreSQL takes over 3 hours (!). For this application, PostgreSQL is Right Straight Out.

Other notes:

1. PostgreSQL's tables took up roughly twice the space of MySQL's.

2. MySQL's lack of transactions is a real pain. I can, however, work around it (in this particular application, at least).

3. MySQL's "text indexing" is useless. The evaluation function returns every record that contains any of the search terms; there is no way I've found to require all search terms. No documentation, of course.

4. The latest beta of MySQL can use Berkeley DB tables to get real transaction handling. Unfortunately, this is even slower than PostgreSQL.

Obvious conclusion: Run your own tests and draw your own conclusions.

--

When Erik Eng tries to explain why they didn't put the QT libraries under the GPL, he perpetuates the biggest myth about the GPL: that the GPL forbids making proprietary derivative works.

It doesn't. It just doesn't permit making proprietary derivative works. Copyright law forbids making derivative works without permission; licenses, such as the GPL, give that permission.

If TrollTech GPLed QT, they could still make money by selling it to people who wanted to use it for developing proprietary software. This is exactly what Sleepycat Software does. They make the ubiquitous Berkeley DB libraries, which are used for free software development under a very GPL-like license. (Essentially the GPL, without the long rant at the beginning.) But if you want to use their libraries to make proprietary software you pay them for a different license.

Maybe QT has other good reasons for not GPLing QT, but claiming that the GPLing it would preclude it's use for proprietary software development is just plain false.
--

Actually, Berkeley DB does support client/server. Take a look at Berkeley DB Transactional Data Store.

I would never trust the master copy of any critical data to MySQL. It's a nice little database, simple and very fast. However, without transactions or journalling, there's no way to trust completely that the data is safe. I would use MySQL as a high-speed cache, but not as a master repository; you may need to rebuild the database at any time if it becomes corrupted.

Berkeley DB is one of my favorite databases, because it is also small and fast. Unlike MySQL, it does support ACID properties, transactions, journalling and rollback, etc. However, it doesn't support a schema layer or a SQL processor. It's designed for embedded applications.

Neither MySQL nor Berkeley DB is a substitute for a real SQL database. Berkeley DB at least has a solid foundation that could be extended to become a full SQL database, should someone write the necessary code. MySQL, on the other hand, has fundamental deficiencies that are hard to correct. (On the bright side, that's why MySQL is really fast.)

As far as Interbase goes, it should be interesting to see if they will actually provide Interbase under anything that could truely be considered an open source license. Their ever increasing business relations with Sun might rub off and result in Interbase appearing under an Inprise "community" license. It also seem pritty stupid to have spent so much money on Ashintate (sp?) to get the dBase name for building up the Interbase name and then let it rot as a commerical product. But if it becomes available under a license that will allow intergration with gdbm or Berkeley DB then I'm definately all for it.

Even if Red Hat goes bankrupt tomorrow, all their code will be around for anyone to use. And just as importantly, their code will not be used in a way that is harmful to the Open Source communitiy, such as in a closed source distro by Microsoft or another giant corporation. Why? Because of the GPL.

The commercial BSD vendor, Berkeley Software Design, Inc., and Eric Allman's companym, Sendmail, Inc., share several characterics. (Note: I may be wrong about some of the following. Corrections welcome) They both started with free software. They both added proprietary enhancements. The both sell their value-added product as a revenue source. Both give you source code to the product you bought. And both forbid you from redistributing that source or changes to it to those who don't hold a licence.

Two critical questions are:

1. What's the current technology transfer? To what extend do corporate BSDI enhancements return to the free BSD distributions?
2. If these companies go down, what happens to their code? Licence holders still have the source, but so what? Is it dead?

To add one more pair of companies to the stack, consider John Ousterhout's TCL-based Scriptics company, or the Canadian Perl-related firm, ActiveState. My understanding is that there's more technology transfer between these two companies and their core free software roots than might be immediately obvious with the previous pair. I cannot really speak of the TCL world, but in the case of the Perl one, that firm funds not only the salary of the Perl release manager, they also fund development for porting to non-free systems. For example, they've made Perl's fork() call work "right" on Microsoft systems (actually, Microsoft paid for that work!) and have immediately returned those corporately funded enhancements back to the world of free software.

Yes, that means that the current developer release of Perl, version 5.005_63, supports fork(2) with Unix semantics even on Microsoft. Hurray!

If you want other mixed-mode business models, think about Alladin Ghostscript. The interesting issue of licensing is covered in the FAQ. There's also Sleepycat Software, whose database product, Berkeley DB, was used in Netscape with neither credit nor compensation, thus triggering a good bit of bad blood on the authors' parts because of lack of public recognition and appreciate for their work. The resulting `poison pill' licence seeks to avoid a repeat of this unpleasantry.

Now, we have in contrast to those situations, look at companies that are making a business, or trying to make a business, out of GPL'd software. The two most obvious examples, RHAT and LNUX, are hardly typical cases due to their current market valuations, which are obviously astronomically overvalued. But even in their cases, you'll find things that aren't what you would call "free software". In fact, they aren't even open source; look at the way Redhat ships "demo versions" of things without source. Now, I would be willing to argue that this is in fact a good thing because it shows people that Redhat's operating system is a viable platform for traditional licensed software. Others, however, dispute this, pointing out that that software would be orphaned if the company who produces it were to die.

My point is that I believe we now have a sufficiently long list of corporate endeavours which are based, at least with respect to some definitions of the term, free software. That means we have actual cases to look at, not hypothetical cases. I'm sure I've only named a couple of them here. What about other companies? I'm not talking about simple packagers and distributors. I mean firms that do serious development work based on free software. (I would mention Cygnus, but they've recently become an acquisition by Redhat.)

Do we have examples of companies that have died or otherwise abandoned their work in these areas? The university Ingress experience and Britten-Lee? Can we come up with other examples to look at? What has happened to the product of their work? Has it truly gone the way of all things, or did humanity derive some benefit from it?

The expected benefit of this new license is almost exactly the same as my licensing plan for libart. I'm just doing it using existing licenses.

Specifically, I'm releasing the code under GPL, but I'm also holding onto the copyright so I can license it to proprietary customers. I ask people to assign copyright over to me if they want their work to go in my relase. This creates a nice balance of powers, and gives me incentive to be a "nice guy." If I stop doing my job of maintaining libart well, then anyone who wants to is perfectly free to continue development under the GPL. Similarly, people are also free to fork if they feel that what I'm doing is unfair. It's in my interest to avoid a fork, so I better play nice.

Actually, while libart as a whole is released under GPL, large chunks (basically, everything used by gnome-libs, including gnome-print and the Gnome Canvas) are released under LGPL, to make it even more friendly towards people with alternate licensing arrangements. This may increase the fraction of proprietary users who can just use it for free and not pay me any license, but that's ok. It still gets libart out there and used, which is no doubt good for business.

This model is pretty simliar to what Sleepycat is doing for their Berkeley DB code. The main difference is that they have YAOSL, which imho is not quite as friendly as using the existing LGPL and GPL licenses. In particular, they had to grant Gnome a special one-off license to use DB safely in the Gnome libraries, which is obviously not needed for LGPL stuff.

I'm not advocating this model for everybody, but I'm expecting it to work well for libart. I think everyone benefits: I get funded, which means that I can eat and afford to put a lot of work into making libart great, and the free software community gets a well-polished graphics library without encumberance.

Isn't this supposed to be an important aspect of the programming art, to make best use of existing tools rather than trying to create a new set of tools for every possible use? In any case, I cringe every time I see yet another goddamn open source license.