Licensing Commercial Source Code?

toughguy asks: "I'm the principal in a software startup that develops web apps for a relatively small market. We typically run our software for our customers in hosted environment (kinda like SalesForce.com). We've got some large potential customers who are more sophisticated and would run our application in-house. They'd also like to be able to do more customization using their internal development staff. This customization would require us to give them our source code. This, frankly, gives me the willies. The source code for our application represents millions of dollars of invested time and energy. At this point, we're not interested in open-sourcing the whole thing. I'm interested in knowing how other people have handled similar situations. What protections did you have in place? A good lawyer is a must. A good contract with the customer that makes it clear what they can and can't do with the code. How have you handled similar situations?"

"From a technological stand-point we'd considering watermarking the code in some form for each customer, but this has problems in that if the customer makes significant changes then the watermark may be illegible. We're also considering some sort of Encrypted key scheme that would tie the software to a particular server or something like that. I'd be interested in knowing what other protections you may have used in the past.

If you've been in a similar situation in the past can you share your story with how things worked out. Horror stories are appreciated as well as the 'happily-ever-after' types."

Plugin Architecture

[forsetti]

If you truly do not want to make your code FOSS, then I am a believer in not giving the code out at all, even under contract. Code has a way of making it out to the 'net.

Instead, how about extending your architecture to allow for a plugin & theming framework? Graphical modifications are handled through a theming engine, workflow/process changes are handled through plugins and configuration files.

I understand that this means (potentially) much cost, but it is (potentially) less cost than recovering from a code leak. Think of this "boxed" version as a *new* COTS product for you, as you will be moving from service revenue to product revenue, and then invest R&D and effort into it as such.

Escrow

[passthecrackpipe]

Place your code in escrow. That way your customer has the guarantee that even if you should go belly-up, they still have access to the code - which in commercial settings is usually the driver behind this. There are usually few other valid reasons (other then to just steal your work). We are in a similar position - medium size ASP doing business with very large global players, and thats how we deal with it.

Re:Trust your customer

[rocjoe71]

How about just trusting your customer?

Umm, NO.

Many, many companies out there ask for the source code because their long term plan is to do everything "in house" and cut you, the creator of the source code, completely out... It has happened to me twice in the past five years.

In the big picture, in-house development is going to cost alot more than outsource for projects of larger scale. A customer expecting to walk away with the source code probably has designs on finding ways for all their in-house development to get paid for and the best way to do that is to turn around and become your competitor... not the only way, but the best way.

Re:Trust your customer

[hibiki_r]

All you have to do is have a pricing model that allows you to lose the customer. There's plenty of companies that would let you buy the source of their program, but it'll cost you at least 10x the price of a normal enterprise price. You'll also have to sign a contract saying that your company and none of its affiliates will release a competing product to the market for the next 5 to 10 years. Besides, in many cases the only other people that could want to buy your product are your customer's competitors. If they are anything other than a software house, it's highly unlikely that they'd even considering selling your app to their competition.

I have to disagree with your view of large scale projects too: I've worked for a company that sold its products to a big iron industry. Our initial customization charges always started relatively cheap, but once you started relying on our project for your core operations, the prices would start to go up and up. They'd be charged six figures for a change that took 1 programmer 3 hours to code, test, and put on CVS. One specific company ended up spending one billion dollars on product, changes and consulting fees before they decided that they had to pull the plug. They were better off making the program from scratch than buying ours and paying for customizations.

I guess it's likely that what you call large scale is significantly smaller than what I think is large scale. Most Fortune 500 companies have a dev staff just to make those apps that no outside firm can sell to them for the same price. Walmart has programmers. Home Depot has programmers. Nextel has programmers. Citybank has programmers. And if one of those companies is outsourcing a mid sized project to you, I'd not be afraid of them trying to sell your app.