Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Licensing Commercial Source Code? 52

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."
This discussion has been archived. No new comments can be posted.

Licensing Commercial Source Code?

Comments Filter:
  • Plugin Architecture (Score:5, Interesting)

    by forsetti ( 158019 ) on Monday June 05, 2006 @03:52PM (#15474785)
    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.
    • 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.

      Too true, too true. But how could you forget the obligatory link [thedailywtf.com]? :P
    • Distribute customized code just for them. Modify your originals in a few ways that would make tracing a leak to the internet unique to them. In this way, the burden of protecting the IP is on your client. Make sure there are very stiff penalties in the contract (and that your corp. attorney stresses this to them). If it does leak out, at least you can get damages.

  • Escrow (Score:5, Interesting)

    by passthecrackpipe ( 598773 ) * <passthecrackpipe@@@hotmail...com> on Monday June 05, 2006 @03:53PM (#15474801)
    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.
  • by Ckwop ( 707653 ) * on Monday June 05, 2006 @04:00PM (#15474869) Homepage
    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.

    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

    • Compilers ignore whitespace which means you should focus on introducing changes in to the white space.

      So, uhh, out of curiosity, what happens when a malicious client who knows something's up does something like, say, strip out all the whitespace, and then runs things through a whitespace prettifier?

    • There is probably a way to do this is secure even when the stego algorithm is known.

      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

    • 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.

      Hmm - not sure about that.

      If somebody knows the algo, couldn't they just re-stego the code with a different key? Now instead of all the ternary operators spelling MICROSOFT it would spell BORLAND. Or, if you know the algo you could read the current watermark, and then mangle the code until it is no longer readable.

      All they really need to do is just run the code though a polymorphic
    • 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.

      Just to be real picky, compilers for some language ignore whitespace. Fortran 77 (which is what the code I'm taking a 5 minute break from working on right now is written in) has some pretty strict rules about whitespace. Python too.

  • Talk to Larry McVoy (Score:3, Informative)

    by jthill ( 303417 ) on Monday June 05, 2006 @04:05PM (#15474899)

    Bitkeeper.com

    He's been doing almost exactly that for years.

  • by Zaurus ( 674150 ) on Monday June 05, 2006 @04:08PM (#15474922)
    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.
    • 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 w
      • 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.

        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

        ...and if you're really that paranoid, then "they" have already discovered
        • Comment removed based on user account deletion
          • A search client in which stored searches are not important to the company's business is not the same as, say, a customer relationship management system where the data is important.

            I agree that searches and CRM systems are not the same. That was pretty obvious. Your sweeping generalization that "stored searches" are not important while "[CRM] data is important" is unsupportable. I've used a CRM before which I wouldn't have cared if all the data suddenly disappeared, or if all the data were printed on t
      • How about they wanted to keep their data on their servers and not your servers?

        Exactly, that can be a very powerful driver. I write data analysis software for big pharma, and they generally won't even consider any system that requires that even one bit of data leaves their network. I wouldn't either, if I'd just spent hunderds of millions on research generating those bits. We hardly ever sell anything without an NDA. So, good luck trying with a hosted service there...

        Many other organisations just don't

    • somebody mod the parent as something other than funny. while it is funny, it also represents a serious answer to the problem. It might be worth $500,000.00 to someone have an application in house. $500,000.00 might not be high enough to charge, especialy if the application depends on modified GPL code.
  • I've dealt with this from the client side (i.e., I've been the one getting the code) and I can tell you that you could probably put the source on the internet and post it on billboards and it wouldn't really matter. The important thing is not so much the code itself as the architecture and structure of THE ENTIRE PRODUCT and how one would go about doing important (i.e. business related) things to it. Your customers will need training AND documentation to do this, especially if your code base is of any sig
  • by Lenolium ( 110977 ) <rawb&kill-9,net> on Monday June 05, 2006 @04:18PM (#15475010) Homepage
    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.
    • by Aadain2001 ( 684036 ) on Monday June 05, 2006 @04:26PM (#15475078) Journal
      How about just trusting your customer?

      Ok, I'll give you $5 to for a copy of your house keys. You can trust me, after all, I'm paying you therefore I'm your customer and you can trust me :)

      Most people can be trusted to do the right thing. It's the one or two people who would exploit an opportunity that you have to watch out for. Maybe they want to take his code, make a bunch of modifications, and then somehow claim that because of all their work they don't own anything to the originating company. After all, if you rewrote 90% of the code, there isn't much left that isn' your's (ya right). Watch, there is some lawyer out there just chomping at the bit to fight a case like that.

      To the OP, get a damn good IP lawyer. Ask around in the game industry because they license our their graphics engines all the time and have for a while. They would have experience with this.

    • I agree with Lenolium. Don't be paranoid. Have a good license contract made by a specialist lawyer, spelling that the customer licenses the source code and you retain copyrights; it's common to ask that your customer keeps the code confidential, but have a lawyer write it down.

      Furthermore, before you ship sourcecode, check that all files have a prominent copyricht notice:

      (c)

      Unauthorised copying and publication prohibited...

      Your lawyer should be able to give you some boilerplate text for that too.
    • 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 develo

      • Any halfway decent Software License would prevent that sort of abuse. If a customer tried to create a competing product from their supplier's codebase, the supplier could sue the pants off of the customer. Hell, look at the SCO trial! SCO did not even have a case, and they gained a lot of attention. Most businesses are afraid of a costly litigation, and potential competitors would develop a competing product entirely in-house instead of courting a lawsuit.
      • 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
  • If your code was writting in something like Java, then you could protect your JARs using some encrypted-code-locking system (think - encrypted JARs) and then give your customer some interfaces to build off of with API documentation.

    This will give your code protection, and let your customer expand on what you've done.

    But I imagine you havn't written all this in Java, otherwise you wouldn't be asking the question.

    For code that isn't written in a interpreted or VM'd language, I'd suggest lawyers and contracts
  • Wrong category (Score:1, Flamebait)

    by Russ Nelson ( 33911 )
    This posting doesn't belong in Ask Slashdot. It belongs in Ask Lawyer.

    • Some moderators need their pointendectomy. The plain and simple matter is that this guy needs to talk to a lawyer. If you talk to a bunch of hackers, you'll get a hackish legal document. That will stand up about as well in court as would as a lawyer's program would run in a computer. No insult meant to lawyers, but training and education matter. This is a legal question and it needs an answer from a lawyer. Post it in the Ask Lawyer category, if Slashdot has one (which of course it doesn't; you get my
    • Ask Slashdot responses are perfectly reasonable when you don't want a legal soution. A lawyer will always give the same answer, which would involve paying the lawyer a lot of money to write a legal document spelling out the rights each side has. It's a perectly reasonable solution, and would sound like the best general purpose solution to a lawyer, but not neccesarily the best overall solution for this specific problem.

      What Slashdot will provide is a number of solutions to similar problems that they've
  • Quite a few comments on this page explain different technical "solutions" to the distribution of source code. But the problem is not a technical problem. I'm sure your decision to release or not release the source was not done for technical reasons, but for commercial and legal reasons. And that's how you have to fix your licensing problem.. Through a propre contract and by being ready to enforce your contract terms. Maybe have the contract say that the customer has to provide you any change he made to the
  • A good contract? (Score:3, Insightful)

    by LWATCDR ( 28044 ) on Monday June 05, 2006 @04:22PM (#15475047) Homepage Journal
    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.

  • Some thoughts (Score:5, Insightful)

    by eric2hill ( 33085 ) <eric@[ ]ck.net ['ija' in gap]> on Monday June 05, 2006 @04:25PM (#15475075) Homepage
    Slashdot Rants

    First, let's get the slashdot mentality out of the way.

    • You're evil because all source code should be free, no matter how much blood, sweat, and tears were put into it.
    • Your design is fracked and you should go out of business because you suck.
    • It's technically impossible to keep code secure, so again, youre fracked.

    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:

    • Back-end storage system, typically some SQL server variant
    • Business rules of some sort, most likely the location of the true IP of the company
    • A presentataion layer such as PHP or JSP that presents/manipulates the business data
    • A web server to execute the presentation layer

    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 [pdflib.com]. 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 [safenet-inc.com] software [aspack.com] vendors [aladdin.com] that [ionworx.com] 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.

  • ...its called "customization" licenses.

    In the end you no licensing the entire source code, most of the core functionality should be locked up in .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...

    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.
  • Non-disclosure detailing exactly who can see your source code and requiring them to maintain due diligence in keeping it secret. Non-compete so that your customer won't create a product and use it to compete against you. Binary license so that you know how many copies of your code they are using and what they pay for them. Hold-harmless so you won't get sued for faulty modifications they might make.

    As you said, you need a good IP lawyer.
  • by Anonymous Coward
    Been there. The customer wanted the source code, for validation, customization, and because they were afraid we would disapear overnight.

    Solution:
    1/ Offered them to come on site to look at the code as much as they wanted. They came, but just looked at a tiny bit
    2/ Built API in the code, so they could customize it by writing additional DLLs
    3/ Put the code in escrow, so they can get it (with the build system) if we had anything

    At the end, it always ended up this way. And, retrospectively, point 2/ was a mista
  • by hedronist ( 233240 ) * on Monday June 05, 2006 @05:18PM (#15475507)
    A number of people have already touched on some of these points.

    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. :-) 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.

    (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* /. 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.

        Good Luck,
        Peter
  • If you've written good APIs for your product (you have done that, right?) then it should be no problem. If you haven't, then you probably have no business dealing with companies big enough to have their own intranet programming teams. If you have a well written and documented API that gives them access to all the functionality of your web app without needing to use the web app, they should have no need for your source code; they can modify the output of your application in whatever way they need.

    If you didn
  • Dude, first of all your code isn't worth "millions of dollars". Seriously, 1998 was eight years ago. Code is cheap these days, and every family has a "programmer" somewhere.. I mean, they're BAD programmers but such is the way of the world. Second, the usual flavor when dealing with large corporate accounts is to give them whatever they want and adjust your price accordingly, so that whatever happens, you've made enough money that any adversity won't bother you much. They're probably not going to screw
  • Clearly I would need to now a lot more about exactly what's proposed by your customers, but to me the main issue is rather who owns copyright on the extended work? If they start adding features that you might have added yourselves in the future, you could find yourself licensing back technology from them if you don't have the right legal framework in place. While it isn't as flexible as giving them the code, I would suggest you doing their in-house development and hosting for them - just move some people
  • by Anonymous Coward
    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 u
  • 1. find out- why they want the code? what all changes do they want to make?

    2. if they do not want to change the core of the product, then look at alternatives: like releasing an API/dlls

    3. if they want to change the core of your product, then you need to get a really good lawyer. determine things like who will own the code and the modified code; how much will they pay you (one time/yearly basis); scale of deployment of code; how many copies can they make; can they sell the code their/your code to others;

  • I would obfuscate (=mangle, =scramble) the core of your product (the part they wouldn't change anyways - the libraries you wrote and use). Or even better - give out all code in obfuscated form, and each time they need some module in non-obfuscated form, they will contact you and you'll ask them why they need particular module in non-obfuscated form, what they need to be changed in it and so on).

    If your code uses C/C++, then use tool similar to Stunnix C/C++ Obfuscator [stunnix.com]; for Perl, JavaScript and VBScript/AS

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...