By: Josh Srago and Tim Albright
This is AVNation’s second contribution to the EFF’s Copyright week
There are copyright laws for written works, art, film, and music. When it comes to figuring out who owns code that controls your automation system, the laws, and rules are murky at best. This is a question that is often debated at great length by developers and firms providing the services, but let’s take a look at why there’s so much confusion as to who owns the code.
Diversified Control Code
Code development, in the integration and automation fields, starts with the manufacturer. These companies make a product that requires some form of customized programming. Due to the fact that not everyone wants to set up their home or corporate solutions in the same way, they have each developed software that allows for integration firms or end users to customize the way a system responds and the user interface on any touch control surface.
In order to customize the solution to meet the desired end game, the programmer on a project look at all the connected source devices (Blu-ray player, Xbox, Playstation, 5.1 surround sound receiver, etc.) and output destinations (TV, 5.1 surround sound receiver, home audio system, etc.) using the manufacturer’s proprietary software to make these pieces work together. Honeywell, Trane, Crestron, Control4, AMX, and many others provide software, typically free of charge to their dealers, resellers, and partners to create the customized user interfaces. The manufacturers have a copyright on this software.
However, since the manufactures providing the control system and associated software suite do not always provide every single input and output device in a system that means that the other manufacturers of these products must also provide a certain amount of proprietary command code that will work with each of the proprietary software suites from the control system manufacturers. This is true whether you are talking to the devices through infra-red (IR), RS-232, IP, or CEC. The end point manufacturers create the specific commands for things like power on, switch inputs, and raise and lower volume.
To get all of these disparate devices working in symphony you needed a person who spent a number of years to learning how to do so using best practices in user interface and code writing. These programmers have tricks they have picked up from others and probably lines of code that have been used in countless other installations and will be used in more. You hire them for this code and probably feel you should own this code.
The long debate over who, ultimately, owns the control programming code after the completion of an integration project is well documented with people falling on all sides. Some believe that the end user that paid for the project owns the code. Others will state that the integration firm that provided the customized solution owns the copyright to the customized code but are licensing it to the end user as a part of the contract. Still others would argue that this is a work-for-hire scenario with the ownership starting with the end user and transferring back to the company that provided the customized programming at a later date. The issue is that there is no standardization for who controls the copyright to these customized solutions.
New Landscape of APIs
The new world of the Internet of Things (IoT) is only going to make this increasingly more complex and convoluted. The communication method in an IoT environment is predominantly IP based. The central interface device that is controlling people’s homes has shifted to a voice controlled interface provided by the likes of Amazon, Google, Samsung, or even independently developed. It is no longer about just controlling other devices from a central system, but rather having your environment interact with itself. Walking in and telling the room to, “turn on sports,” to have the lights dim, the tv turn on, and already have the cable/satellite receiver tuned to your favorite sports channel is similar to macros but with improved interaction between the devices.
All of these network connected appliances and devices that litter your home and are beginning to permeate your office have APIs (application programming interfaces). These APIs are hooks into and out of network products and are also proprietary to the companies that developed them. Amazon owns the API to integrate the Echo. Other IoT manufacturers like Nest, Sonos, and own their APIs.
In the music industry there’s a circumstance of the “poor man’s copyright” wherein the songwriter will take their latest track (recorded, written down, or both) put it in a sealed envelope and mail it to themselves. The postmark on the envelope becomes their proof as to when this song was created. The currently copyright laws that we have are based on physical works, not digital ones. Sure, a person can do a similar thing by emailing a file to themselves and getting the timestamp of when it was created, but that’s not an official copyright. That requires submitting it and getting approval for the unique nature of the information. Given that the same outcome can be achieved through code in many different ways, and is always evolving, how will we be able to determine who owns the copyright on code as more and more network devices require APIs?
In just searching for how to interconnect an IoT device with Alexa, you may find 15 different suggestions. Each of them has been proven to work by the person kind enough to put the code out there, free for your use. You find the one you like most, but your device is a newer generation than the one the which the code had been written for. You modify the code slightly to get the operation that you desire. So, do you own the copyright to this new code?
Change Must Come or the Courts Will Be Busy
This was a similar question that came up during the court case where Oracle sued Google over the use of the Java open API platform. Oracle put the open platform out there for developers to create things but never envisioned that it might get utilized on such a large scale platform worth so many billions of dollars and they wanted their cut. Ultimately, the Court (in the first round) sided with Google.
The massive push on teaching younger and younger kids to code in our society is an amazing and wonderful thing because it allows them to create and teaches them critical thinking and problem solving. However, it also means that at some point we’re going to reach a critical mass of people creating interactive hooks for their automation and control systems with no fundamental way to protect those out there that are creating the source code.
Without copyright reform to reflect this new form of speech, we are looking at the ongoing possibility of lawsuits that never end and a stifling of creativity of the next generation of developers unless they freely enter the sharing economy. But even if they do, who is to say that wonderful programmer that put the code up online for you to automate your latest device into your voice controlled system was legally allowed to do so?
By: Josh Srago and Tim Albright