[GUFSC] Fear and Loathing in Source Code Licensing

[Daniel Martins]

http://www.ipfrontline.com/depts/article.asp?id=4272&deptid=3


Fear and Loathing in Source Code Licensing

Friday, July 01, 2005
by: Andy Singleton 

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.
Related Story
Open Source Software - Factors to Consider

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.