Q I was making a joke about starting up a remote programming escrow service. Don't worry I have way to much going on in my life to do something like that. haha

The point I was making was the part that you called a red herring. If something could happen to the AV integrator that created the remote programming then couldn't something happen to an escrow company? But I do like the idea of an escrow company. I just don't think that it could happen anytime soon.

Julie,

I'm an independent AMX programmer. I take pride in what I do, but not so much that I think everyone wants my code and are just waiting to stumble onto a system I've done to steal my awesome work so they can reproduce it and make a killing.

AMX hardware allows you to store the uncompiled source code on the processor. I do this. Always. If a client wants a copy of the source code (and their bill is paid), I provide it.

Here is my point of view:
KEEP THE CLIENT HAPPY and you won't be in a situation of someone stealing your code! This is what it comes down to -- programmers don't want other programmers to steal their work. I understand this, and I feel the same way. But I also feel that a happy client is A#1. If they don't have a reason to go somewhere else then there is no threat of "code stealing".

I've been on the other side too many times -- oh, sorry, we don't have the source code. Yes, it is a pain. This is why I'm not so clingy about my code.

But Julie, PLEASE don't make your article "AMX/Crestron BAD! Control4/Lifeware GOOD!". Granted, I don't know the details of C4/LW, but my understanding is they are not able to do the custom programming to the level of AMX/C. There are a lot of people that DO WANT that level of customization. Scaring them away from AMX/Crestron isn't helping the industry provide the high-end customization that the high-end (big $$) clients want.

Making the public aware of the "no code" situation is fine, but steering them away from AMX or Crestron isn't necessary.

To all those afraid of someone stealing your work: GET SOME CONFIDENCE! Make your clients happy, make some money, and stay in business!

Yes, they are two completely separate files, at least in the crestron world, i.e. a .vtp (touch panel) and .smw (backend control). The reality, though is that a lot of work would still need to be redone in recreating the .vtp if someone only had the .smw

I think you are a lot closer to on track here. The original statement sound like a whole article that said "If they won't give you all the code, don't do business with them," which is completely different. As anyone that has dealt with end users knows, most read just enough about something to be dangerous and ultimately read/hear what they want to hear about something.

Essentially I'm picturing two scenarios. The first is with the type of integrator that would hold the client hostage. Customer says "I want my code or I'm not doing business with you, not giving you final payment, etc." The integrator gives them the compiled files, the end user doesn't know the difference since they can't open it and wouldn't know what they were looking at even if they did. The customer is happy and thinks they took your advice until they actually need it.

The second customer insists that they have to have all the software used and now the integrator is in the position of having to choose whether to lose the job or potentially lose their dealership.

The reality is that even with good intentions, it would be impossible to educate consumers what to ask for in the case of every control system. The average consumer barely understands what we do, nevermind how we do it. Suggesting that the bring up the idea of control code ownership with the integrator as one aspect of evaluating an integrator is one thing. Suggesting that owning the uncompiled code and being free to do whatever you want with it is something completely different.

I'm all for educating consumers. Correct me if I'm wrong, but the target market of EH isn't really the $50K worth of Crestron programming set, so this is kind of a moot point anyway, but I'd like to suggest a compromise here. What about bringing up this concept and educating customers about both sides of the issue in an article about "How to evaluate a qualified integrator" or "Partnering with a qualified integrator" or something to that effect, i.e. it's one piece of a much bigger puzzle that is really the issue here.

I often make the statement to customers that a custom system is only as good as the people that designed, installed, and programmed it. Two systems with exactly the same components can be completely different. One can work very well and the other not. One can be very serviceable and the other not. There are a whole bunch of factors to this. Control code and ownership thereof is a big one, but only one.

What about a system with no as-built drawings? No labelling, etc. They can be just a difficult to service and in a lot of take-overs the new integrator has to start there before they can even touch control code. What if the control programming was just poorly done to start with? Does the client now thing that it's only going to be an hour or two to fix since they "have the uncompiled code" when it needs to be started from scratch to work right regardless?

A lot of this is all in how you spin in, and please forgive me for generalizing and reading tone into your posts, but you are coming off as bitter. The last thing we need to be doing right now is to be scaring customers away that might otherwise be bringing revue into this industry. Let's try to focus on the good work that the industry does and the good companies in it as a model for what customers should be looking for rather than focusing on the negatives. I think that will give you the opportunity to educate consumers as is the goal wearing your EH hat while also showcasing the good parts of the industry as is the goal of your CE Pro hat. With that context I think a lot more of us would be behind this article.

Is there a contract with the customer on this specific point? If not, then a judge will have to decide. Would you like to go in front of the judge and explain that you are right in retaining the code the customer paid you to create?

Let me expand on this. In the business world, we pay all the time to have contractors and or companies to develop software for us. To the extent we are paying for it fully, then it is called "work for hire" which means we retail all the rights to everything developed including the IPR (Intellectual Property Rights).

The contractor of course, has the right to negotiate the above away but that is rare and must be an explicit clause in the contract. And as a matter of course, I doubt there is any company who would pay to have code developed but only receive binaries when all is done.

Now, the contractor, should he/she bring in IP into the product that he/she owned, can have a carve-out which allows him/her to retian the rights after the project is done (i.e. the macros). Or to provide a binary only license to that library. But all would need to be stipulated in the contract as otherwise, it falls under "work for hire."

Just think about this: if you paid me to do some work for you for your next project, would you assume that I only give you binaries? If not, why is there an assumption that the judge would treat it differently when it is a customer/CI relationship as opposed to contractor/CI?


Let's not confuse scenarios here :). If I pay you to write code, it has nothing to do with buying shrink-wrap software. I assure you the courts would not automatically assume it is "licensed" software because that is how you buy off-the-shelf software. You are writing code to a spec unique to me. Commercial software is not that way.

Most importantly, commercial software comes with a license which I am supposed to agree to before using. Do you provide such a thing to your customers and have proof of that? If not, there is no "license grant" here whatsoever. We have an implied work-for-hire contract and the judge will decide who is right.

Reading some of the posts here, clearly this is a sensitive area. But I hope everyone agrees that there is no clear set of rules governing it. And what there is, is likely to protect the customer far more than the company per above. So if you like to retain the code, best policy would say put in something in your bid/contract saying you are retaining the rights. It is the only way to know you can sleep easy and have the law on your side :). And if you are afraid of losing the job if you did, then don't do any installs for a lawyer who will sue you for free :).

The argument is whether the client is buying a single solution/product or a bunch of hardware and programming.

When one buys an ipod they get the functionality of the ipod but they dont get the software or schematics to it and should they try to upgrade it at some point they are on their own. Same goes with software or anything else you buy.

So the only way to make this a non issue is for the CI to first.. make the client aware of the issue and then give or sell the code to the client.



This is the same issue.. are they buying shrink wrapped software or are they buying written/editable code? This is where a contract is important and what the judge would have to determine.


The work for hire contract is (or could be viewed as) for the solution not the components and programming.

Lots of good points.. This has the bones of a great article.. Got some free time? :)

There is a lot of precedent on this one, and sorry to rain on your parade, but if you declare bankruptcy you are no longer in control of who gets what, including customer lists, documentation, etc. It becomes an asset that is sold to the highest bidder. In the case of proprietary control code it typically only has value to that specific customer and they can purchase it relatively cheap, but customer lists, databases, etc. will be auctioned likely to you competitors and whomever is willing to pay the most. It is what it is.

If you just decided to stop operating at some point then you could "sell" your company to a company of your choice and be in control of the process. Most of the time, though, and in context of the current climate, the type of "going out of business" being looked at here typically involves a bankruptcy.

Wish I did ;)

...actually I'm pretty grateful to be busy right now. :)

You're quite right about bankruptcy, however, I always think that if I closed shop for some reason it would be something other than bankruptcy. I hope I would see the writing on the wall before long reaching that stage.

It happens. We are observers/creditors watching an architecture/construction management firm going through it right now. Luckily we had a good enough year that we can sustain the losses/deferred payments (It's a CH11) and won't be following right behind them, but a lot of smaller companies in this industry have so many of their eggs in one basket that not getting paid on one big project due to someone else's bankruptcy that they may have seen coming for a long time but didn't necessarily disclose.

We say it a few months back with a large GC we'd worked with. Developer went under, couldn't pay for a lot of work on a condo development, took the GC and who knows who else with them.

The bankruptcy take-overs I've referenced a couple times here weren't some fly-by-night operation. It was one of the larger and more respected integrators in this industry and was pretty sudden. Luckily we were in a good position to step up and take care of the customers.

There is absolutely nothing wrong with what you are doing. Secession planning is important in any business, especially if you are a small shop. Just playing a little devil's advocate as this topic brings up a lot of others.

Again, just playing devil's advocate, but in this case the court decided that the code was the property of the intellectual integrator and thereby property of the receiving bank to be sold to recover losses. Let's say we advise customers that they own the code and then we go out of business. The bankruptcy court decides otherwise. Are we now exposing the customer to liabilities in the bankruptcy if they think they own something and the court sees it otherwise?

Things like secession planning, history, code availability, backups, etc. are all things that could potentially be brought up in an article like this, but the real question is the fine line between painting a full picture and going overboard.

If customers are to be educated that they should ask for code, as-builts, etc. should they also be educated to ask for bid bonds? performance bonds? How about a review of audited financials? These are all things that have come up at least on commercial projects and once you open pandora's box...

How do you write your proposal? The ones I have seen go like this:

1. Cable/wire/connector: $X for material, $Y for install
2. Equipment (Crestron, TV, Touch Panel, etc): $Y
3. Programming: $XXX/hour, YYY hours = $ZZZ

So unless you write your contract differently, the only part that smells, walks and talks like a work-for-hire, is precisely the programming :).

The only way out would be to have a fixed SKU for #3, that is independent of the amount of work you are doing for me which I assume is not practical.

3. Programming

Again.. are they paying for the programming that makes the system work.. the compiled code thats loaded on the system.. Or are they paying for the uncompiled code. This is the argument that would take place in a court room over the code.

In your last post you talked about software. Microsoft sells you Word for $100 bucks. It costs much more to develop that product and bring it to market. Your paying $100 for a finished uneditable product that provides a solution to your word processing needs.

Some Crestron programmers are saying that they are providing a finished product that allows the clients system to operate and thats it. A done, finished solution just like MS word.

Just because the cost is $50,000 for finished uneditable crestron programming and its only $100 for finished uneditable MS programming (Word) doesnt mean the two are different. Compare a ford to a porsche. Vizio to Fujitsu.

I think part of the issue is that people spend $500k on a system and this issue of the code and paying to have it rewritten to add a VCR is absurd to them. Personally i feel it is absurd but i also feel that you get what you pay for. As an example... compiled code is $50k uncompiled code is much more. Obviously its completely up to the programmer and client how this all plays out. Im just trying to shed light on the 2 sides of this coin.

For those who think its unfair to pay extra for uncompiled code... $100 AV integration exists.. The ipod :).

This situation is a little different than your iPod hypothetical because the client hires you to write specific code for their particular installation. The question (one of law) is whether this is contribution to collective work under the "work for hire" doctrine of copyright law.

There could be specific modules included in that code which could be covered under a separate copyright, but you are granting a license to the end-user when you include it in the compiled program. Use of an iPod is governed by license, but differs because the end-user does not contract with Apple to build a specialized program, particular to their installation.

What im saying is that an argument can be made that the integrated crestron audio video system and the ipod are exactly the same. The "work for hire" programming, could be interpreted as the compiled code that makes the system function.


For the sake of keeping things simple here we should exclude modules and artwork that are not owned outright by the programmer. Lets just assume the programmer created everything and can freely license anything he wants to the end user.



The end user contacts me for an integrated audio video solution. They dont contact me for a specialized program particular to their installation. One could argue that Apple built a specialized program, particular to apple users.

This is what im talking about. I know both sides of this but we still come to the same question.. Is the client paying for a 1 time single uneditable solution or are they paying for all of the bits and peices that its made up of?

With the ipod there is no lingering question. Its on a shelf, done, no customization with a price tag on it. The fact that the crestron system is tailored to an individual does not make it different because the end result is a product thats done and serving its intended purpose.

I am not arguing for one side or the other.. Just explaining that.. without a contract that is specific about the details.. it could go either way in court. Hopefully the judge is happy with his Crestron system :).