Then again, I bill by the hour -- so scope creep doesn't bother me at all
Discussion on:
View:
Show:
Good article, but I have to disagree with the statements under "Scope of work", unless the engagement is intended to be short. Most of mine tend to be ongoing for years, with an annual contract renewal. Trying to specify everything in detail that I will provide for them over the next year is impossible.
Then again, I bill by the hour -- so scope creep doesn't bother me at all
Then again, I bill by the hour -- so scope creep doesn't bother me at all
Your coverage of the topic is generally reasonable but I don't know why you seem to feel a need to put in language that the client should negotiate for .. or demand, as the case may be. The one that sticks out is the "work for hire" clause; while I may ultimately not care if the client owns the work I don't generally believe in just giving things away and that's what you're doing here.
You may need the WFH clause as a bargaining chip if the client gets edgy about some other issue .. wouldn't it be nice to be able to say, "ok, if we can agree to on-site not more than two days per week, I'm ok with the work-for-hire" ??
Of course if you know in advance that the client will absolutely insist upon the clause it may be wise to just put it in in the first place and avoid any additional hassle.
I'm not going to argue too strenuously here as I know some contractors have a bit of a fetish for written contracts, and indeed sometimes they come in handy .. BUT, personally, over many years and many projects I don't think I've used a written contract more than half the time and each time was at the insistence of the client. Why? Because I know that the kind of clients I have will ALWAYS have the upper hand in the negotiations; I'm a licensed attorney but that really doesn't help a whole lot against a big bureaucracy with an ARMY of licensed attorneys and rules which stretch from here to hell.
I don't really expect to influence the "have to have a contract" gang on the issue; I raise it only as something to think about, and, to say that in case anyone should find themselves mid-stream in a project without one, don't panic .. there are other legal grounds for recovery when you've actually delivered something of value.
You may need the WFH clause as a bargaining chip if the client gets edgy about some other issue .. wouldn't it be nice to be able to say, "ok, if we can agree to on-site not more than two days per week, I'm ok with the work-for-hire" ??
Of course if you know in advance that the client will absolutely insist upon the clause it may be wise to just put it in in the first place and avoid any additional hassle.
I'm not going to argue too strenuously here as I know some contractors have a bit of a fetish for written contracts, and indeed sometimes they come in handy .. BUT, personally, over many years and many projects I don't think I've used a written contract more than half the time and each time was at the insistence of the client. Why? Because I know that the kind of clients I have will ALWAYS have the upper hand in the negotiations; I'm a licensed attorney but that really doesn't help a whole lot against a big bureaucracy with an ARMY of licensed attorneys and rules which stretch from here to hell.
I don't really expect to influence the "have to have a contract" gang on the issue; I raise it only as something to think about, and, to say that in case anyone should find themselves mid-stream in a project without one, don't panic .. there are other legal grounds for recovery when you've actually delivered something of value.
... but not any more. Those big companies with all the lawyers also know how to squeeze out of some verbal agreements. IMHO it's better to protect yourself.
I agree with you on the WFH clause -- I like to retain some ownership of some of my work, in order to be able to reuse it. I make it clear in my contract that there are two types of software that I'll supply: a "work product", which is theirs, and additional software that was not first developed for the project to which they have an unrestricted license but I retain copyright.
I agree with you on the WFH clause -- I like to retain some ownership of some of my work, in order to be able to reuse it. I make it clear in my contract that there are two types of software that I'll supply: a "work product", which is theirs, and additional software that was not first developed for the project to which they have an unrestricted license but I retain copyright.
sure ... if that's what the contract actually does; but sometimes the contractor would do better without it. For my nickel, the best protection is a short leash on payment ... you just don't work more than a week or two out in front of payments.
The other thing about that piece of paper you have is the big question: can you afford to enforce it? Most ICs will get slaughtered in litigation; the merits are irrelevant ... the corp will just take over your life, and your checkbook, with discovery and motion practice from day one
sounds nice but it can be hard to identify which is which ... the whole thing is typically academic: most clients really need nothing more than a non-exclusive, unrestricted license (no matter what they THINK or SAY they need) ... and I've never actually seen the dreaded scenario of a developer not being able to make use of common routines in other project work; how are they going to know? If there's a chance they will, there's always another way to express your code.
If this stuff actually DOES get thick, as a fallback position, developers should consider some kind of cross-licensing agreement where you get back whatever rights you need to maintain use of your libraries.
The big problem with copyright is that what the customer normally needs can't be licensed.
Generally speaking, most clients need:
1. the ability to change the software
2. the ability to make copies for internal use (backup etc.)
3. the ability to run the software on multiple processors/machines in their organization
4. the right to transfer their rights on sale of a unit.
Very few companies ever consider the possibility of selling their software as a package unless that's the business they're in.
The first one is the only one that really sticks out as an issue to most clients.
The problem is that the last three can be licensed. The first is called a moral right and (at least in Canada) cannot be licensed.
That's why a lot of companies try to get a "work for hire" copyright... the employer owns the copyright with an employee. And it's the only way they can see to get the moral rights.
The problem of course is that most clients don't realize that the legislation sets out the rights and limitations. In Canada, for example, there is a provision preventing a software contractor from transferring moral rights. Effectively, the clause is null and void.
Definitely a case of the need for copyright law to be adjusted to meet the world of the information age. Unfortunately, the drive for reform seems to be focused on protecting company rights from that great threat to the capitalist system. I'm speaking of piracy here. (sarcastically if you haven't guessed).
Glen Ford,PMP
http://www.trainingnow.ca
Generally speaking, most clients need:
1. the ability to change the software
2. the ability to make copies for internal use (backup etc.)
3. the ability to run the software on multiple processors/machines in their organization
4. the right to transfer their rights on sale of a unit.
Very few companies ever consider the possibility of selling their software as a package unless that's the business they're in.
The first one is the only one that really sticks out as an issue to most clients.
The problem is that the last three can be licensed. The first is called a moral right and (at least in Canada) cannot be licensed.
That's why a lot of companies try to get a "work for hire" copyright... the employer owns the copyright with an employee. And it's the only way they can see to get the moral rights.
The problem of course is that most clients don't realize that the legislation sets out the rights and limitations. In Canada, for example, there is a provision preventing a software contractor from transferring moral rights. Effectively, the clause is null and void.
Definitely a case of the need for copyright law to be adjusted to meet the world of the information age. Unfortunately, the drive for reform seems to be focused on protecting company rights from that great threat to the capitalist system. I'm speaking of piracy here. (sarcastically if you haven't guessed).
Glen Ford,PMP
http://www.trainingnow.ca
To be more precise, in Canada moral rights may not be assigned , they may, however, be waived, which effectively solves the problem you assert.
See Canadian Copyright Act, Section 14.1 (2) in particular and the entirety of Section 14 generally.
http://www.cb-cda.gc.ca/info/act-e.html#rid-33225
You are, of course, correct. That is the work around.
Unfortunately, it requires the client to understand copyright law. ("Why can't I license moral rights? What do you mean you waive your rights? No, my lawyer says I have to have a work-for-hire clause." etc.). And the sad truth is that most internal IT people don't know enough about running a service company. And copyright, you must admit, is approaching the esoteric limits for even a consulting company.
It also requires more words than a simple, "this license includes the right to change the code", since you need to "waive the moral rights" only for this client and work done on the client's behalf. And then only certain of the moral rights etc. etc. etc.. A paragraph where a sentence will do.
All for code that the contractor may or may not retain. (My coding was on big machines and I don't normally keep a copy if only because of the difficulty and cost of copying and storing it).
I should also point out that the only reason I'm familiar with this is that I typically act as a consultant even if I am hired as a contractor. That means I share documents and articles that will not become the property of the client. So I have a need for two clauses - one for software (or other product) and one for documents.
Glen Ford, PMP
http://www.trainingnow.ca
Unfortunately, it requires the client to understand copyright law. ("Why can't I license moral rights? What do you mean you waive your rights? No, my lawyer says I have to have a work-for-hire clause." etc.). And the sad truth is that most internal IT people don't know enough about running a service company. And copyright, you must admit, is approaching the esoteric limits for even a consulting company.
It also requires more words than a simple, "this license includes the right to change the code", since you need to "waive the moral rights" only for this client and work done on the client's behalf. And then only certain of the moral rights etc. etc. etc.. A paragraph where a sentence will do.
All for code that the contractor may or may not retain. (My coding was on big machines and I don't normally keep a copy if only because of the difficulty and cost of copying and storing it).
I should also point out that the only reason I'm familiar with this is that I typically act as a consultant even if I am hired as a contractor. That means I share documents and articles that will not become the property of the client. So I have a need for two clauses - one for software (or other product) and one for documents.
Glen Ford, PMP
http://www.trainingnow.ca
my understanding of Canadian copyright law, as it would apply to a computer program, is that by default, where the work is commissioned and paid for by another entity, that entity is the "first owner" of the copyright and therefore the legal "author" per the statute, UNLESS there is an agreement to the contrary. Since Section 14 gives moral rights to the "author," it follows that the employer has the moral rights as well as the usual legal rights incident to ownership.
I have to say the issue is not entirely clear, however, and there does seem to be a fair amount of confusion and disagreement up there on the issue, no doubt in part because there are different rules applicable to different kinds of works of authorship.
From an employer perspective I would likely insist upon an assignment and waiver of moral rights just to make clear what the understanding of the parties is.
From a programmer's perspective, assuming I was concerned about my own or my client's future use of the code, I would take the time to draft an appropriate agreement making clear that the actual author would retain certain rights to use the work, whatever those might be.
I cannot disagree that certain employers or clients might find all of this a tedious, burdensome and difficult exercise .. which leaves the developer to decide how important the concessions on each side really are and the extent to which they are willing to risk loss of the engagement.
As a practical matter, in the case of unsophisticated client I don't think I would worry a great deal about later use of common library code. In all events, in the case of code authored prior to the present engagement, the client should have no copyright ownership interest in it unless the developer assigns it away. They would of course have an implied license to use it .. and I don't think I would fuss about them modifying it.
That's a common error. In a similar discussion a few years back a manager up here stated that he always owns the work.
Section 13 gives the original author ownership by default. Section 13 (3) says the owner is the employer and is the section which is misread as work-for-hire. (BTW ... important note that up here, T4/W2 contracting is unusual since it is not considered to be contracting but rather employment). Section 13(2) says the purchaser is the owner but only applies to photography. HOWEVER, the key is that section 13 only applies to licenseable rights.
Section 14.1 applies to moral rights and grants the author of the work moral rights to the work. Note - the author of the work - not the copyright owner.
That's why section 13.3 allows the author to refuse to allow publication of an article even if copyright is owned by the purchaser. (And you thought coders liked unstructured code!).
And I now have a headache ....
Glen
P.S.
BTW the only reason this matters to me is that I traditionally work on equipment where "Open Source" -- in the real meaning of the phrase and with major restrictions -- is the traditional format. This is because virtually all clients have their own internal IT people.
Section 13 gives the original author ownership by default. Section 13 (3) says the owner is the employer and is the section which is misread as work-for-hire. (BTW ... important note that up here, T4/W2 contracting is unusual since it is not considered to be contracting but rather employment). Section 13(2) says the purchaser is the owner but only applies to photography. HOWEVER, the key is that section 13 only applies to licenseable rights.
Section 14.1 applies to moral rights and grants the author of the work moral rights to the work. Note - the author of the work - not the copyright owner.
That's why section 13.3 allows the author to refuse to allow publication of an article even if copyright is owned by the purchaser. (And you thought coders liked unstructured code!).
And I now have a headache ....
Glen
P.S.
BTW the only reason this matters to me is that I traditionally work on equipment where "Open Source" -- in the real meaning of the phrase and with major restrictions -- is the traditional format. This is because virtually all clients have their own internal IT people.
One of the downloads Techrepublic has/had was a short letter style contract.
The reason I point it out is that most consultants/contractors need several different contracts depending on the type of work to be done.
For example, a contractor may need:
1. An agreement letter for single shot small jobs.
2. An estimate acceptance agreement/work order for really short jobs. This is the small print on most work orders ... the stuff on the back page.
3. A single use contract which has been designed for a single engagement. (This is what is being suggested in the article).
4. A multiple use or revolving contract (Chip is suggesting this above).
What a consultant/contractor really needs is to look at his/her business and identify the various types which are needed.
Glen Ford, PMP
http://www.trainingnow.ca
The reason I point it out is that most consultants/contractors need several different contracts depending on the type of work to be done.
For example, a contractor may need:
1. An agreement letter for single shot small jobs.
2. An estimate acceptance agreement/work order for really short jobs. This is the small print on most work orders ... the stuff on the back page.
3. A single use contract which has been designed for a single engagement. (This is what is being suggested in the article).
4. A multiple use or revolving contract (Chip is suggesting this above).
What a consultant/contractor really needs is to look at his/her business and identify the various types which are needed.
Glen Ford, PMP
http://www.trainingnow.ca
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
