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

Reply via email to