Thank you Dylan, Simon, I don't understand the code for the work done for a specific customer(s), can be a gold mine. I am not sure what owning the code means, anyone and everyone (competent programmer) can reproduce the same effect with some variation.
Kind Regards Arjang On 4 June 2010 09:34, Simon Haigh <simon_ha...@pillar.com.au> wrote: > I always thought that being a contractor is similar to being an employee and > therefore the codebase would belong to the person/company who employed you > (unless otherwise specified). Would that be correct? > > If not, I'm potentially sitting on a goldmine. :-) > > -----Original Message----- > From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On > Behalf Of Dylan Tusler > Sent: Friday, 4 June 2010 09:21 AM > To: 'ozDotNet' > Subject: Code Ownership WAS: RE: .NET Obfuscator Software..free! > > Disclaimer: IANAL > > Employee - Any code you write is the property of your employer. > > Consultant - Any code you write is your property unless you explicitly assign > ownership to your client. > > Company - Any software you sell, the codebase remains your property, not the > property of your customer, unless there is a specific license agreement > indicating otherwise. > > For what its worth, when I was consulting, I used to assign code to my > customer explicitly, so that they could freely engage other developers to > work on it at a later date. > > If you are working on T&M or are working fixed price, I don't think it > matters. What matters is the arrangement that you have made between yourself > and your customer/client/employer. > > Here's an article on the US perspective. It mentions the concept of a "work > for hire" agreement, which is where you cross the line between employee and > consultant: http://articles.techrepublic.com.com/5100-10878_11-5034783.html > > Dylan. > > > > -----Original Message----- > From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On > Behalf Of Arjang Assadi > Sent: Friday, 4 June 2010 8:38 AM > To: ozDotNet > Subject: Re: .NET Obfuscator Software..free! > > Hi Anthony, > > Please forgive my ignorance but my question is what is normal practice? What > is meant by work? When quoting hourly rate, I assume that at the end they > would get everything and since I have been paid for the time to produce it, > it belongs to them. > > Kind Regards > > Arjang > > > On 3 June 2010 20:11, Anthony <asale...@tpg.com.au> wrote: >> I assume that if the client doesn't ask for the code then i don't give >> it out. I would increase my fee if they want the code anyway >> >> >> >> From: ozdotnet-boun...@ozdotnet.com >> [mailto:ozdotnet-boun...@ozdotnet.com] >> On Behalf Of Michael Minutillo >> Sent: Thursday, 3 June 2010 3:07 PM >> To: ozDotNet >> >> Subject: Re: .NET Obfuscator Software..free! >> >> >> >> Well most clients I have dealt with in the past end up with the source code. >> >> >> >>> After all, "clients" have been accepting obfuscated code since time >>> immemorial already! (Well, at least since the 1980s.) That's what >>> compiled code is! Unless you wanted to reverse engineer to assembly >>> language, pretty much everything was obfuscated. >> >> >> >> In the form of a product that is true. But if that were the case I >> would expect the OP would have wanted to obfuscate the entire >> solution. As there is a single binary to be obfuscated (and it gets >> used a lot) it sounds more likely that it is being used in custom >> software that is developed for a single client. For the client: >> >> >> >> If they purchase a library then they get a support contract so if >> things go wrong they get fixed >> >> If they use an open source library then they get the code so they can >> fix issues or pass them on to someone to fix. >> >> If the developer hands them a library which is neither they could be >> in trouble. >> >> >> >> If you are selling a product with support then this is OK because you >> have an agreement with the client that you'll fix anything that goes >> wrong. If you were to have a falling out with the client over an >> invoice or something (it happens) then they effectively have a piece >> of software that only you (someone they no longer wish to do business with) >> can maintain. >> >> >> >> As a client I would consider that an unacceptable risk. >> >> >> >> On Thu, Jun 3, 2010 at 12:48 PM, Dylan Tusler >> <dylan.tus...@sunshinecoast.qld.gov.au> wrote: >> >>> That is potentially a pretty dangerous risk for a client to accept >>> isn't it? Unless it contains some kind of proprietary algorithm or >>> something I'm not sure it's a great idea. >> >> >> >> That's a pretty weird point of view. >> >> >> >> After all, "clients" have been accepting obfuscated code since time >> immemorial already! (Well, at least since the 1980s.) That's what >> compiled code is! Unless you wanted to reverse engineer to assembly >> language, pretty much everything was obfuscated. >> >> >> >> Dylan. >> >> >> >> >> >> ---------------------------------------------------------------------- >> --------------------------- >> >> To find out more about the Sunshine Coast Council, visit your local >> council office at Caloundra, Maroochydore, Nambour or Tewantin. Or, if >> you prefer, visit us on line at www.sunshinecoast.qld.gov.au >> >> This email, together with any attachments, is intended for the named >> recipient(s) only. Any form of review, disclosure, modification, >> distribution and or publication of this email message is prohibited >> without the express permission of the author. Please notify the sender >> immediately if you have received this email by mistake and delete it from >> your system. >> Unless otherwise stated, this email represents only the views of the >> sender and not the views of the Sunshine Coast Regional Council. >> maile 3_1_0 >> >> >> -- >> Michael M. Minutillo >> Indiscriminate Information Sponge >> Blog: http://wolfbyte-net.blogspot.com > > ************************************************************************************************************************ > This email (including all attachments) is confidential, may contain personal > or legally privileged information and is intended solely for the named > addressee. Confidentiality or privilege is not waived or lost because this > email has been sent to you by mistake. If you have received it in error, > please let us know by reply email, delete it from your system and destroy any > copies. > This email is also subject to copyright. No part of it should be reproduced, > adapted or communicated without the written consent of the copyright owner. > Any personal information in this email must be handled in accordance with the > Privacy Act 1988 (Cth). > Emails may be interfered with, may contain computer viruses or other defects > and may not be successfully replicated on other systems. Pillar > Administration makes no representations and gives no warranties in relation > to these matters and does not accept liability for any loss or damage which > may result from this email. > If you have any doubts about the authenticity of an email purportedly sent by > Pillar Administration, please contact us immediately. > ************************************************************************************************************************ >
