
Paying for code doesn’t mean owning it - Hagelin
http://www.pcpro.co.uk/realworld/356161/paying-for-code-doesn-t-mean-owning-it
======
fnid2
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
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.

------
Xurinos
_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
_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?

------
__bjoernd
"...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.

------
petewarden
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
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.

