Skip to navigation
Real World Computing
Binary

Paying for code doesn’t mean owning it

Posted on 5 Mar 2010 at 17:45

Kevin Partner tackles the thorny issues that surround code ownership

If there’s one problem (after lack of cash, of course) that blighted the first ten years of my company NlightN's existence it’s code ownership, which has become more problematic as most of our work is aimed at web deployment.

Ten years ago, we were creating e-learning courses that we’d deliver on a CD-ROM containing a compiled version of the software, which was usually based on Flash or Mediator. Our clients understood that if they wished to update the course, they’d do so through us. These days, however, many clients believe that by paying for the work to be done, they own it.

On the face of it this might seem reasonable: surely if you pay for something then you own it? Not if what you’re buying is an end product, rather than the work itself or the tools used to create it. If I buy a bible, I don’t own the original Lindisfarne Gospels; if I pay a plumber to fix my tap, I don’t ask him to leave his toolbox so I can fix it myself next time; if I buy Harry Potter and the Half Blood Prince on Blu-ray, I don’t own the movie but only a copy (whose usage is restricted by the terms of the licence); if I buy Microsoft Word, I own one copy of the compiled code, not the source.

Put simply, code is owned by its developer even once the client has paid, unless that developer is legally employed by the client or a contract exists that transfers full ownership (even then it’s far from clear-cut). The client has paid only for the results of the labour: for example, if a client commissions us to build an online quiz app, they pay for and own the working application, but have no rights over the code itself.

One problem is that if you’re working in an interpreted language such as PHP then your code isn’t compiled, so in practice your client does receive source code and can do what they like to it, even though they have no legal right to

One problem is that if you’re working in an interpreted language such as PHP then your code isn’t compiled, so in practice your client does receive source code and can do what they like to it, even though they have no legal right to.

It might seem that ownership remaining with the developer is unfair to the client, but then consider the alternative. Most developers will have created a library of custom code segments they use for every project: for web applications, such a library might include functions to handle database connection and interaction in a way that makes sense to them and so speeds up subsequent projects.

If you give away ownership of this library code you’re giving away your “tools of the trade”, just as much as that plumber would be by leaving his toolbox behind. Your libraries give you an advantage over other developers in terms of the speed with which you can complete work and, therefore, the price you can charge.

This is a commercial advantage you must protect if you’re to build up a viable business. A second problem with giving away ownership of that code is the way it would affect previous projects for other clients that use the same code – you could argue that client two would end up owning part of the code originally put in place for client one.

So that’s the legal position, the code belongs to you unless contracted otherwise, and it’s very important you bear this in mind when negotiating with clients. I’m not saying never hand over ownership to a client, I’m saying remember that ownership of the code has a value and you should expect the client to pay for that.

1 2
Subscribe to PC Pro magazine. We'll give you 3 issues for £1 plus a free gift - click here
User comments

Copyright

Here's a simple way to think about how copyright law works by default in most places:

If you create a work and sell a copy of that work, you retain the rights to the original. However, if someone pays you to create a custom work, then they retain the rights to the original.

In your case, your client would probably have a right to any code you created specifically for them, but not for the libraries you created on your own.

By CoryJ on 6 Mar 2010

Kevin, you got copyright law wrong...

You stated: "if I buy Harry Potter and the Half Blood Prince on Blu-ray, I don’t own the movie but only a copy (whose usage is restricted by the terms of the licence)".

That's not true for the product (the film). The first-sale doctrine allows the purchaser to transfer (i.e., sell or give away) a lawfully made copy of the copyrighted work without permission once it has been obtained. This means that the copyright holder's rights to control the change of ownership of a particular copy end once that copy is sold.

That usage cannot be restricted by any license. Autodesk discovered this recently when trying to prevent sales of used software...

By Woodnag on 6 Mar 2010

Not sure about this.

I think these analogies don't hold up very well.

Code is not the tool that we use, but the material. The tools are your IDE, your compiler, etc. The code is more akin to the bricks used in building a building, or the architectural plans. A person who has a building built definitely owns the bricks, and they also may own the plans for the building (that depends on their contract).

Not being contractually explicit about who owns the code will not help you in terms of client relationships. Your clients need to be clear about exactly what they are paying for, and exactly what the deliverables are. Simply waiting until the end of the contract to argue about who owns the code is not a good idea.

By quadelirus on 6 Mar 2010

Apparently the US court system doesn't quite agree with you: http://arstechnica.com/tech-policy/news/2008/05/co
urt-smacks-autodesk-affirms-right-to-sell-used-sof
tware.ars

By 10bay on 6 Mar 2010

You have it totally wrong

Open source your code. Solves your problems immediately. If you think your code gives you an advantage then you are a decade or two behind.

By chx1975 on 6 Mar 2010

"I’ve found, over the years, that insisting on a contract before development starts will result either in a delayed start or even a project being shelved."

So let me get this straight, it is your policy not to be up front with clients about what they're getting from you because you know that it might kill the deal? At the very least that's a shifty business practice and not something I'd go about admitting to in a public forum.

As an aside,
To those commenters who think the AutoCad case has any bearing on Kevin's article, you're just plain wrong. The AutoCad case dealt with "off the shelf" software products and its holding does not apply to custom built code.

By oldsak on 6 Mar 2010

AutoCad

oldsak - you're right, the article is about custom software contracts, not shrinkwrap retail. My criticism was regarding Kevin's erronous statement that a software license was valid for a DVD purchase. It isn't. Further, copyright law trumps contract law, as Autocad found out by trying to use the license to remove the customer's resale rights.

Sure, Kevin used a bad illustration to make his point. But the distinction being copyright and IP is being deliberately blurred by so many people. Copying a retail DVD is a copyright violation, not IP theft.

By Woodnag on 6 Mar 2010

You wouldn't work for me!

Hmmm. You are entitled to believe anything you want about who "ought to" own the code, but the fact is, I run a business, and I absolutely would not hire you to work on my projects. The only way I would allow you to own the code after I paid you as the developer is if I was certain that this was a simple one-time project that I absolutely knew would never, ever need to be revised or updated at any future point. If you wanted to assert your right to the code before getting the job, you wouldn't get the job. Further, you wouldn't get the chance to 'forget to mention this to me' because I make sure of this issue before I sign a contract. It seems like you don't know how to think like your customers and understand the customer's point of view. What I do is simply too important to entrust to someone who can, at least theoretically, disappear with the code that I paid good money to build my business on-- leaving me to start over with someone else.

By panderso on 6 Mar 2010

Concur This is a Shady Practice

I concur with the posters who say this is a shady practice, especially your reluctance to specify what your client's rights are to the code. If you feel that it's obvious that the client has no rights to modify or change the software you wrote as part of this contact, make it clear in the contact. Generally, in all aspects of life, it is better to get a clear understanding before proceeding.

This reminds me of a contractor who put a fence in for me. We negotiated a price, which included "materials" and his labor, but afterwards he also presented me with a bill for "hardware." I told him that materials were included, but that hardware was not considered part of materials by anyone in the building trade. When I told him I wasn't paying, he threatened to put a lien on my house, so I folded and paid, since the cost was fairly negligible. He won that small battle, but I had lots of friends who needed work done, and specifically told them to avoid him.

By Perry64 on 6 Mar 2010

You're wrong on the facts here

I'm going from U.S. Copyright law, so there may be discrepancies, but I've had the impression, not much.

And in the U.S. there are (badly enforced) provisions of the rights of the "Owner of a Copy". Your article fundamentally ignores this entire concept.

Additionally, the rights of a business (in *any* field) to intellectual work produced while in it's employ are strongly covered in both U.S. and international law. A contract might be written to retain those right (and sometimes are) but long legal tradition makes the default for those rights go to the employer.

This is all subject to individual decisions and varying legal histories obviously, but anyone that took your article at face value would end up in legal danger with very little chance of coming out on top.

It is actively dangerous to your readership.

Jonnan

By Jonnan001 on 6 Mar 2010

Lots of people wrong here.

The problem isn't so much that everything is wrong (although some is), it is mostly confusion about which law applies where.

For example, "oldsak": You are right about a DVD license not applying to contracted software. However you are 100% wrong when you say "Copyright law trumps contract law." Actually it is exactly the opposite. Otherwise you could not sell your copyrights to someone else! That was not the issue in the Autocad case. Rather, the decision reinforced the idea that a "shrink-wrap" license is NOT in fact (could not be) a contract, and so cannot override the "first sale" doctrine of copyright law.

It is quite possible to enter into a contract BEFORE the sale that overrides first sale and other aspects of copyright law, but it takes the prior agreement of both parties to do that.

And Jonan001 is also wrong. In particular, the rights of "owner of a copy" apply to off-the-shelf products (software, books, etc.), not to contracts for creating custom software. Legally, those are completely different matters. Second, the article is referring to contract work, not "work produced while in its employ". A contractor is not an employee and is not "employed" by the client in any legal sense. Again, those are two entirely different matters.

So from a legal standpoint, Partner is quite right. He just didn't explain how contract work differs legally from employment, and how custom software differs legally from a mass-produced, off-the-shelf item.

By Jane_Q_Public on 7 Mar 2010

UK, not US

Many comments here seem to be forgetting that this is a UK site and Kevin Partner is likely thinking under UK laws. I am not sure if there is any difference there, but all posts I have read so far contradicting him refer to US law and cases, not UK ones.

I am not in a position to dispute the points of the article either, just to state the same most have stated: in the US, this article does not apply.

By Tharsman on 7 Mar 2010

Lots of people wrong here.

The problem isn't so much that everything is wrong (although some is), it is mostly confusion about which law applies where.

For example, "oldsak": You are right about a DVD license not applying to contracted software. However you are 100% wrong when you say "Copyright law trumps contract law." Actually it is exactly the opposite. Otherwise you could not sell your copyrights to someone else! That was not the issue in the Autocad case. Rather, the decision reinforced the idea that a "shrink-wrap" license is NOT in fact (could not be) a contract, and so cannot override the "first sale" doctrine of copyright law.

It is quite possible to enter into a contract BEFORE the sale that overrides first sale and other aspects of copyright law, but it takes the prior agreement of both parties to do that.

And Jonan001 is also wrong. In particular, the rights of "owner of a copy" apply to off-the-shelf products (software, books, etc.), not to contracts for creating custom software. Legally, those are completely different matters. Second, the article is referring to contract work, not "work produced while in its employ". A contractor is not an employee and is not "employed" by the client in any legal sense. Again, those are two entirely different matters.

So from a legal standpoint, Partner is quite right. He just didn't explain how contract work differs legally from employment, and how custom software differs legally from a mass-produced, off-the-shelf item.

By Jane_Q_Public on 7 Mar 2010

UK, not US -- absolutely

I think most of the comments are from a U.S. standpoint. The AutoCad decision, for example.

Nevertheless, the particular points that Partner makes are true in the U.S., as well.

By Jane_Q_Public on 7 Mar 2010

I Think Some Commenters Are Not Thinking About Professional Developers

It would not be unreasonable for a professional developer to have his/her own compiler. Many of the people I know tweak gcc for their own use.

Also, my scripts which allow faster code development are not part of the final product, but are needed to easily modify the final product.

It is true that some people have open-sourced their tools (Google Neil Gunther for an example), but unless you are in an area which requires a deep understanding in order to do the work, giving away the tools essentially gives away your secret sauce.

-Todd

By Todd__ on 7 Mar 2010

Concur This is a Shady Practice

I concur with the posters who say this is a shady practice, especially your reluctance to specify what your client's rights are to the code. If you feel that it's obvious that the client has no rights to modify or change the software you wrote as part of this contact, make it clear in the contact. Generally, in all aspects of life, it is better to get a clear understanding before proceeding.

This reminds me of a contractor who put a fence in for me. We negotiated a price, which included "materials" and his labor, but afterwards he also presented me with a bill for "hardware." I told him that materials were included, but that hardware was not considered part of materials by anyone in the building trade. When I told him I wasn't paying, he threatened to put a lien on my house, so I folded and paid, since the cost was fairly negligible. He won that small battle, but I had lots of friends who needed work done, and specifically told them to avoid him.

By Perry64 on 8 Mar 2010

Personally...

....I would have no problem with Partner's approach of releasing the code he specifically created for me to me and retaining the more generic libraries that he uses for other jobs so long as he had no problem lodging those with a code escrow service, so that in the event of his carking it, his company going under, whatever, we could apply to have those released to enable maintenance of the application.

By nichomach0 on 8 Mar 2010

End Users License Agreement

If you are an employee of a company and make a discovery it belongs to them.
If you are contracted to a company the contract should detail services you are to provide (inventions rights etc) and will become property to that company.
Someone who is self employed is not working for another company and can be independent (as in "Freelance Developer").

End User License Agreements can become very lengthy in their terms and conditions trying to cover all eventualities.

EULA's state if backups or copies can be made and if they can be distributed.

You sell the user a license to USE your code but not to re-engineer it.

It may be prudent to think clearly about the EULA at the start of a contract.

Have all software that you OWN copyrighted by solicitor.

This is important for you own interest as it prevents a company laying claim to the invention while you were working for them.

By lenmontieth on 9 Mar 2010

Not a shady practice

This is how developing code has always worked. The customer gets the rights to use the finished product, but they rarely own the code - it just isn't cost effective for them.

There are frameworks out there that are open source and make a good starting point.

The code specific to a customer, that isn't a real issue, if they want that / the rights to change it, then they can buy that fairly cheaply.

The problem is the generic libraries / classes that are used on several projects.

If I sell you a site cheaply, using my standard libraries and then I develop another site for a competitor and they pay me extra to own the rights to my libraries, they can then shut down your website, because it includes "their" libraries...

The alternative is to always charge several times more for a site and re-write all of those library routines from scratch each time. A complete waste of time, effort and money - and you will probably end up re-using some algorithms and code fragments, because that is the way your mind works and that is the easiest/only way to implement the task.

In general, the customer gets a reasonably priced solution, but they don't get the rights to own / re-use the custom libraries.

The Autodesk case is more like Kevin selling an e-Learning CD to a client and the client then selling it on to a third party after they have finished with it, annoying for Kevin, in that he lost a sale, but understandable and legal from the point of view of the customer and the third party.

This problem only really crops up in web sites and systems which use uncompiled scripts. When the product is compiled, the customer gets exactly what they wanted. With the website, they get what they wanted, plus they can see the source code behind it.

Obfuscation is a generally accepted principle and is often used in JavaScript classes which can be re-used, but you don't get a right to modify. As is removing all comments and reducing variable names to single letters and not using line breaks etc. The code doesn't need to be human readable, it just needs to run without errors on the server. It also makes the code more efficient and faster to download / interpret, because all of the whitespace and comments don't have to be loaded and skipped over.

Getting everything signed up bound under legal contract before the project begins is the way to do it - in an ideal world.

But in the real world, clients want a fully working system, which will take 20 man years to complete, they want it for next to nothing, oh and they want it delivered next week!

You can't do much to reduce the price beyond the minimum, without going out of business. You can save delivery time by starting work straight away, with a verbal agreement (and a pre-payment for some of the work) and work out the thornier parts of a contract as work progresses.

The problem is when you come across a customer that doesn't understand how software / web development works... That is where the fun begins and this is where Kevin's advice comes in.

I've worked for small customers and I've worked for large customers. The large customers usually aren't a problem, they will either buy "everything" by having you develop on-site on their machines and they provide the tools and libraries and any code you produce there stays there - and it is clear up front and you don't use your own private libraries, you generate all new code and the customer accepts that the project will take 20-40% longer and cost 20-40% more than if you worked on your own site and used your pre-existing libraries. Sometimes you can agree to give them non-exclusive rights to your libraries - they can use them internally, they can't modify them, they can't redistribute them and they can't resell them.

Small customers don't understand the intricacies as well, they know that if they buy Office off the shelf, they have a CD and they can do pretty much what they want with it, they are often surprised when they don't get the code behind the project (or the rights to modify/redistribute the code of a website), without having to pay appropriately for it. The biggest problem being that they usually can't really afford what they've paid for, so they feel hard done by, when they ask for exclusive rights and are told that that will cost them proper money...

By big_D on 9 Mar 2010

@nichomach01

Yep, the right to use the code if the supplier goes under is a good thing to include in the contract.

By big_D on 9 Mar 2010

As a slight aside, I have no problem at all with any contract or licence conditions providing that I am made aware of them before I make the purchase. However with much computer software and dvd etc I can only find out what the T&C are after getting the product home, unwrapping it and putting the disk in my computer. As at that point I have already made the purchase, and just about every retailer of such products will not accept a return of a shrink wrapped product that have been opened, I feel under no obligation to be bound by any T&C revealed to me after purchase. A contract is effected at the time of sale, you can't reasonably enforce additional T&C at some later date.

By stokegabriel on 10 Mar 2010

Who owns the code

I'm glad my article has sparked such a debate - if nothing else it emphasises how complex and misunderstood this area is.

A few points:
1) I didn't say that I didn't WANT a contract ahead of each project, what I said was that in most cases the process delayed things or caused projects to be shelved. This is most often because the client doesn't, at that point, know precisely enough what they want for it to be encapsulated in a legal document. I prefer and encourage my clients to agree to a plain-English "letter of understanding" where we can agree what needs to be agreed before starting work. You see, clients like to have the leeway to discuss altering the specification as the project goes on - this is what happens in the real world with complex application development.

2) Even though I have, by default, the legal right to own the uncompiled version of any application I am usually happy to share/give away legal ownership of code that has been created specifically for a particular project so that the client is not locked-into my company for ongoing development. What I am NOT going to share (for free, at least) is the right to the source code of my generic libraries. The client has benefited from a much shortened development cycle (and therefore cost) so to also want to own that code (and therefore make it difficult or impossible for me to reuse it on another project) is not reasonable. If the client wants ownership of the entire codebase, therefore, it would need to be agreed upfront that my generic libraries are not to be used and therefore the timescale/cost will be greater.

3) I operate from a point of view of being fair to all parties in all my dealings and operating with complete integrity. I have absolutely zero interest in locking clients into my company whether that's for development or hosting - in the vast majority of cases clients choose to stick with us but there is no legal or practical lock in. Where a client wants to move to another provider we will, and do, help constructively. If they want to take our generic toolkit with them, then we need an agreement and this is the problem with the particular case in point.

At the end of the day, it's all about fairness. In practice, for most projects there is no issue if every party is open, honest and acts with integrity throughout. Where this isn't the case, it's my job to protect its intellectual property: this is, after all, the main asset of the company. The vast majority of my company's projects are completed with no problems at all - however the few that give rise to issues do occupy a disproportionate amount of time and can be extremely stressful all round

By KevPartner on 10 Mar 2010

Client also needs to be aware of rights.

The other side of this is that as a software customer, you need to protect your rights to continue to use code on which your business depends. If you do not, you may become a victim of a kind of reverse-piracy by software vendors.

Many webdesign firms want to register YOUR domain in THEIR name, and host in on their server. This is a very bad situation to get into, as you may find it extremely hard to get out of the deal even if you are given bad service. Above all, insist that you are the registered owner of the domain.

I recall some years ago, when adding two users to a LAN cost £2500 as a result of sharp practices by a software vendor.

This arose because the fileserver software was copy-protected and usercount-protected, and the vendor refused to sell two additional licences for the version they were using, instead insisting they bought a completely new version. Which they didn't need or want, they just wanted two more users... The licensing cost was £2000, and the additional IT work to perform the totally-unneeded upgrade throughout the whole site cost £500. A cool £1250 per seat ripoff, all for the want of two floppies with a tiny file on each. It makes Microsoft look saintly by comparison.

The latter is a very good argument for insisting on open-source, and freedom from product-activation or DRM schemes.

By Anteaus on 11 Mar 2010

Domain names

Anteaus: I agree wholeheartedly re domains. These are a business asset and should be owned and controlled by the business.

In my case, I use Daily to register mine. If the customer wants me to register on their behalf, I get the client to also sign up with Daily and once it's all set up with appropriate nameserver settings etc, it's a very simple and instant transfer process.

The world is full of sharp practice, I fully acknowledge but this does cut both ways. My company has never reneged on an agreement (written, legal or otherwise) but we have been shafted by clients several times: especially in recent years.

I agree about open-source. I am beginning to think that this might take the sting out of most of the arguments. However, I seriously doubt that my clients would agree!

By KevPartner on 11 Mar 2010

The PHP programmer's toolbox

I reject the idea that there is significant value to third parties in a programmer's toolbox, or library code, or whatever you want to call it. Such code is usually badly documented, and without some kind of overview document or deep understanding of the code any prospective thief would be out of their tiny little minds to use such custom tools. Unless the functions themselves were tiny, in which case, easily reimplemented.

I do always make the point when it comes up, that any custom code for the customer's specific purposes can be theirs, but I must always keep access to a bunch of stuff I re-use.

If someone else came across this bunch of stuff I'm sure the usual "not invented here" syndrome would kick in and it would be duly lambasted as lacking feature X, or not implementing feature Y in a certain way, whilst there might be the occasional begrudging approval that it does have feature Z.

By RichardFletcher on 15 Mar 2010

Leave a comment

You need to Login or Register to comment.

(optional)

Kevin Partner

Kevin Partner

Kevin is a contributing editor to PC Pro. He's managing director of NlightN Multimedia, a Milton Keynes-based company specialising in web application development and internet marketing.

Read more More by Kevin Partner

advertisement

Most Commented Real World Articles
Latest Real World Computing
Latest Blog Posts Subscribe to our RSS Feeds
Latest News Stories Subscribe to our RSS Feeds
Latest ReviewsSubscribe to our RSS Feeds

advertisement

Sponsored Links
 
SEARCH
Loading
WEB ID
SIGN UP

Your email:

Your password:

remember me

advertisement


Hitwise Top 10 Website 2010
 
 

PCPro-Computing in the Real World Printed from www.pcpro.co.uk

Register to receive our regular email newsletter at http://www.pcpro.co.uk/registration.

The newsletter contains links to our latest PC news, product reviews, features and how-to guides, plus special offers and competitions.