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."
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.
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.
The only thing correct about your post is the title.
As a programmer I own all the of the code I write until I sign away that right. It is my companies fault that they did not require me to sign a contract giving up those rights. In fact I brought the issue up to them they still haven't done anything about it.
Try asking your dentist some time if you can have the x-rays they take of your teeth.
IMAGE VERIFICATION IS EVIL!
Nope. He's not wrong at all. Copyright belongs to the creator by default, even if someone else paid for the work. There are a few exceptions, the biggest being that if the work is "work for hire," then the employer owns the work. This most commonly happens when a regular employee does copyrightable work for his employer.
Normal property laws do not apply to copyright. Copyright is governed by federal statute.
Funny, I *do* keep copies of X-rays and even was given a copy of viewing software and the images from some MRIs. No hassle whatsoever. If you're employed, you don't own the rights to the work you do for the company, unless *they give it to you*. Try it in court and you'll find your unsuccessful.
As a matter of US law, you are wrong. Copyright in a work for hire resides with the employer (or whomever the work was made for). See Circular 9 of the US Copyright Office. If an entire program is being developed as a contract piece, it *might* not qualify as a work for hire, but contracted software components and anything a normal employee writes within the scope of his employment are works for hire, and the people writing the checks own those works.
I don't know about the corresponding laws in other countries, but if you work in the US, you are woefully misinformed.
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 even true. You own the copy, but your permitted usage is restricted only by law and can be expanded by the copyright holder through the forfeiture of some of the exclusive rights conveyed by copyright. This is at least partly because licenses are generally not a precondition for the purchase of a copy of a movie/song/etc.
Bottom line is that if you're buying COTS, then you get whatever the license says. If you're paying for development, then you get whatever you negotiate. Articulate your requirement for data rights in the RFP, carefully review the proposals for meeting your requirements, then follow-up to ensure the contract says what you need it to say.
Wedding photography has a very well established business plan where the base fee covers the basic costs of the photographer, and the prints supply the profit. You are not paying twice for the same thing - the real cost has simply been split up in a way which is convenient to both the photographer and the customer. As it is not exactly an uncompetitive industry, and you don't see many wedding photogs turning up in Porsches, i'd say the pricing and model were pretty fair.
The reasons for the model relate to the photographer having control over his/her reputation, not to screwing the customer - when photos were still taken on film, the quality of the final print had as much to do with the printing process as the actual taking of the picture. Retaining control over that was important to the reputation of the photographer - if he actually handed you a stack of negatives and let you have them printed by any old mail order company, the lousy final prints would impact his reputation. You *could* argue it is an outdated model now, with the rise of electronic media, but most couples still want prints, and the same problem actually still remains - giving out jpg's and letting people print at home or from a cheap online outlet is going to result in exactly the same quality/reputation problem as in the film days.
The industry is adapting to modern times though, so you will now find some wedding photogs will include a DVD of low resolution images for you to put on the web (and many will host a web presence for you as part of the package). But any you find who are willing to give you full size images and reproduction rights for anything less than a big pile of money are probably not the quality of photographer you want covering your wedding anyway.
Erm, no. "Moot" means up for discussion, not yet agreed. Write a good contract, and the issue is no longer moot.
Of course you're right that this is all a non-issue. I've never seen a contract which didn't make it perfectly clear who owned the code. In many cases ownership is transfered - as the programmers Mr. Partner hires (either as employees or contractors) will no doubt confirm. Surely he knows what's in their contracts?
Buying a book? Never. Paying someone to write a book? Entirely different. When I am paid to write a book, my publisher doesn't own the book, but they do own exclusive publication rights and various other things. These are all made clear in the contract. If I am paid to write code then it's usually work for hire and the client does own it, unless the contract explicitly stats something to the contrary. If you're paying someone else to write code then you should either own it, or make sure that you have it under an X11-style license. Anything else and you're locked into that person for all future maintenance.
I am TheRaven on Soylent News
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.
The reputation argument may have made sense 40 years ago, but it hasn't for 20 thanks to automation. And if you think the pictures where ever developed by the master himself, that hasn't been true since photography became a commercial operation. That work was handed over to some assistant. Reality is, this argument was given to people commenting about the price to give them a rationale to accept it. By the time they figured out it was wrong, if they did at all, the photographer was long gone.
The real business plan, and the real reason, is to lower the price as much as possible for those who have a say in the matter (the bride and groom), and raise it as high as bearable for those who don't (the rest, and in particular the parents and grandparents who will shell out no matter what), including mandatory "extras" such as frames. The whole thing is a big scam built on "that's the way it's done" (and indeed good luck finding a photographer who will give you the copyright as part of the deal), and the quite reasonable fear of the newly-wed-to-be to ruin their great moment by not going with "the best"
As for this "adaptation" of providing low-res samples to "put on the web", it's idiotic at best. Anything that's worth looking at on my standard 24' should be at least 1-1.5 MP. That will look fine printed on a 9*13. Conversely, something that doesn't look fine on a 9*13 will look like a stamp on my screen, in which case it's a scam again.
I don't know how much money these guys make on prints, but I'd rather pay an extra grand and get the copyright. What's unacceptable is that it's not even an option.
a "good contract" may have loopholes you didn't think of
Then it isn't a good contract, is it? In the case of SCO and Novell, their problem was physically losing a lot of the original paperwork, and a bad contract with more legalize than plain English. Most contracts I have seen aren't good contract and suffer the same problem.
Tequila: It's not just for breakfast anymore!
If someone pays you to perform work, they own all rights to that work.
This is your opinion, and your clear intent and desire when you are soliciting work. It is not however legal fact.
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.
It's difficult to find a photographer that agrees, because its a false legal assumption. Your actions however are the proper way to deal with the situation... refuse to hire anyone to do the work, who refuse to transfer the copyrights.
I consider that a form of double jeopardy where I'm being forced to pay for something twice.
You're misusing the term "double jeopardy". Double jeopardy only applies to criminal punishment. This requirement to "pay for something twice" is also not something that is so unfair that it cannot be contracted away. It's entirely reasonable for an artist (e.g. a photographer) to retain the rights to the works, which they produce. They are after all artists. If you want to own the copyrights to it, then you have to pay for that separately from simply having the artist produce the singular work for your enjoyment.
Software is no different.
Actually, it legally is different. Specifically, there is no way at all for software to be written "for hire" unless you are a normal employee.
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.
This is not legally correct.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Unfortunately that's not particularly strange at all. Most coders don't own their code either, the company they work for does. Same is true for songwriters, screenwriters, etc.
Well last time I checked with my lawyer I in fact *do* own the code I write and I own the moral rights to any work I produce and those rights cannot be assigned away by copyright or any other because I am the original producer of the work.
Untrue. You as the producer of the work CAN if you desire to transfer the copyright to someone else.
The parent is correct. Most coders that work for a company, have an agreement with that company in their contract that code they write for the company is a work for hire and they require the transfer of copyright.
The coder would need to agree to that to get hired there.
So that coder does have the right to transfer their copyright, and most coders do exactly that.
Actually, you're both right. "Moot" is a frustrating word in English, because like 'sanction', it has contradictory meanings.
Moot does mean 'debatable', but it also means 'insignificant', 'meaningless', or 'irrelevant'. In the applicable context here, a statement regarding legal issues, it also means 'nonreal' (a moot issue is one in which there is no longer (or never was/will be) an actionable, real legal controversy).
GP's point and usage is correct. Even the most basic and elementary contract in this field will establish ownership rights. Generally, this allocation is the reason for the contract in the first place, apart from memorializing the payment agreement.
You are woefully misinformed as well.
GP broadly misstates the work for hire doctrine, but so do you--just in the opposite direction.
If you are a contractor, then in so far as computer programming there is NO WAY FOR THE WORK TO BE A WORK FOR HIRE... even if your contract says it is.
Not so. Written agreement by both parties in a valid contract can establish the work as a work for hire copyright so long as it is commissioned for a collective work. 17 USC 101.
If your customer provides a copyrightable data set or is integrating your software product with any other copyrightable work, they have a collective work claim, and coupled with contract language stating that it is a work for hire, it will usually be so.
For computer programming, one's contract must explicitly include terms for the transfer of copyrights, otherwise the programmer will retain all copyrights
This is true, if the programmer is an independent entity and is contracting for work with a third party. Stating that you are an independent contractor does not make it so, however, as many "contractors" are in fact employees for the purposes of the Copyright Act.
In order to be considered an independent contractor for copyright (and agency purposes in general), you must demonstrate that the putative employer does not maintain any substantial control over the work or over the programmer, and that the programmer's does not comport himself in a manner that would lead others to believe he was an agent of the employer. In modern programming relationships, this has grown increasingly difficult, given the increased input and meetings with the customer, along with their increased executive authority over project direction.
Assuming you did accept a simple commission and are deemed not an employee-agent, the product will not be considered a work for hire only if it is not part of a collective work. The collective work need not be entirely software to qualify, so programmers are rarely off the hook on that basis alone. The parties in this case must agree that the product is a work for hire, as required to fulfill the definition of 17 USC 101 under paragraph 2 of the "work for hire" definition.
What this means in practice is that all contracts should specify, in the positive or negative, the work for hire status to minimize disputes later on. Good attorneys can move the work for hire line a fair distance both ways because the concept of agency is fairly nebulous and the degree of customer control exercised necessary can vary wildly from case to case.
If the customer explicitly agreed that it was not a work for hire, particularly a sophisticated customer, it probably won't be found one later. If the contract explicitly states that it is a work for hire, it is a virtual certainty that federal judges will make it so by the end of the trial, and usually will do so without so much as breaking a sweat.