Let me start by saying that I know this blog is going to draw criticism from both sides. This is a long standing argument in the AV community, one that has yet to be universally agreed upon, and I’m certain this piece will NOT change that fact. There will still be people who fall on both sides of this argument, but perhaps at the end of this you will either understand the issue better, or potentially even jump from one side to the other.

First, let’s define what code we are talking about. When we ask “who owns the code?”, typically we are talking about the code for the control system we use to control our installed AV systems. When we ask “who” owns the code, I think we generally agree the programmer, being an employee of a company, does NOT own the code. Where we disagree is whether that code is owned by the integrator or whether that code is owned by the end user who paid for the AV system and its corresponding hardware, programming, and installation.

Some integrators claim the code is “my Intellectual Property” or “my IP,” while others assert that the end user should get everything required to maintain the system as part of their purchase.

First I’d like to explore the concept of “my IP.” Is this code actually copyrighted by the sheer fact that it was written by the integrator? To answer this we have to look at a couple factors.

First, in general, a copyright is “a property right that springs into existence when a sufficiently creative idea is reduced into or onto a tangible medium.” –Hawley Troxell

By this measure code, meets the copyright standard. Some of you are saying: case closed. Not so fast.

Let’s quickly think about a piece of code for an AV control system. First the code is written in a language like C+, Java, Simpl, etc. and the control system manufacturer lays out the rules by which this language can be used in their systems. Secondly, the code includes what I will call “industry code” from manufacturers that includes all the commands needed to execute operations on those devices. Thirdly, there is “operational code” that creates an execution of, combination of, and transition between those “industry codes” to operate the system. Finally there is code that pertains to the GUI or the look and feel of the interface.

Can the integrator lay copyright claim to all of these types of code individually?

Programming Language: This language itself already has a copyright owner. A programmer using common instruction sets from a programming language really hasn’t exhibited a “creative idea” at this point, and would have no more claim to a copyright on that than I would on the English language because I wrote this blog using it.

Industry Code:  This code typically already has been written by someone else. Many times the control system manufacturer even manages a library of these code sets for their programmers to use. Given this, the integrator would have no copyright claim to this piece of the code. As an exception, sometimes this code DOES NOT exist and must be written. We will tackle that soon.

Operational Code: This is where the integrator strings operations together utilizing both the programming language and the Industry Code above. This part of the code is at least reasonably able to be claimed as “my IP.” We will return to all this later.

GUI Code:  Many times, the GUI is created from an existing template provided by the control system manufacturer or a third party. In those instances, the copyright actually resides with them and not the integrator. An integrator may claim that their arrangement of those items within the template is still “my IP” and we will also revisit that shortly. However, if the integrator creates a custom GUI with new graphics and objects, that would definitely be their IP, no argument there.

Alright, so let’s come back to operational code and arrangement of items in an existing GUI template as potential IP. In order to accurately assess this, we may have to look past copyright in general. This really comes down to if the assembly of existing parts in a particular order is protect-able.

There is a great scene in Flash of Genius when Ford’s attorney asks Robert Kearns if he invented any of the parts within his intermittent windshield wiper circuit. He answers no on all counts. Under cross examination, his own attorney asks him which of the words in his plays Shakespeare created. Again the answer was none, and the attorney asserted it was in fact the order of the words that made them unique and not the words themselves.

By this test alone ,it would seem operational code and GUI arrangement is IP, but the U.S. Supreme Court may see that differently.

In 2007, “the Supreme Court decided that when elements, techniques, items, or devices are combined, united or arranged, and when, in combination, each item performs the function it was designed to perform, the resulting combination — something the court called “ordinary innovation” — is not patentable. This can be true even if there is no teaching, suggestion, or motivation to make the combination.” (1)

In other words, a new control module not in the existing library for a piece of equipment, operational code, and GUI arrangement are most likely “ordinary innovation”, not IP. These are no more an original work than copying 10 pages from 10 different books and binding them all together. Kearns’ situation was different in that he combined parts not previously combined to perform a new function not performed before.

Given all this, the only part of the control code that can realistically be called IP is custom GUI code.  Now this could be a GUI that the integrator built and uses across several clients and projects, or it could be one created specifically for the client at hand.

In both cases, it seems that the problem is that there is no practical way to provide the end user a file that includes the industry and operational code (not IP) while excluding the custom GUI code (IP).

The interesting shift in the conversation here is that most integrators I have spoken with about this, actually don’t care too much if the customer has the code or not. They typically can’t do anything with it on their own. They don’t have the hardware or the skill-set to use it to launch internal DIY efforts and circumvent the integrator in the future.

The main concern seems to be that it will wind up in the hands of their competitors. The client may hire someone else next time, and if the customer has the code, they can hand it to the new firm who can then utilize it in future rooms as well as other jobs. (In the majority of cases, a large chunk of the code needs to be redone each time anyway to adjust for different components and room functionality).

So what is an honest integrator to do to protect the work they’ve done?

All of the following solutions require the integrator to do one thing they may not typically do. Have a conversation with the client at the beginning of the job specifically about code ownership.

My problem with the whole “who owns the code?” conversation is that in my experience, the client rarely knows that he won’t get the code as part of the project, that the code can’t be pulled from his system by another authorized dealer and that without the code, only the original firm can ever work on the system to maintain or upgrade it. In short, the customer is getting less than what he thought he was getting.

I’d never buy a car that could only be fixed at the dealership I bought it from.

By having a conversation up front about code ownership, the integrator and the client can come to a common agreement and appropriate price structure based on what code they want to own.

The code can be defined specifically as “work made for hire” meaning the end user owns it and pays the associated cost. Any client specific GUI should be done this way in my opinion, as it can’t be leveraged elsewhere anyway.

The integrator could provide a licensing agreement that defines how the code can be used. This would allow the end user to own the code, but also pay a per-device fee for its use. This is helpful when the integrator has invested in developing an in house custom GUI they want to leverage across multiple jobs, as they can offset the development cost through licensing per system.

The integrator could relate they never sell their code and allow the end user to decide up front if they are comfortable with the arrangement. In this case, it would be ethical to include a clause that says if the integrator goes out of business, they will relinquish the code to the client at that time.

The integrator should also include contractual language to the effect that the GUI used in the system is their copyrighted IP and cannot be reused elsewhere.

Conclusions?

If you are providing systems with custom GUI code then you do really have IP. Have the code discussion up front. Define the client’s wants and needs and price them accordingly. If there is additional work being done specifically for this client that will never be leveraged anywhere else, define it as a work made for hire, charge accordingly and relinquish the code to the end user as part of the close out package.

If you are providing a control system from a manufacturer programmed in their language, using existing industry code, and utilizing an existing GUI template, I would assert that by the standards above, no IP has been created here. The only reason to not include the code as part of the project in this case would be to maintain an unfair advantage on the customer in case they try to hire another integrator later. (If you disagree, there is a comments section below, so fire away).

Systems that implement wholly new ways of doing things or combine things in ways that are not obvious, logical extensions of existing arrangements would also be an exception.

So who owns the code? Well possession is nine-tenths of the law so if the integrator chooses not to release it as part of the project, that is ultimately up to them.

From an IP standpoint, most of the code is likely not protect-able as the integrator’s IP, either in its written form or methodology, so there is really no reason not to include it as part of the project. In the rare cases that the system GUI is completely custom, IP claims are justifiable. In all cases, a code discussion should be had with the end user up front to set proper expectations for what will and will not be included, and if done properly, the appropriate pricing can be assigned to that agreement as well.

References:

1. Combination Inventions
2. Who Owns the Source Code?