July 1997 If You Build It, Will You Own It?

Interesting idea, ownership. We are accustomed to the concept of "make it, own it." When you take raw materials and create something of value, you naturally want to own it. That's why there is a Patent Office and a Copyright Office, isn't it? But do you own it? As Systems Integrators, you are involved in many projects where the assembly of components - hardware, software, combinations of the two - creates a new system. It is understood that we don't "own" the wire and switches, sensors and PLCs we buy from suppliers and install at customers' sites. The act of purchasing those components gives us no right to replicate them in violation of the patents and copyrights held by the developers. SIs are in the position of creating new systems from existing products without the results being, really, a new product itself. Let's look at how the "solution assembly" concept is handled elsewhere. Open a desktop computer - most of us have at one time or another - and what you see is a collection of components that were made by companies other than the computer assembler. Whether resistors, chips, diodes, capacitors, processor, the case or the circuit boards, few computer companies do more than assemble the end product. Some design and even manufacture their own processor chips (Sun Microsystems' SPARC, Digital's Alpha) although most chip designers (Intel, AMD, Cyrix) are not in the mass produced computer business. They don't compete with their customers, although Intel comes close sometimes. So what do these assemblers really "own" in the boxes they produce? They can, and often do, try to copyright the design of the board's circuitry - the electronic paths. Apple has been successful in closing their Macintosh from infringement, not in regard to the components or their relationships, but from the standpoint of their firmware and programmed logic. This is where one comes to the concept of "intellectual property" and that is where we start looking at how SIs can protect themselves from being "ripped off." Yours, Mine, Ours As a writer, I supply my publishers with words on paper or disk. I neither invent the words (OK, sometimes I do, but that's not the issue here) nor create the paper or disk they are delivered on. My contribution is the order of those words, and the ideas and concepts behind that order. Like me, an SI strings existing elements in a particular order to create something that accomplishes the goal. Like me, that goal is usually established by the customer. Whether it's a publisher or a manufacturer, we are working to satisfy someone else. When I present my golden words to the publisher, and they get printed, the copyright to those words, in that order, conveying that idea or concept becomes the publisher's. Why? Because they were written "on assignment" or, in the legal terminology, they were "Work for Hire." On the other hand, I often have a few minutes spare time when the muse strikes and I create a piece that no one asked for. Then I try to get it published, sell it, give it away, whatever I can to get it off my desk and into the real world. But this time, I own it and I can do whatever I want with it. I hold the copyright, a factor of creating that linkage of words. I can license that piece to as many publishers as I want - or can find willing to print it - and collect each time it is used. If my basic building blocks are words, the basic building blocks of factory automation are simple things like wire and connectors that join PLCs and PCs. Those PCs and PLCs are connected by software, too, however. The SI's real value added is usually in creating the software connection so the whole thing works. Works right. Works all the time. And keeps on working long after the SI leaves. But as we all know, once your foot is out the door, the customer wants a change, right? Calls you back, "Make this do that, that do this, those things do these things." Or, you don't get a call back, just a note, "Please forward the code you wrote so we can modify it, change it, improve it, replicate it, propagate it, sell it and make our money back from it." OK, few clients will be so honest, but many still ask for the source code or logic. One we heard of felt that once the code was implemented, "improving it" could be handled by a high school graduate with no experience but computer literacy. I hope I don't tour that factory soon. SIs are in much the same boat as writers. When you create a program, in Visual Basic, C++, COBOL or ladder logic to make an automation project work, that is intellectual property - the code - and can be considered in much the same way as my words. If you do it for someone as an assignment, they probably own it. If you do it on your own - to develop a spec system, for example - it is yours to license, give away, sell or whatever. But nothing is forever and not much is protected by assumption. Building blocks are fine but they need a strong foundation. For the SI, like the writer, that foundation starts with a good, strong contract. "We don't want anything to do with that legal stuff," you respond. "That's not where we put our efforts." Too bad; see you in court. All eyes and ears The following are some of the online comments made by SIs and automation professionals discussing their experiences with customers who want more than just a job well done. It all started with William Irish ([email protected]