Ethical ownership and proprietary OEM

[Rick Densing]

It appears obvious that all answers are correct here. It depends.
If I were Mike, there is no way I would want anyone in my program.

As an OEM of special equipment, there is only so much you can do for a customer in the development phase. A lot of times, the customers doesn't really know what they want until they live with it.

Every machine we ship, I learn something new and try to incorporate it into the next.

I have one customer that has a transfer line that is producing at about %50 above the designed rate. All because of the customer's efforts. No knock on the machine's builder- they built to spec'ed rate, but fortunately for the customer their volumes increased dramatically. That kind of tweaking is much easier for someone who lives with the process every day.

 

[Tom Jenkins]

I'm an OEM.

I recognize that there are a lot of legitimate reasons for an end user to want access to my logic. I also have a legitimate concern about protecting logic and techniques that took me years to figure out. I don't need to give my erstwhile competitors my technology on a silver platter so they can eat my lunch!


I have arrived at a compromise that I feel is fair to all parties. I give my documented source code to customers on request, but only after I have received a single system license agreement from the owner that does several things. It gives them access to the entire program. It protects me from any responsibility for the system if they make any changes. It keeps me from having to go in and restore the original program if they meddle with it. It restricts this code to a single system and prohibits them from copying it or using it on any other machine without my permission. It allows them access to the logic without any passwords. It requires them to have any third party system integrators or subcontractors read the license and agree to its terms before they can give them access to the PLC.

It isn't perfect, but it puts everyone on notice that there is protected intellectual property involved and they should respect it. It also keeps them from feeling they are out of luck if I get hit by a truck, and lets them know I don't intend to hold them for ransom if the system needs modifications. I can still be "robbed" I suppose, but in twenty years this hasn't happened, and I feel it is a fair solution.

 

[MartB]

Ok, my companys stand is that when we supply a machine everything is unlocked. The customer signs an agreement that any changes to the plc, hmi, robot or anything else are their responsibility and they are held fully responsible for the consequences. We back up all code when we've finished the installation and leave a copy with the customer. We keep a copy in a firesafe as our archive.
To this date I have only ever visited one of our customers that has been brave enough to have changed anything (small portion of plc code). 99% of our customers will call us to make the changes for them, or at least ask us if it's ok and what the consequences might be.
It seems that when you make someone totally responsible, they stop and think before tinkering.

 

[Oakley]

I've been on both sides of the issue. My take is this ...

If a machine is purchased and installed as cots, then the system can and should be protected.

If a machine is custom built then the system should be the owners - unprotected with owner as responsible party in all matters.

If an end user demands the code (for any system) to be unprotected, then Tom's method is appropriate - gets the issues out on the table and agreed upon upfront. This document would be key in any legal issues.

 

[Stephen Luft]

There are a few different perspectives that have been brought up.

1. Adding additional features and functionality to a machine
2. Troubleshooting a problem
3. The OEM's perspective.

Let's deal with them one at a time...even though some issues will cross over.

There are obviously several issues with modifying a machine, whether new or existing. Any modifications should be discussed with the OEM. Whether you have the code or not, the OEM still knows their equipment better than anyone else. Maybe there is a reason why they didn't incorporate a certain feature.

Troubleshooting of equipment can be done without a program. It is called documentation. Some documentation is better than others. A ladder program will not tell you if an output device is bad. If the OEM has alarm conditions and faults programmed in with an annunciator light or operator interface that will typically provide maintenance with the information they require to fix a problem. (keeping in mind this is a very basic example) Once the system is installed and tested, there should be little reason that someone would have to access a ladder file to determine a fault with the system.

When one has to look at ladder code of a machine, then the code was either not written properly, they want to bypass a certain function or completely change a routine. Changing the original intention without involving the OEM, can cause more problems than it solves.

From the OEM's perspective, Tom brings up some of the points I would have addressed.

Why on earth would someone who spent countless hours to develop their code want to make it available to anyone for free. When you are purchasing a product, you are not buying the right to use the code...the code is part of the equipment you are purchasing. When you purchase a computer, do you get the source code to the operating system? The PLC program is the operating system for the machine...it is what makes it work. When you purchase a PLC and software, do you get the source code for the controller? I don't think so. You get documentation that tells you how it works.

Is it within anyone's right to demand something...in order for the priviledge of doing business...yes. However, it is also the OEM's right to protect their intellectual property. If they choose to provide their code, it should be up to them...not demanded by the customer as a condition of sale. (See the examples above) Customer spec. is bad enough for many integrators who want to do business with certain companies. I can even understand some of the rational behind it...that is the customer's right.

We offer our OEM customer's an alternative to dealing with customer specifications. Many have used our suggestions with success. They don't have to worry about their code being copied, modified or tampered with. No one can get into the controller to make the changes, even if they have our software. We give the OEM control over their equipment design. The customer is no worse off. Reason being, they are buying our customer's equipment. We are merely a component.

We had a recent situation whereby a customer's controller locked up and the program needed to be downloaded. The integrator sent him the program for download. The customer downloaded the program and the scan light continued to flash. We had them send us the program to review. What had happened when the customer opened the program to compile and download, they inadvertantly added a branch down with no contact, thus corrupting the program.

When you give something as important as a program, you are creating the potential for problems.

As a ePLC manufacturer, we even get calls from people servicing equipment with our products installed. They will call us up expecting to obtain a program, source code or schematic for the equipment (or our controller) they are servicing. We have to explain who we are and that they have to go back to the OEM for support. Let's see Allen Bradley or Siemans do that for their customers.

If you are not aware of what I am talking about, we have two articles posted on our web site, explaining what we do for our customers.

www.entertron.com/oem.htm
www.entertron.com/info.htm

I would consider myself to be biased, because my customers are not the end customer but the OEM.

FYI...if the OEM is out of business, we have and will support the end customer to the best of our abilities with what is available to us.

Perspective from a manufacturer.

God Bless,

 

[kamenges]

This is a very loose generalization but I would put OEMs into two broad classifications. There are full custom equipment OEMs who manufacture one-off equipment to detailed customer specifications. Then there are OEMs who have an established product and the customer basically buys to a spec established by the OEM. I have worked for both and feel differently based on which class we are referring to.

The 'standard equipment' OEMs spend significant resources on product development. The company I used to work for spends tens of man-years ANNUALLY on raw R&D and product development. This cost is only recovered if future machines can be sold on the merits of these developments. The only way these developments have merit is if no one else can provide them. To a large degree this software was protected for intelectual reasons. To a lesser degree it was a field service training issue. As stated earlier downtime is very expensive. By keeping the code locked field service techs had a better chance of finding what they were looking for more quickly. They also didn't have to worry about finding a modification that may or may not be there and then determining whether that modification was an issue.

I currently work for a full custom OEM. We take detailed customer specs and build machines off of these. We typically have alot of customer input in the design phase. In this case we release all software unlocked to the customer on project completion. Since our machines get maybe a month of internal runtime we understand that there may be issues that we don't immediately catch or fucntions the customer may want after install. We don't do any raw R&D. Everything we do is dedicated to a specific job. So everything we do is paid for by a specific customer, not spead across the next 100 customers. In this case the customer should have full access to everything. We didn't give them anything that they didn't pay for directly. And they will ultimately know the machine and process better than we ever will.

I like Tom's idea in the abstract. However, not being a lawyer, I don't know how solid it is. In reality, since Tom has never been tested on it, I don't think he knows for sure. The courts can be oddly fickle where intellectual property is concerned. I think Tom's track record with his policy may be more a testiment to his dedication to his customers and customer relation skills than it is due to the power of his documentation.

Keith

 

[elevmike]

I like Tom's idea in the abstract. However, not being a lawyer, I don't know how solid it is. In reality, since Tom has never been tested on it, I don't think he knows for sure. The courts can be oddly fickle where intellectual property is concerned. I think Tom's track record with his policy may be more a testiment to his dedication to his customers and customer relation skills than it is due to the power of his documentation.

Warren A. Bechtel is often quoted as saying "When you can’t trust a man’s word you can’t trust his signature." With that in mind Keith is right dead on; Toms relationships with his customers are really what's protecting his intellectual property, and not his contract.

 

[Tom Jenkins]

Warren A. Bechtel is often quoted as saying "When you can’t trust a man’s word you can’t trust his signature." With that in mind Keith is right dead on; Toms relationships with his customers are really what's protecting his intellectual property, and not his contract.

You guys are right, of course. The big advantage to the license (since I don't want to ever sue anyone anyway!) is that it makes sure everybody knows that this is not public domain technology that they can run away with for their own purposes. Most people, when they know there is a legitimate concern, honor it.

You can't completely stop the crooks no matter what you do.

 

[monkeyhead]

It seems that when you make someone totally responsible, they stop and think before tinkering.

We actually maintain a controls group in our business. Even though i'm the only controls guy at my site, I'm the Jr. member of that group which spans our entire distribution network. Our company rarely ever calls for outside help. So my behaviour isn't rebellious or maverick in any sense. It's encouraged and expected.

I can't remember the last time we called in an OEM to fix something for us.