When you sell code to the customer...
-
Note: I hope this can't be considered a programming question... :~ When you sell code to the customer which kind of license do you use? What information do you leave on the code? i.e. programmer, date, company A to company B... What should be taken into account when doing that? Any hint? how you avoid problems/responsibilities when code is changed by the customer? Thank you all! :thumbsup:
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
-
Note: I hope this can't be considered a programming question... :~ When you sell code to the customer which kind of license do you use? What information do you leave on the code? i.e. programmer, date, company A to company B... What should be taken into account when doing that? Any hint? how you avoid problems/responsibilities when code is changed by the customer? Thank you all! :thumbsup:
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
Joan Murt wrote:
how you avoid problems/responsibilities when code is changed by the customer?
Have a bullet proof EULA (for what it is worth). Document your code. Have working examples and samples that showcase your source code. Have unit tests for your own source code. (ship them). Have good technical support.
I'd rather be phishing!
-
Note: I hope this can't be considered a programming question... :~ When you sell code to the customer which kind of license do you use? What information do you leave on the code? i.e. programmer, date, company A to company B... What should be taken into account when doing that? Any hint? how you avoid problems/responsibilities when code is changed by the customer? Thank you all! :thumbsup:
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
That depends entirely on the customer. If they're good people, give them what they need. If they're @rseholes, be an @rsehole. If one or the other doesn't come naturally, fake it.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Note: I hope this can't be considered a programming question... :~ When you sell code to the customer which kind of license do you use? What information do you leave on the code? i.e. programmer, date, company A to company B... What should be taken into account when doing that? Any hint? how you avoid problems/responsibilities when code is changed by the customer? Thank you all! :thumbsup:
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
Development manager here. Seems like you might need to differentiate between 2 different things: selling a packaged product and selling source code. In my experience purchasing products, buying raw source code is rare. But if done, this is a special situation with different terms that say (in essence), "The client is buying the source code. All maintenance and support are now the client's responsibility." This is typically at a much higher price that if you just licensed it to the client. They want to make a customized version of the functionality OR if you're a small shop, they may want the source code in case you go out of business, esp if it's something critical for their operations. Usually we see the finished product that is a compiled/built application that has an installer or something like that where you cannot see or get at the source code. (And if you do, please look into a code obfuscation product...) You are starting to hit on the problem in your question. You mention, "how you avoid problems/responsibilities when code is changed by the customer?" You do that with an agreement from the start. If you provide a product, you license it to them and provide support & updates. If they want the source code, then you have no reasonable way of controlling what is done to it over time, making support almost impossible. But if you want to do this, you can raise the price for the source code as I mentioned before. You can also sell your support services as a consultant to the client with the understanding that the source code is still their ultimate responsibility.
-
Development manager here. Seems like you might need to differentiate between 2 different things: selling a packaged product and selling source code. In my experience purchasing products, buying raw source code is rare. But if done, this is a special situation with different terms that say (in essence), "The client is buying the source code. All maintenance and support are now the client's responsibility." This is typically at a much higher price that if you just licensed it to the client. They want to make a customized version of the functionality OR if you're a small shop, they may want the source code in case you go out of business, esp if it's something critical for their operations. Usually we see the finished product that is a compiled/built application that has an installer or something like that where you cannot see or get at the source code. (And if you do, please look into a code obfuscation product...) You are starting to hit on the problem in your question. You mention, "how you avoid problems/responsibilities when code is changed by the customer?" You do that with an agreement from the start. If you provide a product, you license it to them and provide support & updates. If they want the source code, then you have no reasonable way of controlling what is done to it over time, making support almost impossible. But if you want to do this, you can raise the price for the source code as I mentioned before. You can also sell your support services as a consultant to the client with the understanding that the source code is still their ultimate responsibility.
-
Development manager here. Seems like you might need to differentiate between 2 different things: selling a packaged product and selling source code. In my experience purchasing products, buying raw source code is rare. But if done, this is a special situation with different terms that say (in essence), "The client is buying the source code. All maintenance and support are now the client's responsibility." This is typically at a much higher price that if you just licensed it to the client. They want to make a customized version of the functionality OR if you're a small shop, they may want the source code in case you go out of business, esp if it's something critical for their operations. Usually we see the finished product that is a compiled/built application that has an installer or something like that where you cannot see or get at the source code. (And if you do, please look into a code obfuscation product...) You are starting to hit on the problem in your question. You mention, "how you avoid problems/responsibilities when code is changed by the customer?" You do that with an agreement from the start. If you provide a product, you license it to them and provide support & updates. If they want the source code, then you have no reasonable way of controlling what is done to it over time, making support almost impossible. But if you want to do this, you can raise the price for the source code as I mentioned before. You can also sell your support services as a consultant to the client with the understanding that the source code is still their ultimate responsibility.
If they just want your source code in case you go out of business, a viable solution is to pay a lawyer to keep your source code, so that it is available if they want to buy it in the future from you (or you heirs). I suggest to charge them for the cost of the lawyer an extra cost for you in the case you have to continue to develop the application, so you periodically have to send a copy of the updated sources to the lawyer. This means that this cost cannot be payed just one time, instead it should be considered as a subscription to a service to keep the source updates always available to the customer.
-
Note: I hope this can't be considered a programming question... :~ When you sell code to the customer which kind of license do you use? What information do you leave on the code? i.e. programmer, date, company A to company B... What should be taken into account when doing that? Any hint? how you avoid problems/responsibilities when code is changed by the customer? Thank you all! :thumbsup:
[www.tamautomation.com] | Robots, CNC and PLC machines for grinding and polishing. [YouTube channel]
1. Get the money up-front: at least 20 times the cost of the code in obfuscated form, or in some UI package. 1.a. offer the customer, at the time of purchase, a paid-in-advance yearly maintenance fee to cover new versions of the code with bug-fixes, and/or new features. make it clear that you will not offer this yearly service after the sale. 2. Remove all comments from the code, but do not obfuscate. 3. Put in your EULA attached to the code: a. support provided only with advance payment for a certain number of hours of your time at a rate you set. 4. In response to inquiries from customer: quote the text in 3.a. to the customer, along with an invoice for said number of minimum hours at rate you specify. sincerely, Nicolo Machiavelli
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
Development manager here. Seems like you might need to differentiate between 2 different things: selling a packaged product and selling source code. In my experience purchasing products, buying raw source code is rare. But if done, this is a special situation with different terms that say (in essence), "The client is buying the source code. All maintenance and support are now the client's responsibility." This is typically at a much higher price that if you just licensed it to the client. They want to make a customized version of the functionality OR if you're a small shop, they may want the source code in case you go out of business, esp if it's something critical for their operations. Usually we see the finished product that is a compiled/built application that has an installer or something like that where you cannot see or get at the source code. (And if you do, please look into a code obfuscation product...) You are starting to hit on the problem in your question. You mention, "how you avoid problems/responsibilities when code is changed by the customer?" You do that with an agreement from the start. If you provide a product, you license it to them and provide support & updates. If they want the source code, then you have no reasonable way of controlling what is done to it over time, making support almost impossible. But if you want to do this, you can raise the price for the source code as I mentioned before. You can also sell your support services as a consultant to the client with the understanding that the source code is still their ultimate responsibility.
I wrote an RTOS designed for ARM Cortex-M series processors. Much of its build process modifies source file templates producing code to be compiled. A configuration file specifies the number and sizes of FIFO buffers. Adding a task, or changing its priority or stack requirements modifies multiple files – most often via a generated header file. It switches tasks quickly and uses minimal ROM and RAM and even works okay on Cortex-M0 products. I would sell the source code with an NDA that prohibits distribution. Use on substantially similar products is allowed. I.e. first use is the brain of a coffeepot. No second fee for use in a toaster. Extra fee for use as an IoT security appliance or as part of a bowling alley pinsetter. I expect any sales would begin with a contract to teach about my RTOS followed by hands on assistance in developing the embedded application.