Become a fan of Slashdot on Facebook


Forgot your password?
Programming IT Technology

How to "Open Source" Custom, Contract Software? 392

customWorks asks: "I've been approached to write a piece of custom software for a small business owner with the promise of autonomy in its design and implementation. I do not intend to stick around for incremental development after I've delivered it, and so I feel strongly that open sourcing the software would be prudent for the both myself and prospective client. That said, I still expect to be paid for the developing the software. The issue of course is over convincing the client of the benefit of giving away the source to something they've just paid to have developed. I'd like to know if any of you who've done similar contract work have had experience (success?) in presenting an argument for open sourcing the end product? What were the major concerns/misperceptions that you had to overcome in making the case for open source?"
This discussion has been archived. No new comments can be posted.

How to "Open Source" Custom, Contract Software?

Comments Filter:
  • If you GPL it, it'll have a virus in it. That's what the Microsoft people said. I don't want a virus on my computer, so forget it.

  • by rfreynol ( 169522 ) on Friday May 10, 2002 @06:36PM (#3499737)
    In any contract work I have ever done, I have made sure that I own the copyright, and give the client a perpetual license for the resulting programs.

    If the customer insists on owning the IP, then there is a great reason to raise your rates.

  • And of course the whole wanting the end result to be open-source but you getting paid your fee is so totally a "have your cake and eat it" situation, that words escape me...


    • Re:and further... (Score:2, Interesting)

      by kolevam ( 452046 )
      The actual labor required to develop something GPL'ed doesn't have to be free! Does it?
    • Re:and further... (Score:3, Insightful)

      by jimbolaya ( 526861 )
      Words escape me, too. What does he expect, that the "open source community" will support this proprietary application for his client? What's in it for the company or the open source developers? It's if it's a custom application, it's not likely to be of much us (as a whole) to the general public anyway. Besides, the application may, in it's business rules, contain "company secrets" or "competitive advantage." A company would be insane to pay somebody to give away the code. It's just not going to happen.

      Me thinks the guy just wanted to get on the front page of Slashdot, and he figured the phrase "open source" was a good way to do so.

      • Re:and further... (Score:2, Interesting)

        by homer_ca ( 144738 )
        A common practice in industry is to keep source code of custom apps in escrow, with the understanding that if the original developers go out of business or stop supporting their software, the source code is released to the customer.
      • Re:and further... (Score:2, Insightful)

        by SanGrail ( 472847 )
        Why would the Open Source community be into it?
        If it's useful, and people hear about it, they'll use it.
        And since he's doing it for a client, it's got a headstart in that he will actually produce a working model, rather than one of those projects that never even gets to a beta version.

        Why would the company open source it?
        First, they need the product. They need a working tool, and it's not something that is currently available (to their knowledge). So they are going to develop it, regardless of Open Source support to begin with.

        But, that's all they need. It's internal, so they aren't going to sell it to anyone else. They wouldn't be losing any income.

        It will need maintenance. It may need small, ongoing maintenance forever - somethings are like that. It sounds like original developer may not be available.

        If they opensource the product when it's been developed, they haven't lost anything, they still have the tool they wanted.
        Meanwhile, on the principle maintenance costs just keep accumulating, and can add up to more than the cost of the original product over time (depends what it is of course), if it goes opensource, the maintenance costs get taken on by the other users as well.
        The company benefits from any improvement or maintenance that other users make to the product, with no extra cost to them.
    • It depends. (Score:3, Interesting)

      by mindstrm ( 20013 )
      Are they paying for him to deliver a solution, or are they paying him specifically to develop code for them. There is a difference.

      If they are paying the hourly cost of development, then it is absurd, even rude, to expect them to let you keep the copyright.

      On the other hand, if they are simply paying you a flat fee for a solution, and it is up to you how you attain that solution, then it's another story. You can write the code and license it to them and keep it yourself.

  • by techmuse ( 160085 ) on Friday May 10, 2002 @06:37PM (#3499743)
    The client is paying you for your time in developing an application. For that money, they should get at least:

    1) The binaries
    2) documentation
    3) support

    If you can't give them support, the ethical thing
    to do would be to let them know, and give them the
    source code so that they can have someone else
    maintain it. But THEY should choose whether to
    open source the code or not. They paid for it. It's their decision, not yours.
    • by Bradmont ( 513167 ) on Friday May 10, 2002 @06:50PM (#3499819)
      I disagree with this. It depends entirely on the contract he makes with the client at the project's inception. If the agreement is that he supplies neither source code nor support, that's the ethical result. After all, I have no right to that copy of windows that came with my computer -- the license says so, even though I (indrectly) paid for microsoft to make it. Yes, contract work is a somewhat different situation, but the same principal applies. If he can convince the client to let him put it under some Free license, there's nothing unethical about that, and more power to him.

      As a side note, putting it under a Free license (GPL, BSDL, whatever) doesn't necessarily mean he's going to release the source to the general public, or even at all. With the GPL, he only has to give the source to anyone to whom he supplies the binaries.
      • As a side note, putting it under a Free license (GPL, BSDL, whatever) doesn't necessarily mean he's going to release the source to the general public, or even at all. With the GPL, he only has to give the source to anyone to whom he supplies the binaries.
        Thank you.

        This is the single most insightful comment made in this entire thread.

        Why does everyone think that just because the software in question is GPL'd that therefore everyone in the world will have access to it? In the traditional closed-source model, two parties have access to the source: the contractor (programmer) and the buyer. The contractor licenses the binaries to the buyer under non-exclusive terms -- meaning that he can later turn around and sell the same code to a competitor if he so wishes.

        If the contractor GPLs the code, then he's required to provide the buyer a written offer for the source code, free of charge. This isn't a big deal, since the buyer ought to have access to the code anyway. The contractor is also required to provide a similar offer to anyone else to whom he supplies the binaries. Just as in the closed-source model, the contractor can distribute the program to whomever he wants! The buyer only has a non-exclusive license to the program.

        As long as the buyer doesn't expect to own the code, there's really no difference from their point of view. They have to trust the contractor, or else make the terms of his contract such that he cannot supply copies of this program to their direct competitors. IANAL, but I don't believe terms like that would preclude licensing the program under the GPL.

        Of course, depending on the type of project in question, GPL may be impractical for other reasons. Especially if the design of the software would include, for instance, trade secrets or other information (like APIs or other interface specs that are internal and proprietary to the buyer's company), it may be better to opensource the majority of the program under the LGPL and then use a closed-source link between them. Or it may be better to simply keep the entire program closed.

        But the program certainly shouldn't be closed source simply because someone thinks "open source means this will help our competitors". That's misleading at best and flat-out wrong at worst.

        • If the contractor GPLs the code, then he's required to provide the buyer a written offer for the source code, free of charge. This isn't a big deal, since the buyer ought to have access to the code anyway.

          *If* what you say is true, then what would be the point of GPL-ing it? The customer, after all, has access to/owns (according to your statement) the source code anyway, so should the original developer be unavailable, they can take it to whomever they want to after they've 'bought' it anyways.

          That said, I doubt if what you're saying is true. I know for a fact that the company I worked at a few years back developed custom applications for clients, but to the best of my knowledge these customers were never provided with the source (which would've been useless to them anyways), just with a (hopefully) working binary. Now this was in the Netherlands (yes, the country where fanatic lefties shoot insane right-wingers, yadda-yadda) and things may be different in the US or wherever you're from, but if they are in this respect, I really can't see why.
    • actually, it depends on the contract. If it doesn't say source code to be included, then it doesn't have to be. Pretty much like any 3rd party vendor.
    • If you can't give them support, the ethical thing to do would be to ... give them the source code
      And if you do give them support it makes it so much easier if the client already has the code.
    • by fmaxwell ( 249001 ) on Friday May 10, 2002 @07:32PM (#3500004) Homepage Journal
      If the client agrees to make the work open source, then their competitors will be able to use it at no cost. How is that in your client's interest after they paid you to develop it?

      What makes you think that the open source community has any interest in supporting the custom application that your client is paying you to write?

      Your client will already own the code, so they can give it to whomever they want. Why would it be in their interest to obligate themselves to give it to any more people than absolutely necessary?

      I've been doing software consulting for 20+ years and, forgive me for being blunt, but you sound like some kid on one of his first consulting jobs. You seem to have this naive view that you can write code, throw it over the wall, and run. You can -- once or twice. Then the word will get around that you don't support your clients and the work will dry up.

      If you want to participate in the open source movement, do it on your own time. What you're trying to do is like someone who volunteers with Meals On Wheels and then expects to make the delivery runs while he's on the clock at his job.
      • Support.

        If the software is popular/useful enough to be adopted by open source volunteers the company will have the benefit of ongoing development of the product that they paid for once.

        Also, depending on the program, it may make sense to hold some key (but not critical) object back as closed source they way Sun does with Star/Open Office.

    • The client is paying you for your time in developing an application.

      Not always. In my experience, there are several types of customers for contract programming:

      one who wants a tool

      one who wants a new product

      Those interested in a tool aren't normally interested in the source code, other than as a form of support. Normally, they're not paying you for your time or for ownership of the source code. They want a tool to do a job and are willing to pay for it.

      Many of them know enough to ask for the source code so they can get bugfixes if you happen to be run over by a doughnut wagon. Even in this case they usually don't want ownership of the source code--they just want a license to it.

      Normally the people who want you to create (part of) a product are the ones who want you to relenquish the rights to the code. If so, make sure you charge them accordingly. After all, for my customers who buy a tool, I can use significant chunks of code I've used in many other projects. I can't use my subroutines for customers wanting exclusive rights, so not only do they pay for the extra time in reinventing wheels (or the purchase of third-party libraries to do tasks), they also get to pay for the exclusivity.

      As an (admittedly ridiculous) example, suppose a secretary wanted a word processing program, but no word processing software exists yet. She could pay you to write one for her. She doesn't really want to sell word processors or anything, she just wants one to help her business. You could write one for her, and she could write you a check.

      For that money, they should get at least:

      1) The binaries
      2) documentation
      3) support

      No argument there...

      If you can't give them support, the ethical thing to do would be to let them know, and give them the source code so that they can have someone else maintain it.

      Giving them support can come in many forms, one of which is making available the source code so they can get someone to fix it if you're unavailable.

      But THEY should choose whether to open source the code or not. They paid for it. It's their decision, not yours.


  • by Anonymous Coward on Friday May 10, 2002 @06:37PM (#3499746)
    You'd do better to leave them well commented code with a few backups. Leaving it up to the OSS community and expecting them to produce something useful to your client (i.e. you're getting paid to serve them, not the OSS community) is a gamble at best. Not a dig on them, they're just not looking out for your client.

    So lots of comments and documentation are what you would produce if you truly have your client's best interests at heart.
    • > Leaving it up to the OSS community and expecting
      > them to produce something useful to your client

      There are many more reasons to open source something than to sit back and let people hack at your code while you just absorb the patches, you know.

      Sometimes the code is dead to you. But you make it available just in case someone else wants to use it. Sometimes a hack you made would serve as a great example to help teach someone else. Sometimes it tackles a problem in a totally new way that someone would just love to incorporate into their program.

      I make a habit of tarballing everything I write and tossing it up on my website. I don't clean up the code, I don't turn it into a distribution.. I just let the people have the code because it serves no purpose to let it rot on my HD. Has anyone ever sent me a thank you email? No. But watching my http logs, once in a while someone does download something, and it feels cool to know that someone somewhere might be learning something from it.

      THAT's what open source is about. ;) Letting people do whatever the heck they want with the code.
  • by nagora ( 177841 ) on Friday May 10, 2002 @06:38PM (#3499749)
    If he's paying you to produce the work then just do it and assign the copyright to him, i.e., sell the source. He gets the program and the material needed to hire someone else to maintain and upgrade it; you get paid and don't have to come back to work on it in a year or two when he needs more functions etc.


  • In this case, you could make open sourcing the program part of the development contract. Just squeeze it in there inconspicuously. Much like so many EULA's we've seen.

    Or say that the custom app will be based on your own technologies so that you can open source say the main engine, and not give out proprietary stuff, such as database data.
    • by jarito030507 ( 537910 ) on Friday May 10, 2002 @06:46PM (#3499795) Homepage
      While this may seem like an attractive idea, the ethos of open source is the free exchange of ideas. This ideal would be damaged by tricking a company into signing a deal that would open source software which they paid for. This would not only engender a possible court battle when the company wishes to enforce its rights but would also ensure that the company would be less willing to discuss/implement open source solutions in the future. If you cannot convince a company of the benefits of open source, then you must bow to their wishes, after all, they are paying you. Just another side note, if you are a member of the ACM the kind of conduct you suggest would most likely be against the ethical guidelines.
  • that great of a thing unless other people find the project interesting. It will loose any resale value, so if its something they'd like to sell, they could only make money as support.

    OTOH, ih its something people will enjoy enhancing, then they get value from free enhancments.

    Explain to the the philosophical reason for opening source. Or just GPL it.
  • If you were paid for your *time* developing some solution, this piece of code/intellectual property still belongs to you. This would entitle you to do with that code whatever you want.

    If the contract with the client states that all the IP you create belongs to the customer for whatever he wanted to do with it, then there's little point forcing the customer to do something specific with it.

    Either way, the customer will face the problem of later support and evolution. If he cannot get hands on you, he either has to hire someone for hard bucks, or he donates the stuff to the public and crosses his fingers that someone will take care of it. Which does not necessarily mean the necessary work is done then - this depends on how 'hot' that piece of software actually is. You might have problems making some 08-15 applet Open Source in the hope of getting volunteers.


  • major concern (Score:4, Insightful)

    by banks ( 205655 ) on Friday May 10, 2002 @06:42PM (#3499768) Homepage
    i've never coded a piece of software in my life, let alone opensourced one, but i can tell you right now the single major objection or concern you will face.

    The dialouge will go something like this:

    Coder: Let's open source this after you pay me to write it.

    Buyer: Wait. So once we pay you to produce this for us, you want us to let you open source it, in effect giving it away for free?

    Coder: Yeah. It's neat. Information wants to be free.

    Buyer: But you want to be paid.

    Coder: Yeah, I gots ta get paid.

    Buyer: They don't require computer science majors to take economics, do they?

    Seriously here. A buyer who is paying to get a custom piece of software made for them will be very very reluctant to let the rest of the world have that software for free once they have it. Especially if they have competitors. Especially if that software is mission critical at all.

    In summary, best of luck. But perhaps opensource idealism should get a bit more used to taking a back seat to harsh economic reality.

    *ends post, dons flame proof suit*
    • Actually (Score:5, Interesting)

      by Srin Tuar ( 147269 ) <> on Friday May 10, 2002 @07:08PM (#3499895)
      Its pretty standard practice to keep ownership of the code you produce on contract. Typically, its so you can reuse bits for different jobs.

      You almost always give the client an Unlimited Non-Exclusive license to the stuff, but you certainly dont give away what you can sell.

      If a client adamantly wants exclusive rights to whatever you produce, then you certainly raise the rates. And if you bring any preexisting code in an the product, which you will always do, you have to be clear that they dont get exclusive rights to that as well.

      • Re:Actually (Score:2, Informative)

        by SideEffects ( 123663 )
        Standard practice to keep ownership?? Out of the 16 years I've been writing software I've been contracting all but 4 of them. Only once have I every not had to sign an agreement that stated that the company I was contracting for did not retain full ownership of what I produced.

        So the question is "How do you get around this?" I'd love to know, because from the contracts I've had (mostly large telco's) it was either sign the paper or I don't get the work.
      • Re:Actually (Score:4, Informative)

        by NutscrapeSucks ( 446616 ) on Friday May 10, 2002 @07:49PM (#3500077)
        I've been doing this for a while and in something like 90% of the cases the client proactively demands ownership of the code. And it's Work For Hire, so that makes sense.

        This can get tricky because you might want to use some of it for in house code libraries and the like, and in some cases they have objected to using any pre-existing code and/or using any of "their" code for future projects. Yes, this affects the price, and yes you should get a contract signed that covers all of this.

        Furthermore, there's the matter of good business sense. Even if you do own copyright, giving away what you just sold to your clients competitors doesn't sound like a good idea. It causes ill feelings when a developer is selling a app they were paid to write -- much worse if they just posted it on their website.
    • Ok, here is the alternate dialogue where the educated Buyer is also required to take economics.

      Coder: Let's open source this after you pay me to write it.
      Buyer: Wait. So once we pay you to produce this for us, you want us to let you open source it, in effect giving it away for free?
      Coder: Yeah. So that if other people find it usefull and make it better, we can benefit from it.
      Buyer: But you want to be paid.
      Coder: Yeah, I gots ta get paid. But if you closed source it, you will have to pay me forever, and if someone else puts more money than you, you'll be damned. For nobody will help you out and you'll be on your own. And even if you start to depend on this someone, it will always be for the price they ask. So your "competitive edge" either costs you a lot, reducing the incentive, or it is avalilable to everyone else, same result as making it free. The difference is now you don't own the product, you can't make it better and you can't even modify it if you even want to add some speacial feature for use within your company (that GLP explicitly allows).
      Buyer: Mhhh, then did computer science majors start including economics course?

      • Re:major concern (Score:3, Insightful)

        by singularity ( 2031 )
        You forgot one line in there:

        Buyer: But that means that I will pay you for a product that all of my competitors will get for free. They also get all the advantages I do, including other people improving the code. They get that for free, as well.

        Buyer: Why do I not just wait for them to contact you to write an open source solution and then use what you write for free?
        • Buyer: Why do I not just wait for them to contact you to write an open source solution and then use what you write for free?

          Seller: Well, you might be waiting for a long time...

        • Well, it that case your company ends up either:

          - Paying ALL the cost and ALL the upgrades, in which case making it open is a no.
          - Paying someone else who did the product, still getting nothing. The someone can also sell the product to everyone of you competitors. And you fund that company.

          Then you and your competitors start to realize that they are BOTH paying money do this other company which got in the middle, and because you really depend on that single app, you'll have to pay whatever price they ask. And by that time, you also realize that if you NOW want to produce your own tool, it will costs you the SUM of ALL MONEY you and your competitors spent on this product.

          And this is what companies are nowadays finding out. They thought they had a competitive advantage, and everyone thought that. But reality turned out that the software producer was the one that had the competitive advantage. How else would you collect $40B in a competitive market?

          Good try though...
    • Re:major concern (Score:2, Insightful)

      by tclark ( 140640 )
      There is a big mix up here. "Open source" does not mean "give away the code for free". It means that when you give (sell) the clients their license, you give them the source code, and the permission to use, modify, and redistribute the code as they please.

      How is that not a great deal for the client?
    • When I worked for ICL we often had one customer pay for development that later benefitted other customers.

      There were features we weren't interested in adding to our base product but we would add them if a customer would pay for that development. Once the feature had been added to the base product the benefit was available to all our customers.

      Also, customers did not receive the source code to our modifications (the code they paid would have done them no good without the rest of the code). The product was ours and if they wanted to pay for an enhancement that was fine but the product remained 100% ours.

      By the way, the customers were banks.

    • The people who want to be the first to get something always have to pay a lot more than the people who wait for someone else to buy first, and then get in once other people have paid the creator back for R&D costs.

      People paid a whole lot for 486s way back when, and the price dropped quickly once these initial people had bought them.

      The client is paying to have this software available to them. They should negotiate a price that reflects the value to them. If the software is mission critical, it will probably save them more money than they pay for it. The fact that their money additionally benefits others is something they should be prepared to live with, because it's an economy of scale, like everything else, and client #2 always gets a better deal than client #1.

      Furthermore, if the software becomes open source, they stand a good chance of being client #2 for some features they want later; if the software is a totally custom job for them and unavailable to anyone else, it's automatically orphan code.
  • Open Source Policies (Score:3, Informative)

    by Bouncings ( 55215 ) < minus bsd> on Friday May 10, 2002 @06:42PM (#3499772) Homepage
    I've done only very limited contract work and at that, it wasn't Open Source. I think it really depends on the client, as the people I was working with hired me specifically because they were a Windows firm and didn't want to bother themselves with some Unix stuff that came their way from an existing client. For them, of course, it would have been impossible. But I can speak in regard to how some companies would react in general.

    If you're working with a firm that's more familiar with the a community or is part of a larger scientific community, it's another matter. Some firms view releasing open source software as almost a promotional effort and you might egg them to develop an "open source policy" to satify their concerns.

    Board of director types have bazaar stigmas and FUD like "won't we have to support it," "won't it give away our business model," and so on. You can address those questions by suggested an OSS policy. The policy basically comes down to how and when they'll open source software. For example, they won't open source software that would be directly useful to their compeditors. When they do, putting the employee email addresses won't be allowed, as it will burden them with emails. Open Source projects shall be included on another website, etc etc etc.

    But they will be more warm to a policy than simply deciding to open source things adhoc -- so if you give them a policy to address their concerns, you might have better luck.

    And of course if your Philip Greenspun [] good, you can TELL them it'll be Open Source. :)

    2 cents.
    • Reinventing the wheel.
      Paying good money for someone to reinvent a rather poor wheel.
      Paying lots of good money for people to reinvent a lot of bad wheels, some of which don't even work.
      Paying lots of good money to ensure that disfunctional wheels never get fixed.

      Figure that closed source cost GE several billions last year over and above the cost of hardware/software itself.
  • by Col. Panic ( 90528 ) on Friday May 10, 2002 @06:42PM (#3499774) Homepage Journal
    and make sure your source doesn't either in case it should reveal "interesting" information about their systems, environment, transactions, etc.

    If I were paying someone to write code for my business I would want it as customized to my needs as possible while making it modular for further enhancement. What I would not want is for the entire open source community to know what network OS, database version, hardware, etc. I am using since that would reveal too much useful information to potential intruders.
    • Somoene motivated enough to dig through sourc code to figure out your database vendor and version, etc., is also dedicated enough to use other profiling techniques. In the end, you're going to spend more time than it's worth trying to hide your database version. Anyone going after your source code is speciffically tageting your company. If looking though the source code is the easiest way for them to get that info, you're putting too much hard work into hiding that info.

      Here's the easiest way to put the argument: sure it's harder for the attacker, but it's like using a Kryptonite lock and duct tape to attach your bike to the bike rack. Sure it's more secure, but not worth the effort. If you think you need the duct tape, maybe you should lock your bike in a better neighborhood and spend your time walking an extra 4 bocks or something instead of spending that same ammount of time attaching and cutting duct tape. In the same way, you should spend your time properly securing and maintaining all of your boxes, setting up proper cryptography, and enforcing strong passwords with proper limits on lifetimes. Try getting help setting up a firewall from MIT Network Security and they'll tell you to set up cron jobs to port scan your boxes and vulnerability scan your boxes instead. It's a bit extreme to discourage the use of firewalls, but I can definately see where thy're comming from. Just like Morris discouraging shadowed password files. md5 passwords and strongly enforced password complexity offer MUCH better seccurity than shadowed crypt password files.

  • by JanneM ( 7445 ) on Friday May 10, 2002 @06:42PM (#3499775) Homepage
    Tell them that by allow you to open-source it, they will no longer be dependent on you for maintenance; they can hire anybody to do any revisions. Remind them that without this move, the IP will still be yours and they will have to negotiate with you for improvements and further development, and that if they want the IP themselves, that will mean a cost increase for them.

    As a second, less important, benefit you can mention that there is a possibility that others will pick it up for use in their projects, and those improvements will benefit them without it costing them anything at all.

    When they ask why they should pay you to write it in the first place if you're just going to turn around and open it, point out that without a developer under contract to write it, it won't be written at all in the first place. Emphasize that the open sourcing is about the maintenance of the software after it's been written, not about a different model for the development.

    • This is not a decent argument for opensourcing the software! If they want to havesomeone else maintain it at a later date, then they should specify in their contract that they will recieve the source code to the program developed.

      In either case - company recieving source or not, the IP would belong to the company - not the contract programmer and they wouldn't have to say anything to him if they wanted to extend the application. Any company who would hire a programmer to develop an application from scratch that would not become the IP of the company (opensource or not) would be stupid.
    • Tell them that by allow you to open-source it, they will no longer be dependent on you for maintenance; they can hire anybody to do any revisions.

      No, since they have the source, they will provide it to the "anybody" you mention to fix/enhance/etc. I've been that "anybody" many, many times.

      Remind them that without this move, the IP will still be yours and they will have to negotiate with you for improvements and further development, and that if they want the IP themselves, that will mean a cost increase for them.

      This is just not true. They paid for your time, they own the source. You however, can go off and reimplement it at your next client... Remember, you didn't just get paid for some text files, you got paid to transform a set of requirements into a tested solution... This includes testing, debugging, looking on #dumbass for help, etc.
    • Tell them that by allow you to open-source it, they will no longer be dependent on you for maintenance; they can hire anybody to do any revisions.

      Can't they do that anyway? The small business owner will get the source code regardless of whether or not it's open-sourced, won't he?

      Remind them that without this move, the IP will still be yours

      No, unless the contract explicitly says that the coder retains copyright, the copyright on the code will belong to the small business owner. When a work is commissioned--a "work for hire"--the copyright belongs to the person or organization commissioning the work, not the creator.

      (Not to mention the fact that if the IP did still belong to the coder, as you suggest, he would not need the business owner's permission to open-source it.)

      • I'm not sure how software code works but as a graphic designer I most certainly own the copyright to my work unless otherwise stated in the contract. Contract does not mean work for hire. If it did then the company would be responsible for paying me benefits as top of my fee.

        If I design a logo for a company I state up front in the contract what they can do with the logo. For instance if they were going to just use the logo on a web site I would charge accordingly. However, if this logo is to become the company's entire identity system I charge a dfferent, more lucrative (for me) fee. I can't turn around and sell this logo to another company but as I own the copyrights to the logo, I can include it in my portfolio without the company's approval.
  • by oneiros27 ( 46144 ) on Friday May 10, 2002 @06:42PM (#3499776) Homepage
    Depending on what you're attempting to develop, you may be able to develop the code faster using code fragments from other developers. Of course, if those bits of code were GPL'd, you'd be obligated to make your code available.

    Depending on the scale of the project, and the odds that the code segments you need already exist, you have to determine how much time savings you'd have by researching previous GPL'd projects over writing it on your own.

    Although many companies wish to retain the rights to software you write, there are very few people who don't re-use bits from project to project. [Hell, it'd be downright foolish not to use already written and tested code]. As such, on any programing project I take, although there might be an NDA, I still retain the right to re-use the code in any further projects. Otherwise, I run into the risk that my common code library will be locked down once it's in use in this project, and I'd rather not take the project.

    [even if they paid me more than my going rate, I'd be worried about using knowledge that I got from the project towards another project, and getting sued.]
    • by Anonymous Coward
      Grrrrrr... In a case like this, the GPL does *not* obligate you to make your source code publicly available. It does require you to give a copy of the source code to the same person you are giving the compiled executable to. That is all.
      • You aren't obligated to make the source code publicly available, but you are obligated to "cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."

        If you're a contractor, and not an employee, you almost surely are considered to have "distributed" the derivitive work. While you aren't obligated to make the source code available, you are obligated to GPL the code, and unless you are under an NDA to not disclose the code, if it happens to get onto a public FTP server, then anyone is free to use, copy, and redistribute it.

    • Using bits of GPL in a work owned by your company (or a company with whom you have a contract) without first asking for permission to do so will expose you to more civil liability than you can shake a house at.

  • by Codex The Sloth ( 93427 ) on Friday May 10, 2002 @06:43PM (#3499778)
    I assume you told him the part about not supporting the software you write, correct? Open sourcing software is not the magic pixie dust you apply to a half assed job. Look through Sourceforge at all the abandoned projects -- the world is not interested in finshing the job.
  • Custom apps (Score:5, Insightful)

    by frank_adrian314159 ( 469671 ) on Friday May 10, 2002 @06:44PM (#3499784) Homepage
    ... often contain proprietary business logic. The first step would be to convince me that nothing like this would leak out of the app and be used by my competitors to gain advantage.

    Next, you'd have to show me that releasing the code would not open me to any liability nor to any security breach. Saying that "more eyes see more bugs" is not an answer either, because I'd still have to pay someone to integrate fixes or, at least, re-install on my system each time an eye found a bug.

    Finally, you'd have to show me that I couldn't profitably sell this as a product - probably not a big deal, as software doesn't appear to be your customer's area of expertise, but small businesses live and die on cash flow and, if I can keep it proprietary, not do anything to support it, and still charge money for it (i.e., the Microsoft strategy :-), I'd still do it...

  • by itwerx ( 165526 )
    Don't give them an option. This does pre-suppose that your contract gives you full rights to the software of course. I own all the rights to every database and utility I've ever written, and while none of them have been sufficiently general-purpose enough to actually be worth releasing I have the legal right to do whatever the heck I want with them.
    Now I wouldn't go shoving it in their faces. Heck, I wouldn't mention it at all. But if you release it six months or a year after it's finished - A. They might never know, and B. Even if they do pitch a fit there's nothing they can do if you own the rights to it.
  • by edp ( 171151 ) on Friday May 10, 2002 @06:50PM (#3499816) Homepage

    Present the potential customer a list they can choose from like this:

    • Software for XYZ and copyrights, $5000.
    • Software for XYZ and non-exclusive license, $4000.

    If they take the software with a non-exclusive license, you still own the copyright and are free to release it under GPL or whatever other terms you like.

  • *Clue Stick* (Score:2, Insightful)

    by glitch_ ( 48803 )
    No offense, but this is one of the stupiest ideas I have ever heard. When you develop code for a client, the client then owns the code. Simple. If you cannot support your own code, at least they have it so they can give it to somebody else to support and maintain.

    Remember though, that your name is going to be associated with that code for all future developers to see. You better take some time and carefully document everything you do. Your code is a personal reflection of you and your work ethic, so you don't want people to get the wrong idea.
    • When you develop code for a client, the client then owns the code.

      Not true. Unless the contract says you are doing a "work for hire" the writer retains the copyright. Also, only works that are created to be part of a larger existing work can be a "work for hire".

      Also increasing the strength of an author's claim to ownership is the fact that he's a contractor and not an employee.

      Therefore, if you are hired to write a program for someone, you own the copyright, even if the contract describes what you are doing as a "work for hire".

      IANAL but Google can confirm what I have said.

  • by Kagato ( 116051 ) on Friday May 10, 2002 @06:52PM (#3499830)
    I've worked for companies that have paid HP and IBM hundreds of thousands of dollars to have features placed in products. Never, ever, was there even a question who owned the source. HP and IBM.

    But I've been in this guys position. Small companies are control freaks. They aren't willing to pay the money that a larger client is, they don't understand the debug cycle, they are usually more of a hassle to deal with, and to make it that much more irriting they want to own the IP.

    Stick it to them straight. You'll provide them the solution, and the source, you own the IP and will do whatever you want. Don't be rude, but be prepared to walk.
  • Your idea (Score:3, Insightful)

    by GoRK ( 10018 ) on Friday May 10, 2002 @06:53PM (#3499835) Homepage Journal
    I have to say one thing about your notion - If I were the company thinking about hiring you to write the software, you wouldn't be far enough along to be asking this question.

    I'd have fired you long ago because you won't continue to support your work. (Of course, writing an app so good it never NEEDS suport is another matter altogether.) It's completely ridiculous to assume that publishing the source under whatever open license will instantly give you an army of developers willing to continue to support and continue developing on the application for free.

    Normally what you'd do is write the opensource app, and then a compnay would hire you to extend and support your own application inside of their project - in that case, then you could start talking with the compnay about whether the changes would be opensourced or not. In this case, you're turning the whole thing on its head.

    Still, you may be right in that opensourcing the project would be a good idea for the company - but that is a decision that should be made INDEPENDENT of the development itself. The company should approach the decision with the assumption that the package is already developed, or even better AFTER the package IS developed. Most importantly, do not give this company any kind of false hope about what opensourcing the software will do. If you are a developer who actually runs any opensource projects, I don't really know why you would even think of recommending this so soon.
  • by gewalker ( 57809 ) <Gary.Walker@Astr ... m ['ita' in gap]> on Friday May 10, 2002 @06:55PM (#3499841)
    Why do you feel compelled to persuade the customer to open source the software you intend to deliver?

    1) Moral objection -- then do or do not (sorry Yoda). You may choose to express you moral view or not to client depending on whether proseltyzing is worth the effort/benefit ratio. If you fail to persuade, do you turn down the job?, if not, see point 3

    2) Don't want to support -- then don't support, let customer know this, and why (at least if they ask). If you feel OSS makes a different in support, see point 3.

    3) Anticipated benefit to customer -- explain your view of benefit, let customer choose.

    4) Want to use exising OSS, see #3

    If all you want is additional bullet points for #3, I'm sure you'll get plenty of opinions on slashdot. But, I would recommend sticking to things I believe in and understand (preferably have experience with) when making the case for OSS.

    Hmm, point 3 seems to be pretty important. Give the customer a rational (or emotional) basis for making a decision. And let them make a decision. It's their money, their project, not yours. Of course, if its a moral issue with you, don't violate your morals. Don't come crying to anyone if you have to sacrifce though, high morality requires that you be consistent and be willing to accept the sacrifice it may involve.

    My life is complicated enough without having to convert others. Matters of religion, politics, etc. are very similar to the arguments we coders get into -- We believe strongly in what we believe, for waht we believe to be good reasons, others believe just as strongly differently. You may convince some, other's you just make mad.

    I may believe it's worth arguing religion (save their soul, or save the waste of their time/beliefe in myths, not saying which i follow). Politics -- you get morality and economics. But coding ... Sorry, I take option 3 -- I have enough hassles in my life.
  • What's the problem? You sign over the rights to use, or modify the code. You don't sign over the rights to distrubute it.

    *OR* Sign it over to him under the GPL and restrict yourself from distributing it.

    Any body he hires to modify it is restrained by the contract they sign with him as it is an internal project (to his company), and -if- he ever decides to release it he can do so.

    And no future developers can take any rights away from him on the code, or modifications to the code. (ie: they couldn't hand him binaries without sourcecode).

    If you want to get paid to develop something you have to expect that you won't have full rights to it when your done. If you client says 'sure, no problem', great. Otherwise you won't have a choice.
  • by dustin_c1 ( 153078 ) on Friday May 10, 2002 @06:59PM (#3499853)
    Remember, open source does not necessarily mean free as in beer or free as in speech. A lot of business software licenses allow purchasers of the software access to the source code, but it strictly forbids redistribution of the code. Such a license is open source yet not free as in beer and certainly not free as in speech.

    Your best bet is to give the client the source code. You need to choose whether or not you want to retain rights to the source code, or give all rights to the client. Most contract programming jobs I've ever heard of require that the client not only gets the binaries and documentation (and sometimes training) but also the source code and complete rights to the source. That way, you don't depend on you for incrimental improvements. They can hire their own developers to do that if they have the source.

    Honestly, if this is a custom job that is likely only of interest to the client (and perhaps the client's business competition), you are ripping them off by not giving them the source. But again, it's your job to choose whether or not you want to retain the copyright to the code for yourself, or give all rights to the client.
  • by teambpsi ( 307527 ) on Friday May 10, 2002 @07:00PM (#3499857) Homepage
    The contract jobs I'm doing lately, I'm plugging in as much open source as I possibly can, and then essentially charge the client for the "glue" code that puts it all together.

    Most business problems have been "solved" in one way or another elsewhere -- extol the virtures of sourcing in something that they will be able to get support for, using the old "if i get hit by a bus" scare tactic ;)

    Otherwise, through good architecture, you can compartmentalize the proprietary bits to a few files, thus allowing them to have something of their own at the end of the day.

    And again, BE OPEN UP FRONT -- you are probably not in a position to identify on your own what the client may or may not consider proprietary -- lots of businesses have "grey-matter" or "raw experience" when it comes to processes and methods that are not obvious to their competitors.

    But basically we get a lot of mileage becase I stand on the shoulders of giants everyday!

    and remember, work = force * distance ;)
  • Geez... (Score:2, Insightful)

    by BayStealth ( 137271 )
    I'll make this short...

    First, there are an awful lot of folks here who are beginning to sound a little like a bunch of NW fools I can think of.

    Second, I'm no coder. I'm one of the owners of an engineering co. that hires coders. And I "get it".

    If some coder thinks he can tell me what to do with something I am paying him for he can hit the road, period.

    OTOH, I am currently paying a coder to develope a number of OpenLDAP tools for managing and syncing user accounts across multiple servers. I have every intention of "open-sourcing" these once they are debugged and useful.

    But just because I get it does not mean I will stand for being told what to do by an employee. Instead of arguing about IP, you folks should be figuring out how to make the PHBs "get it".
  • Your client may not be opposed to inclusion
    of open source INTO his app. So write the open-source on the side, increase the hourly rate
    accordingly so that the labor of integrating it
    pays the same, voila :)
  • You want to leverage the availability of Free software beacause it will let you get the job done faster, cheaper and better, right? If you aren't planning to use some of what's already freely available, then what's the point? It should therefore be fairly easy to convince the client that they can get software of exactly the same functionality (and probably better quality if you use proven components) for a whole lot less time and money if they let you borrow from - and give back to - the Free software community. If the alternative is paying you to develop everything from scratch, it should be a no-brainer.
  • by OldTome ( 89259 )
    Just put the GPL in the EULA everyone clicks through on install.

  • I really don't understand how open source benefits the customer. If they need a custom app, there is obviously not a large amount of demand for it. As such, why would a group of programers be willing to donate their time to a project with limited potential. Thousands of open source projects are abandoned every year. Just look at sourceforge. Second, if this is very custom software, why would the open source community be willing to add all the features that this one person needs? Now, I am sure this software would be useful to a few more people, his competitors. So, he is paying for something that benefits him, as well as his competitors, and on top of that, giving away to them what he could potentially sell for a fraction less, or even more, then what he paid you to develop it in the first place. Have you seen what very specialized, complicated apps can sell for.

    The bottom line is, he will have to hire someone else to maintain it anyways, because I can assure you that the open source community will have no interest in maintaining it for him, but he will have given it away to all his competitors. He is a fool to go the open source route.
  • give them a choice (Score:2, Insightful)

    by ryochiji ( 453715 )
    Ultimately, they're the ones hiring you, so it might not be a good idea to say "Open Source, or else..." Instead, tell them that if they want "all rights" to the code, they would have to pay significantly more. I suspect most companies would go for whatever's cheaper, since, they're going to get their software either way.
    You could try convincing them about the virtues of OSS, but at the end, most businesses are more interested in the bottom line...
  • sample language:

    The software will include Open Source components for which neither CLIENT nor CONSULTANT will hold exclusive copyright. CLIENT will be granted an unlimited license to use the software. The right to resell the software will be granted but will be restricted by the terms of the GNU General Public License ( and/or other Open Source Initiative approved licenses (

    This particular case was for a project which I knew would include some custom code in addition to some pre-existing open source components, but you could apply the same idea to 100% new code.
  • I do not intend to stick around for incremental development after I've delivered it

    Does the client know this?
    Be open with your clients.
    Lay all the options on the table and let the customer decide.

    Explain why you cannot maintain the software.
    You could be assuming they expect you to maintain it. (Assuming too much is a bad habit).

    Being open in all aspects, is the best thing "Open source" advocates have going for them.
  • What's the problem? (Score:2, Interesting)

    by dskoll ( 99328 )

    I had a client ask me to do a piece of software. I said right in the contract that I owned the rights to it. I GPL'd it and it morphed into MIMEDefang, which is a far better product now than it was when I originally delivered it.

    I'm working on another piece of software which has certain proprietary and competitive features. After a lot of back-and-forth with the client, we've agreed that I can GPL parts of it (called "core infrastructure code") while giving up rights to other parts (the "non-core code.")

  • Don't convince the client of anything. As an independent contractor, your work isn't work for hire. You hold copyright. So, just don't sign a contract which stipulates that it will be work for hire.

    Disclaimer: IANAL, TINLA
  • How about instead of writing something from scratch, and open sourcing it; you find an existing OSS Project and extend it to do what your customer needs? There is a better chance it will be maintained when you are done with it, because it is already being maintained. If we all did this we would have a few enterprise level Apps that kick ass instead of a bazillion that are half written.

    But please don't bother open sourcing anything if you (or no one else) plans to maintain it.

    There are enough dead projects out there already. Don't add to the graveyard.
  • If the software is not seen as a huge direct advantage (the secret sauce) and is not sold by the company, then there is a big advantage in having the source open if it is a generally useful set of functionality. In this case it is likely the company will benefit from ongoing free maintenance and debugging. They also get often more talented and interesting programmers involved if the result is OS than they would get to come do maintenance on a piece of proprietary code. If it is fairly popular they can also more likely find talent when needed that already knows that code.
  • It sounds to me like you want to have your cake and eat it too. Isn't the typical Slashdot argument to paying for software, "All software should be free"? And yet, you still want to get paid to write it? That doesn't seem to compute to me. This seems like the big problem with the open-source methodology. Nobody likes to work for free, and yet people often voluntee their time and skills for certain efforts they appreciate/support/believe in. If you want to open source the software, then open source it and don't expect any compensation for developing it. If you want to be compensated, then don't complain when companies like Microsoft, Sun, etc. want to be compensated for their work in developing their products.
    • Do all your work in front of a webcam and sell the client a ticket to watch you create open-source software that just happens to meet his exact project needs. This way, you get to thumb your nose at all the self-righteous /.ers who are wailing about "having your cake and eating it too." You get paid for your performance (just like an actor), the client gets his software, and the software is liberated.

      And if you didn't realize this was a joke, well... either you need a better sense of humor or I need to work on it and tell it again when it's funny.

  • by hol ( 89786 )
    In all honesty, this depends on what you're writing, and how you present the idea to the client.

    Your client could be convinced to open-source something if:
    • What you're writing is not crucial to their business, i.e. a utility or something like that
    • The software is generic, and does not contain business logic or other domain expertise of your client
    • If this is useful enough to others (not direct competitors) that they would invest some time in improving what you wrote.

    On the last point, they might agree if you can show the client that what you will be writing will indeed be picked up by some other people/companies. These other people would be interested in what you wrote because they would also need what you wrote, and the improvements made by others can provide a direct benefit to your client.

    I realize that the logic is somewhat circular here. You have to prove it's good enough for everybody, and then everybody else would do something that's good enough for your client. Presumably then they would also need the technical expertise to actually use what you did.

    The other problem is convincing the client that there is nothing proprietary to them in the software. If they hired you, it usually means they don't have enough in-house expertise to decide this, and their decision will be no.

    If this gets open sourced, your name would be on it, and that means you would be on the hook to _everybody_. It does not absolve you of the responsibility of maintaining the software and defending your design decisions. In fact, it makes you more responsible.

    I have worked with companies who thought about this long and hard, and typically did not do it. The exception was software that was end-of-life, with maintenance being cut, and the costs amortized. At that point, unless one of the points above applies, it can make sense because open-sourcing internal software is a hedge for maintenance provided several others start using it and work on it.

    On the IP-side, the work you are doing is considered "work for hire." This means your client owns the IP, all of it. It's like being an architect: you draw plans, and if the client goes ahead with building the building they have full rights. Yes, your name is on it, yes, you have liability exposure, but they own the work, because they bought it from you. The only way to get around it is if the agreement between you and the company states clearly that you are giving them a license as opposed to performing work for hire. If you want to be really clear about what you're giving away, get a lawyer - your client likely has one too.

    just my half-cent.

  • by wirehead_rick ( 308391 ) on Friday May 10, 2002 @07:44PM (#3500059)
    not the code. Develop the code under GPL/Open Source. Then charge them to implement it on their system.

    Re-organize it so they are paying for your support and service while you are paying to write the program.

    Frankly that is what you are trying to do anyway. You want them to pay you for your services not for your code or you wouldn't have even considered open sourcing your SW.
  • Don't present a smoke and mirrors handwaving routine. Just plain speaking will do you fine, I'd guess.

    I'm going to assume, perhaps incorrectly, that you are developing an application which will be deployed in a GNU/Linux or BSD environment. I'd simply say "I'm able to provide this solution for you because other people have provided free license for use of their software. In exchange for my services you are paying me money. In exchange for the contributions (which are 99.9% of the total package) provided by the free/open source software community, you are simply agreeing to contribute something back."
  • It don't think anyone produces near perfect or perfect software in one development cycle. Let them know EXACTLY what they are paying for and if they want more, charge them. You're a contractor, A paid professional who's purpose is to accomplish a specific task and ONLY that task. Otherwise pay more :-). Somebody calls me for a "quick question" outside of work regarding an issue that I am working on under contract. I CHARGE THEM for my time. You bet your ass when they get the bill they wait until the next day to ask me questions :-).

    If anyone has ever had to deal with a Lawyer you know what I mean. Call the man to chit chat for 15 mins and you get a bill in the mail for his $450/hr rate divided by 4. No kidding. Why should your time be worth anything less?

    Don't give your software away and don't sign away your ideas if you can help it(i.e. IP). Every idea in your head is worth money to someone even though you may not realize it. Telling your client that you recommend giving this software away will make them feel insecure and they will also be reluctant to hire you again to maintain and extend the software. Also, If the software truly is 'unique' it is another feather in your hat that the next contracter DOESNT HAVE. Don't work yourself out of a job. Know the difference between what is work and what is your hobby.


  • by rjamestaylor ( 117847 ) <> on Friday May 10, 2002 @08:18PM (#3500155) Journal
    Having determined that most of the posters to this Ask Slashdot have decided to buck the trend of mindlessly supporting Open Source philosophy by mindlessly opposing Open Source, I'd like to offer a suggestion to the Asker.

    First, base your project on an existing Open Source project. Show the client how much value s/he gets from starting with the project(s), not limited to the fact that others have reviewed the code.

    Second, once the client sees that h(i|er)s project will benefit and that the total project will cost less, explain the need for continuous updates and maintenance. Explain how costly it will be to maintain that work totally and solely in house.

    Then, propose a solution to 'leverage' the Open Source community to assist with the project by releasing the changes, with the client's approval, back to the project. Explain the benefit of many eyes and many users perfecting the codebase.

    This is exactly what I and a colleague have done with a very properietary-minded client. Now he's onboard for releasing the modifications and enhancements we will create back into the project community. Actually, he's excited to do this.

    The way to your client's heart is through the bottom line.

  • by zulux ( 112259 ) on Friday May 10, 2002 @08:25PM (#3500170) Homepage Journal
    All our bid specify that the cusom software is GPL'es and it's help us squish the competition after we explain the benefits to them:

    1) If we die, then they arn't left up a creek without a paddle.
    2) Their data can be easily migrated over to a new peice of software if need be.
    3) They can extend the program if they later decide that we suck.

    It wins contracts, and we don't low-ball our bids.

    Aside: Never low-ball a bid, it looks syspicious and makes the prospect nervous.

  • Contracting (Score:2, Interesting)

    I contracted for years to several companies, developing custom solutions for them, and never once did I have to give them the source code (lucky, they were a pack of twats!). IP rests with the developer unless the contract specifies it belongs to the company who hire you. They have a clear right to the binaries, but access to the source code is up for negotiation.

    What is the point of open sourcing the code? Put it in escrow if the company requires that, or negotiate code release into the contract if they want that, but make them pay for it. Remmember, it is always more expensive to contract someone to produce reusable code for you, than it is to have a system built.
  • We are a custom software development shop using our own framework as a basis for delivering custom applications to customers.

    We have an arrangement with our customers which works out very well for both of us. Once you factor in the incentives of both parties, this arrangement naturally leads to a happy situation for both parties.

    We come into the relationship with a substantial framework, which we license to the customer under the GPL. As the relationship progresses, we build many components. Some of these components are specific to the customer's business process, and some are more generic. We retain all IP rights to the generic components, which we integrate into the framework and license back to the customer under the GPL. The customer retains all IP rights to code that is specific to their business process.

    We maintain a code repository for each customer which contains their business specific code. These are typically workflow definitions, business specific data models, entry screens and reports, etc.

    We also maintain a common repository for the framework, which contains all the reusable code (whatever we define to be reusable). We usually have a few projects going on at the same time, and this repository receives contributions from all of them.

    The benefits of this arrangement for the customer are:

    * Customer owns specific business process logic, UI elements, data models for their business, which means that they control their trade secrets and we can't go to their competitors and sell them the system they payed to custom build. In return, customer is solely responsible for paying someone (usually us) for maintaining and enhancing these components as their business changes.

    * Customer does not have to pay to build a major system from scratch. They get a tested and tuned framework for free upon entering the contract, and only pay for customization, which is a process we excel at. In this fashion, we can deliver a return quickly and with minimal expenditure, since we don't have to build much infrastructure.

    * Customer gains the benefit of framework enhancements for other customers. Over time, as contributions are made to the core framework, more and more reusable functionality is available to incorporate into our custom solutions. This has the effect of bringing sophisticated functionality into the customer's price range. In effect, all our customers indirectly share the cost of maintenance, tuning, and additional generic functionality.

    * If we go out of business for some reason, the customers have all the source code they need to achieve continuity.

    The benefits of this arrangement for us are:

    * We gain a powerful framework that is tested and tuned across multiple production deployments.

    * We can out-bid competitors who need to build things from scratch, who base their work on proprietary software which they cannot enhance or control, or who must recoup massive amounts of R&D , marketing expense, and capital risk.

    * We spend our time solving unique business and technical problems, as opposed to re-coding functionality for multiple customers simply because we don't own IP.

    * We spend very little time on maintenance because most of the difficult code is maintained in one place- application specific code is mostly declarative.

    * We do not have to pressure customers to buy upgrades. We keep customers current as part of the development process.

    We have been modestly successful using this model, and people who work with us, both developers and customers, are happy and getting good value.

    Once caviat- our customers tend to be in a line of business other that software development, thus they care less about owning software IP than than do about streamlining their business processes.

    Hopefully this will inspire some ideas.

  • The question makes a wrong assumption about Open Source. It assumes that you have to give the source away to everyone. That is wrong. There may be some licenses that require this, but they are few and far between.

    Let's take two examples, the BSD license and the GPL. The GPL only requires you to give the source code to the recipient. In this case it happens to be your client. Once they get it, it's up to them as whether they want to distribute the source further. The BSD license doesn't even require this. But you're going to give your client the source code anyway. So it makes no difference.

    That said, I think it would be extremely rude if you charged your client for the code and then turned around and posted it on your website. If you're going to do this, let them know ahead of time.
  • by GiMP ( 10923 ) on Friday May 10, 2002 @09:38PM (#3500368)
    I have written software for clients, anything from simple shell scripts to large web applications.

    Typically, If I intend for the software to be OpenSource, then I only charge for the installation of the software.. and not the development of it. I will normally charge for the installation of opensource software which I did not create, why should I not charge for the installation of software which I have created?

    I have worked for some clients who have requested, at the completion of the software.. for it to become Opensource, for the sole reason that the software meets their minimum requirements.. but would like continued support after the end of my contract.

    If you have any doubts, discuss it with your employer/contractee.
  • by Jay Carlson ( 28733 ) on Friday May 10, 2002 @10:02PM (#3500447)
    I know I'm tempting moderator retribution but let me summarize some of what I see above:
    • The contractor owns everything; customer gets license to a binary
    • The contractor owns everything; customer gets license to binaries and the source code under some circumstances (such as contractor unavailability)
    • The contractor owns everything; customer gets license to use and modify binary or source for any internal purpose
    • The contractor owns everything; customer gets an unlimited but non-exclusive rights to binary or source.
    • The contractor owns everything, but agrees on limitations on reuse or redistribution; customer gets some license from above
    • The contractor owns nothing; it's a work for hire, since the customer contracted for the work rather than a service
    • The contractor owns nothing, but the customer grants certain rights to the contractor, such as limited reuse of modules.
    • Ownership is mixed, with some parts retained by either sides.
    It sounds like what you need to do is agree with your customer what their expectation is on licensing, and get that in the contract. For example, if you own the work but agree not to disclose certain modules dealing with business process, it's clear to both sides what you can and can not disclose later. That may mean reuse on other contracts, provision to their competitors, or release to the general public.

    In general, the more restrictive the customer rights to work performed, the higher the rates.

  • You are the author of the work and therefor have the copyright unless the you assign it to the client or unless it is a work for hire. Since your are not an employee, and it is not a collective work, etc. (See, warning: PDF) it is not a work for hire. So, in theory you can do anything that you want with it.

    That said, you have an ethical obligation to work out a resolution with your client.

    (Assigning it in the contract is also considered a work for hire.)

    In theory, theory and practice are the same, in practice, they are not.
  • I've done this (Score:3, Interesting)

    by Simon Brooke ( 45012 ) <> on Saturday May 11, 2002 @02:38AM (#3501209) Homepage Journal
    The last several big jobs I've done, I've agreed in advance with the customer that the software produced would be released under my copyright under BSD license. I've had no trouble getting big corporate customers to agree to this. The next negotiation, I shall try to get them to agree to GPL. It has some benefits for the customer: it guarantees that they have access to the codebase in perpetuity, whatever happens to me.
  • by foniksonik ( 573572 ) on Saturday May 11, 2002 @04:06AM (#3501382) Homepage Journal

    The client gets exclusive rights to the software for two years at which point the software becomes open source. This would manifest in the form of a clause in the contract stating such.

    This would give the client room to breathe against competitors or enemies seeking to compromise their software, gain from their expense, etc. while still allowing for the continuation of the code in the open community. If the code is interesting enough to still be viable in two years then it will persist.

    This is very similar to having someone license technology but instead of losing their rights to the tech they merely have to share with everyone else, though not any additional modifications they have made to the code in the meanwhile.

    This would also mean that the code would have to be put into escrow in order to meet the requirements of the contract for both parties and as an insurance measure for both parties.' Escrow 'meaning that a 3rd party would have a copy of the original code and would release it into open source according to the contract despite any intentions of the two parties otherwise.

    Seems like a lot of effort but if you think your code is important enough to the community at large then this would be worthwhile because of the checks and balances it imposes. The client would of course pay for everything.

  • by dbretton ( 242493 ) on Saturday May 11, 2002 @09:42AM (#3501890) Homepage
    In The Cathedral and the Bazaar, Raymond mentions a case where he spoke with a small company about some peculiar software they used for their product.
    The company asked him if OSS'ing their software would be beneficial. His reply was "no", since the software had a somewhat limited application outside the context of this company.

    The situation cited in the article sounds similar to the one ESR mentions, so I would have to say "Nay" here.

    -PS. The story was in his book, The Cathedral and the Bazaar, so I am not certain if it exists in the online white paper of the same name.

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller