ODB is dual-licensed under the GPL and a proprietary license (there is both a free and a commercial version of the latter). As discussed in the ODB Licensing FAQ this model caters fairly well to other open source projects that use the GPL (or a similar license), private closed source projects, as well as commercial closed source projects. However, there is a significant drawback in this dual-licensing model when it comes to other open source projects that use a more liberal (than the GPL) license. In this post I would like to discuss the nature of this problem in more detail as well as explain what we did to allow more liberally-licensed projects to still use and benefit from ODB.

In case you are not familiar with ODB, it is an object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL, and manually writing any of the mapping code. ODB natively supports SQLite, PostgreSQL, MySQL, Oracle, and Microsoft SQL Server. Pre-built packages are available for GNU/Linux, Windows, Mac OS X, and Solaris and were tested with GNU g++, MS Visual C++, Sun CC, and Clang.

Before we go into the details of the ODB situation, let’s first get a quick overview of the state of the open source software licensing. All open source software licenses can be broadly divided into two categories, the so-called copyleft and non-copyleft licenses. Copyleft licenses give us the right to distribute copies and derivative works of software but require that the same rights be preserved in the derivative works. In other words, it is not possible to take a copyleft-licensed project, say a library, use it in our own project (thus forming a derivative work) and then release our project as closed source. In contrast, non-copyleft licenses allow us to base proprietary, closed source works on the non-copyleft software. The most popular copyleft license is the GNU General Public License (GPL). For non-copyleft, several licenses are widely used, including BSD, MIT, and the Apache License.

A quick note on the term derivative used in the preceding paragraph. Many people mistakenly assume it to mean only modifications to the original software. In reality, derivative work is a much broader concept. In our context, it is more useful to think of it as covering any functional dependency between two pieces of software. For example, if we use a GUI library in our application to display some information, then our application is a derivative work of that GUI library.

It is also useful to understand philosophical grounds of the copyleft vs non-copyleft debate. Proponents of the copyleft licenses want to preserve the freedom of every end-user to be able to distribute and modify the software. And if derivative works can be released closed source, then such a freedom would be denied. In contrast, the non-copyleft camp believes that the choice to release derivative works open or closed source is as essential a freedom as any other. There is also a third group, let’s call them the quid pro quo camp, which prefers the copyleft licenses because they ensure that those who benefit from their work are also required to give something back (i.e., make their work open source). Dual-licensing software under a copyleft license as well as a proprietary license on the commercial basis is then a natural extension of the quid pro quo idea. This way, companies that are unable or unwilling to make their derivative works open source have the option to instead pay a fee for a proprietary license. These fees can then be used to fund further development of the original project.

A copyleft project, say GPL-licensed, can normally use non-copyleft software, say BSD-licensed, without imposing any further restrictions on its users. This is not the case, however, in the other direction, for example, a BSD-licensed project using GPL-licensed software. While releasing the derivative work under BSD will satisfy the requirements of the GPL, the resulting whole now carries the restrictions of both BSD and the GPL. And that means that the users of the project no longer have the freedom to use it in proprietary derivative works.

If we are proponents of the copyleft licenses for the sake of preserving the end-user freedoms, then this outcome is exactly what we would want. However, if we use a copyleft license as a way to implement the quid pro quo principle, then this is not quite what we had in mind. After all, the author of the project is giving something back by releasing his software under an open source license. Further restricting what others can do with this software is not something that we should probably attempt.

And that’s exactly the problem that we faced with ODB. We are happy to let everyone use ODB in their projects as long as they make them open source under any open source license, copyleft or non-copyleft. However, as we have just discussed, the standard terms of the GPL make ODB really unattractive to non-copyleft projects.

So what we decided to do is to offer to grant a GPL license exception to any specific open source project that uses any of the common non-copyleft licenses (BSD, MIT, Apache License, etc). This exception would allow the project to use ODB without any of the GPL copyleft restrictions. Specifically, the users of such a project would still be able to use it in their closed source works even though the result would depend on ODB.

You may be wondering why didn’t we just grant a generic license exception that covers all the open source projects? Why do we need to issue exceptions on the project-by-project basis? The reason for this is because a simple generic exception would be easy to abuse. For example, a company wishing to use ODB in a closed source application could just package and release the generated database support code without any additional functionality as an open source project. It could then go ahead and use that code in a closed source application without any of the GPL restrictions. While it is possible to prevent such abuse using clever legal language, we found that a complex license exception text will only confuse things. Instead we decided to go with a very straightforward license exception text and to offer it to any open source project that looks legitimate.

In fact, the other day we granted our first exception. It was for the POLARIS Transportation Modelling Framework developed by Argonne National Laboratory (U.S. Department of Energy) and released under the BSD license.

So what do you need to do if you want an ODB license exception for your project? The process is actually very easy. Simply email us at info@codesynthesis.com the following information about your project:

1. Project name
2. Project URL
3. License used (e.g., BSD, MIT, etc)
4. Copyright holder(s)

Once we receive this, we will send you the license exception text that will be specific to your project. You can then add this text as a separate file to your source code distribution along with the LICENSE, COPYING, or a similar file. Or you can incorporate the exception text directly into one of these files. We also store each exception granted in our publicly-accessible ODB source code repository.

Today we introduced a free proprietary license for CodeSynthesis XSD and XSD/e. The new license allows you to handle small XML vocabularies (less than 10,000 lines of generated code) in proprietary/closed-source applications free of charge and without any of the GPL restrictions such as having to publish your source code.

What were the reasons for offering such a license? After all, it seems like we will just loose money on this deal. We often get requests for our commercial proprietary license from developers that have a fairly small XML vocabulary. Typically a configuration file or a small communication protocol for their application. While the XML documents are quite simple and it wouldn’t be very hard to parse them using DOM or SAX, the developers would still prefer to handle this task using our tools. After all, spending a few days writing mind-numbing code is still worse than generating the same code in a few seconds.

However, the administrative burdens and delays involved in such a purchase (getting approval from management, contacting the purchasing department, purchasing via PO or credit card, etc.) are often hard to justify considering such simple XML processing needs. The administrative overheads on our side (processing the PO or credit card, delivering the license, issuing the invoice, etc.) also force us to set a minimum limit on the license size and price that we can offer.

All this usually leads to either the license being too expensive for the task at hand or the understandable unwillingness of the developers to endure the purchasing process. As a result we have decided to spare the developers the agony of using inferior products and/or raw XML processing APIs and offer this license for free.

How much is 10,000 lines of code? While it depends on the optional XSD and XSD/e compiler features that you use (e.g., support for XML serialization, polymorphism, comparison and printing operators, as well as XML Schema validation in case of XSD/e), as a rule of thumb, 10,000 lines of code are roughly equivalent to 40-50 local element/attribute definitions in the schema. This should be sufficient to handle small and and even some medium-sized XML vocabularies. Also, if you have your schemas ready, you can quickly check how much generated code they require by downloading XSD or XSD/e and passing the --show-sloc option when compiling the schemas.

For more information on the new license as well as for answers to other common questions, see the following pages:

• Free Proprietary License for XSD
• Free Proprietary License for XSD/e

For the past year and a half I’ve been driving past a new BMW dealership as it is being built. The project started just before the beginning of the sub-prime saga when the economy was still good, credit was easy, and people were lining up to buy new cars. Now the new building is almost ready, the economy is in a bad shape, and dealerships are struggling to stay afloat.

A number of prominent VCs published letters they sent to their companies on how to survive the downturn. The standard advice includes not hiring, shutting down or cutting R&D, and making everyone, including receptionists, sell. This approach, which boils down to getting as much cash in and as little out, sounds logical, especially for a startup strapped for cash. But what if a company has cash reserves sufficient to last several years even if the sales dried up completely? Is there a better strategy than hibernating until the economic sprint comes back?

A company that operates in the survival mode during downturns ramps up new product development during boom times. In a good economy financing is easy and, as a result, many new companies are being started. There is an increasing demand for engineers and there is a lot of noise from all the new products being introduced into the market.

During a downturn, such a company concentrates on sales which are harder and harder to get (unless the company is selling something that is in demand during a recession). Sales people, at least the good ones, would be let go as the last resort. Since the majority of companies tend to operate in the survival mode, there is not much opportunity to improve the quality of the sales team, at least not until later when companies start running out of cash. This company got an uphill battle in both good and bad economic conditions.

Let’s now examine how the contrarian approach works, assuming the company has enough cash to survive several years with significantly reduced sales. Such a company would ramp up new product development during the downturn and slash down the sales effort, perhaps even purging the sales team. At this time it should be easier and cheaper to pick up quality engineers since there are more of them on the market and there is less competition from other companies. It is also easier to introduce new products and appear as a market leader during a recession.

Towards the end of the downturn the company can try to improve the quality of its sales team by hiring people from failed companies. As boom times come back, the contrarian approach yields new products ready for the market and the sales team ready for the renewed interest. At this point the company becomes cautious of any aggressive expansions as costs increase. Instead, it concentrates on accumulating enough cash to repeat the cycle when the economy turns bad again.

During boom times companies rush to get to market as quickly as possible in order not to miss opportunities. A downturn, therefore, could be a perfect time to develop and introduce radical and unproven new technology that can take years to get right.

The contrarian approach is logical for a bootstrapped or established business that got a chance to accumulate substantial cash reserves during a boom. It is the way investing, especially the VC type, works that forces companies into the survival mode. Raising venture capital in a good economy is a lot easier than during a downturn. It is also easier to get investment for an idea that is in a “hot” market such as e-commerce during the dot-com boom and social networks more recently. VCs also expect their companies to expand rapidly. This makes a VC-funded company burn cash by rapidly growing in a crowded and noisy field with expensive and scarce engineers.

There are other advantages of expanding during a recession. Office space becomes cheaper as the demand slows. It is easier to negotiate better deals with suppliers and partners as they become dependent on the revenue your business brings. Tax incentives for R&D, starting new businesses, and hiring people are often introduced during recessions to revive the economy. It is also well known that teams become more focused and work harder in the face of a powerful enemy. Recession can be such an enemy. Boom times have the excitement of the overall activity in the field as well as easy sales. But excitement is fleeting while the resolve to outlast a recession stays.

The contrarian approach is not without risks, the biggest of which is running out of cash before the downturn ends. The other problem is finding early customers to use your product and provide feedback. However, one can offer the initial version for free or at a significant discount which may work rather well during a recession when customers presumably need your product but simply cannot afford to pay the full price at the moment.

The survival approach is not without risks either. The biggest of which is expanding into a recession, as the BMW dealership example above illustrates. As with the contrarian approach, there is also the possibility of failing to preserve enough cash and generate enough sales to weather a recession.