How to work together? - source-code ownership solutions

Question

My startup is planning to work with a recommendation system developer company to improve our product. The only problem is, that they wouldn't like to give us the source code at the end of the project because of the unique algorithms implemented.

We plan long-term co-operation with this team, but the recommendation engine is a core part of our product so we would like to be as independent as we can be in this case.

We are looking for a solution where they can keep their algorithms safe, and we are the sole owner of the rights of our product.

The ownership of the code could be a great question/problem when we raise money from investors in the future.

Have you been to similar situation? Can you suggest sources to look-up? Or a good lawyer :)

Thanks, Zsolt

Answer 1

Why not let them put their algorithms into libraries.

Just agree on the interfaces and call the library functions:

• You would not need any access to their source code.
• You can use their algorithms.
• If Your partnership ends, You still have a license for the libraries.
• You could even replace the libraries with others that implement the same interface.

The payment for the library licences should worked out by both parties. You could pay for the development, per installation, per developer, ...

Answer 2

In my experience, no attorney, nor source code protection regime can help you out if you aren't partnering with people you trust. It should be enough to place your copyrights at the top of your authored files, make sure that the contract with your partner explicitly stipulates what your rights are, and that's that.

Failing that, I would have your build process compile your engine to binary form (and digitally sign your binaries, and add your copyright to the metadata) and have your partners use those binaries without access to the other partner's source. The understanding, trust, and contract parts are, of course, mandatory...

Answer 3

There are a couple of alternatives that I have seen implemented:

1. buy the code rights from them
2. buy an exclusive/binding license from them, include an up-side for both investment and real income
3. implement it yourself and say goodbye to them
4. buy a part of their company so you have some leverage in their boardroom (i.e. invest in them)
5. create a joint venture to develop your app on top of their IP (not too different from 4)

The bottom line is that if your code is dependent on theirs and key IP does not belong to you, then you have a choice of either acquiring it (directly from them or by creating it yourself) or binding them into your future in a way which shows up-side for both of you.

If this is a big part of your offering then your potential investors will look carefully at the agreement you have with this 3rd Party. In that case a JV is probably the best looking agreement.

If it is just one library amongst many that you use, then as long as you can show that you have an alternative strategy in the case that they get nasty, or disappear, then your nivestors ought to understand your predicament.

You will be in a much better overall position if you find a win/win relationship with the 3rd Party before you seek investment. You definitely don't want to be negotiating with a key supplier at the same time as negotiating with investors.

Answer 4

I think this is primarily a business decision: how comfortable you are "buying" a black box for the core of your functionality, and how likely are your clients (if you disclose) to buy a product from a vendor that is not familiar with the black box.

From a technical point of view, one strategy would be to make their algorithms "replaceable" for disaster-recovery purposes (if that is possible with these algorithms). Separate out very clearly the "secret" chunks, and have them offer them via a subclass where you defined the superclass/interface. Also implement a subtype that offers a last resort version that may use really inefficient but straightforward brute-force algorithms for the same goal (if that is possible). Then develop unit tests that can pass on both. This will help ensure that they conform to your specifications, and that you have a fallback in the worst case or if you need to go to another vendor.

Answer 5

There are legal protections available here that the lawyers can work out -- non-disclosure agreements, records of trade secret information, etc. This of course could be hampered if the relationship is across country boundaries, etc.

I'd like to add too that in the past, when source code isn't available for some business relationships (although, I think this is getting more rare, as it should), an escrow arrangement could be of use. Up-to-date source code is required to be submitted to escrow, and in the event of a severed relationship, it can be released.

Answer 6

country/state law varies, but common sense suggests that if you are paying them to develop the algorithms, then you own the algorithms, and so there should be no question about obtaining the source code. If they balk or refuse, reconsider the partnership - why would you pay someone to develop something if they're going to hold you hostage with it?

if you are not paying them to develop the algorithms, then you are just buying a license to use their software. As a precaution, have them put the source code in escrow in case they go under

Answer 7

the Escrow arrangement that Kris Kumler mentions is essential.

Their IP is also your IP if your product cannot work without it. You must consider what the consequences of bankruptcy or force majeur would be. for instance they go bankrupt and disappear and you have a library of executable code that cannot be maintained, upgraded or ported to a new platform when you have no source code - and believe me trying to pry that source code out of a bankruptcy judge's grasp can take years and may never happen.