Slashdot Mirror
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."
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."
How about just trusting your customer?
The reason your customer is buying your product is because they don't want to (or can't) write the entire thing from scratch. I'm pretty sure that they are also in an entirely different field. They don't want to sell your product. They don't want to create a product and steal your source code. They are in the business of doing something different, and they are probably planning on staying in that business.
Overall, I think you are worrying more than it is worth. Just have some legal agreements put together, and if it is compiled code, make them use a precompiled (.o file) licence manager that contacts your server to make sure that they are on the level. Overall however, I wouldn't worry about it, those guys have a business to run over there, their first thought is not to try and steal it and run their business on your work. The company I work for will let anyone have access to the source code of their system. It's still copyright us, and so they can't stop paying the licence fees and continue to use it. Overall, it's been a big boon, because there are a lot of places out there that won't run their important internal data through a hosted datacenter.
Regarding some outside hacker getting access to your source code. It's a worry, but most businesses aren't going to run some random illegal source code that they found on the internet somewhere, they want support, they don't want a huge legal liabilty from running something some IT guy found off of a Warez site. Also, unless you are never planning on updating your software again, by the time it gets out there, you'll probably have the next release all ready to go.
That's my opinion from someone who has given out commercial source code so customers can modify it to suit their needs.
Do you trust this customer? If not don't do it. Are they a lot bigger than you? If they are bigger than you and you trust them then write a good contract. If they let out the source code you sue the living daylights out of them.
The simple fact is they have no real reason to want your code to get out. If the product is good and gives them an advantage why would they want their competitors to get something for free that they had to pay for? If you have a good contract they will have everything to loose by not securing your code and nothing to gain.
It is not uncommon for large companies to get the source to a program they buy.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
First, let's get the slashdot mentality out of the way.
There. That's a little better.
Two Distinctly Different Problems
Your question has an unstated assumption that might be steering you in the wrong direction. You assumed that you have to release your source code. You might not have to do that...
Application Layers
In the theoretical world, a web application has the following components:
Given these layers, what are you willing to open up? The web server is probably already open source or an off-the-shelf purchased product. Same with the back-end storage system. This leaves the presentation layer and the business rules layer. What are your top-tier customers going to do to your application? Change the way it looks, change the way it behaves, or add missing functionality? You need to know the answers to these questions before you move on...
Licensing Models
You can license the whole mess as one big slab of source code, or maybe a bunch of loadable modules and just open source the "glue". If you open source the glue, the customers can make major changes to your application without having the source code... Look at the PDFLib libraries. They are very powerful, cross platform, and completely closed source. Can't you do the same thing? Maybe build all of your business rules into a collection of libraries and make them binary only? Then wrap them with a license key or even a hardware dongle if desired. There are several software vendors that do this for a living. Talk to them.
SAAS
If your core codebase is really "all that", why don't you look at a three-tier model? Your customers can host their own web server and database, and pay for a leased line back to your office for the business rules. There are many variations on this theme.
Other Options
You could open-source your code and copyright it so that only you could release software under the current name. Depending on whether your revenue model makes more money out of service or sales, this might actually be a viable option.
You could offer a turn-key "vendor supplied" package consisting of a pre-loaded server and hard-lock your software to that server. Sort of a Google Appliance for your app model. This way you can retain control of the platform and the customer can have your platform on their site.
LOAD "SIG",8,1
LOADING...
READY.
RUN
...its called "customization" licenses.
.dll's or .so's the end customer can't generall touch. However your software does have areas that the users can touch and customize the functionality of...
In the end you no licensing the entire source code, most of the core functionality should be locked up in
This is how most Helpdesk support software works (from companies such as Peregine, Clarify, Applix, Remedy, etc) you should probably look to do something along those lines. It will however probably require some changes to your code base to enable such functionality.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
How about they wanted to keep their data on their servers and not your servers? This is why we refuse to use any externally hosted systems where I work. If you didn't think ahead of design your system to work on anything else than your specific setup then I don't want to use your software. Customising is a different issue, we don't expect the full source code however we do expect some kind of framework that we can extend. It is 2006 not 1996, if your web application can't be extended by third parties it won't survieve the next 10 years IMHO.
A number of people have already touched on some of these points.
:-) My first attorney told me that I should not do business with people I fundamentally didn't trust, but once I decided to do business with them I should draft a contract that was absolutely crystal clear on who could do, or not do, what and when. The vast majority of people and businesses are honest, but that doesn't mean that weak or vaguely worded contracts won't get interpreted differently by different people.
/. after all). If this is a real fear, then you could either cause that to terminate the license or, probably a better path, you have the right to determine if the transfer is agreeable. Remember, this is *your* code. If they can't agree to it, then maybe you should not be giving it to them.
1. This is primarily a legal matter. Having said that, there are an infinite number of contracts that can be created. Find out what they really want and why, then decide what would make you feel comfortable with giving that to them. This may represent essentially free money for your company.
2. I suggest that you be both paranoid and trusting.
(As a side note: we once had a corporate-wide contract with HP. Five years after signing it, they were licensing manufacturing rights to the machine to a Japanese company. The contract wording was unfortunately vague on this point and could have been read that HP already had the rights to give our code to the other company. We reluctantly said as much, but noted that that had not been our intention. HP decided that that since it was not what we had *intended* when we made the contract with them, then they owed us some more money. The next week a check for twice the original contract amount was hand-delivered to us. Amazing. This happened 17 years ago and it still represents the classiest thing I have ever seen a company do. But you can't count on HP being on the other side of your contracts.)
3. We had a clause in one of our contracts we called the 'Microsoft clause', that gave us significant auditing rights if the other party developed a product or service that was significantly similar to the code being licensed. If they suddenly annouced a TurboCharged Toaster, 6 months after licensing our Competition Toaster, then we had broad rights to examine the code of the competing product.
4. More than likely, their having your code will actually bind them *more* tightly to you. This is especially true if you have a plug-in archetecture and most of their mods are in the plugins. They may also find that they benefit by their people helping to strengthen your product. I don't know your details, but it could happen.
5. Make sure that the contract covers what happens if they are acquired by someone else -- someone you might not have wanted to do business with directly. Say, for example, Microsoft (this *is*
Good Luck,
Peter
How about they wanted to keep their data on their servers and not your servers? This is why we refuse to use any externally hosted systems where I work.
...and if you're really that paranoid, then "they" have already discovered all your deepest, darkest secrets, your tin-foil hat isn't working, and we are all watching you. Right. Now.
That's quite a broad statement. Do you really refuse to use any externally hosted systems to protect all of your data? That rules out using Google for searches. They save your search criteria, you know.
NEWS FLASH: Using an online service != Divulging all your darkest secrets
If you didn't think ahead of design your system to work on anything else than your specific setup then I don't want to use your software.
In other news, the fact that you can't buy a shrink-wrapped, boxed set of "Google" to install on your laptop means that Google is useless, and you don't want to use it. You go, girl! (no disrespect to females intended)
Customising is a different issue, we don't expect the full source code however we do expect some kind of framework that we can extend.
Aha! So even if Google's search engine were available to install on your personal machine (I bet that'd have some hefty system requirements), you still wouldn't be satisfied unless it were extendable. I think that's more a statement about you than anything else.
It is 2006 not 1996, if your web application can't be extended by third parties it won't survieve the next 10 years IMHO.
And you top it all off with a scathing prediction of the long-term failure of all non-extendable shrink-wrapped web apps (which you apparently don't use at work).
So in a nutshell, you don't use online services because they are not standalone applications.
I'm rather skeptical. Suppose a security company says that they've got a program which will guard your source code. The security company says "Mangle it however much you want, we can still extract our watermark!". This means that two functionally equivalent pieces of code always have the same watermark, no matter how you define "functionally equivalent".
Horsepuckey. Lets define functionally equivalent in a braindead stupid way: two programs are functionally equivalent if they both halt when given the same input. "No problem", says the security company representative, "we've got the watermarking algorithm that meets your needs". If this were true, then I can take one program which is known to halt (for example, int main() {return 0;}) and watermark it with "foo". Yay, I've now got some quirky looking code which also halts all of the time. Now, I can take any piece of code and test it for equivalence to my original code by running it through the watermark reader. If arbitrary code contains the watermark "foo", then this code halts when given no input. Phew, I've solved the halting problem. Oh wait, nobody can solve the halting problem, which means our security company is selling magic and moonshine.
Now hold on one minute, says the security company representative. OK, so you might be right. So we can't prove that its impossible to rewrite watermarked code such that it functions the same without the watermark. But its sure infeasible. Even if you have the complete description of how we embed the watermark and the watermarked source code. Horsepuckey again, security company! Now you're just selling me security through obscurity ("We bet you won't find the transformation between functional marked code to functional unmarked code") without the obscurity bit!
Help poke pirates in the eyepatch, arr.
I've heard stories from people delivering large applications in C to financial institutions.
Rather than deliver in compiled form, they always deliver in source form and work with the customer so they customer can do the compilation themselves.
This has the effect of getting their guys much more familiar and comfortable with your codebase, lets them do all kinds of handy and cool things, and makes them trust you (if your code isn't shit).
So if they are ever to _stop_ using you, they are faced with black-box unmaintainable code they can't tweak and can't trust. And so guess who they stick with instead.