Posted by andy@assembla.com Sun, 22 May 2005 17:50:00 GMT

Can established enterprise software vendors match the flexibility of open-source applications? Their customers want the ability to easily fix, integrate, and enhance applications. In many cases, everybody benefits from source code licensing. However, if you ask for source code from a vendor that doesn’t normally distribute it, you often get an instinctive answer of “we can’t do that�. You see fear, even paranoia. What are the sources of this fear that is preventing wider source code licensing and collaboration?

When faced with the opportunity to license source code, a software vendor needs to do an unemotional analysis of the actual risks involved and the actual economic cost of those risks compared with the benefits of a new licensing model.

What are the commonly cited risks?

Unauthorized distribution

This is the risk that people will use an unauthorized copy instead of paying, thereby cannibalizing revenue. It is always a risk for digital assets, but it is particularly unlikely for enterprise software vendors that sell to large enterprises who require services and have copyright policies in place. Does source code licensing raise this risk? A rational economic analysis will probably show the vendor that the contribution of source code licensing to the economic cost of lost revenue due to unauthorized distribution is vanishingly small.

It is worth asking whether free distribution is benefit to the vendor rather than a cost. If unpaid copies are going to users who would not otherwise pay for the software, the vendor doesn’t lose any revenue. Instead, the vendor benefits from free marketing, since some of those non-paying users will eventually need support and perhaps even licenses as they come to depend on the software. Free distribution is the economic model that underpins the old shareware business and many of the new open source software companies.

Competitors might use the code

For this risk to have economic impact, the competitor would need to adopt the code (given how specialized it is, it often can’t be used except in an exact clone), invest in development and marketing of a product they don’t own, and sell it to commercial buyers that the vendor is also interested in, without detection. It seems unlikely. This has been cited as a risk that arises when vendors outsource software development to offshore companies, and I have seen at least one case where it actually happened. Even in that case, probably the worst case, the offshore competitor was easily discouraged without significant cost to the vendor.

Trade secrets will be revealed to competitors

This is the risk that valuable trade secrets, indicated by the code but not dependent on the code, are given away to competitors. That could be a factor for some companies, and those companies often decline to distribute some code modules. When you consider most enterprise software code honestly, it may be well engineered, but most of it doesn’t represent any kind of proprietary trade secret. So, the amount of code that needs to be withheld because it contains trade secrets isn’t large.

The code will become open source and free

When I approach vendors about source code licensing, they often say “I don’t want to open source my product and make it all free [as in beer].â€? Many vendors have used a restrictive license for so long that they are not fully aware of the vast range of licensing options, and the ways those licensing options can be used to enhance both freedom and revenue. They haven’t considered licensing source code only to customers and their contractors (the traditional OEM license), or licensing usage rights (often referred to as object code) and development rights (source code and modifications) separately. One good stepping stone for these vendors is the shared-source model – licensing the usage rights under their standard pricing and terms, and licensing source code for development under less restrictive terms.

GPL contamination

If customers and partners have the code, they may be contributing modifications to the product. There is a certain amount of concern, coming mostly from lawyers, that outsiders will “contaminate� code by including code covered by viral open source licenses such as the GPL. We studied this issue and we determined two things: 1) That accidental GPL contamination doesn’t destroy IP value, because the remedy is not to put the entire “contaminated� product under the GPL, as has been suggested by some lawyers, but rather to replace the GPL code. 2) A good way to deal with this issue is to use a code scanner like the Black Duck or Palamida products, which identify any code that creates licensing conflicts. This solves problems not only with the small amount of contributed code, but also with the larger base of code that originates in-house.

So, licensing source code and taking contributions doesn’t significantly raise the cost of avoiding GPL contamination.

Version management

If the customer makes modified versions of the application, how will the vendor test and support these new versions? Most of the risks cited above do not have significant economic costs. In contrast, maintaining multiple versions of an application can be complicated and costly.

Vendors need to upgrade their tools and tactics for supporting custom versions. Some tactics can be borrowed from the open source world. For instance, having a clear policy for contributing changes back to the mainline will prevent forking into multiple versions, as it does for open source projects. Some vendors will choose to provide a higher level of support so that customers and partners can take responsibility for maintaining custom versions. This could extend to providing code, contractors, project portals, build scripts, and build farms, paid for out of a slightly higher maintenance fee. And, vendors will need to consider upgrading their own capabilities for configuration management, source code handling, and distributed team management. It will be a worthwhile investment if it opens up new opportunities to work with customers and partners.