OUR NETWORK: CompTIA TechLore Magenium Solutions MyOpenRouter About UsAdvertiseContact Us
The Largest Online Community
for Software CEOs and Executives.

Learn about scoring Forum's Raw Score: 32437.9
July 27, 2008 11:48 PM

Categories: Licensing Issues

Rating (0 votes)
  • 1
  • 2
  • 3
  • 4
  • 5
Rate This!

Member Avatar


Joined: 02/28/2008

Hello and my apologies for a seemingly silly question about semantics.

Our company funded the in-house development of a custom software application.

We have a customer that has requested a proposal for the use of this application for 12 months, possibly more.

Normally we would propose a renewable annual ┬?licensing fee┬? for the use of the software.

However (for reasons beyond the scope of this post), we need to avoid the use of the term ┬?licensing fee┬? or ┬?software lease┬?, or ┬?software subscription┬? or ┬?software rental┬?.

Instead, we┬?re looking for an industry standard term (if there is one), that addresses what we┬?re attempting to do: recover the costs we've incurred in developing the software application.

About the only term that we┬?ve hit upon so far is: ┬?Software Development Recovery Fee┬?.

This term is ┬?okay┬? but it seems a bit awkward, especially if there┬?s something more conventional that┬?s already in use.


In terms of our business model, our primary proposal is for services and the software application is not so much of a revenue stream, as it is a ┬?cost of doing business┬?.

The challenge is that the customer has agreed to cover our software development costs, but not as a single contract line item (CLIN) and only if the costs can be distributed over time and as a function of usage.

Thanks in advance for any inputs!

Discussion:    Add a Comment | Comments 1-11 of 11 | Latest Comment

July 28, 2008 5:54 AM

"shared development cost"?

July 28, 2008 10:41 AM

The term I have usually seen used for this is "non-recurring engineering" cost or fee, often simply referred to as "NRE".

Phil Morettini
PJM Consulting
Moretti on Management Blog
+1 858 792 1062

July 28, 2008 11:21 AM

NREs is a good approach but that may violate the "line item restriction"

Since you are likely to be supporting the product, here are two related ideas...

First, consider giving them one year of services that includes SW maintenance, support and non-recurring software fees. This could be billed quarterly.

The second option is to eliminate any mention of the software fees and "bury" the software use as part of the services you will be providing. (Make it clear to your POC that this is for his/her company's convenience.)


Jim Geisman

[COLOR=DarkRed][B][URL="http://www.softwarepricing.com"]Software Pricing Partners, Inc.[/URL] [COLOR=Black]+508-647-0330[/COLOR][/B][/COLOR]

July 28, 2008 12:19 PM

We appreciate all of the inputs above.

They are simultaneously helpful and useful in poking some holes in how we had previously intended to approach this.

Some additional pieces of the puzzle; which were not previously provided only because I had hoped that this would be simpler than it┬?s turning out to be.

We need to be careful that we don┬?t somehow convey that by the customer reimbursing us for our upfront development costs (which have already been spent in developing the application) that they ┬?own┬? the software.

This whole project was a shot in the dark. The customer asked us if we would like the chance to test and evaluate a prototype process (which we did and it was successful), but the risk was entirely our own.

Now that we┬?ve demonstrated that the process (a combination of services and a software application that is used to support those services) works, the customer is looking to put us under contract for a wider implementation.

Other puzzle pieces:

The customer has asked for a ┬?road map┬? that might eventually allow them to take this entire process ┬?in-house┬?.

We┬?re fine with that and we┬?re proposing a transition plan that would allow this to happen over 3 years.

HOWEVER, once the transition occurs, we┬?d like to continue receiving some sort of ┬?fee┬? for the customer┬?s continued use of the software that we assumed all of the risk in developing.

WRT charging them a 1x NRE:

I┬?m not certain how that would work for us in the long term (e.g., I┬?m not certain how I┬?d be able to answer the question: ┬?We already paid for this once, why are you going to keep charging us for it?┬?)

WRT burying the development costs in the pricing of our services:

The problem (I think???), is that if we bury the software development costs in what we┬?re charging for our services, if at some point down the road the customer decides that they want to perform those services ┬?in-house┬?, then we┬?ll have to ┬?introduce┬? the concept of a software subscription fee. (I can hear it now, ┬?Why should we start paying for this now? You never charged us a fee in the past.┬?) Bottom line, I┬?m ┬?okay┬? with burying the costs, but I┬?d at least like to introduce the notion that ┬?it┬?s in there somewhere┬? so it┬?s not a big shock (or point of contention) down the road.

As for why we can┬?t simply call this what it is (a licensing fee), that┬?s an immovable hurdle and one we┬?ve been told to leave alone.

Again, a sincere thanks for all of the input!

July 28, 2008 12:54 PM

We need to be careful that we don┬?t somehow convey that by the customer reimbursing us for our upfront development costs (which have already been spent in developing the application) that they ┬?own┬? the software.
You're right, that is extremely important. There is one and only one answer, and it's not the line item description on the invoice. The one and only solution is a signed contract that explicitly states that you own the software and are granting them a license to use it under certain conditions. Any other approach risks the probability that the software becomes a "work made for hire" that they own (the same way that your company owns software written by your employees and contractors -- at the end of the day there's not much legal difference between your people's relationship with you and your relationship with this customer).

July 28, 2008 2:41 PM

There are many instances where NREs are charged in conjunction with a licensing fee.

It seems to me that there is a bigger issue here than terminology. I get the distinct impression that you have one thing in mind (you own the software) and they have another (they simply asked you to do a prototype to see what you could do,with no committment on their end, and now want you doing work for hire).

Frankly, this is the sort of thing that always needs to be negotiated at a very early stage to avoid a real mess, and work being done under a misunderstanding. Of course I don't have all the details, but from what you have disclosed, it seems to be what needs to happen is an honest discussion about each parties interests and needs. I don't think that any amount of wordsmithing or dancing around the issue will replace that.

Phil Morettini
PJM Consulting
Moretti on Management Blog
+1 858 792 1062

July 30, 2008 9:28 AM

Thanks for posting that, Phil. I was uncomfortable with the original question but I couldn't quite put my finger on it.

The earlier you get everyone's expectations in alignment, the better. These things get very expensive to sort out down the road.

I can't say it any better than Phil. No amount of wordsmithing will change the underlying reality.

July 30, 2008 9:38 AM

On a more "positive" note, let me say that I used to encounter this objection fairly often in my very long-ago contract programming days: "why should we pay you to develop this, and then you go out and sell millions of copies."

There are a number of counters to that objection:

- There is a lot to the software publishing business besides development. If I get lucky with this software as a product, it will be because of a lot of effort on our part (you can enumerate here if you wish) not just development.

- Do you really want to own it outright? Is there a benefit to you in doing so? Okay, the price with full rights is $XXXX (perhaps a 50% to 100% premium).

- The software business is tough. There are very few products that sell a million copies, so we are worrying about nothing.

- A variation is "if you're not willing to pay for this software, what makes you think that a million others will?"

- Perhaps they are worried that you sell it to their competitors and they lose a strategic advantage. You can give them an X-year exclusive in their industry.

- Would you be interested in revenue sharing? If we sell the product, we would pay you 3% of each sale until you had received 200% of your costs. You in return would agree to endorse us at industry conferences, etc.

- You benefit if we re-sell the software. That would give you enhancements at no cost, and a guarantee that we would stick around and maintain it.

- Your core competency is the widget business; ours is software. You want the best widget management product; don't worry about our software business.

July 30, 2008 12:40 PM

Hey Guys,

Appreciate the info ┬? my problem is that everything that┬?s been suggested here makes sense to me -- but it┬?s an uphill battle (that all of you have obviously faced before) in getting my customer to think ┬?logically┬?.

Complicating this whole mess is that the ┬?customer┬? is an entity within the government so there┬?s no ┬?single point of contact┬? (nor is there a single ┬?authorizing agent┬?) per se.

We have end-user┬?s involved, a PM, the contracting folks, and the funding folks ┬? all of whom (obviously) know each other, but rarely seem to talk to each other.

Basically what seems to be happening is that they all have various ┬?requirements┬? (of varying natures) and somehow we┬?re expected to prepare an offer that satisfies all of their collective (and sometimes competing and seemingly conflicting) wickets.

As for us being able to get ┬?everyone in the same room at the same time┬? ┬? based on several years of experience, that┬?s simply not going to happen.

Please don┬?t get me wrong, we┬?re happy to continue working with this customer, it┬?s just that as we move into broader implementations and ┬?production work┬? (vs. small ┬?science projects┬?), things are getting much more complicated for us than they have been in the past.

What scares me the most, as has been suggested above, is that *a lot* of this stuff should have been hammered out well upstream of where we are now.

As a ┬?tactical┬? guy, my interests have been in providing services, getting paid and fighting the problems of the day ┬? not the ┬?strategic┬? problems of tomorrow or next week or next month.

But again, I sincerely appreciate all of the inputs.

Charles, your most recent list of possible ┬?counters┬? to their objections is MOST appreciated!!! (It will keep things moving.)

And, Phil, yes, I┬?ve read, and re-read, your post several times over; now I need to figure out how to do something about what you┬?ve suggested. (Talk about a mess... ummm, yes, it is!!!)

July 30, 2008 12:49 PM

FWIW - there must be a champion inside the organization, or someone who commissioned the original work from you.

Perhaps it is time for a frank discussion with this person, and say you are not equipped as a company to manage their different groups and distill a common solution from their different requirements. In short, if they need someone to do that, it is not you and if that is your only option you'll spend your time elsewhere on customers who offer a better business prospect. In short, you can always threaten to take your ball home.


July 30, 2008 1:12 PM

the customer has agreed to cover our software development costs, but not as a single contract line item (CLIN) and only if the costs can be distributed over time and as a function of usage
Isn't that the answer to your original question. Can't you just bill them for a "software usage fee"? Couldn't that fee include (without your enumerating or breaking it out into components)

- your direct costs in providing the software as a service
- a partial (total over enough time) recovery of your up-front costs
- a contribution to your general overhead
- profit

Discussion:    Add a Comment | Back to Top | Comments 1-11 of 11 | Latest Comment

You must login to discuss this item.


Please log in or register to participate in this community!

Log In


Not a member? Sign up!

Did you forget your password?

You can also log in using OpenID.

close this window
close this window