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