Did anyone sell source code here?

[dc_2000]

Hi folks:


I need advice of people who tried this before. I've been contacted by a company here in U.S. requesting to write a small custom program. As a stipulation they required that I supply the source code for the project upon completion. There's really nothing proprietary in that source code project but I'm leery about simply giving it to them.

Does anyone have any idea what shall the charge be for the source code files of this custom made program?

PS. I charged them $45/hr. for 12 hours of work for the program itself.

[JVene]

To your title question, yes.

I can only speak to my professional experience as a developer relative to U.S. law.

If you work as an employee of a company (there is an employment agreement/contract in force), then all that you write is already in the copyright ownership of the employer.

If you are a contractor, you are not considered an employee by the governing law - you're an author. The contract you sign with the customer is the controlling document. If ownership of the copyright of what you author is not stated in the contract, copyright ownership "automatically" rests with the author, not the customer - but then the contract "ought" to indicate the rights to license the customer is purchasing.

If the contract is a "work for hire" contract, the specification is that you are being hired to create a copyright-able work for the customer, and ownership will be with the customer, not the author. It would be specifically stated in the contract.

There should always be a clear agreement - but, the law is full of more detailed pre-requisites and stipulations than writing an assembler application for Windows. Hiring an attorney is an unfortunate and evil necessity, at least to get a solid "boilerplate" contract format that suits your interests, and that you understand.

You can, and I have (when I was young - years ago) written agreements myself. If nothing goes wrong, you don't even need a contract (that's kind of an old saying). It's if something goes wrong and there's a disagreement that you need a contract, at which point if you weren't knowledgeable about the law, the issue can blow up worse than an uncaught exception.

...but then, people can and do sue for just about any reason, especially in the U.S., and civil court is a bit of a crap shoot.

Anyway, yes, selling source code is definitely a common practice. The viewpoint can be a bit like the photographer and the negatives. He keeps ownership if you don't contract otherwise, and if you can't get an agreement on the point of ownership, you don't use that photographer.

Of course, we don't have negatives anymore, do we? So it's ownership of the bits now.

The customer has an interest in keeping ownership of the code for the same reason you might want ownership of the negatives from a photographer taking you're portrait. If you don't own the negatives, he charges for every copy you want. (In the software agreement, it's for every change to be made to the work).

[GCDEF]

The time to work that out is before you do the work. Was a contract in place? Was it discussed before you started? What are you leery about?

If it were me, for such a small project, I'd likely just give it to them.

[ovidiucucu]

[ Moved thread ]

[JVene]

GCDEF's right. Live and learn.

If what you're about to make for a customer seems like a product you might want to sell in the future, it's in your interest to keep ownership for that purpose, in which case you're not actually working for hire - you're creating a product "using" that customer's needs as a definition for the product - and you're going to sell them a license for that product, just like Microsoft selling Word.

On the other hand, if the customer's view is that of their ownership, and you're not likely interested in crafting it as a product for sell to others, it's may be better to let them own the resulting code. They'll feel more comfortable about their future with that code (they're not utterly dependent upon you for maintenance). If the reason to want to maintain ownership is to "hook" the customer, they have reason to want to avoid that, and could "walk" to another engineer anyway. They may reason that keeping you is more expensive in the long run that dropping everything and finding someone else. Hooking the customer on your professionalism and skill is a better business relationship.

I've had several situations, too, where a custom application, owned by the customer, turned into a product. Because of my rather entrenched and very positive relationship, I was invited into the resulting company which sold the product (who else would they have found better for that purpose, since they already knew me, our relationship was positive, I knew the product, etc).

[dc_2000]

Thank you for your input guys.

No, JVene, I do not work for that company. This request came through my web site and it's rather simple service module and, no, there's no contract either. For the amount I'm going to get paid from them, i.e. $45 * 12, I reckoned, it is not worth paying a laywer for a solid contract. But, of course, I see your point and one of us can get easily sued for pretty much anything in this country.

I was wondering though about financial part of the bargain - shall I charge them more for the sale of the source code?

[JVene]

It's more of a poker game than a theory of proper behavior.

The simple answer, you should probably not increase your rate over the issue of the code's ownership, but it's with a qualification I'll clarify.

The issue isn't so much of propriety as it is of long term gain. It's likely you'll never hear from them again, but is it possible you'll gain a longer term relationship? It's a fine line; if they demonstrate they want a bargain, they'll always want a bargain. You can't expect a low price leader to result in higher priced long term work - it might even seem like a good idea, but it seldom works out that way unless it's obvious you could mark something as "on sale - one time only"...

So, if $45 an hour is a fair rate to you, sure - leave it at that.

If you think there's value in the results, such that owning it would be of use to you elsewhere, you have an interest to reconsider and charge for the perceived loss of value for giving it up.

For example, I was hired to help on an iPhone application. I have a few ideas on that point myself, and one technical point that's a considerable advantage - a concept no-one else has instituted, in fact the common example code from Apple which everyone follows demonstrates a serious flaw which my own method entirely corrects. Apple would even benefit from having this little technical gem.

I certainly wouldn't want to just give it to a customer, purchasing my coding service, when I myself would make a considerable advantage for releasing my own applications which demonstrably compete (and win) with the advantage.

I'd charge heavily for it, or refuse to give it at all. The actual implementation of this thing is short - it would fit on a page. Its just a bit of math and theory, the results simply elude everyone else so far. What can I say, I'm a genius (sorry, I AM joking about that, but I do have this code I speak of).

On the other hand, it is just a trifle. Anyone paying big bucks for this would be seriously disappointed. Within 5 minutes, they'd slap their forehead and say, "Well that's frickin' obvious" - and it is, yet it HAS escaped everyone who makes apps for the iPhone, and my applications are rather OBVIOUSLY better at this one thing because of it (don't ask, I'm not giving away such things here either ).

Anyway, it's valuable to me, and it's valuable to keep secret. If you paid $30 for it, after understanding it, you'd think that would be fair price - it obviously takes about half an hour to cook up the example. Factually, for as long as I can keep it secret, it's worth at least a few hundred thousand to me. Not because I simply say so, but because the applications I make with this 'exclusive' feature will sell that many more copies because of it.

I'm trying to illustrate the perception of value. Any technician looking at this would seize upon the obvious nature of the technique, deem the value to be no more than the 30 minutes it would take to understand it rather completely, and therefore disagree with it's value. It's like the magician NOT telling how the trick is performed. If you knew, there'd be no magic.

If what you're selling isn't any more valuable to you than any other item of code you'd write, then letting go of the source isn't going to be any loss. If you pull the "photographer's" position, you can get value for owning the negatives, but how many copies of a set of wedding photos will you actually sell? It would have to be the untoward photos of a celebrity to be of considerable value - or the photo some famous person DOES NOT want to be in the public view. To whom, and for how much, you sell such a property depends really on where the most income is to be made.

Since the customer expresses concern over ownership, and you haven't stated any particular concern other than "wondering if" - there's no reason to hold ownership of this code, and the only result from raising prices because of this point is possibly to loose the account to a competitor not so inclined. Consider it a work for hire, code in the customer's ownership.

If they come to you with a request for something of value, and you can pull this off, you know that it's something you'd rather own. If they can't make it and you can, and they intend to resell it, you have reason to want to keep ownership, it's worth charging more for it.

In such a situation where it's obvious, the customer would likely have made you sign a non-disclosure and perhaps even a non-competition contract before even telling you what they want. You walk in knowing this is going to be heavy, they've come to you because of your expertise, and they want to walk away with a hot, money making property. This is poker at it's finest! It takes some cojones to pull this off with experienced negotiators and large businesses without getting burned.

So, if they're not coming at with you "secrets" you have to sign non-disclosure for before even talking, then it's likely one of two things; it's generic, non-valuable work you can let go of, or they have no idea what they're doing, and if it IS a hot idea, you're in the driver's seat so STEP ON THE GAS (make the thing for free, give them a license, but keep ownership and sell, sell, sell).


Another informative anecdote on this subject is the story of IBM/MSDOS/Gates. Gates didn't make MSDOS, he bought it. The guy who made it (I don't recall his name) sold it to Gates for under $100,000. The author didn't know IBM was looking for an OS, and didn't have any contact at IBM. Gates did, and needed the product to sell to IBM, without the time required to make it. At the time, IBM was considering CP/M, and product already in use on 8bit and some 16bit computers. MSDOS was not known beyond this author's small circle of contacts (how Gates and he met I've never heard). If the original author had any notion of Gates true plans, he wouldn't have sold the whole thing, rights and all. He would have held Gates over the deal, desperate to close with IBM, and license it to Gates. Even at $1 a copy, it would have meant hundreds of millions. He got under $100,000 for his work. This was all because Gates was careful about letting the secret loose, and the author wasn't as cool a hand at business, wasn't sure of the value of the product, was willing to part with the source for that fee, and didn't have a clue as to the true purpose or value of the product. Not even IBM was aware of the value of the operating system; they thought the real money was in the hardware.

Gates ended up with ownership of the first billion dollar software property in history. IBM lost potential revenue because they didn't insist on ownership, they simply licensed the software. The original author lost millions simply by allow Gates to control the deal, and not investigating what his hard work was going to be used for.

It's informative to study the history of Xerox PARC (the Alto computer system), and how that influenced the Apple Mac and Windows. Just how that became Microsoft's second hottest software property in history is definitely a demonstration of Gates understanding of market forces, of industry and of product placement.

It has an impact on understanding just what we're doing when we contract for a small job on a simple idea. Most are not of much value. Gary Kildall is probably an unknown name to you now; at one point he was positioned exactly where Gates ended up - we may have all had CP/M based IBM PC's instead of MSDOS based PC's, and Kildall might have been the most successful man in software.

[dc_2000]

JVene, thanks again. I read about the whole MSDOS and Bill Gates story somewhere as well, and also how they used to and still are simply buying companies and products of competitors (which, by the way might also be a demise for Microsoft), but that is another subject in itself...

Hey, listen, this source code has nothing that cannot be found on MSDN site and in their samples, thus I cannot even come close to your one-page "super code", which, I wish you luck selling, by the way. I know what you mean, when the best solution could be the simplest one.

So, if $45 an hour is a fair rate to you, sure - leave it at that.

OK, now. What do you mean -- is it too low? High? Am I underselling it?

[JVene]

Let's see, national average of a competent developer in C++ is found in the vicinity of $85,000 a year, depending on experience, so $45 isn't far off that - it sounds about right.

[dc_2000]

Hey, JVene, I little bit off subject, what do you use to program those iPhone apps? Any way to use C/C++ for that and anything comparable with MS Visual Studio?

[JVene]

Funny you should discuss that in context with visual studio.

There's a little good news, some better news, some not so great news.

The XCode IDE from Apple is a free download, and it includes the GCC compiler around version 4.0 or so.

The iPhone requires the use of Objective-C for the GUI interface work, because it's based on a subset of Cocoa, which is written in Objective-C.

However, that can be Objective-C++. So, indeed, you can write in C++ for a great deal of the application development work, and it's possible to use or develop a framework which encapsulates the UI as C++ classes - in which case the underlying functions of those classes access Objective-C function calls into/out of the Apple GUI code.

For all of the GUI style apps for the iPhone, coding and work must be done in XCode using the Cocoa subset for the phone.

On the other hand, if you're making OpenGL ES applications, the news is brighter. OpenGL ES 1.x is on the phone, and it's not all that bad a 3D graphics feature set, supporting 2D and a range of features. The graphics chip vendor (Imagination Technologies, their PowerVR chip) offers an OpenGL ES emulation library for 1.x and 2.0 (the iPhone to date is the 1.x, not yet 2.0).

That can be loaded into Windows. If you arrange your code such that the OS to Application interface is highly abstracted, you can develop an application in Windows using Visual studio, provided you have an application shell for the iPhone. In this way, you create a shell to "fit the Game Into" - so the application code really doesn't "know" the difference between a "windows" host of the OpenGL ES application, or the iPhone host of the application. There are minor differences between the compliance of C++ in GCC and Visual Studio, but it's manageable. The emulation of OpenGL ES is rather good, even to the emulation of the specific bitmap formats the iPhone graphics chips depends upon.

You can't compile from Windows and expect the output to be installed on an iPhone. You can only develop and debug with the caveat that you have to "simulate" input, especially from the accelerometer, and fashion your display into a 480 x 320 window (or, oriented the other way as required). Important to note that on the iPhone, you must be able to rotate the image to fit the orientation of the user, but you can't easily rotate a desktop monitor to emulate that - so there's a minor math puzzle on how that works, but you can handle that within a special 'camera model' or some such isolated means.

You can get off track doing this, because the iPhone has a 412 Mhz processor, the iTouch is 532 (I think), and there's rumors of the next iPhone at 800 - perhaps 1Ghz. The graphics chip is something a $30 card can exceed (but then it's not on batteries), so you could easily write something the phone could never run at reasonable speeds, but if you can test carefully, you'll get close. I have a Quadra FX4400 that gets typically 400 frames per second on imagery the iPhone can't quite manage 30 fps. On the other hand, a built in nVidia 6150 or 7200 (el cheapo, ok cards, not for games) are similar, perhaps twice or more faster than the phone as opposed to 10x or worse. The phone also limits output to 60 fps, and factually, if you can limit that with a timer to 30, you're saving the consumer some battery power.

You must, however, have an Apple (or..*cough*..the equivalent) with XCode and the iPhone SDK in order to compile and install to the iPhone. Check Apple's site for the details on the program (and I'd suggest incorporating before you pay the fee so you're actually set for business).

You can, however, download, try, and actually test iPhone apps in the XCode emulator without a license or a phone.

You simply can't tell if it would really work on a phone, and there's no accelerometer emulation.

[STLDude]

Let's see, national average of a competent developer in C++ is found in the vicinity of $85,000 a year, depending on experience, so $45 isn't far off that - it sounds about right.

That does not apply if you contracting. Good rule of thumb is to take that number (some average salary) and at least double it.

To OP, why are you apprehensive of giving source code to them?

[dc_2000]

JVene, thanks for the lowdown on Apple stuff. I guess you can't just make your own app and load it on your iPhone without being "incorporated", hah?

why are you apprehensive of giving source code to them?

Potential loss of future jobs from that company, or them reusing the code, or worse, selling it as well. You can do a host of different things with a source code project. In my book I always treated source code file as some sort of intellectual property, that is why my hesitation. All my previous contracts (freelancing) did not include sales of the source files. I'd normally offer a 6 month warranty on the software that would be enough for a company to fully test it and see if it suits their needs. Software is not like hardware, it doesn't break with time.

[thomus07]

JVene, thanks for the lowdown on Apple stuff. I guess you can't just make your own app and load it on your iPhone without being "incorporated", hah?

Potential loss of future jobs from that company, or them reusing the code, or worse, selling it as well. You can do a host of different things with a source code project. In my book I always treated source code file as some sort of intellectual property, that is why my hesitation. All my previous contracts (freelancing) did not include sales of the source files. I'd normally offer a 6 month warranty on the software that would be enough for a company to fully test it and see if it suits their needs. Software is not like hardware, it doesn't break with time.

For freelancing work, it's a good idea to always get the source code in buyer's point of view.

In freelancer's point of view, unless they are selling their own specific product, they can come forward to give the source files. The freelancer may be an expert developer, but they are after all a freelancer. An one man show. If they have a registered company, then closed source is meaningful.

When I work for tele-commute, they usually get the source codes.