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."
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.
10b||~10b -- aah, what a question!
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.
People who think they know everything are a great annoyance to those of us who do.
Actually, it does not. You see a good watermark scheme relies extensively on error correcting codes; that is, if they mangle one of your bits you've got enough redundancy to reconstruct your watermark. You don't actually need to hide that many bits in the source to get this watermark in. You should at most require 20 bits; this would give you around a million watermarks. This should give you plenty of scope to hide your watermark.
Compilers ignore whitespace which means you should focus on introducing changes in to the white space. It's also a good idea to change some of the program code aswell. One of the top of the head that might be useful is to expand the ternary operators out in to if statements.
Unfortuantely, all the methods that come to mind seem to depend on the secrecy of the stego method which is bad design. There is probably a way to do this is secure even when the stego algorithm is known. I'd go and hunt through the literature.
Combined with a decent license, this stego can help you protect your copyright.
Simon
We developed a hosted service over the last 6 years, and a couple of times some big clients asked us if we could "install it" internally, for various reasons.
We told them "No." But we said it in a way that they understood. It sounded something like...
"We custom-built this system over the last 6 years around a centrally-hosted architecture. If you'd like to give us a $500,000.00 down-payment we'll get started on porting this to a stand-alone solution right away, but please realize that you will need to bear all costs of development, we won't guarantee when it will be finished, and once it's done, you'll have to bear all costs of maintenance and upgrades to software and hardware, and you'll probably need to have at least one full-time employee to oversee it the whole time. Oh, and we'll need to work out all sorts of legal paperwork before we'll be able to deliver anything."
"...or you could just continue to use our existing system, and we'll address whatever problems you think would be solved by 'moving it in-house'."
They chose the latter option. The funny thing was, we could never dig out any real reasons why they wanted to move the thing in-house in the first place.