Mike Olson

Subscribe to Mike Olson: eMailAlertsEmail Alerts
Get Mike Olson: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: MySQL Journal

MySQL Journal: Article

Show Me the License

Show Me the License

Here's why. While Linux operating system vendors such as Red Hat and SuSE benefit from the GPL, application vendors do not. Red Hat will be able to provide businesses with Linux software and support for years to come. Even if they go out of business, there are literally thousands of developers, as well as every major IT company in the world, ready and willing to support your GPL software. Most GPL'ed applications, on the other hand, have very small developer communities outside the companies that support them. Any organization buying application software under the GPL risks losing vendor support if the company fails. Be prepared and understand the risk. The business model has to work.

Don't get me wrong. The GPL is a good thing. But there are no examples of profitable GPL-only software development companies. Profits are a company's oxygen. You don't want to bet your company's success on a vendor who follows a business model on life support.

The exceptions are companies such as mine, Sleepycat, that have innovated on the GPL and offer dual-use software licenses. MySQL and Trolltech are two others. We're all profitable and growing. I think the license makes the difference.

Under a dual-use license, software is still available to customers with a GPL-like software license. However, these licenses also give customers a choice to pay for a commercial license that is less restrictive than the GPL. Basically, it allows customers to use open source software in closed, proprietary products.

For example, Trolltech customer IBM wanted to use Trolltech's Qt libraries (a toolkit for faster development of graphical user interfaces). IBM engineers didn't have the authority to share the source code with their customers. But Trolltech's commercial license gave IBM engineers the freedom to develop and distribute applications without opening the source code. Unlike the GPL version of Trolltech's product, the commercial license version didn't require the distribution of the source code.

Sleepycat customer Cisco Systems wanted a quick way to provide name and address lookup in its high-performance network router products. Cisco wanted to use Sleepycat's Berkeley DB product, but wanted to protect the intellectual property of their networking products. Cisco paid a fee to license a version of Sleepycat's Berkeley DB that wasn't restricted by the GPL.

Cox Communications, one of the largest cable network companies in the U.S., chose to implement the commercial version of the MySQL RDBMS to avoid the legal restrictions of the GPL and to get the support and warranty of the commercial version.

Dual-use licenses give customers the freedom to choose if and how they distribute the source code. The licenses also help to create stable software companies with profitable business models.

Berkeley DB, MySQL, and Qt did not start with their current dual-use licenses. The licenses, like the software, evolved through an analysis of both customer feedback and company balance sheets. Though Sleepycat, MySQL, and Trolltech arrived at roughly the same licensing model, the companies came at the problem from different directions.

Trolltech was an early pioneer of dual-use licenses. While their commercial license stayed the same, their noncommercial-use license evolved over time to meet customers needs. "We changed the free edition license from binary only to QPL, and then finally to the GPL," said Haavard Nord, CEO of Trolltech. "Our current dual license gives Trolltech customers maximum flexibility while preserving a strong and profitable software development business model."

Berkeley DB was originally available from UC Berkeley under the popular open source Berkeley Software Distribution (BSD) license. When we decided to form a business around Berkeley DB, we looked at the BSD license closely. The BSD license would give our customers flexibility. It would allow them to freely embed Berkeley DB in hardware or software products and distribute their product without restriction. However, the BSD license would also allow our customers or any developer to take our code and create their own products without our permission or payment. We would create our own competition. We decided to begin the business with a dual-license strategy.

MySQL started with a commercial license. According to their CEO, Marten Mickos, "MySQL moved to the GPL in the summer of 2000 to help MySQL gain wide adoption. At the same time, we introduced a dual license strategy, which has been great for business."

Haavard, Marten, and I recognize that our businesses need a license like the GPL. It's good for our businesses. Our products and our customers benefit from this type of license. A license like the GPL brings two things: it helps our products gain wide adoption and it makes it easier to manage a consistent, unified code base by forcing any changes to be open source and available to us.

MySQL has more than 4 million active database deployments. Qt has deployments in the tens of millions. We estimate that Berkeley DB has over 200 million deployments. In all cases, that's a lot of people using our software. A wide user base means the product is tested by more people, which leads to stable products with good performance. A wide user base also means lower training costs for our customers. Their developers are familiar with our APIs and other programming approaches.

GPL-like licenses also help to maintain product consistency by preventing closed, proprietary branches. We call this phenomenon forking, and it's always bad news for customers because it creates many different versions of essentially the same product.

To understand the problem this creates for customers, let's take a look at what happened to Unix. There are many different versions of Unix and most are similar. Each version of Unix has small, proprietary enhancements that vendors added to create product differentiation. Solaris, AIX, HP-UX, SCO, and BSD are not binary compatible and do not share a common management framework. Customers are forced to spend money to maintain different applications on different operating systems.

The Linux kernel is released under the GPL and unlike the Unix kernel, there is only one mainstream version of the Linux kernel. There is also only one popular version of Berkeley DB and Qt.

Dual-use licenses may appear more confusing at first. However, this new type of licensing can bring your business more benefits than any single license can. Before buying your next piece of open source software, check the license.

More Stories By Mike Olson

Mike Olson, one of the original authors of Berkeley DB, is a technology industry veteran with more than 20 years of experience in engineering, marketing, sales, and business management. Mike was named president and CEO of Sleepycat in 2001 after serving as vice president of sales and marketing. Prior to Sleepycat, he served in technical and business management positions at database vendors Britton Lee, Illustra, and Informix. Mike holds BA and MA degrees in computer science from the University of California at Berkeley.

Comments (10) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Zoue 12/19/04 09:36:04 AM EST

Great!
Best Wishes.

Joe Borists 09/24/03 10:58:50 AM EDT

Jim,

Thanks for the response but I was actually arguing for software that is GPL'ed or under other similar licenses. I agree with you whole heartedly. I have never understood the thinking that proprietary is better. Somtimes it is and sometime it's not.

Jim 09/24/03 08:01:29 AM EDT

For one if a company with GPL open source goes belly up there's bound to be some one that can handle fixing the code for your company. Such as a contract software development company. (To answer Joe Borsits) The beauty of GPL is that it allows dual licensing. Other companies could provide support like Red Hat does for their Linux OS, in other words you pay for service for security patches and to get technical support instead of paying $200 to $1200 for your operating system on top of the other costs. Also it's a big mistake to think you have any more control of the commercial/no code version of the GPL. This is like the Microsoft or any other proprietary software company. What's done to it can not be modified by any one except the company that produced it. Granted that if the company goes under you will still be able to find some one to support the software, a hired programmer or a contract firm.

Jim Tozzi 09/23/03 10:37:53 AM EDT

The Need For More Open Source Watchdogs
The security problems associated with proprietary software products have been well documented. Thanks to the efforts of countless IT watchdogs, security flaws in Microsoft Windows XP and other proprietary software packages have been exposed and patched. However, there are fewer watchdogs focusing on the many "open source" software programs that are in widespread use. The most important IT watchdog, Carnegie Mellon University's CERT Coordination Center, has identified security vulnerabilities in two popular open source programs, Sendmail, an e-mail program, and OpenSSH, a software tool used by network managers "to log in remotely and gain encrypted access to computers..." The Sendmail flaw was described by one security expert as "an extremely serious vulnerability" while the OpenSSH vulnerability was considered more theoretical although "it might prove to be exploitable." A CERT official said that if the flaw were exploitable, it would be serious since, "a user would not need privileges to log on to the machine to run the exploit." A number of major name software vendors sell products incorporating the vulnerable OpenSSH program including: IBM, Sun Microsystems and Red Hat. Hewlett Packard, IBM and Red Hat sell products that could be affected by the Sendmail security flaw. An internet security specialist explained that both programs "are commonly used at large companies, making them an attractive target to hackers." Also noted was that "In any given year there have been just as many vulnerabilities in the open-source community as there have been with Microsoft." In that open source software is being increasingly used in critical business and government applications, there is a clear need for additional watchdogs to monitor the security of open source products. Furthermore, Winston has a question regarding open source programs. When there is a problem with an Apple or Microsoft product, he knows who is responsible for patching them, but who is responsible for fixing software that nobody is responsible for writing in the first place?

This question is of sufficient importance that a discussion thread on the issue has been established on CyberActivist.US. Please click here to comment.

Click to read CNET News article.
Click to read CERT Advisory for OpenSSH.
Click to read CERT Advisory for Sendmail.

Victory In A Battle, Not The War

Tony O'Grady 09/23/03 07:02:10 AM EDT

Read the Licence!

It's interesting how so many people are willing to state opinion as fact. Your standard EULA for proprietary software gives NO protection against copyright infringement beyond "possible" refund of the purchase cost. Have a look at the Timeline case: http://www.theregister.co.uk/content/53/29419.html.
I believe Microsoft have offered to amend their licence agreement - it won't be back-dateable - but what about the rest? As the article stated, for many of the major packages, a standard commercial licence is available to provide you as much (or as little) protection as the other, wholly proprietary offerings.

As regards Hawkie's claims of "knowing" people who have stolen code. I suggest you are morally bound to inform the maintainers of the projects of the lifted code. Remember, the GPL and other "Open-Source" licences have been created to protect Copyright. It's also a very cheap dig to imply that the Open-Source development model somehow encourages or supports lifting other people's code. It's quite the opposite in fact - only the Open-Source development model provides the infrastructure to permit the clear and easy identification and removal of any such infringeing code. And on another matter, Hawkie, "If my clients asked me to sign a statement that i took on the legal responseability for" proprietary software - no chance. I'm not big enough and I can't afford the programmers and legal team to verify the legality of every line of source code - assuming the proprietary software manufacturer would even give me a look. Go ask your insurance company if they'll provide cover - unlikely.

For Joe Borsits, if a packager or supplier of a GPL'd piece of software goes bust, yourself, or anyone else in the develoment community, can continue to make amends, improvements or continue to support the package. If this had been a proprietary package - no chance - the code has gone. Or, you may be lucky - someone else may buy the system and continue to supply - but if the original supplier went bust then why would someone else pick it up? Now, if you are a small company, maintaining a piece of software on your own may not be an option. But if the software has been popular, there may be potentially tens, hundreds or even thousands of people willing to participate and contribute.

In reply to BB, Exchange 5.5 is not going to run on Windows Server 2003. Applications written for NT are not going to run either. The latest version of MS Office is not going to run on any system older than Windows 2000. Bye-bye Visual Basic. The benefit of being a Monopoly is that you get the set the rules and prices at your whim - and not as dictated by the markets or for the good of your client base. You also get to break backward/forward compatibility to ensure cash-flow through enforced upgrades. As regards Linux, I believe (but I'm not 100% sure) you are mixing up the differences between API's and packaging between the distributions. Most of the applications you need are packaged and distributed by the maintainers - you just need to download from the correct site. Many software developers also make the packages for the distribution available on their websites for various distributions. I have many systems running in many, many clients and I've never had to compile anything for them! I've had to compile some stuff for my own use and I have had problems - but that is bleeding edge or esoteric stuff that has no place in a standard business environment.

Also, when did competition become bad (apart from MSFT shareholders)? I think this choice, along with the flexibility and stability, is where Corporate/Enterprise will really go for Open-Source. They can tune the whole desktop environment to their own needs. They can select a distribution and a supplier which is a "best-fit" in the knowledge that no-one can hold them to ransom and that they are protected from suppliers going bust - if a piece of software is critical they have the resources to maintain it or collaborate with their peers in maintaining it.

BB 09/22/03 08:10:00 AM EDT

Just my $0.02 on Open Source development...

The Linux kernel is the posterchild for Open Source development. What's glossed over is that the various Linux based operating system are not compatible. Different commands, filesystem structures, and other operating system differences to break binaries. All of these distributions may be Linux kernel based, but you still need to recompile your binaries from source for most of them.

Closed source propietary solutions have the benefit of one set of specs for developers to work with. Win95/95a/b/c all have the same API. 99% of the API stayed the same for Win98. And ditto for the upgrade to WinME. The jump to Win2k still retained 99% API compatibility. Same application binary on Win95 RUNS on Win2k. Same application binary from RH doesn't run on Slackware...

The benefit to being a monopoly is that you set the standard. No one competes with you to make their own. You do not have to write for multiple platforms. One vision, one design, one API = marketplace dominance IF the developers start writing for your platform (and they did for Windows).

If there were ONE Linux based distribution, ONE GUI desktop for Linux, ONE filesystem standard, then everyone writes their software for the ONE standard. One platform = more code from developers and less compatibility issues.

If only Linus would have blessed a Linux distribution as the "standard" distribution. All others would have to be command compatible (add new commands, but base commands must always be present). Pick one desktop GUI spec and make all others compliant to the spec. The KDE/GNOME wars were because there was no standard GUI desktop API and both sides wrote their own competing APIs.

Perhaps 'monopoly' is the wrong word. I'm thinking more along the lines of a standard specification for a Linux based OS.

ah well, it's late and I'm off to sleep... if this doesn't make sense, keep in mind it was only $0.02 worth...

Hawkie 09/15/03 02:54:34 AM EDT

As i pointed out earlier the legal issues involving a company using OpenSource software, i still can not see anyone actually willing to address this issue. As i see it, this is the main issue to convince corporate users to use OpenSource. The liability issue is a major one, as the OpenSource end user is actually the liable party. Proprietary software is developed by a company that is a legal entity, and as such this one guarantees for the copyrights involved. In such cases the end user can not be sued by a party claiming copyright issues, only the distributor/manufacturer can be sued. So who will be willing to make a legal change to shield end users of OpenSource ? Well most certainly not any US government, because that would in reality be the same as opening up for re-use of any code found anywhere. So how can this issue be solved ? Well i know that lawyers will have filed day when OpenSource really enters the business market. They will hire fleets of people to look for cases in the source codes, and then get tons of revenue from legal proceedings as those using that software.
I can almost see the scenario where i as a systemspecialist recommends a OpenSource alternative for a customer, and eventually he gets sued for copyright violations, as well as beeing put in a position where he has to find another alternative for the software. That can be coslty for the customer as well as for me and my employer. So what do i recommend today ? Proprietary software off course.

I am myself involved in openSource projects and as such i also love to study what others do, and reads through their code. And more than once i have found code snippets i can clearly guess is borrowed from the employer of one of the particpating programmers. One example is some code in a project for clustering Linux, where i KNOW that none of the programmers had access to their own mainframes, or heavy duty servers, but several worked for companies that had some, and that was involved in making similar solutions. Imagine the future lawsuits here.

Well as i said, no use of OpenSource in corporate enviroments until the legal issues are solved.

If my clients asked me to sign a statement that i took on the legal responseability for OpenSource software i recommended i would not dare to sign it, not even if it was concerning the Linux kernell itself, because i can not say for sure where they got all their code from.

Would you sign such a statment ?

Joe Borsits 09/10/03 04:19:46 PM EDT

I don't see how this solves the problem of getting support for a prodoct if the company that puts it out goes belly up. Regardless of the license the company is no longer around.

Michael Brownell 09/09/03 09:13:28 PM EDT

"The article suggests that the small developer community doesn't support the software packages they release under the GPL."

Actually what it says is that the consumer needs to be aware that while support for Linux will continue if RH goes tits up, an application developed by a small group would potentially be unsupported if the group dissolves. It doesnt say anything about the small dev community not supporting their packages.

And my support from Redmond based companies has been just fine.

Jay C. Theriot 09/09/03 07:33:59 PM EDT

The article suggests that the small developer community doesn't support the software packages they release under the GPL.

My question is: Have you ever tried to get tech support from a Redmond based company selling a competitive operating system and office suite?

Yep...Things are tough all over.