Don't pay lawyers to do it! There are plenty of pro-forma contracts available on contracting sites (e.g. ContractorUk.com). If you are offering a service then you offer YOUR terms and conditions - that is all a contract is. If the client is not willing to accept your T&C's then it is their responsibility to offer an alternative - which you are within your rights to reject, accept or offer suggestions for amendments.
Software Development contracts are no different to any other service provided by any other supplier... negotiation may be more prevalent is all.
Who do you want to be in control - the client, or yourself? It also depends on where you are - in the UK you need to be fully conversant with IR35 (personal services company taxation) and it's virtually certain that a client-provided contract will be inadequate. If you're a contractor, you should be a member of your "local" trade association - in the UK that would be IPSE[^] and any decent association will provide sound template contracts.
I always offer my "standard" contract (based very closely on the IPSE one) and clients are normally happy with this. If they are reluctant, just tell them that you can use their contract but will need to charge them for an independent contract review. Even if they insist on using theirs and refuse to stump up the review fees, it's usually worth paying for the review yourself anyway - certainly in the UK in the current climate.
FYI, my standard contract simply refers to a "schedule" for the actual scope of the project, timescales, and fees. That's again based on a boilerplate but customising the contract and schedule normally takes only 1/2 hour or so, even on a larger contract.
Now, if you mean a GPS receiver terminal... well, it really depends on what you want it for and what you want on it. The cost of receivers nowadays is all over the place, you can go from something really cheap like a GPS receiver module or integrated circuit to something that's commercial consumer driven to something that's military equipment. Every one of those options will have a cost that's completely different, depends on wants/needs (also known as requirements ).
Practical example; say I write a Memento-pattern for one of your applications, to provide Undo/Redo functionality. There's nothing stopping me from coding the same pattern in my own application. That is not a "ripp off", it is merely doing the same thing again, but in a different application.
'nother example; someone wrote a copy-protection scheme, and it needs maintenance. How could I perform maintenance, without seeing the code? Once it is seen, it can be reproduced.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
If you paid them for the work, then the ownership of the codebase is legally yours. You'd have copyright.
You could break up your application into modules, and mak sure that some of the writers have no knowledge of the other modules - but that creates more risk (what if all people with knowledge of module A are sick?) than it actually adds.
See, all the modules would come together in a setup-package. The person who goes to the client and installs the stuff might just as easily copy the entire product.
Most shops that I know of don't even think about their employees as potential liabilities. I'd be looking for work elsewhere right away.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
Actually, it depends on the terms of the employment contract and the jurisdiction.
If the person is a contractor, then unless explicitly stated in the contract, they may retain copyright and IP ownership and you can only use the code for the purpose stated in the contract.
You cannot hide the source code from the programmer. At any cost, at any circumstances programmer would be able to re-write the code of your application, just even if he knows what your application is doing; if that is his intent.
Since you're running the business and before hiring the programmer you should have full control over which person you are going to make a business relation with. You should first of all write your policy and other terms, that he must accept before he starts the job.
In those terms you can indicate what-so-ever you want to abide him by. But still that doesn't give a 100% guarantee that programmer would always ensure the terms being applied on him. In these cases you are always allowed to use legal jurisdiction to fight for your right (if there are some).
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
Two steps on top of my mind:
1. Keeping core algorithms and code to yourself, with others just getting a dll to link to.
2. Making sure that the licensing algorithm and code is with you alone. You alone should hold the license generator.
1. You could make them partners in your company. Then they'd be stealing from themselves.
2. Give them profit sharing so that the more money the code makes the more money they make then they have no reason to steal it.
3. Pay them so handomely it would be more work to steal the code than to sit back and rake in the money you are paying them.
Is everything okay with your code and your employees now? I am about to do the same thing, I am not really good at these things. I proposed a term in the contract to prevent him from copying the code. Is this enough? Could you share what you have done? Thanks in advance
In computer science, method of maintaining proof of authorship (PoA) in code is done in the style of one of two approaches. The chosen approach is either A) a tangible, or B) an un-tangible.
Tangible PoA methods are usually either literally simple like writing your name, username, ID number, into the code. This does work to some extent but can be removed, even if the thief doesnt remove the string, you must be able to show PoA of this string. So, make sure the string you use is verifiable to you as the string has to be able to show by verifification that you have PoA of the string (tag/ID number/email address etc.). Using this method, you could include a ciphertext string in the code if the plaintext had been encrypted using your public key. If the plaintext consisted of 'mr.xx wrote this code and owns all including intellectual rights to this code' for example, before insertion of the ciphertext string into the code, remember that the encryption key for this string must be one which your private key can decrypt. This therefore stamps the code with an easily provable PoA element, so if the code pops up somewhere else, you could demonstrate your explicit and exclusive PoA of the code.
Another useful tangible approach method is adding 'red herrings' into the codebase. A red herring in this context is anything in the code that is nonsensical and usually syntactically invalid.
If you added a few letters at random to the end of randomly-selected and randomly-ordered code lines it could be used an PoA as only you could explain it (showing your valid PoA); nowadays you could even include an encrypted statement of ownership and timestamp ciphertext that can only be decrypted by using your private key, then build a pseudorandom ciphertext-bit distribution process. The reverse of the distribution algorithm will collect and reconstruct the original ciphertext. You could then decrypt this ciphertext and show those who are concerned that you have PoA over the code.
Whereas an intangible method would likely be computerised; one example is, the use of compartmentalisation to keep code secret from those who didnt code it. This can be done by writing chunks of code in various containers, such as;
a Python script batch that is called upon by the C++ applicationcodebase or even just host the secured script on sister server and code the applications interaction with the code via APIs like you would in most applications.
This is a tricky one and it depends on the size of the code base you are trying to protect.
Here are a couple of things you can try.
1. If the code represents a platform, and if the team is large enough you can segment the codebase into multiple repositories and then segment access to them e.g. repositories for the presentation tier (gui interfaces) and repos for services so no one in the team has access to the full set of code.
2. You can achieve similar things to the above by having "core" code e.g base and common classes which are compiled and provided as compiled assemblies to the rest of the team. This way they never work with the deep internals of the system.
3. If you are working with applications you can look into locking them down with code signing certificates. This not prevent the source code but it will prevent the team from taking the code and repackaging it for sale as they won't have the certificates.
4. If you are really paranoid, consider getting all developers to remote into a terminal services environment (or similar) for development, this prevents the ability for the developer to copy large number of coding files off the development environment.
Hope this helps a little.
Last Visit: 31-Dec-99 18:00 Last Update: 23-Sep-23 21:39