Slashdot Mirror
Why Paying For Code Doesn't Mean You Own It
Barence writes "Why do people think they own code just because they've paid for it? PC Pro's Kevin Partner says many of his clients believe that by paying for the work to be done, they take ownership of it. But, 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 (and even then it's far from clear-cut). He discusses the thorny issue of making clients understand that distinction and gives advice on how developers can assert their rights."
If I buy a bible, I don’t own the original Lindisfarne Gospels
Yes, actually you do. At least where I live they are public domain. You might not own the particular translation or interpretation of said gospels but you do own the core concepts. All of us own them. They are a part of humanity whether it be good or bad. This is the most confusing analogy one could produce.
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;
No, but if you bought a book on plumbing you might just fix it yourself next time. The results may vary but it's different from compiled code in that the person has no option to 'decompile' the code and go through it. You're right but the analogy has flaws. The plumber isn't producing a copyrighted work for you, he's performing a service. No goods are exchanged between you and the plumber like a software release.
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.
This is it, it comes down to licensing and copyright. Why do you waste so much breath on this rant when it's a legal agreement between you and your customer that is based on commonly known and accepted copyright and licensing terms?
I will say that with the advent of the Agile Methodology in where I work, the customer is much more involved. We meet with them every two weeks. We constantly incorporate their ideas into their site or program through our own code. And at the end it's a mixture of ideas but we're still the ones that coded it. Between you and I, I'd love to give them the code. But that's the decision of the guy who runs my company, not mine. If you have switched from the previous models of "wait a long time and big bang release" to "constant customer input" then you may now be experiencing something natural--the customer feels they own the code. Because they were with you every step of the way from infantile code to adult production code. Just keep that in mind.
My work here is dung.
Write a good contract and the issue is moot, for both parties.
---- Booth was a patriot ----
If someone pays you to perform work, they own all rights to that work. When I was married, we had a difficult time finding a photographer that agreed, and simply didn't do business with those that wanted to be paid for their work, and wanted to keep all rights to said photos for use in promotions and fees for reprints. I consider that a form of double jeopardy where I'm being forced to pay for something twice.
Software is no different. If you're being paid to perform a specific work, it's no different than if the person/organization paying you did the work themselves. You can't have both.
There's a practical presumption in law that if you pay for something and it is delivered, you own it. You have to have it in writing if you don't want to work that way. That, for instance, is why we have those obnoxious (and legally tenouous) "shrink-wrap" licenses. Because "licensing" is not the same as "owning." If licensing were the normal case in common law, you wouldn't need a "licensing" agreement.
"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"
"You might ask why I didn’t make a contract with this client in the first place. It’s because 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, this developer doesn't disclose this to customers who aren't aware that they are screwed when the developer walks away? His tortured analogy of the plumber and his tools is only correct if the plumber is installing pipes, valves, etc. that are 100% proprietary to the plumber and can't be purchased anywhere else. The word slimy leaps to mind for his business ethics (and plumbing in general).
"Powers. I have them."
I've done a significant amount of contract work over the years, "flying solo" so to speak. I've only once had a contention about copyrights, and since then, I've never done work where I don't own what I write!
My explanation goes something like this:
I have years of experience and have developed a standard set of tools that I use to solve different types of problems. I intend to use these tools to cut costs for you, and it's that time savings that makes me worth the money that I'm charging - I'll do a good job in a short time. But I'm writing the software for YOU, not for somebody else, and if I develop a new idea working on your code, I intend to use that same tool elsewhere. So I'll keep the copyrights, leaving me free to do my job elsewhere, and grant you a license letting you use the software as you see fit. You can do what you want to do, I can do what I want to do, and we can both be happy! I will grant you unlimited use license, including access to the sources, and I will make it transferrable - if you sell the business, it's no problem. The only right I won't grant is the right the resell the software, because I don't want to compete with myself!
This has never been a problem - when explained this way, nobody objects and everybody sees what I'm after.
I have no problem with your religion until you decide it's reason to deprive others of the truth.