Who Owns the Code? CE Industry’s Dirty Little Secret

You’re programming each job from scratch because you are worried about some other programmer seeing the stable, extensible, mature framework you developed to base your programming on?  You’re limiting client functionality because you are worried about some other programmer seeing your code?  Seriously?

Why not tie the code to the mac address of the processor so it will only run on that single processor?  Why not license the code and have it report back if its being used on more than one project?

The reality is that consumers can be left empty-handed when something happens to the original programmer.

They need to be assured that—whatever happens, and assuming they’re paid up—there is a way that someone else can take over the system. That might just be the core functionality, and not necessarily some of the bells and whistles and graphics.

As mentioned, the customer may have to pay for it at the end, have it put in escrow, whatever.

Consumers should be educated about the issue so they can address it up front with their (prospective) integrators…before it’s too late.

ej said - Why not tie the code to the mac address of the processor so it will only run on that single processor?

That represents the same problem. If the integrator closes shop and the processor has to be replaced due to failure the uncompiled code is useless because the of the new MAC address.

If a Crestron programmer develops custom modules for a project, they can be locked to protect the programmers intelectual property. This will make the code secure but still allow changes due to system upgrades.

Julie, I must say that even though we do not agree on everything you have written for CEPro, I have to give you a large amount of credit for touching on such a powerfull subject with a “Fair and Balanced” article. Well done!

Julie-

When a company goes out of business, typically it doesn’t go out on its own terms.  It often leaves behind a wake of unfinished business, out of work employees, and end of benefits for these employees as well as a lack of support for their former customers.  In addition to the programming code, I’m sure clients are missing the wiring diagram information for their homes as well. Another integrator would have to tone out wires and redocument everything that was previously run.  We’ve had to do that 100’s of times.  It is a cost that unfortunately the end consumer pays for one way or another. 

Crestron and AMX wash there hands from responsibility in the programming issue though they created the problem with their system architecture.  Once the bankers and lawyers get involved they only see this as a way to generate money from a bad situation. 

I’m sure no one at Baumeister or any other CI firm wants to close their doors and irritate their former clients.  Unless the manufacturers make the programming up and down loadable this problem will persist.  Even if clients were given the program, they could lose it or corrupt it or not have the most current version, all of which cause problems.  I dont believe the integrator should be hung out to dry here.

Guy—those are great comments, thank you.

This is why, I believe, software escrow is a great idea. Charge clients a monthly/quarterly fee to ensure that all of their programming is automatically backed up and held by a trusted third party.

When a co. goes chapter 11, naturally the trustees want to sell every asset they can, including code, schematics, etc. Can’t blame them.

This is why consumers need to be guaranteed access to that stuff as soon as they’re paid up.

Julie
Crestron should end this and step up, buy the codes, and give them to their customers for the price of a CD!!!!!!!!!!!!!!!!!!!!!!!!

After reading the article and comments, it seems like there is some confusion or misinterpetation of contractual obligations and deliverables.

In order to better explain my point of view, I would like to take a real-life example from software development industry. Some of my points were already mentioned here, but I wanted to group them all together:

-When you purchase a shelf software, such as Office, you don’t get the source code. Actually if you read the license agreement, you will see that you purchased a license to use the software but not an ownership of the software. The IP in this case belongs to the creator of the software.

-When you hire a software development company to custom develop an application for your company, for example, a Flash application for your web site, you pay for their knowledge, labor and a compiled product that will allow you to perform your business actions the way you wanted. Unless you negotiated a separate price for the source code, you will not be entitled to get the code and your will be held “hostage” by the company. If the developer decide to give it to you, it his/her prerogative and you can decide to not hire them if this is an issue

-The scripts that were created by the integrator in the article, even if they were compiled, are not falling under “software code”. they are scripts, just like HTML, PHP, JavaScript etc.. and as such, they should have be given to the customers upon completion of project and payment.
In the software industry, we often include some proprietary libraries that we developed on our own with the software we developed for the customer. These are called common libraries that we re-use in every application we develop and by all means, the customer is not entitled for the source code of these libraries, even if he/she is entitled for the source code of the application that was developed for him/her.

-Just because a company is going out of business and is trying to capitalize on its assets - which some of them are the source code of their clients, doesn’t mean they should be automatically be considered evil or wrong. In the case mentioned in the article, it looks like the company owned every single right on the code and is entitled to sell the code in order to cover some of its debt.

-Whoever buys the source code is not going to automatically be able to access the entire system of all customers. In fact, they may find themselves with unprofitable investment if the home owners decide to scrap the control system and start from scratch because they don’t want to get involved with this.

Just my 2 cents…

-E

Julie, 

Can you please do an investigative piece on the ring of gypsy code bandits that go to home’s diguised as telephone repairmen and covertly steal code from processors using zigbee and wi-fi code snatchers.

I here this band of code pirates are reselling the intellectual property of other integrators to gypsy programmers on RC CENTRAL and IP Forum for big money.

Please uncover this piracy before they move to e-bay for redistribution of this code stolen from the home’s of unsuspecting and innocent consumers!

Speaking of the “Right Thing To Do”, Jack Goldberg nailed it down (above)!!!

Eyal-
It is quite possible that the buyer has every intention of doing this very thing. Here’s your code, do what you want with it, but let me tell you why you should do business with us…

Kevin - you made my day

Hey - times are tough! right?!

Let’s not forget that crestron code is comprised of a whole host of file types; graphics
, SIMPL files, SIMPL+ files, ir drivers, etc….

Any module worth anyhting is written in simpl+, which can be password protected,
Irrespective of the main program.

Everyone should be backing up the files on in-house servers,
CF cards in the processors, off-site servers; wherever.

Then, we can freely disperse the code to our clients, all the while
Protecting our intellectual property by password protecting our Simpl+ files.

OHHH NOOOOO Barry, those gypsy code pirates have ALL the password hacking tools, the world is not safe!  Run you programs on this new ultra secure home automation processor from CRESTRAMX http://news.cnet.com/2300-11386_3-6222398-1.html

We will once again be safe to leave behind the valuable code

Julie,

I have contact the folks in Switzerland and the Nobel is being Fed Ex’ed to you today.  Congrats!

I remember being on a panel at CEDIA and when this topic came up the panelists almost came to blows.  To be clear, I am of the belief that the customer owns the code once it is paid for.  In fact, I am of the belief that back-up copies should be burned to disks and handed to the customer as part of the job close.

After that, if a customer chooses to not do business with the integration company, it is likely because of dissatisfaction.  I base that assumption on my experience that if they were satisfied, they would still be dealing with you.

In the event that they are dissatisfied and are leaving…what possible gain is there in “holding” the code…they aren’t going to stay with you…they aren’t going to say nice things about you….you aren’t going to make money from future contracts with them….lose/lose for everyone involved.

Client pays, client owns…..would be an easy rule of thumb to follow.

At the very least, at LEAST be explicit with the client up front about what the ownership of this code means and who will own it.  That would allow clients to make informed decisions about who they do business with.

Hint: For those of you selling against companies that still hold the code, it is the easiest way to secure the business with the client. Just fully explain the situation, your policy, your competitor’s policy…and watch how quickly they sign with the company that is doing the right thing.