It used to be that software had a “hard” component: if you wanted to install it, you had to unwrap it, take it out of the box and slide a disc into a drive.
These days, all most software installations require of users is that they check that infamous little “I Agree” box and they’re in business. And in many cases, the ensuing upgrades don’t even require that; we simply program our devices to update applications automatically. Sometimes we’re not even aware that an update has taken place.
On a personal level, or even for micro-businesses, this rarely raises any issues. The number of applications that are running are generally limited in number and customizations, rendering it difficult to break software-licensing agreements. It’s a little different, however, for systems contractors— especially as the technologies they integrate are increasingly less about black boxes and more about software. Ask yourself: are you sure you are following all of those clauses in the licensing agreements that you have signed?
Cliff Ennico, a Fairfield, CT-based contracts lawyer and author of Small Business Survival Guide advises his clients to look for several words under what is generally titled the ‘Grant of License’ clause in software licensing agreements: ‘perpetual’ and ‘royalty-free’. “‘Perpetual’ and ‘royalty-free’ means that once you pay up front for the license, you don’t have to pay any more money for that license,” he said.
However, software updates may present potential licensing issues, noted Chuck Wilson, executive director of NSCA. “You might have renewed that [original] agreement three or four times just by signing a quick little one-page agreement, but in the meantime they have sent out software updates and things that have a new provisional licensing agreement that’s in the download,” he said, referring to that ‘I Agree’ checkbox. The problem is, the licensing associated with the new update may be significantly different from that which you signed when you first took on the new line.
What complicates matters is that the manufacturers that are selling this software aren’t always the original software developers— they contracted a third party to write the code. “What happens is, the manufacturer agrees to something with that original developer, and then we’re third party to that, and then we incorporate that into one of our integrated systems and then sell that to the end user,” Wilson illustrated. This doesn’t always give the integrator the right to sell that software, however; they’re just permitted to license it. “And then we find out that it wasn’t even ours to offer to them in the first place.”
As the cloud houses an increasing number of software applications, Wilson urged integrators to seek out what contractual surprises lay within. “With anything that exists somewhere else other than on site, there are generally some new software licensing agreements,” he said. “Sometimes those agreements are different than the [contracts for] the software that’s resident on a server at an end-user facility.”
What’s perhaps most challenging is that there are no standard software licensing agreements. Each one is slightly different, requiring systems contractors to remain on top of whether or not they are playing by the rules. Wilson encouraged integrators to pay attention to the fine print, and to conduct annual audits of all of your software licensing agreements to ensure that you aren’t breaking any clauses—especially as they pertain to remotely hosted applications, and what you have the right to sell.
He also noted that the NSCA offers guidance and best practices for managing software licenses.
Carolyn Heinze is a freelance writer/editor.
Issue Your Approval
Many companies issue lists to their employees detailing what software they can use while at work to avoid issues surrounding pirated software, or software that they don’t have the right to use company-wide. Chuck Wilson, NSCA executive director, urges systems contractors to do the same within their own organizations. “Watch for this whole BYOD movement and have a policy against any kind of pirated software or any software that you download for free as it relates to the customer that you’re serving,” he said. “In other words, the customer—your client—may have a policy about what software is approved and not approved to be used at their facility. You should make sure that your company, in support of the systems you provided, has a similar policy to that.” —C.H.
Compilation Claims
One area that raises differing opinions is how AV integrators should treat their own intellectual property— programming codes that they have developed in-house or contracted out. Should you turn it over to the end user? Should you license it to them? What if you hired a third party to write the code—how does that work? And, if you’re customizing existing software developed by another company, do you really own that new code? “In most software licenses, the original software developer includes that if there are any upgrades, modifications or improvements to the software itself, they can claim ownership,” Wilson said. Thinking about declaring ownership of an upgrade to a Microsoft component of that control system you’re installing? Better read your contract first.
Steve Greenblatt, founder and president of Control Concepts in Fair Lawn, NJ, noted that providing control system source code as part of the close-out documentation is not only a best practice, but a common practice—provided that the terms of the agreement state what will be provided and what will not, along with the terms under which it may be used. “Typically, these terms state that the source code is being provided for usage in a particular system, site, or customer, and that it may not be reused in whole or in part without consent of the provider,” he explained.
He added that some agreements state that the client may have unlimited use of the source code, but that an additional charge for this should apply. Where this gets tricky is that when a client is provided ownership of the source code, the author of the program is then held liable to the terms of a software agreement in reverse. “In other words, they would not be able to reuse or resell any or all of the code without the permission of the client.”
Greenblatt goes on to point out that the most significant development he is currently experiencing is that the discussion around source code has now expanded beyond the traditional, uncompiled program and associated files—such as modules including files and IR codes—that are required for modification and recompiling. “It now includes whether the source code for the modules should be unlocked and available for modification,” he noted. —C.H.
