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."
yeah, I am used to paying for an item, and software happens to be an item (especially when it is delivered on a CD)
In soviet Russia, God creates you!
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.
I subcontract to a company and on Monday morning I'm going to walk right in (actually send an email) and tell them that all that code I have developed for them over the last several years is actually mine and that if they want the source code then they need to pay me a $$$ more money.
I'll try to remember to keep my head high when I am kicked out of my home and am sitting starving on the side of the road!
In theory, practice is the same as theory. In practice, it differs.
I am Slashdot. Are you Slashdot as well?
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.
It depends upon your local laws and your contract. In the U.S., the default laws tend to vary by state. The last time I checked with my attorney, he told me that here in NY, all work is considered to be work-for-hire unless specified in writing. This means that the source code is automatically the property of the client, unless I get a contract stating otherwise. Which I do sometimes, but not that often.
Things get stickier if you use other people's libraries or even open source software within your project.
I've found that it's easiest to avoid problems if you simply discuss it with your client beforehand, and be as transparent as possible in your methods and expectations.
Let's say I buy the software, the end product. It's bits. It's ones and zeros. Do I own them? Am I allowed to tamper with them? It isn't the source code, and I lay no claim to owning that. But do I have a right to be able to manipulate the bits as I see fit? Can I share the bits? These are the truly thorny questions, and they're the ones that are changing our society.
I've had clients who think that they own the code simply because they paid for a website that uses one of our libraries. They buy the right to use the code.
When you buy software in a store or online you don't own the source code. Open source software may provide its source along with the executables but that doesn't mean you own it either.
When doing custom work we offer the client the option of full ownership at full price or 'shared' ownership for a reduced fee. With 'shared' ownership they can modify it at will but aren't allowed to ever resell it. We can't sell it to anyone who would be considered a competitor. I've yet to have someone opt for the full price/full ownership option.
IANAL, but I have researched this subject for my own work-product. The ownership of work produced on contract depends highly on the terms of the contract but nominally is considered work for hire, and, therefore, belongs to the client. If the contract does not stipulate otherwise, then the client owns the work-product.
Now, if the work-product consists of delivered source code, then the client owns the source code. If the work-product consists of delivered compiled code, then the client owns the compiled code.
Again, IANAL, but my research into this question boils down to something just that simple. The important conclusion is: if you desire a specific disposition of your work-product (like you retain ownership, or retain the ability to sell the same work-product to someone else, or retain the ability to modify it, or release it as open-source, etc.), you should put that in your contracts.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
This is a weird and slippery slope. I don't think that anybody feels that because they buy software they own rights to the source code, to edit code and distribute it, etc. But they do own the rights to use or utilize the software as they see fit within the confines of common copyright laws.
The author uses the example that you can buy a book or movie, but you don't own the rights to that book or movie. And that's fine, I think we'll all agree to that. However, if I buy a replication of a piece of art, a book, etc., I'm allowed to vandalize/defile it in any nature I wish as long as its for personal use and it is not distributed.
I'm not sure that I like the slippery slope that a lot of developers are trying to tread these days. Notice my use of the words "use" and "utilize." These are two very different words in the English language. Use means, well, to use something. Utilize means to use something for a purpose in which it wasn't originally intended. I can go to the hardware store and buy thousands of different tools and items for home repairs and various other projects. Many times I'll buy patented items because they almost meet my uses. I modify and "utilize" them for the specific task at hand. And this is fine, as you don't see me on the street corner trying to sell modified black and decker pecker wreckers at a markup. I think think that 1) that would infringe patents, 2) that would infringe registered trademarks and patents, and 3) I'd probably go to jail for trying to sell "pecker wreckers."
In the end, I have a product that meets my requirements and the vendor makes money off of my purchase. Everyone is happy, right? I think that this is the hurdle that software developers have to get over. As long as people buy your software, that's all you should care about. Let them modify it to their hearts content as long as they're not selling it for profit. In fact, possibly learn a lesson and integrate some of these features in your next version to appeal to a larger market. I think this is mutually beneficial in the long run. EULA are trash and need to go away.
Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
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.
Not having a contract in place before you start does speed things up, but it's kind of like running a heavy industries company without insurance.
Why not have two general contracts drawn up in advance; one which points out that the client gets what is essentially first publishing rights, or whatever comes closest to emulating the copyright system, and another where you sell the code outright. Explain the difference up front and then pull out the pen. "Option A is cheap, but I can sell the same code to other clients and you can't change it, and Option B will cost you several orders of magnitude more, but it's all yours forever and you can do whatever you want with it. This is standard copyright practice. We can start work as soon as you sign!"
People like clear options and little check boxes, and this would avoid weeks of legal dickering. Yes, you may lose some work in the short term because people realize that you're not selling what they actually want for the price they can afford, but this way is more honest and your headaches will be fewer.
Just my opinion.
-FL
IAAL, but the issues here are complex so this is NOT advice for any particular person in any particular situation:
If what you are interested in is owning a copyright to source code there are two ways for a "customer" to get the copyright:
1. If the software is a work made for hire. "Work for hire" is a legal definition (see 17 U.S.C. 101), with two different paths. The first path is for the software to be written by an employee within the scope of employment of the organization claiming copyright. Employee specifically does NOT mean an independent contractor, and code written by a contractor is NOT a work for hire! The definition of an employee goes into all sorts of common-law factors a court will look at, but the shorthand is the tax status of an employee with the IRS.... merely calling a contractor an employee is not enough. Also, the work has to be made within the normal scope of employment, so no, the employer cannot claim copyright as a work for hire for something the employee did outside of work. In fact, even if the employee works for the organization as a regular employee, if writing code is not within the normal scope of employment it still might not be a work for hire (up to the courts to decide if things go south). While some works for hire can be done by an independent contractors along with a specific written agreement, software code generally does not fall into any of the specifically enumerated categories where these written agreements work (see 17 U.S.C. 101 for more details).
Interesting: Technically, code written for a big company like MS or IBM by the armies of independent contractors are NOT works made for hire. See point 2 for how the companies can still get rights.
2. Assignment of Copyright: This is much more common for any work not directly made by an employee. There is a written agreement assigning ownership of the copyright to the contracting organization. The usual rules of contract law cover what is and is not within the scope of the assignment. Assignments can be non-exclusive (we can do what we want with the code, but the developer is also free to do what he wants), or more commonly, exclusive (the assignee getting rights to the code has full control, the original developer loses his rights to that specific work). So is there any difference from a work made for hire? YES! In a work made for hire, the organization OWNS the copyright for the entire length of the copyright term. However, in an assignment, Copyright law specifically splits the copyright term into two parts. An assignment made when the work is created transfers rights to the assignee (usually the company) for about 1/2 the term (the time varies depending upon whether the author dies and some other factors, but it is usually a long time > 30 years). The copyright automatically reverts back to the original author, and the assignment agreement cannot override this rule. The law is written this way to give the authors a "second bite at the apple" in case a work they assign away for peanuts becomes very valuable later. The author can extend the copyright to the second half of its term by paying a nominal fee, and can then go out and the assignee loses all previously held rights.
The upshot for the software industry: Any assigned copyrights will eventually revert to the authors. Now, by the time the reversion occurs most software will be long out of date, but as we all know there is plenty of software out there that lingers for a LONG time, and non-employees DO get there rights to the underlying code back.
One other point: Binary code gets a separate copyright from the underyling source code. But binary code is a derivative work of the underyling source code, so even if the developer never compiles code he writes, the binary distribution using that code would violate the copyright of the original code if ther
AntiFA: An abbreviation for Anti First Amendment.
It's pretty simple. If you are an employee, your employer owns your code. If you are a contractor you own your code unless your contract or agreement states that the work is a "work for hire" (or uses equivalent language). Requisite Wikipedia reference.
Other posters have already said that legally it all depends on the license you work out with the customer, and they are correct.
Having said that, I find that the customer's expectations will depend on what the financing model for the product was. Typically when you get paid for software, it will have been developed under one of two models:
If you're using one of the above approaches but want your licensing to work differently, the key is to make this clear to the customer up-front (managing expectations isn't something techies typically enjoy spending time doing, but it's a very important part of having a successful business relationship with your customer) and make sure all your legal wording is done correctly as well. I've worked at companies before where product development was funded by customers, but the need the customer wanted addressed was sufficiently general that the company wanted to retain the copyright and IP to resell to others. In this case, the customer was granted cheap or free perpetual licenses to use the software that was developed, but the contract was written so that the company retained the copyright and the right to sell licenses to others as well.
Then Linux came along and somehow "closed source" became a synonym for "proprietary", and "open source" a synonym for "free" (gratis). Microsoft feeds into this by not releasing the source code to Windows. Windows would be an even stronger (proprietary) product, IMO, if the source code were available.
Lawrence Lessig tried to rectify this false dichotomy by founding the Creative Commons. But the public has little knowledge of the existence of the Creative Commons, let alone the particulars of any of the licenses it offers.
The Linux community shares some of the blame by touting libre, gratis, and "open source" in the same breath. This lawsuit is a consequence of that.
I deal with this frequently with sub-contractors (and firms) doing development.
It's actually very simple.
The understanding starts out as: This is a work-for-hire. All work product is property of the company.
Which eventually leads to a contract containing:
All source-code, build scripts, documentation, keys, any other materials required to use or reproduce the deliverable item are exclusive property and proprietary information of the company.
The contractor shall not release, reuse or redistribute any component of this work in any other business. This includes any custom libraries, headers or other application work-product.
This does not apply to off-the-shelf open-source tools and libraries, however such items shall be documented and approved in advance to avoid GPL contamination.
I don't see a problem here.
I expect to pay through the nose if i want exclusive rights and ownership to someone's special library, for exactly the reasons the article dictates.
Otherwise a non-exclusive source-code license that I may do with as I please is cheaper. A binary-only license might be cheaper still.
They devs have to make a living and if it wasn't cheaper/faster to use them in the first place I'd just write it myself.
Just try explaining these legal subtleties to someone who doesn't understand software.
First of all, client expects to be able to use and MODIFY code you've done for them, both physically and legally. Who owns the code - is the second question. They don't want to own your library - they just want THE LICENSE allowing them to see, modify and use that modified code. It is the same thing as open source, except that they don't get the right to redistribute your library.
Don't be a dick, just give them that license.
"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."
In California, at least, there's also some tricky sales tax issues to be aware of. If you hand that client a CD-ROM with the product, for them to keep, of your $100K worth of toil, you have made "a transfer of tangible personal property", and sales tax is due on the whole $100K. On the other hand, if you FTP it to their machine, it's just non-taxable services. Or, if they provide you with a blank CD-ROM and you burn your software onto it as a service.
This is why architects retain ownership of the drawings they produce, for instance.
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).
Just a point of clarification: You can't write a contract that transfers ownership of a copyright that doesn't (yet) exist. Well, you can but it's unenforceable in the US. You can write a contract to the effect that you *will* transfer ownership of the code you build, but you still own the code until you sign a subsequent document transferring it.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I've been coding for about 22 years. In that time, I've worked on proprietary code for customers and employers. customers usually understand that they are paying for the final product, not the inner workings to give them the final results. you can use the concept of building a house. they are paying for the house, not my workers, not my tools, not my materials. i do not leave a copy of my dev tools for the customers, nor will i leave them a copy of my proprietary code libraries which i employ regularly to make my coding job easier. if i write a a library which creates a unique object type and use this object in many of my projects, clients are not entitled to this code. although it helps make their final product work, the concept is the same. they are not paying for the code, just the finished product.
if a chef is hired to cook someone a special dish, they are paying for the finished dish, not the recipe.
Generally speaking the graphic design and of course the content (textual content, photographs you have licensed, etc.) of the site is yours to do with as you please, but the underlying source code (PHP and JavaScript) remain the intellectual property of Company, LLC. You may modify them as needed, but you may not duplicate the software for use on other websites, and you may not distribute derivative works. This license is transferrable as long as Company, LLC is notified in writing of the transfer, and may verify that the transfer has taken place.
I've never had a problem.
I still cannot find the droids I am looking for...
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.
In other words, he wants to lock them in to using only HI to extend the application. There is no reason he can't deliver it completely unobfuscated, yet still protected by copyright. Explain to them that they have a license to use it, that but they can't give or sell copies to anyone else because of copyright.
This guy should be avoided like the plague. He's like the people how "help" you by registering your domain for you, but put their name as the administrator, so you can't move it somewhere else when you're pissed off with their childish - and VERY UNPROFESSIONAL - tactics.
Other posters have already said that legally it all depends on the license you work out with the customer, and they are correct.
Which is why we need to eliminate licensing and have two modes for work - either you work for someone else and they own what you produce or you work for yourself and others can come to you and buy copies from you. Then it's very simple and there's no needing to read 5,000 lines of legalese bullshit in order to try to find out who owns what.
As for the guy at hand being contracted to produce code, sorry, but if they come to him saying "Write X for us", then they own it because they paid for all of the development. If you write X own your own and then decide to sell copies of it, then you own it. However if someone else comes and pays for you to write X, they own it because they paid all the costs of producing it.
Also, does anyone else find it extremely absurd that only when it comes to software / digital content that people are allowed to sell you something and claim that they still own it? No other industry in the world would be allowed to get away with that bullshit. Sure, I understand distribution rights for a game / song / movie / software, but once you buy that copy, you OWN it.
"The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants." ~Thomas Jefferson
Books don't have source code.
The "source code" for a book would be the author's imagination and creative ability. The publishing company most certainly doesn't own *that* after they buy the rights to a particular book.
In the software world, if I buy the rights to a program I'm buying the end result of a particular combination of code. I don't get the rights to the individual modules/libraries inside that code.
No sig today...
Here, are we to feel that the people who paid for the code don't own it and can't do what they want with it? Are developers acting the part of the MPAA now?
Lots of the responses are like "you own what you contractually purchased, according to said contract", which is cool 'cause that's what I think should be the case.
But the tone of the original post is Weird.