3 ms·

Paying for code doesn’t mean owning it

17 points by Hagelin 17y ago

petewarden 17y ago
Summary: PHP developer obsfucates his proprietary frameworks to prevent clients from unauthorized modifications. I'm sympathetic to his need to get paid for his work, but I couldn't help wondering if the benefits of open-sourcing his frameworks would outweigh the loss of control? He could still charge clients more for hosting on their own servers, and I bet most of them would still turn to him for maintenance and upgrades.
Flow 17y ago
I don't agree with his "of course I still own the source code" attitude. If he uses his own framework to create the application the customer wanted, he'll have to explicitly tell them about that part. If it's an engine that presents courses in web-form, the engine is still his, but the content belong to the customer.
Xurinos 17y ago
One problem is that if you’re working in an interpreted language such as PHP then your code isn’t compiled This has always bothered me -- the theory that compiled code is not also code. It is a language that can be interpreted by the OS and anyone else who is familiar with it. This is not a skill most people have, and byte code is not English, but it is code nonetheless. It is not magic, specially sealed, wrapped in a black box. I may not have your source code, but your source code is just your view of the same program. Even your source code could have a pretty printer applied to it so that you edit it differently from other developers on your team -- developers who use different syntax highlighting schemes already do this to aid their mental interpretation of the same code language. I am annoyed by usage licenses with the warning against using disassemblers, as if someone has the right to tell you what kind of viewer/editor/OS/program you are allowed to use to translate/interpret the byte language. They never say, "You are not allowed to open this in a hex editor or notepad". This is an attempt to sell air and trying to seal it with more air, but it also misses the point of the software; it is a misleading and even invalid view of the software's actual value. As someone making money off software, I have never assumed that the software itself held the core value. The value comes from my trusted name, my continued support, and other things I do for the environment of the software. It may even come from the software being necessary for something physical to operate (a robot or firmware on a card). From another perspective, the value is in the physical medium I use to distribute the software so that you can feel more confident in your continued access to it. Keep in mind that while PHP is not compiled, developers at the customer site could alter the PHP code and add value to the application/package that was sold. They also would have to accept the trade-off: Upgrades get pretty complicated when you mix new code with the local changes. They also would have to spend time to learn the code and support it. This tends to be a waste of resources, and thus the advantage remains in the hands of the active producer. The value is not in the libraries I distribute. The value is in me being able to easily maintain and support the libraries and the constructs built on top of them, that I can construct a software package and environment that people are more willing to invest money in than similar things from my competitors. If I do that quickly and well, and if I establish trust with my customers, then I will not as easily lose my customer base to someone else.
- fnid2 17y ago
  I have never assumed that the software itself held the core value. The value comes from my trusted name, my continued support, and other things I do for the environment of the software. This is a mistake a lot of coders make. The software does have value. It's the completed project that solves a problem that has value. If the project is a success and meets the needs of the users, it often matters little who the coder was who built it. The value comes from automating processes, simplifying tasks, and enabling collaboration -- all of those have value regardless of you. Just like a bookshelf has value without the IKEA. Is hacker news great because pg wrote it and can maintain it? Maybe it's a better community because he is around, but it matters little that he typed the keys to make the loops. What matters is that the software has been written and we can use it to communicate. The existence of the software is the value. Of course it takes a certain skill to get a project to completion. That has value up front, but once the project is done, they may not need you anymore -- the software is what they wanted. The same is true of everything else. Is it the furniture maker that is important -- or the table? Is it the running shoe that is important -- or the nike swoosh? Is it the water that is important, or the bottler? You could argue there is a certain level of quality associated with a coder, maybe you, but that quality -- again -- is independent of the coder who wrote the lines of code. If the code is exactly the same, doesn't matter if you wrote it or someone else did. To your other points: Have you ever tried unobfuscating code? It's really hard. Just try unminimizing javascript. It's really hard. It's so hard, you may be better off just rewriting it. Obfuscation does wrap code in a magic, specially sealed black box. That's exactly what obfuscation does. It reduces code to a jumble of wires you don't know where go, encrypted strings, for loops that do maybe nothing or something extra special. Can it be unobfuscated -- yes, but probably not by the client. If you can't write code, you can't unobfuscate it. PHP, while interpreted, can still be obfuscated. People don't really care about the fact that you can create software. They won't pay you for that ability. They will pay you if you create some software for them, but they won't pay you just because you can. Lots of people can, but will they?
fnid2 17y ago
I recently got embroiled in a dispute over a contract term that I include in all my custom projects. The clause states explicitly that I own any code that I write and am giving the client a royalty free license to use it forever. This is almost always a sticking point and I explain to them why, which is almost exactly what the linked article states. Only one time has anyone not agreed to the stipulation, but in that one time, the client went elsewhere. IMO, it's not worth the hassle of going over what I own and what they own and even later when I reuse code from one client's app to another. I don't want to have to think, "Can I legally use this code or do I have to rewrite it?" The headaches, legal troubles and wasted time simply aren't enough to modify what is already codified in U.S. legal statute and supporting court cases. The irony is, if I hadn't included that clause in the contract, explicitly stating what the law says -- that I own whatever code I write, then the client would never have known and everything would have proceeded exactly the same way as if the client had signed a contract without that clause in it. The clause doesn't change the law, it just says what the law is. So I am considering taking the clause out. The reason I haven't yet is because I know that if I'm not explicit about it at the beginning, I could have a very angry client on my hands later. It's been argued that it isn't my responsibility to educate my potential clients about the law, but it is my responsibility to create happy clients, or at least not create unhappy clients.
- ktsmith 17y ago
  Don't take the clause out. If you have a client that insists on code ownership simply give them a new quote for the project. This new quote should be significantly more since you won't be allowed to reuse any of your existing code to build their project. You'll want to charge a higher rate since you also won't be gaining new code to use in future projects. I've had to do this a few times. In one case the client went elsewhere, in a couple of cases the client paid the higher price because they felt that the work would be a profit center for them in the future if they owned it and could resell it, but in most cases clients want cheap and they will be happy to pay for a license. I would also make sure your contract has something specific in it about non transference of your license. It should be clear that if they sell their company or something like that the new owner can continue with the existing licensing terms, but they do not have the right to resell your code to any third party outside of that type of an event. It will almost certainly be unnecessary, but there are enough unscrupulous people out there that it's better to be safe.
__bjoernd 17y ago
"...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; ..." Well, but I do have the right to go to the next DYI market, buy these tools and use them myself. Of course, I can't claim a warranty from the plumber if anything goes wrong afterwards. It is just much more convienient for me to ask the plumber to do this job, because he sells me his knowledge and skill in doing things that I could only do much slower in a much poorer quality. That's how far the similarity goes here. Problem is that as a coder, there is no clear distinction between the tools you use and the result you produce with them. So in the end, I'd understand the author.

17 points by Hagelin 17y ago

Summary: PHP developer obsfucates his proprietary frameworks to prevent clients from unauthorized modifications. I'm sympathetic to his need to get paid for his work, but I couldn't help wondering if the benefits of open-sourcing his frameworks would outweigh the loss of control? He could still charge clients more for hosting on their own servers, and I bet most of them would still turn to him for maintenance and upgrades.

Flow 17y ago

I don't agree with his "of course I still own the source code" attitude. If he uses his own framework to create the application the customer wanted, he'll have to explicitly tell them about that part. If it's an engine that presents courses in web-form, the engine is still his, but the content belong to the customer.

Xurinos 17y ago

One problem is that if you’re working in an interpreted language such as PHP then your code isn’t compiled This has always bothered me -- the theory that compiled code is not also code. It is a language that can be interpreted by the OS and anyone else who is familiar with it. This is not a skill most people have, and byte code is not English, but it is code nonetheless. It is not magic, specially sealed, wrapped in a black box. I may not have your source code, but your source code is just your view of the same program. Even your source code could have a pretty printer applied to it so that you edit it differently from other developers on your team -- developers who use different syntax highlighting schemes already do this to aid their mental interpretation of the same code language. I am annoyed by usage licenses with the warning against using disassemblers, as if someone has the right to tell you what kind of viewer/editor/OS/program you are allowed to use to translate/interpret the byte language. They never say, "You are not allowed to open this in a hex editor or notepad". This is an attempt to sell air and trying to seal it with more air, but it also misses the point of the software; it is a misleading and even invalid view of the software's actual value. As someone making money off software, I have never assumed that the software itself held the core value. The value comes from my trusted name, my continued support, and other things I do for the environment of the software. It may even come from the software being necessary for something physical to operate (a robot or firmware on a card). From another perspective, the value is in the physical medium I use to distribute the software so that you can feel more confident in your continued access to it. Keep in mind that while PHP is not compiled, developers at the customer site could alter the PHP code and add value to the application/package that was sold. They also would have to accept the trade-off: Upgrades get pretty complicated when you mix new code with the local changes. They also would have to spend time to learn the code and support it. This tends to be a waste of resources, and thus the advantage remains in the hands of the active producer. The value is not in the libraries I distribute. The value is in me being able to easily maintain and support the libraries and the constructs built on top of them, that I can construct a software package and environment that people are more willing to invest money in than similar things from my competitors. If I do that quickly and well, and if I establish trust with my customers, then I will not as easily lose my customer base to someone else.

fnid2 17y ago
I have never assumed that the software itself held the core value. The value comes from my trusted name, my continued support, and other things I do for the environment of the software. This is a mistake a lot of coders make. The software does have value. It's the completed project that solves a problem that has value. If the project is a success and meets the needs of the users, it often matters little who the coder was who built it. The value comes from automating processes, simplifying tasks, and enabling collaboration -- all of those have value regardless of you. Just like a bookshelf has value without the IKEA. Is hacker news great because pg wrote it and can maintain it? Maybe it's a better community because he is around, but it matters little that he typed the keys to make the loops. What matters is that the software has been written and we can use it to communicate. The existence of the software is the value. Of course it takes a certain skill to get a project to completion. That has value up front, but once the project is done, they may not need you anymore -- the software is what they wanted. The same is true of everything else. Is it the furniture maker that is important -- or the table? Is it the running shoe that is important -- or the nike swoosh? Is it the water that is important, or the bottler? You could argue there is a certain level of quality associated with a coder, maybe you, but that quality -- again -- is independent of the coder who wrote the lines of code. If the code is exactly the same, doesn't matter if you wrote it or someone else did. To your other points: Have you ever tried unobfuscating code? It's really hard. Just try unminimizing javascript. It's really hard. It's so hard, you may be better off just rewriting it. Obfuscation does wrap code in a magic, specially sealed black box. That's exactly what obfuscation does. It reduces code to a jumble of wires you don't know where go, encrypted strings, for loops that do maybe nothing or something extra special. Can it be unobfuscated -- yes, but probably not by the client. If you can't write code, you can't unobfuscate it. PHP, while interpreted, can still be obfuscated. People don't really care about the fact that you can create software. They won't pay you for that ability. They will pay you if you create some software for them, but they won't pay you just because you can. Lots of people can, but will they?

fnid2 17y ago

I recently got embroiled in a dispute over a contract term that I include in all my custom projects. The clause states explicitly that I own any code that I write and am giving the client a royalty free license to use it forever. This is almost always a sticking point and I explain to them why, which is almost exactly what the linked article states. Only one time has anyone not agreed to the stipulation, but in that one time, the client went elsewhere. IMO, it's not worth the hassle of going over what I own and what they own and even later when I reuse code from one client's app to another. I don't want to have to think, "Can I legally use this code or do I have to rewrite it?" The headaches, legal troubles and wasted time simply aren't enough to modify what is already codified in U.S. legal statute and supporting court cases. The irony is, if I hadn't included that clause in the contract, explicitly stating what the law says -- that I own whatever code I write, then the client would never have known and everything would have proceeded exactly the same way as if the client had signed a contract without that clause in it. The clause doesn't change the law, it just says what the law is. So I am considering taking the clause out. The reason I haven't yet is because I know that if I'm not explicit about it at the beginning, I could have a very angry client on my hands later. It's been argued that it isn't my responsibility to educate my potential clients about the law, but it is my responsibility to create happy clients, or at least not create unhappy clients.

ktsmith 17y ago
Don't take the clause out. If you have a client that insists on code ownership simply give them a new quote for the project. This new quote should be significantly more since you won't be allowed to reuse any of your existing code to build their project. You'll want to charge a higher rate since you also won't be gaining new code to use in future projects. I've had to do this a few times. In one case the client went elsewhere, in a couple of cases the client paid the higher price because they felt that the work would be a profit center for them in the future if they owned it and could resell it, but in most cases clients want cheap and they will be happy to pay for a license. I would also make sure your contract has something specific in it about non transference of your license. It should be clear that if they sell their company or something like that the new owner can continue with the existing licensing terms, but they do not have the right to resell your code to any third party outside of that type of an event. It will almost certainly be unnecessary, but there are enough unscrupulous people out there that it's better to be safe.

__bjoernd 17y ago

"...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; ..." Well, but I do have the right to go to the next DYI market, buy these tools and use them myself. Of course, I can't claim a warranty from the plumber if anything goes wrong afterwards. It is just much more convienient for me to ask the plumber to do this job, because he sells me his knowledge and skill in doing things that I could only do much slower in a much poorer quality. That's how far the similarity goes here. Problem is that as a coder, there is no clear distinction between the tools you use and the result you produce with them. So in the end, I'd understand the author.