Sure thanks for the info. My thoughts (but with no open source license experience):
. I would tend to avoid doing anything without the client knowing in advance at all stages of the process to give them the choice and you the opportunity to assess risk in each case, especially if you are going to be asking them for money. (someone else suggested the same sort of thing) o Of course volume may impact that but if it relates to you changing something on their setup I definitely would communicate first before changing anything. . If you are presenting it to them as an option/upgrade/expansion stage the demo on your own server so you retain control and then you don't have to take anything back. If they don't want it they don't request the upgrade. . If it is a feature they have requested and you want them to carry cost get it in writing in advance as you would with any development process and if roles change you have at least some comeback providing the person making the request had the authority to commit to the cost. (even that is no guarantee but that's when it may get legal) . If it is a bug fix and constitutes meeting expected quality of existing functionality then you may have to suck it in unless the individual client is very accommodating for some reason. . I have clauses regarding liability for things that are outside of my control, the result of 3rd party, or things that could not be reasonably foreseen for what that is worth. . I agree about it also comes down to good will, you may get more sales and repeat business through fostering good will than getting every pound of flesh, within reason. I don't want to carry the can for something I can't control. . Apart from liaising with your lawyer about contractual risk (and paying for it) it sounds like each individual case will have varying levels of risk and I don't think you can contract it all out. . The best insurance may be avoid giving clients unexpected costly surprises and communicate well and openly. . I also try to have clear minimums predefined that I stick to regardless so it isn't personal it is just how I do business . Try Microsoft's risk management methodology (may or may not be beneficial) o brainstorm your potential risk scenarios and any possible early warning signs regardless of how silly o Evaluate a numerical rating for probability and secondly for scale of impact and use those to calculate a risk factor for each scenario o Sort them by highest to lowest risk rating o Develop preventative and/or prescriptive mitigation plans for the tops risks that you determine warrant it o Watch for those you can prevent and use you mitigation plans for those you can't o Review your list from time to time to see if ratings have changed causing a need for new mitigation plans or adjustments to old ones. Don't know if any of that is of use and am sure others will disagree or have better ideas. Andrew McMurtrie, BICT (dist) McMurtrie Group Limited 15 Fulham Street Hornby Christchurch New Zealand Ph: +64 3 960 5077 Fax: +64 3 960 5077 Cell: +64 21 88 1916 Email: <mailto:[email protected]> [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Jochen Daum Sent: Monday, 27 July 2009 4:07 p.m. To: [email protected] Subject: [phpug] Re: legal: retain ownership of code until paid and open source licence Hi, On Mon, Jul 27, 2009 at 3:42 PM, Andrew McMurtrie <[email protected]> wrote: I am still interested in the context to get a handle on what you are asking. . What is the definition of the maintenance? o Is it bug fixes, enhancements, contractual obligations of refactoring, client requested features? client requested features, client requested adjustment to how business has changed. No contractual obligation to do it from our end, but of course its our business to help people cope with change . Was it requested, contracted, quoted, completed and then Acme Ltd had issue? correct . Is it just done and they are told oh by the way we did 'Maintenance' on the product which you are now using and it will cost you $X amount. (I doubt you would do that but hey worth asking) The reality is somewhere between that. Most clients understand if they ask often they pay more than seldomly. . Did one person agree to it and then someone else took over responsibility and said there is no way in hell we are paying for that? (the possibilities are endless) I agree I get the impression you don't know you just want to make sure you are not liable for something that could bite you if it came up under the type of license or is this a real case? I'm posing this as a theoretical question. I'd like make my contract simpler and easier to buy and open sourcing the licence is one part of a method to do that in my opinion. So I'm assessing risks and see how they can be managed by other means than a contract. This is not a real case, I have a lawyer for real cases. Kind Regards, Jochen Daum Chief Automation Officer Automatem Ltd Phone: 09 630 3425 Mobile: 021 567 853 Email: [email protected] Skype: jochendaum Website: www.automatem.co.nz http://twitter.com/automatem http://www.xing.com/go/invite/3425509.181107 __________ Information from ESET NOD32 Antivirus, version of virus signature database 4280 (20090726) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
